DVAトラブルシューティングと最適化
開発者はAWS Step Functionsを使って注文処理ワークフローを実装しています。
ワークフロー内の1つのステートが外部の在庫管理APIを呼び出しますが、このAPIは高負荷時に一時的な `ServiceUnavailable`（HTTP 503）エラーを返すことがあります。
現在の実装ではこのエラーが発生すると即座にワークフロー全体が失敗します。
最小限の変更で一時的なエラーに対する耐障害性を高める最善の方法はどれですか？
A外部APIを呼び出すLambda関数内にtry-catchブロックを追加し、503エラーを検出した場合に自前の指数バックオフリトライロジックを実装する
Lambda内で自前のリトライロジックを実装すると、Lambdaのタイムアウト上限の影響を受けます。また実装負荷が高く、ステートマシンのネイティブRetryより保守性が低く、効率的ではありません。
BStep Functionsのステート定義にRetryフィールドを追加し、対象エラーに対してIntervalSeconds・MaxAttempts・BackoffRateを指定した指数バックオフリトライを設定する
✓ 正解
Step Functionsのステート定義にRetryフィールドを追加することで、IntervalSeconds、MaxAttempts、BackoffRateを設定するだけで指数バックオフリトライが自動的に実現されます。ステートマシンのネイティブ機能として推奨されるアプローチです。
C外部API呼び出しの前にSQSキューを配置してリクエストをバッファリングし、コンシューマーLambdaがポーリングして処理するアーキテクチャに変更する
SQSキューを挿入してアーキテクチャを大幅に変更することは、要件（503エラーへの短期的な対応）に対してオーバーエンジニアリングです。リトライだけなら必要ありません。
DCloudWatch Alarmsで `ExecutionsFailed` メトリクスを監視し、失敗時にSNS通知経由でオペレーターが手動でワークフローを再実行する
CloudWatch Alarmで失敗を検出して手動対応するのは、自動リトライという要件を満たさず、運用負荷が増加するため不適切です。
解説
Step Functionsのステート定義はRetryフィールドをネイティブにサポートしており、エラー名・IntervalSeconds（初回待機秒数）・MaxAttempts（最大試行回数）・BackoffRate（バックオフ乗数）を指定するだけで自動リトライが実現できます。
選択肢AのようにLambda関数内にtry-catchでリトライロジックを実装する方法は、Lambdaのタイムアウト上限（最大15分）の影響を受けてバックオフ待機中にタイムアウトが発生する恐れがあり、実装・保守の負荷も増加します。
選択肢CのSQSキューを前置したアーキテクチャへの変更は耐障害性向上の有効な手段ですが、「最小限の変更」という要件に反し大規模な設計変更が必要です。
選択肢DのCloudWatch Alarmsによる監視と手動再実行は人的介入が必要であり、一時的なエラーへの自動回復ができないため耐障害性向上の要件を満たしません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDVAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →