AWS ソリューションアーキテクト – アソシエイト学習サイト CP 学習サイトへ戻る

Kinesis（ストリーミング）

Amazon Kinesis は、クリックの記録、センサーの値、アプリのログのように絶え間なく流れてくるデータ（ストリーミングデータ）を、リアルタイムに受け取って処理するためのサービス群です。SAA では、Kinesis Data Streams と Amazon Data Firehose の使い分け、シャードの考え方、取り込み後の変換・保存先の選び方がよく問われます。

ひとことで言うと: Kinesis Data Streams は「流れ続けるデータを一定期間ためておくベルトコンベア」、Data Firehose は「集めたデータを自動で倉庫へ運ぶ配送便」です。

たとえるなら、Data Streams は録画機能付きの生中継で、複数の人が同時に見られ、保持期間内なら巻き戻して見直せます。Firehose は、荷物をある程度まとめてから決まった倉庫（S3 など）へ届ける定期便です。

このページで押さえる論点

ストリーミングデータとは

バッチ処理は、1 日分のデータをためてから夜間にまとめて処理するような方式です。これに対しストリーミング処理は、データが発生したそばから数秒以内に受け取り、処理します。「不正な取引を即座に検知したい」「Web サイトの今のアクセス状況をダッシュボードに表示したい」といった要件がストリーミングの出番です。

SAA の試験ガイドでは、タスク「高パフォーマンスなデータ取り込みと変換のソリューションを選択する」の中で「データ取り込みパターン（頻度など）」「ストリーミングデータサービスの適切なユースケース（Amazon Kinesis など）」「データストリーミングアーキテクチャを設計する」「データの形式を変換する（.csv から .parquet など）」が挙がっています。対象サービスには Amazon Kinesis、Amazon Data Firehose、Amazon Kinesis Video Streams が含まれます。

Kinesis Data Streams の仕組み

データを送る側をプロデューサー（アプリ、IoT デバイス、Kinesis Agent など）、読み取って処理する側をコンシューマー（Lambda、EC2 上のアプリ、Firehose、Flink など）と呼びます。送られる 1 件 1 件のデータをレコードと呼びます。

項目値試験での使いどころ
書き込み（シャードあたり）最大 1 MB/秒 または 1,000 レコード/秒書き込みが上限を超えるとスロットリング（ProvisionedThroughputExceeded）。シャードを増やす
読み取り（シャードあたり）最大 2 MB/秒（共有。拡張ファンアウトはコンシューマーごとに 2 MB/秒）コンシューマーが多いと読み取りが足りなくなる → 拡張ファンアウト
保持期間既定 24 時間、最大 365 日（8,760 時間）「過去 7 日分を読み直したい」なら保持期間を延ばす
レコードの最大サイズ10 MiB（base64 エンコード前のデータ部分）それを超えるデータは S3 に置き、ストリームには参照を送る

SQS と同じく送る側と受ける側を疎結合にしますが、SQS は「1 件を 1 つのコンシューマーが処理して削除」、Kinesis Data Streams は「保持期間中は残り、複数のコンシューマーが読める」という違いがあります。詳しい比較は「SQS と SNS」ページの表も参照してください。

キャパシティモードとシャード数の見積もり

モード仕組み選ぶ場面
オンデマンドシャード数を AWS が自動で調整。書き込み・読み取ったデータ量に応じて課金流量が読めない、急に増減する、シャードの管理をしたくない
プロビジョンドシャード数を自分で決め、シャード数と時間に応じて課金。シャードの分割・結合で増減する流量が予測でき、安定している。コストを細かく管理したい

プロビジョンドモードでは、必要なシャード数を「書き込み量 ÷ 1 MB/秒」「レコード数 ÷ 1,000 件/秒」「全コンシューマーの読み取り量 ÷ 2 MB/秒」のうち最も大きい値で見積もります。コンシューマーを増やしたときに読み取りが足りなくなる問題は、拡張ファンアウトで解決できます。拡張ファンアウトに登録したコンシューマーは、ほかのコンシューマーと共有せずにシャードあたり 2 MB/秒を受け取れ、データはプッシュ型で届くので遅延も小さくなります（プロビジョンドモードで最大 20 コンシューマー）。

操作できるシミュレーター

書き込み量とコンシューマー数から必要なシャード数を見る

スライダーを動かすと、プロビジョンドモードで必要なシャード数が変わります。

送信側 ストリーム 受信側

