SOAデプロイ、プロビジョニング、および自動化
データ処理システムで、S3にファイルがアップロードされると以下の処理を順次実行する必要があります:
①ファイル検証（Lambda）
②DynamoDBへの登録（Lambda）
③外部REST APIへのHTTPリクエスト
④SNS通知
外部API（③）がタイムアウトした場合は最大3回リトライし、3回すべて失敗した場合は④をスキップして別のSNSトピックへ失敗通知を送信する必要があります。このワークフローを最も適切に実装する方法はどれですか？
A単一のLambda関数にすべてのロジックをPythonで実装し、try-catchブロックでリトライカウントを管理し、3回すべて失敗した場合は通常のSNS通知をスキップして失敗通知用の別SNSトピックにメッセージを送信する
単一Lambda関数はタイムアウト制約（最大15分）があり、外部APIへの複数回リトライが重なると超過するリスクがあります。状態管理やリトライカウントをコードで実装するため保守性が低く、複雑なエラーフローの管理が困難です。
BAWS Step FunctionsのステートマシンでTaskステートとChoiceステートを使用し、各処理をTaskステートとして定義し、外部APIタスクにRetry設定（MaxAttempts: 3）とCatch設定を追加してエラーフローに分岐させる
✓ 正解
Step Functionsは複雑なワークフローのオーケストレーションに最適です。TaskステートのRetryで指数バックオフ付きリトライを、Catchでエラー種別ごとの分岐先を宣言的に定義でき、実行状態の可視化や監査も容易に行えます。
CAmazon SQSキューに各処理ステップのメッセージを格納し、複数のLambda関数がポーリングして順次処理を実行し、3回失敗時はデッドレターキューで失敗を検知して別のSNSトピックに失敗通知を送信する
SQSを使った実装では厳密な処理順序の保証が難しく、各ステップ間の依存関係やエラー時の条件分岐を管理するカスタムロジックが必要です。デッドレターキューは失敗検知に使えますが複雑なワークフロー制御には不向きです。
DEventBridgeのルールで各Lambda関数を連鎖的に呼び出し、カスタムイベントバスで処理の順序を制御し、リトライロジックとエラーハンドリングの条件分岐をカスタムイベントのルールで実装する
EventBridgeはイベント駆動アーキテクチャに適していますが、処理順序の制御やリトライ時のステート管理機能がなく、複雑な条件分岐を宣言的に定義することができません。
解説
複雑なワークフローの順次実行・リトライ・条件分岐にはStep Functionsが最も適しています。
選択肢Aは、単一Lambda関数は最大15分のタイムアウト制約があり、外部APIへの複数回リトライが重なると超過するリスクがあります。状態管理やリトライロジックをコードで実装するため保守性が低く、複雑なエラーフローの管理が困難です。
選択肢Bは、Step FunctionsのTaskステートはRetry（MaxAttempts・指数バックオフ）とCatch（エラータイプ別の分岐先）を宣言的に定義できます。実行状態の可視化も可能で、複雑なワークフローのオーケストレーションに最適です。
選択肢Cは、SQSキューを使った実装では厳密な処理順序の保証が難しく、各ステップ間の依存関係やエラー時の条件分岐を管理するカスタムロジックが必要になり、複雑さが増します。
選択肢Dは、EventBridgeはイベント駆動アーキテクチャに適していますが、処理順序の制御やリトライ時のステート管理機能がなく、複雑な条件分岐を宣言的に定義できません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →