SAA / ドメイン3 高パフォーマンスなアーキテクチャの設計
Amazon Kinesis Data Streams
概要
は、大量のストリーミングデータをリアルタイムで収集し、複数のコンシューマーで処理するサービスです。
主要技術
① ストリームとシャード
レコードはに基づいてへ分配され、シャード内では順序が維持されます。プロビジョンドモードではシャード数、モードではサービスが容量を管理します。
② 保持と再処理
一定期間レコードを保持するため、コンシューマーはチェックポイントから再読込できます。単なるメッセージ配信より再処理要件に向いています。
ストリームへ入ったレコードは複数のへ複製されて保持されるため、送信元のインスタンスが落ちても、送信済みのデータは失われません。逆に、インスタンス上のファイルやボリュームへ溜めてから定期的に送る構成は、送信前のデータがインスタンス障害で失われます。イベントの欠損を避けたい要件では、生成した時点でストリームへ送る設計を選びます。
③ コンシューマー
やを使って処理します。は、複数コンシューマーへ専用の読み取りを提供します。
GetRecordsで読む共有型のコンシューマーは、あたり毎秒2MBの読み取りと毎秒5回の呼び出しをすべてのコンシューマーで分け合うため、読むアプリケーションが増えるほど遅延が伸びます（1つで平均約200ミリ秒、5つで約1秒）。Enhanced Fan-Outに登録したコンシューマーは、シャードごとに毎秒2MBの専用の帯域でレコードをプッシュで受け取り、コンシューマーの数によらず平均約70ミリ秒で届きます。
ストリーム上のデータへそのまま集計や分析のクエリを実行したい場合は、をコンシューマーにします。ウィンドウ集計、結合、をまたはアプリケーションとして書き、レコードが届くたびに処理できるため、いったんへ保存してから問い合わせる構成よりも結果を得るまでの遅延を小さくできます。
④ 容量、順序、障害時の処理
同じのレコードは同じへ送られ、シャード内で順序が維持されます。特定キーへ集中するとホットシャードになるため、順序要件を守りながら十分に分散するキーを選びます。
プロビジョンドモードはシャード数を管理し、予測可能な負荷に向きます。各シャードの書き込みは毎秒1MBまたは1,000レコードまでで、総量が足りないときはUpdateShardCountでシャードを増やします。モードは容量管理をサービスへ委ね、トラフィックに合わせてシャードを増やします。ただし、1つのパーティションキーへ集中した書き込みはシャード1つの上限を超えられないため、どちらのモードでもホットシャードはキーの見直しで解消します。
のプロデューサーからは、のインターフェイスを使うと、やなしでストリームへ書き込めます。でaws:SourceVpceを条件にすると、指定したエンドポイントを経由しない操作を拒否できます。保持期間内なら複数コンシューマーが独立して再読込でき、障害復旧や新しい処理系の追加に利用できます。
試験対策
① パーティションキー
偏ったキーは特定への集中を招きます。均等に分散するキーを選ぶことが性能設計の要点です。
② SQS・Firehoseとの違い
作業キューには、保存先への管理不要な配信には、順序付きストリームを複数処理系で再読込する場合はです。
| 要件 | サービス |
|---|---|
| 1件を1ワーカー群で処理 | SQS |
| 複数処理系で再読込 | Kinesis Data Streams |
| などへバッファして配信 | Data Firehose |
| 互換性 | |
| ストリーム上でリアルタイムに集計・分析 | Kinesis Data Streams + |
Data FirehoseはS3などへの配信を担う機能で、バッファリングしてから書き出します。配信先へ保存したデータをなどで問い合わせる構成は、取り込みと蓄積には向きますが、バッファリングの待ち時間とクエリの都度実行が入るため、ストリーム処理の代わりにはなりません。リアルタイムに近い分析が要件なら、ストリームを直接処理する構成を選びます。
⚠️ 頻出: 順序保証はストリーム全体ではなく、同一内です。