DOPインシデントとイベントへの対応
あるSaaS企業のDevOpsチームは、Amazon EventBridge のルールで特定のアプリケーションイベントを受信し、ターゲットとして AWS Lambda 関数を直接呼び出して非同期処理を行っている。マーケティングキャンペーン時にイベントが急増すると Lambda 関数が同時実行数の上限に達してスロットリングが発生し、一部のイベントが処理されずに失われることが判明した。イベントの損失を最小化し、処理できなかったイベントを後から確認・再処理できるようにしたい。最も適切な対応はどれか。
AEventBridge ルールのターゲット設定で最大再試行回数と最大イベント経過時間（retry policy）を延長し、デッドレターキュー（DLQ）として Amazon SQS キューを指定する。
✓ 正解
EventBridge はターゲットごとに再試行ポリシー（最大再試行回数・最大イベント経過時間）と DLQ を設定でき、再試行後も配信できなかったイベントを SQS キューに退避できる。DLQ 内のイベントは後から内容を確認して再処理できるため、損失最小化と事後再処理の両要件を満たす。
BLambda 関数にプロビジョニングされた同時実行（Provisioned Concurrency）を設定し、スロットリング発生時は自動的にアカウントの同時実行数の上限が引き上げられるように構成する。
Provisioned Concurrency は関数を事前にウォーム状態に保つだけで、アカウントの同時実行数の上限を自動で引き上げるわけではない。上限を超えたイベントは依然スロットリングされ、失われたイベントを退避・確認する手段も提供しないため要件を満たさない。
CEventBridge のアーカイブを有効化して条件に一致した全イベントを保存し、スロットリング発生後にリプレイ機能で対象期間のイベントをまとめて再送信して処理し直す。
アーカイブとリプレイは保存済みイベントの再送に使えるが、リプレイは条件に一致した全イベントを再送するため失敗分だけを特定できず、再送時に再びスロットリングを招く。失敗した配信を退避する目的の機能ではないため適さない。
DEventBridge ルールのターゲットを Lambda から Amazon Kinesis Data Streams に変更し、シャード数を手動で増やしてスループットを確保したうえでコンシューマーを実装する。
ターゲットを Kinesis Data Streams に変更するとコンシューマーの実装やシャードの手動管理が必要となり構成が複雑化する。またスロットリングで失われたイベントを退避・確認する仕組みにはならず、最小限の変更で要件を満たせない。
解説
Amazon EventBridge ではターゲット単位で再試行ポリシー（最大再試行回数と最大イベント経過時間）を設定でき、さらにデッドレターキュー（DLQ）として Amazon SQS キューを指定できる。再試行を延長することで一時的なスロットリングを吸収し、それでも配信できなかったイベントは DLQ に退避されるため、後から内容を確認して再処理できる。損失最小化と事後再処理の両要件を最小限の構成変更で満たす。
選択肢1の Provisioned Concurrency は関数を事前起動するのみで、アカウントの同時実行数の上限を自動的には引き上げず、失われたイベントの退避もできない。
選択肢2の アーカイブ/リプレイ は一致した全イベントを再送するため失敗分だけを特定できず、再送時に再びスロットリングが発生する。
選択肢3の Kinesis Data Streams への変更はコンシューマー実装とシャードの手動管理が必要で構成が複雑化し、失敗イベントの退避にもならない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →