あるEコマース企業のDevOpsチームは、Amazon EventBridgeのカスタムイベントバスを使用したイベント駆動型の注文処理システムを運用しています。先週の火曜日、15:00〜17:00の2時間にわたって注文処理Lambdaにバグがあり、その時間帯に流れた一部の注文イベントが正しく処理されず未完了のままになりました。バグは修正・デプロイ済みですが、障害時間帯のイベントを再処理して未完了注文を復旧させる必要があります。 前提条件：イベントバスにはアーカイブ（archive）機能が事前に有効化されており、すべてのイベントが保存されています。 要件： ・ 15:00〜17:00の時間範囲のイベントのみを選択的に再処理する ・ 現在も流れている新規注文イベントの通常処理に影響を与えない ・ 修正済みの注文処理Lambdaにのみ再生イベントを送信する この要件を最も効率的に満たす方法はどれですか？
正解： EventBridgeのリプレイ（Replay）機能を使用し、対象アーカイブと15:00〜17:00の時間範囲を指定してイベントを再生する。再生されたイベントには自動付与される「replay-name」属性を利用してルールでフィルタリングし、修正済みLambdaのみに送信する EventBridgeのアーカイブ機能が有効な場合、Replay機能により任意の時間範囲のアーカイブ済みイベントを再生できます。再生時には開始・終了日時・対象アーカイブ・送信先イベントバスを指定し、再生されたイベントには「replay-name」フィールドが自動付与されます。このフィールドを利用したルールフィルタリングで修正済みLambdaのみに送信でき、新規イベントの通常処理ルールと分離できます。 選択肢Bは、ログから再構築する場合、注文イベントの完全なペイロードがログに記録されていることが前提で、再構築の実装工数・エラーリスクが高くなります。 選択肢Cは、SQSキューを経由しているシステムにのみ適用できます。EventBridgeからLambdaへ直接ルーティングする構成では、このシナリオには適用できません。 選択肢Dは、DynamoDBの状態データが正確に保存されていることが前提で、「元のイベントを再生する」のではなく「状態から再処理を推論する」複雑なアプローチです。