※簡略化しています: データがパーティションキーで各シャードに均等に分かれると仮定しています。実際には、キーの偏りで 1 本のシャードに集中すると、合計が足りていても上限を超えます。図のシャードは 10 本までを表示します。

図では省略しているキーの偏り（ホットシャード）は「Kinesis Data Streams の仕組み」で説明しています。オンデマンドモードではシャード数を自分で決める必要はありません。

Amazon Data Firehose

Amazon Data Firehose（旧称 Kinesis Data Firehose）は、ストリーミングデータを受け取り、指定した保存先へ自動で届けるフルマネージドサービスです。シャードの管理もコンシューマーのコードも不要で、流量に合わせて自動でスケールします。

Firehose のソースには、アプリから直接送る方法（Direct PUT）のほか、Kinesis Data Streams を指定できます。「Data Streams でリアルタイム処理をしつつ、同じデータを Firehose で S3 にも保存する」構成がよく出ます。S3 に保存したデータは Athena で SQL 分析できます。

Managed Service for Apache Flink と Kinesis Video Streams

サービスできること選ぶ場面
Amazon Managed Service for Apache Flinkストリームを読みながら SQL・Java・Python などで集計・結合・異常検知をリアルタイムに実行する（旧称 Kinesis Data Analytics）「直近 1 分間の売上を集計し続ける」「センサー値の異常をリアルタイムに検知」
Amazon Kinesis Video Streamsカメラなどからの映像・音声ストリームを取り込んで保存し、再生・分析（Amazon Rekognition Video など）に使えるようにする防犯カメラの映像の取り込み、映像の機械学習分析
Amazon MSK（参考）Apache Kafka のマネージドサービス既存の Kafka アプリをそのまま AWS へ移行する

取り込みのセキュリティ

試験ガイドには「取り込みアクセスポイントへのセキュアなアクセス」も挙がっています。Kinesis では次の方法を組み合わせます。

ストリーミングサービスの選び方と SQS との違い

比較・選択フローチャート

質問に答えてストリーミングのサービスを選ぶ

扱うデータと目的を思い浮かべて「はい / いいえ」で答えてください。答えた経路が上から順に表示されます。

    ※簡略化しています: 代表的な判断基準だけを分岐にしています。Data Streams と Firehose、Flink を組み合わせる構成や、既存の Kafka を使う場合（Amazon MSK）は分岐に含めていません。

    SQS もデータを受け渡しますが、目的が違います。SQS は「1 件ずつのタスクを確実に処理する」ためのキューで、処理したら削除します。Kinesis Data Streams は「大量のデータを流し続け、複数のアプリで読む・読み直す」ためのストリームです。「順序」についても、SQS FIFO キューはメッセージグループ単位、Kinesis Data Streams はシャード（パーティションキー）単位で順序が保たれます。

    問題文のキーワード → 選ぶべき答え

    問題文の言い回し選ぶべき答えと理由
    「リアルタイムに」「複数のアプリで同じデータを処理」「再処理（読み直し）」Kinesis Data Streams。保持期間内なら何度でも読める
    「ストリーミングデータを S3・Redshift・OpenSearch に保存」「管理の手間を最小に」Amazon Data Firehose
    「ほぼリアルタイム」「数十秒〜数分の遅れは許容」Data Firehose（バッファしてから配信）
    「JSON を Parquet・ORC に変換して S3 に保存し、Athena で分析」Data Firehose の形式変換（Glue データカタログのスキーマを使用）
    「ストリーミングデータを配信前に加工」Firehose + Lambda によるデータ変換
    「ストリームに対して SQL で時間枠ごとに集計」「リアルタイムの異常検知」Managed Service for Apache Flink
    「カメラ映像を取り込んで分析」Kinesis Video Streams
    「ProvisionedThroughputExceeded エラー」「書き込みがスロットリングされる」シャードを増やす（分割）、偏りのないパーティションキー、またはオンデマンドモード
    「コンシューマーを増やしたら読み取りが遅くなった」拡張ファンアウト（コンシューマーごとにシャードあたり 2 MB/秒）
    「流量が予測できず、シャード管理をしたくない」オンデマンドモード
    「同じユーザーのイベントは発生順に処理」ユーザー ID をパーティションキーにする（シャード内で順序を保証）
    「既存の Kafka クライアントをそのまま使いたい」Amazon MSK

    引っかけポイント

    まとめ: SAA 試験で押さえるポイント

    確認問題

    参考リンク

    AWS 公式ドキュメント（外部サイトが開きます）。本文の数値はこれらで確認しています。