Kinesis Data Streamsへ到着するイベントをLambdaで変換し、処理済みの位置を自動的に進めたい。
一時的なエラーではバッチを再試行し、同じレコードを再実行しても下流の結果が二重にならないようにする。
最も適切な構成はどれか。
LambdaのイベントソースマッピングはKinesis Data Streamsをポーリングしてバッチで関数を呼び出し、成功した位置をチェックポイントとして管理する。再試行を前提に下流処理を冪等にする。
詳細解説
イベントソースマッピングがシャードからバッチ取得してLambdaを呼び出し、処理結果に応じてチェックポイントを進められる。
スケール、チェックポイント、再試行、シャードのリース管理を自作する必要があり、イベントソース連携の利点を失う。
S3イベント通知はS3オブジェクト用で、Kinesis Data Streamsのレコードを読み取らない。
CloudTrailはAPI監査記録であり、Kinesisの業務イベントを順序付きで配信する入力ではない。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
AWS LambdaのKinesisイベントソースマッピング、バッチ処理、チェックポイント、再試行の公式説明を確認する。
参考にした公式資料
確認できる内容
KinesisからLambdaを呼ぶマネージド連携と、S3通知・監査ログ・自作ポーリングの違いを説明できる。
理解のポイント
- Kinesis Data Streams
- Lambdaイベントソース
- チェックポイント
- 冪等性
確認時の注意
- 確認環境: AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
- AWS公式DEA-C01の該当Skillと各サービスの現行ドキュメントを確認する。
基礎のおさらい
イベントソースマッピング
ストリームやキューをポーリングし、取得したレコードをLambdaへバッチで渡すマネージド連携。
チェックポイント
処理済みのストリーム位置を保存し、再起動や再試行の読み取り位置を決める状態。
冪等性
同じイベントを複数回処理しても、下流の論理結果が一度と同じになる性質。