AWS公式サンプルを使用してStep Functionsサービス統合の挙動を理解する

記事タイトルとURLをコピーする

こんにちは。島村です。
個人的になぜか2月の終わりを感じています。
2月は気を抜くと、すぐに終わってしまうので意識して毎日を過ごしていきたいですね。

さて、今回はStep Functionsのサービス統合パターンを
公式サンプルを使用しながら挙動を確認していく内容です。

Step Functionsとは

Step FunctionsはAWSのオーケストレーションツールです。
オーケストレーションとは、アプリケーションやサービス、設定、管理の自動化を指します。

Step Functionsに対応するAWSサービスを活用したり、アプリケーションの処理をワークフローのように構成することが可能です。

アプリケーション処理の並列化、処理の成功時、失敗時の分岐、とある処理が完了するまで停止したり、 ワークフローを柔軟に構成することもできます

ワークフロー自体はGUI操作で定義することもできますし、Amazon States Languageと呼ばれる JSON構造の定義ファイルを使用してワークフローを作成することもできます。

aws.amazon.com

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サービス

補足

トークンをコールバックしないと、Step Functionsは待機してしまいます。(待機の上限は1年間です。) なお、後続ジョブの処理状況を確認するためにハートビートレスポンスと呼ばれる動作も行わせることができます。

ASLでハートビートの時間間隔を定義し、定義した時間内に成功、失敗、ハートビートのAPIレスポンスがない場合は States.Timeoutエラーで失敗します。
何も考慮しないと1年間は停止してしまうことになるため、実装しておいた方が良いかなと感じました
処理結果はStep FunctionsのAPIを実行する必要がある点も考慮が必要ですね

タスクトークンは1024文字まで含めることが可能です。

まとめ

いつものまとめです。ユースケースで考えてみました。

ワークフローで定義するステートごとに統合パターンを選択できるので実装させたいワークフローの要件に合わせて選択していきたいですね。

参考

aws.amazon.com

docs.aws.amazon.com

docs.aws.amazon.com docs.aws.amazon.com

docs.aws.amazon.com

docs.aws.amazon.com

島村 輝 (Shimamura Hikaru) 記事一覧はコチラ

最近ECS周りをキャッチアップ中。趣味は車・バイク全般。
一応、AWS12冠です。