無限ノック › SAP 練習問題一覧 › 問題SAP 新しいソリューションのための設計
あるEコマース企業は、新しい注文確定マイクロサービスをAmazon ECS on Fargateで構築します。サービスは外部の決済プロバイダーAPIと在庫サービスを順に呼び出します。要件は次の通りです。決済プロバイダーが一時的に高レイテンシや障害を起こした際に、リトライの嵐でプロバイダーをさらに過負荷にしないこと、障害が継続している間は即座に失敗を返して呼び出し側スレッドを浪費しないこと、復旧後は自動的に通常処理へ戻すこと。アプリケーションコードの変更を最小限にしつつ、これらのレジリエンスパターンを実現する最も適切な方法はどれですか。
A 決済呼び出しをAWS Step Functionsのステートマシンに移し、Retryフィールドで指数バックオフとジッターを設定し、Catchフィールドでフォールバック状態に遷移させてサーキットブレーカーを実現する
✓ 正解
Step FunctionsのRetryで指数バックオフとジッター、Catchでフォールバック遷移を宣言的に定義でき、障害継続時の即時失敗と復旧後の自動回復を実現する。状態管理をサービスが担うためアプリ変更も最小で全要件を満たす。
B 決済呼び出しをAmazon SQSキュー経由の非同期処理に変更し、可視性タイムアウトとデッドレターキューでリトライ回数を制限することでサーキットブレーカーと同等の保護を実現する
SQSとDLQはリトライ回数の上限制御はできるが、同期的な注文確定処理を非同期化してしまう。さらに障害継続中に即時失敗を返す「回路の開閉」状態管理を持たず、サーキットブレーカーとは同等にならない。
C ECSサービスのAuto Scalingポリシーを決済APIのレイテンシメトリクスに連動させ、レイテンシ上昇時にタスク数を増やしてリトライを分散することで過負荷を回避する
レイテンシ連動でタスク数を増やすと、既に過負荷の決済プロバイダーへ同時リクエストをさらに送り込みリトライの嵐を悪化させる。過負荷保護や即時失敗の要件に逆行するため不適切。
D Application Load Balancerのターゲットグループのヘルスチェックを決済APIに向け、異常時にターゲットを切り離すことでサーキットブレーカーパターンを実現する
ALBのヘルスチェックは自社のECSタスク（ターゲット）の健全性を監視・切り離す仕組みで、外部の決済APIに対する保護や状態管理には使えない。サーキットブレーカーの実現手段にならない。
解説 指数バックオフ＋ジッターによるリトライ抑制、障害継続時の即時失敗（サーキットブレーカー）、復旧後の自動回復という一連のレジリエンスパターンは、AWS Step FunctionsのワークフローでRetry／Catchを宣言的に定義することで、アプリ側のロジックを最小限に保ったまま実現できます。
RetryのIntervalSeconds・BackoffRate・MaxAttemptsとジッターで再試行の嵐を抑制し、Catchでフォールバック状態に遷移させることで失敗を即座にハンドリングできます。状態管理はサービス側が担うためコード変更が少なく済みます。
選択肢BのSQS+DLQはリトライ上限の制御はできるが、注文確定の同期的な順次呼び出しを非同期化してしまい、即時失敗応答やサーキットブレーカーの「開閉」状態管理は提供しない。
選択肢CのAuto Scalingでタスクを増やす対応は、過負荷の決済プロバイダーへの同時呼び出しをむしろ増やし、リトライの嵐を悪化させる。
選択肢DのALBヘルスチェックは自社ターゲット（ECSタスク）の健全性を判定する仕組みであり、外部決済APIに対するサーキットブレーカーには使えない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →