こんにちは。島村です。
個人的になぜか2月の終わりを感じています。
2月は気を抜くと、すぐに終わってしまうので意識して毎日を過ごしていきたいですね。
さて、今回はStep Functionsのサービス統合パターンを
公式サンプルを使用しながら挙動を確認していく内容です。
- Step Functionsとは
- Step Functionsのサービス統合とは何か
- 使用するサンプル
- Request Responseパターン
- Run a Jobパターン(.sync)
- Wait for Callbackパターン(.waitForTaskToken)
- まとめ
- 参考
Step Functionsとは
Step FunctionsはAWSのオーケストレーションツールです。
オーケストレーションとは、アプリケーションやサービス、設定、管理の自動化を指します。
Step Functionsに対応するAWSサービスを活用したり、アプリケーションの処理をワークフローのように構成することが可能です。
アプリケーション処理の並列化、処理の成功時、失敗時の分岐、とある処理が完了するまで停止したり、
ワークフローを柔軟に構成することもできます
ワークフロー自体はGUI操作で定義することもできますし、Amazon States Languageと呼ばれる
JSON構造の定義ファイルを使用してワークフローを作成することもできます。
Step Functionsのサービス統合とは何か
Step Functionsは前述の通り、AWSサービスを呼び出して、ワークフローを作成します。
別サービスを呼び出す際にStep Functionsでコントロールできますが、いくつか種類があります。
今回は以下の種類の挙動の違いを、AWS公式サンプルを使用しながら見ていきたいと思います。
- Request Responseパターン
- Run a Jobパターン(.sync)
- Wait for Callbackパターン(.waitForTaskToken)
使用するサンプル
以下のリンクを使用して説明していきます。 https://catalog.workshops.aws/stepfunctions/en-US/introduction
リージョンはバージニア北部を利用していきます。
Request Responseパターン
公式サンプル3つ目がわかりやすので、3つ目のCloudFormationを展開していきましょう
catalog.workshops.aws
Cloud Formationを展開すると、以下のようにStep Functionsのステートマシンが構成されています。
※実際に通知が来るように、自分の環境に存在していたSNSを指定しています。
処理の流れとしては、Hello Worldを出力するAWS Batchのジョブが起動し、成功したらSNS通知へ処理が移ります。
さっそく、リクエストレスポンスパターンの挙動を確認していきます。
ワークフローの実行を開始しましょう。・・・実行後、すぐに完了してしまいました。
AWS Batchの実行が完了する前にSNSの成功通知を送ってしまっています。
リクエストレスポンスパターンだとStep FunctionsからAWS Batchへジョブ実行(SubmitJob API)を
実行はするものの、AWS Batchの実行結果を待たずして次のステートへ処理が移ってしまいます。
Step Functionsの結果
Step Functionsから呼び出されたAWS Batchのジョブ結果
RUNNABLEになっていて、バッチ処理が終わっていないことが確認できます。
この場合、Batch処理に失敗した場合はハンドリングできないですね。
リクエストレスポンスパターンは名前の通り、Step FunctionsからAWSサービスを呼び出した際の
HTTPレスポンスを受け取ったタイミングでワークフローを進める挙動をします。
リクエストレスポンスパターンは、実行した処理の結果に関わらず、非同期で実行できるケースで使用できそうです。
後続処理側でエラーハンドリングなどは別途検討する必要はありますが....
実行した処理の結果次第でワークフローを分岐させたい場合はリクエストレスポンスパターンは要件に合わないと考えます。
Run a Jobパターン(.sync)
さて、syncパターンの挙動を確認していきます。
使用するサンプルはリクエストレスポンスパターンのままで問題ありません。
.sycnパターンを利用する場合は、ASL定義のリソースに.syncを追加するだけです。
もしくはWorkflow Studioで、[タスクの完了まで待機する]を選択すればASLに自動で追加されます
Workflow Studio
ワークフロー編集画面
それでは、準備ができたところで動作確認を行っていきましょう。
ワークフローを実行してみてください。
すぐには完了せずに、AWS Batchジョブの完了を待っている動きになっていますね
Step Functionsの結果
Step Functionsから呼び出されたAWS Batchのジョブ結果
タスクの完了を待っているので、レスポンスの内容もタスクの実行結果が取得できていることが確認できると思います。
AWS Batchの実行結果がレスポンスに含まれている。
なお、.syncパターンに対応しているサービスは限られています。
Run a Jobに対応しているAWSサービス
- AWS Batch
- Amazon ECS/AWS Fargate
- AWS Glue
- AWS Glue DataBrew
- SageMaker
- Amazon EMR
- Amazon EMR on EKS
- CodeBuild
- Athena
- Amazon EKS
- AWS Step Functions
Wait for Callbackパターン(.waitForTaskToken)
最後にWait for Callbackパターンの動作確認をしていきます。
公式サンプルの4つ目のCloud Formationを展開していきましょう。
ステートマシンを見るとワークフローは以下の通りとなっています。
SQS→SNSという内容になっています。
ですが、展開されたリソースの中にはLambdaが含まれています。
処理の流れは以下の通りです。
サンプルアプリケーションのワークフロー
Wait for CallbackもASLにて記述が必要です。
ASLのリソース定義で.waitForTaskTokenを付与する必要があります。
では、動かしていきます。
最初のサンプルの状態はコールバックの関数がコメントアウトされていて、コールバックの仕組みがありません。
そのため、いつまで経っても終わらないことが確認できます。
コールバック処理追加前のワークフロー実行結果
任意のタイミングでワークフローの実行を停止しましょう
サンプルで用意されたLambdaでは、コールバック処理が既に実装されています。
コメントアウトを外して再度ワークフローを実行しましょう
コールバック処理追加後のワークフロー実行結果
完了しました。
Lambdaの実行結果など見ていきます。
Step FunctionsからSQSにトークンメッセージを渡していることが確認できます。
次にLambdaからのコールバックを見てましょう。
※CloudWatch Logsから確認します。
同じ値であることが確認できました。
SQSのメッセージからトークンの値を取得して変数に格納している処理が記載されているのでずれるわけないですが
トークンの値を取得する処理も忘れずにしたいところです。
トークンをコールバックする仕組みを検討する必要がありますね。
Wait for Callbackに対応しているAWSサービス
- Lambda
- Amazon ECS/AWS Fargate
- Amazon SNS
- Amazon SQS
- Amazon EKS
- API Gateway
- Amazon EventBridge
- AWS Step Functions
- その他SDKで実装可能なAPI群
補足
トークンをコールバックしないと、Step Functionsは待機してしまいます。(待機の上限は1年間です。)
なお、後続ジョブの処理状況を確認するためにハートビートレスポンスと呼ばれる動作も行わせることができます。
ASLでハートビートの時間間隔を定義し、定義した時間内に成功、失敗、ハートビートのAPIレスポンスがない場合は
States.Timeoutエラーで失敗します。
何も考慮しないと1年間は停止してしまうことになるため、実装しておいた方が良いかなと感じました
処理結果はStep FunctionsのAPIを実行する必要がある点も考慮が必要ですね
タスクトークンは1024文字まで含めることが可能です。
まとめ
いつものまとめです。ユースケースで考えてみました。
ワークフローで定義するステートごとに統合パターンを選択できるので実装させたいワークフローの要件に合わせて選択していきたいですね。
参考
docs.aws.amazon.com docs.aws.amazon.com
島村 輝 (Shimamura Hikaru) 記事一覧はコチラ
最近ECS周りをキャッチアップ中。趣味は車・バイク全般。
一応、AWS12冠です。