あるスポーツデータ企業が、S3バケットに保存された試合動画ファイルを解析するパイプラインを構築している。S3にオブジェクトがアップロードされると自動で解析Lambdaが起動する構成だが、まれに同じファイルに対してLambdaが複数回起動されて重複処理が発生している。アーキテクチャの大きな変更なく冪等処理を保証する最も適切な方法はどれか。
- A. Lambdaの同時実行数を1に制限して逐次処理し、重複起動が起きないようにする
- B. S3オブジェクトのETagをLambda内で毎回チェックし、前回処理時と異なる場合のみ処理を実行する
- C. S3イベントをEventBridge経由でSQSキュー(FIFO)に送信し、メッセージグループIDにS3オブジェクトキーを設定してFIFO重複排除を活用する。Lambdaの処理開始時にDynamoDB条件付きWriteでジョブIDを記録し(既存なら失敗→スキップ)、冪等処理を保証する
- D. S3バケットのイベント通知をSNSトピックに変更し、SNSの重複排除IDを設定する
解答と解説を見る
正解: C
S3イベント通知は「少なくとも1回(at-least-once)」配信であるため、重複通知が発生することがある。FIFO SQSのメッセージ重複排除(5分以内の同一重複排除IDのメッセージを排除)でほとんどの重複を防ぎ、さらにDynamoDBの条件付きWrite(attribute_not_exists(jobId))で冪等処理のべき等制御を追加する。両層の保護により、FIFOの5分ウィンドウ外の重複に対してもDynamoDB側で検知できる。DのSNS重複排除IDはSNS FIFOトピックの機能だが、S3イベント通知をSNS FIFOに直接送ることはできず(S3はSNS標準トピックのみサポート)、設計が成立しない。CLambdaの同時実行数1は処理のシリアル化であり、S3が同じオブジェクトのイベントを2回発行した場合の重複処理は防げない(時間的に分離した2回の呼び出しを防ぐには不十分)。BのETag比較は前回処理の結果をどこかに記録する仕組みが必要で、その記録の更新と比較の間にレースコンディションが生じる。
📚 関連サービスの解説: Amazon S3 ・ Amazon EventBridge