複数 Lambda を含む複雑なワークフローのオーケストレーション
建設機械メーカーの IT 部門が、稼働データの集計基盤を構築しています。処理は複数の AWS Lambda 関数に分割されており、Amazon EC2 インスタンス上で稼働する既存バッチや工場内のオンプレミスサーバーからもデータを取得したうえで、条件分岐、失敗時のリトライ、前段の結果を次段に引き渡す処理を含む多段のワークフローとして実行する必要があります。各処理の実行状況を可視化し、どのステップで失敗したかをすぐに特定できることも求められています。運用コードを最小限に抑えてこの要件を満たすソリューションはどれですか。
解説を読む（正解: B）
AWS Step Functions は、複数の AWS サービス呼び出しをステートマシンとして定義し、実行順序、条件分岐、並列実行、待機、エラー処理とリトライを宣言的に記述できるワークフローオーケストレーションサービスです。各ステップの入出力は自動的に次のステップへ受け渡され、実行履歴はコンソールのビジュアルワークフローで可視化されるため、どのステップで失敗したかを即座に特定できます。
本問は「複数の Lambda 関数を段階的に呼び出す」「条件分岐とリトライが必要」「実行状況を可視化したい」という典型的なオーケストレーション要件です。Step Functions は Lambda に加えて、AWS Systems Manager Run Command や AWS Batch などとも統合できるため、EC2 上のワークロードやハイブリッド環境のサーバーを含む処理も同じステートマシンから制御できます。状態管理のコードを自前で書く必要がないため、運用コードも最小限で済みます。
A は誤りです。Amazon SNS はパブリッシュ/サブスクライブ型の通知サービスであり、順序制御や分岐、リトライ後の状態管理は自前で実装する必要があります。C も誤りです。Amazon SQS はコンポーネント間を疎結合にするキューであり、ワークフロー全体の進行状況を管理・可視化する機能はありません。D も誤りです。Amazon EventBridge はイベントのルーティングには優れていますが、多段ルールを連鎖させる方式ではワークフロー全体の状態や実行履歴を一元的に追跡できず、分岐やリトライのロジックも各所に分散して運用が複雑になります。
複数 Lambda 関数のワークフロー可視化
オンライン学習サービスを運営する企業では、受講修了証の発行処理を 7 個の AWS Lambda 関数に分割して実装しています。受講データの検証、PDF 生成、電子署名の付与、通知メール送信などが順番に実行されますが、現在は各関数が次の関数を直接呼び出す構成のため、どのステップで失敗したのかを追跡できず、リトライ制御のコードも各関数に散らばっています。運用チームは処理全体の流れを図として把握し、ステップ単位のリトライとエラーハンドリングを宣言的に定義したいと考えています。最も適切な方法を 1 つ選択してください。
解説を読む（正解: A）
サーバーレス関数を複数つなげて業務処理を実現すると、処理順序・分岐・リトライ・エラー処理といった制御ロジックが各関数のコードに埋め込まれ、全体像が見えなくなります。AWS Step Functions はこの制御ロジックを関数の外側にステートマシンとして切り出すマネージドなワークフローサービスで、Amazon States Language で定義したワークフローをコンソール上でグラフとして描画し、実行ごとに各ステートの入出力・所要時間・成否を追跡できます。
本要件は「7 つの関数の実行フローを可視化したい」「ステップ単位のリトライとエラーハンドリングを宣言的に持ちたい」というものであり、Step Functions の Retry / Catch フィールドとビジュアルワークフロー、実行履歴のイベントログがそのまま要件を満たします。Lambda 関数側のコードからは制御ロジックを取り除けるため、保守性も向上します。
Amazon SWF はワーカーとデサイダーを自前で実装・運用する必要があり、AWS も新規のワークフロー開発では Step Functions を推奨しています。オーケストレーション用の Lambda 関数を自作する案は、可視化もリトライも自前実装することになり運用負荷が増えるうえ、Lambda の最大実行時間の制約も受けます。EventBridge によるイベント連鎖は疎結合化には有効ですが、ワークフロー全体を 1 つの実行単位として俯瞰する仕組みがなく、ログから流れを事後的に再構成する運用では要件を満たしません。
多段処理パイプラインのワークフローオーケストレーション
ある地域中核病院グループが、院内で撮影した医用画像を解析する処理基盤を AWS 上に構築しています。処理は「画像の取り込み」「患者識別情報の匿名化」「機械学習モデルによる所見の推論」「読影レポートの生成」「担当医への通知」という 5 つの段階から成り、現在は各段階を AWS Lambda 関数として実装し、前の関数が次の関数を直接呼び出すチェーン構造になっています。運用チームからは、処理が途中で失敗したときにどの段階で止まったのか追跡できない、段階ごとに再試行やエラー時の分岐を作り込むコードが肥大化している、という問題が報告されました。さらに推論処理は画像枚数が多い症例では最大 40 分かかることがあります。この処理基盤を改善する最も適切な設計はどれですか。
解説を読む（正解: A）
複数のステップから成る業務処理を関数同士の直接呼び出しでつなぐと、状態遷移がコードの中に埋もれてしまい、どこで失敗したかの可視化や段階ごとの再試行制御が難しくなります。AWS Step Functions はまさにこの課題を解決するワークフローオーケストレーションサービスで、ステートマシンとしてステップの順序・分岐・並列実行・エラー時の Retry と Catch を宣言的に定義でき、実行ごとの状態遷移をコンソール上で視覚的に追跡できます。アプリケーションコードからオーケストレーションのロジックを分離できるため、Lambda 関数は自分の処理だけに専念でき、コードの肥大化も解消されます。また AWS Lambda には 1 回の実行あたり 15 分という上限があるため、最大 40 分かかる推論処理は Lambda では完了できません。Step Functions から AWS Fargate のタスクを起動して実行時間の制約を回避する A が、可視化・再試行・長時間処理という 3 つの要件をすべて満たします。B は 5 段階を 1 関数にまとめる密結合な設計で、15 分の実行時間上限に確実に抵触するうえ、段階ごとの独立したスケーリングもできません。C の Amazon SQS は疎結合とバッファリングには有効ですが、キューはワークフロー全体の状態を保持しないため「どの段階まで進んだか」を一元的に追跡することはできず、Lambda の 15 分上限の問題も残ります。D は各段階の所要時間が症例によって大きく変動するにもかかわらず固定の時間間隔に依存する設計であり、前の段階が終わる前に次が起動する、あるいは待ち時間が無駄になるといった破綻が容易に起こります。