# Step Functions を用いた Lambda 関数のオーケストレーション
AWS Step Functions は、Lambda 関数を他の AWS サービスと調整するためのビジュアルワークフローオーケストレーションを提供します。220 以上の AWS サービスとのネイティブ統合とフルマネージド型のゼロメンテナンスインフラストラクチャにより、Step Functions はビジュアルワークフロー設計とフルマネージド型のサービス統合が必要な場合に最適です。
ワークフローロジックがビジネスロジックと並行して存在する Lambda 内で標準プログラミング言語を使用するオーケストレーションについては、[Lambda の耐久性のある関数](durable-functions.md)を検討してください。これらのオプションの選択については、「[耐久性のある関数か Step Functions か](durable-step-functions.md)」を参照してください。
例えば、注文を処理するには、注文の詳細の確認、在庫レベルのチェック、支払の処理、請求書の生成が必要になる場合があります。それらのタスクそれぞれについて個別の Lambda 関数を記述し、Step Functions を使用してワークフローを管理します。Step Functions は各関数間のデータフローを調整し、各手順でエラーを処理します。この分離型アプローチにより、ワークフローが複雑になっても容易にワークフローを視覚化、変更、維持することができます。
## Lambda で Step Functions を使用すべき状況
以下のシナリオは、Lambda ベースの複数のアプリケーションをオーケストレーションするのに Step Functions が特に適合する場合の例を示します。
+ [シーケンシャル処理](#sequential-processing)
+ [複雑なエラー処理](#complex-error-handling)
+ [条件付きワークフローと人間による承認](#conditional-workflows-human-approvals)
+ [並列処理](#parallel-processing)
### シーケンシャル処理
シーケンシャル処理とは、あるタスクが完了してから、次のタスクを開始するアプローチを指します。例えば、注文処理システムでは、注文の確認が完了するまで支払処理を開始できず、請求書の生成は支払の確認を待つ必要があります。タスクごとに個別の Lambda 関数を記述し、Step Functions を使用してシーケンスを管理し、関数間のデータフローを調整します。
#### アンチパターンの例
1 つの Lambda 関数で、注文処理ワークフロー全体を以下のように管理しています。
+ 他の Lambda 関数を順番に呼び出す
+ 各関数からのレスポンスを解析および検証する
+ エラー処理および復旧ロジックを実行する
+ 関数間のデータフローの管理
#### (推奨されるアプローチ)
2 つの Lambda 関数を使用しており、1 つは注文を確認し、もう 1 つは支払を処理するためのものです。Step Functions で、これらの関数を次のように調整します。
+ 各タスクを正しい順序で実行する
+ 関数間でのデータを受け渡しを行う
+ 各手順でエラー処理を実行する
+ [Choice](https://docs.aws.amazon.com/step-functions/latest/dg/state-choice.html) 状態を使用して、有効な注文のみが支払に進むようにする
**Example ワークフローのグラフ**
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/sequential_workflow.png)
**注記**
**コードファーストの代替:** コードベースのチェックポイント設定と再試行によるシーケンシャル処理については、「[Lambda の耐久性のある関数の手順](durable-basic-concepts.md)」を参照してください。
### 複雑なエラー処理
Lambda は[非同期呼び出しおよびイベントソースマッピングの再試行機能](invocation-retries.md)を提供しますが、これに対し Step Functions は複雑なワークフローに対してより高度なエラー処理を提供します。エクスポネンシャルバックオフを使用して[自動再試行を設定](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html#error-handling-retrying-after-an-error)し、さまざまなエラータイプに対してそれぞれ個別の再試行ポリシーを設定できます。再試行で解決できなかった場合、`Catch` を使用してエラーを[フォールバック状態](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html#error-handling-fallback-states)にルーティングします。複数の関数およびサービスを調整するワークフローレベルのエラー処理が必要な場合、特に便利です。
ステートマシンでの Lambda 関数エラーの処理に関する詳細については、「*AWS Step Functions ワークショップ*」の「[エラーの処理](https://catalog.workshops.aws/stepfunctions/handling-errors)」を参照してください。
#### アンチパターンの例
1 つの Lambda 関数で、次のすべてを処理しています。
+ 支払処理サービスの呼び出しを試行する
+ 支払サービスが利用できない場合、関数は待機して後で再試行する。
+ 待機時間のカスタムエクスポネンシャルバックオフを実装する
+ すべての試行が失敗したら、エラーをキャッチして別のフローを選択する。
#### (推奨されるアプローチ)
そこで、支払処理のみを中心に扱う 1 つの Lambda 関数を使用します。Step Functions で次のようにエラー処理を管理します。
+ [設定可能なバックオフ期間により、失敗したタスクを自動的に再試行する](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html#error-handling-retrying-after-an-error)
+ エラータイプに基づいて異なる再試行ポリシーを適用する
+ さまざまなエラーのタイプをそれぞれ適切なフォールバック状態にルーティングする
+ エラー処理の状態および履歴を維持する
**Example ワークフローのグラフ**
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/error_handling_workflow.png)
**注記**
**コードファーストの代替:** 耐久性のある関数は、設定可能な再試行戦略で try-catch エラー処理を提供します。[耐久性のある関数でのエラー処理](durable-execution-sdk-retries.md)を参照してください。
### 条件付きワークフローと人間による承認
Step Functions の [Choice 状態](https://docs.aws.amazon.com/step-functions/latest/dg/state-choice.html)を使用して関数の出力に基づいてワークフローをルーティングするとともに、人間の判断によりワークフローを一時停止できる [waitForTaskToken サフィックス](https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html#connect-wait-token)を使用します。例えば、クレジット上限の引き上げリクエストを処理するには、Lambda 関数を使用してリスク要因を評価します。次に、Step Functions を使用して高リスクのリクエストを手動承認にルーティングし、低リスクのリクエストを自動承認にルーティングします。
コールバックタスクトークンの統合パターンを使用するワークフローの例をデプロイするには、「*AWS Step Functions ワークショップ*」の「[タスクトークンを使用したコールバック](https://catalog.workshops.aws/stepfunctions/integrating-services/3-callback-token)」を参照してください。
#### アンチパターンの例
1 つの Lambda 関数で、複雑な承認ワークフローを次のように管理しています。
+ ネストされた条件付きロジックを実装してクレジットリクエストを評価する
+ リクエスト金額に基づいて複数の異なる承認関数を呼び出す
+ 複数の承認パスおよび決定ポイントを管理する
+ 承認待ち状態を追跡する
+ 承認用のタイムアウトおよび通知ロジックを実装する
#### (推奨されるアプローチ)
これに対し、3 つの Lambda 関数を使用します。1 つは各リクエストのリスクを評価し、1 つは低リスクのリクエストを承認し、最後の 1 つは高リスクのリクエストを管理者によるレビューにルーティングします。Step Functions で次のようにこのワークフローを管理します。
+ [Choice](https://docs.aws.amazon.com/step-functions/latest/dg/state-choice.html) 状態を使用して、量およびリスクレベルに基づいてリクエストをルーティングする
+ 人間による承認を待っている間は実行を一時停止する
+ 承認待ちのタイムアウトを管理する
+ 各リクエストの現在の状態を可視化する
**Example ワークフローのグラフ**
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/conditional_workflow.png)
**注記**
**コードファーストの代替:** 耐久性のある関数は、human-in-the-loop ワークフローのコールバックをサポートします。[耐久性のある関数の「コールバック」](durable-execution-sdk.md)を参照してください。
### 並列処理
Step Functions には、並列処理を行う 3 つの方法があります。
+ [Parallel 状態](https://docs.aws.amazon.com/step-functions/latest/dg/state-parallel.html)は、ワークフローの複数の分岐を同時に実行します。画像メタデータ抽出中のサムネイル生成など、さまざまな関数を並行して実行する必要があるときに Parallel 状態を使用します。
+ [Inline Map 状態](https://docs.aws.amazon.com/step-functions/latest/dg/state-map-inline.html)は、最大 40 回の反復同時実行でデータ配列を処理します。Inline Map 状態は、各項目に対して同じオペレーションを実行する必要がある、小規模から中規模のデータセットに使用します。
+ [Distributed Map 状態](https://docs.aws.amazon.com/step-functions/latest/dg/state-map-distributed.html)は、最大 10,000 回の同時実行で大規模な並列処理を行うもので、JSON 配列と Amazon Simple Storage Service (Amazon S3) データソースの両方をサポートします。Distributed Map 状態は、大規模なデータセットの処理や、より大量の同時実行に対応する必要がある場合に使用します。
#### アンチパターンの例
1 つの Lambda 関数で、次のような並列処理の管理を行っています。
+ 複数の画像処理関数を同時に呼び出す
+ カスタム並列実行ロジックを実装する
+ 各並列タスクでタイムアウトおよびエラー処理を管理する
+ すべての関数の結果を収集および集計する
#### (推奨されるアプローチ)
これに対し、3 つの Lambda 関数を使用します。1 つはサムネイルイメージを作成し、1 つはウォーターマークを付与し、最後の 1 つはメタデータを抽出します。Step Functions でこれらの関数を次のように管理します。
+ [Parallel](https://docs.aws.amazon.com/step-functions/latest/dg/state-parallel.html) 状態を使用してすべての関数を同時に実行する
+ 各関数の結果を収集し、順序付けられた配列にまとめる
+ すべての並列実行のタイムアウトおよびエラー処理を管理する
+ すべての並列分岐が完了した場合にのみ次に進む
**Example ワークフローのグラフ**
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/parallel_workflow.png)
**注記**
**コードファーストの代替:** 耐久性のある関数は `parallel()` および `map()` オペレーションを提供します。「[同時実行](durable-execution-sdk.md)」を参照してください。
## Lambda で Step Functions を使用すべきではない状況
すべての Lambda ベースのアプリケーションに Step Functions を使用するメリットがあるとは限りません。アプリケーションのアーキテクチャを選択する際、次のシナリオを検討してください。
+ [単純なアプリケーション](#simple-applications)
+ [複雑なデータの処理](#complex-data-processing)
+ [CPU 負荷が高いワークロード](#cpu-intensive)
### 単純なアプリケーション
**注記**
視覚的な設計や広範なサービス統合を必要としないワークフローの場合、[Lambda の耐久性のある関数](durable-functions.md)は、ワークフローロジックを Lambda 内のコードに保持するより簡単な代替手段である可能性があります。
複雑なオーケストレーションが不要なアプリケーションの場合、Step Functions を使用すると不要な複雑さにつながることがあります。例えば、Amazon SQS キューからのメッセージの処理や、Amazon EventBridge イベントに応答するのみのサービスであれば、Lambda 関数の直接呼び出しで対応できるでしょう。同様に、エラー処理が簡単な 1 つもしくは 2 つの Lambda 関数 で構成されるアプリケーションであれば、Lambda の直接呼び出し機能もしくはイベント駆動型アーキテクチャの方がデプロイもメンテナンスもしやすいでしょう。
### 複雑なデータの処理
Step Functions の [Distributed Map](https://docs.aws.amazon.com/step-functions/latest/dg/state-map-distributed.html) 状態を使用することで、Lambda 関数で大規模な Amazon S3 データセットを同時に処理できます。この方法は、JSON ファイルや CSV ファイルなどの半構造化データの処理を含め、多くの大規模な並列ワークロードに効果的です。ただし、さらに複雑なデータ変換や高度な分析を要する場合は、次に説明する代替方法も検討してください。
+ **データ変換パイプライン**: AWS Glueを使用して、複数のソースからの構造化データまたは半構造化データを処理する ETL ジョブを構築します。AWS Glueは、ビルトインデータカタログやスキーマの管理機能が必要な場合に特に便利です。
+ **データ分析:** Amazon EMR を使用してペタバイト規模のデータ分析を行います。この方法は、Apache Hadoop エコシステムツールが必要な場合や、Lambda の[メモリ](configuration-memory.md)制限を超える機械学習ワークロードに特に適しています。
### CPU 負荷が高いワークロード
Step Functions は CPU 負荷が高いタスクもオーケストレーションすることができますが、Lambda 関数自体の CPU リソースが限られているためにこうしたワークロードには適していない場合があります。ワークフロー内のコンピューティング負荷が高いオペレーションについては、次の代替方法を検討してください。
+ **コンテナオーケストレーション:** Step Functions を使用して Amazon Elastic Container Service (Amazon ECS) タスクを管理し、一貫性がありスケーラブルなコンピューティングリソースを提供します。
+ **バッチ処理:** AWS Batch を Step Functions と統合し、継続的な CPU の使用を必要とするコンピューティング負荷の高いバッチジョブを管理します。