IoTセンサーのイベントを毎秒取り込み、複数の処理アプリケーションが利用する。
障害後に保持期間内のデータを読み直せるようにする。
最も適切なサービスはどれか。
Kinesis Data Streamsはシャードへレコードを保持し、複数コンシューマーが独立して読み取れる。保持期間内なら障害後の再処理にも利用できる。
詳細解説
S3などへの配信を管理するサービスだが、複数のカスタムコンシューマーが保持データを任意に読み直すストリーム基盤ではない。
S3などへの配信を管理するサービスだが、複数のカスタムコンシューマーが保持データを任意に読み直すストリーム基盤ではない。
シャード上のレコードを保持期間内に複数のコンシューマーが読み取り、シーケンス番号を使って再処理できる。
シャード上のレコードを保持期間内に複数のコンシューマーが読み取り、シーケンス番号を使って再処理できる。
キューとしての非同期連携には使えるが、同一イベントを複数の独立コンシューマーが順序付きで再読する要件とは異なる。
キューとしての非同期連携には使えるが、同一イベントを複数の独立コンシューマーが順序付きで再読する要件とは異なる。
既存ファイルのETLには向くが、継続するセンサーイベントを保持しながら複数コンシューマーへ配信する取り込み基盤ではない。
既存ファイルのETLには向くが、継続するセンサーイベントを保持しながら複数コンシューマーへ配信する取り込み基盤ではない。
実際に確かめる
一時的な検証環境で実行できる例です。
Kinesis Data Streamsのデータ保持期間、シャード、コンシューマーの公式説明を確認する。期待される結果
配信専用サービスと、保持・再読可能なストリーム基盤を区別できる。理解のポイント
- Kinesis Data Streams
- 保持期間
- 再処理
- 複数コンシューマー
確認時の注意
- 確認環境: AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
- AWS公式DEA-C01 Domain 1・Task 1.1と各サービスの公式ドキュメントを確認する。
基礎のおさらい
ストリームとキュー
ストリームは位置を指定して保持データを読み直す設計に向き、キューはメッセージを処理主体へ受け渡す設計に向く。
再処理設計
障害時にどの時点から読み直すか、保持期間とコンシューマーのチェックポイントを事前に決める。