The AWS Step Functions workshop API201-R1 に参加したレポートです。
Workshopは現在公開されているので、現地で参加していなくても実際に触って動かすことが可能です！(AWSアカウントは自分で用意する必要あり)
この記事の目的
- StepFunctions触ってみようという動機付け
- 実採用を検討するとき参考になりそうなリンクの提供※
- re:InventでのWorkshopについて雰囲気を伝える(英語ヨワヨワの自分の体験ベース)
※ざっと触ったあと、対応する公式ドキュメントの記載を見ておくと記憶の定着や、あとで採用を検討するための正しい理解と裏付けに役立つので備忘録を兼ねてリンク貼ってみました
会場
前のほうに座って、そこからの景色しか撮れていませんが、実際は5人がけの机が20個くらいありかなり広かったです。電源タップがあるので充電しながら参加です。
re:Invent初日の朝のWorkshopということもあってか、同じ机になったひとから立て続け２人にre:Invent会場Wifiのパスワードを聞かれましたが、キャプチャをとっていたのでそれを見せつつ「Here it is」「(You are) welcome」と定形コマンド発言と雰囲気だけでのりきりましたが、あぁ会話できるようになりたいなぁとも思いました。
Introduction
最初にStepFunctiosの概要説明とWorkshopの流れの説明がありました。
記憶とメモとOtterによる文字起こしから覚えているところだけ雑に意訳+補完で再構成して記載します。
わからんわ、という方はよければ弊社エンジニアがStepFunctionsの初心者向け勉強会をしたときの動画(日本語)も参照くださいmm
概念(primary concepts)
StepFunctionsとはローコードのワークフローサービスで、AWSの各サービスをオーケストレーション※できます。
※補足：マイクロサービスの「オーケストレーションパターン」のことを指す理解でいいと思います
中央のコーディネータ(今回の場合はStepFunctions)が、各種AWSサービスを呼び出し、処理の流れ(フロー)をコントロールします。
一般的なパターンと、リトライ・エラーハンドリング、並行処理をサポートしこれらの実装をシンプルにするため、開発者が顧客のビジネスロジックに集中できます。
以降で説明のあった各概念について記載します。公式ドキュメントのStep Functions 仕組みにも各概念についてまとまっています。
ワークフロー
ワークフローは論理的な処理の流れのことで、しばしばステートマシンとも呼ばれます
StepFunctionsのワークフローはAmazon States Language(=略:ASL)というJSONベースの言語で記載します。
Workflow Studioを使えば視覚的にワークフローを構築することもできます。
ステート
ステートはワークフローの中で入力を受け取り、アクションを実行し、次のステートに出力を行います。
標準(Standard) vs Express
StepFunctionsには「標準ワークフロー」と「Expressワークフロー」の２種類が存在します。
https://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/concepts-standard-vs-express.html
に記載の内容をベースに語られていました。
以下、ドキュメントからの引用
- 標準ワークフロー:長時間実行され、耐久性が高く、監査可能なワークフローに最適です。最長 1 年間実行でき、実行完了後 90 日以内であれば Step Functions API を使用して完全な実行履歴を取得できます。
- Express ワークフロー:IoT データの取り込み、ストリーミングデータ処理と変換、モバイルアプリケーションのバックエンドなど、大容量のイベント処理ワークロードに最適です。これらのワークフローは最大 5 分間実行できます。
補足：実採用を検討するときはStepFunctionsのクォータ(割り当て)も併せて確認しておくのがよいかと思います。
Task Patterns
Reposseパターン
長時間実行されるサービスがある場合、そのサービスがいつ完了するかには注意を払わず、そのまま次のステップに進みます。
(=リクエストの応答だけ確認し、完了を待たず次のステップに進む)
WorkshopのModule2で体験できます
Sync(polling)パターン
このパターンを使用すると呼び出し先サービスのモニタリングができる。
(=リクエストの完了まで確認してから次のステップに進む)
WorkshopのModule3で体験できます
Call Backパターン
(ここは実際の説明はキャプチャありきの内容だったので、ドキュメントの内容から引用してます)
タスクトークンが返される(CallBackされる)までワークフローを待機させる方法。
WorkshopのModule4で体験できます
実際にModule4をやるか例を見るのがわかりやすいと思います。
Workshop
各ModuleでベースとなるCloudFormationテンプレートが用意されていて、必要なリソース群を簡単に作成できます。
そのあと実際に作成されたStepFunctionsの定義(ASL)を見て仕組みを理解したり、実行してみて流れを追ったり、手を加えたり、ヒントを元に改修して挙動の変化を確認します。
実際にWorkshopで手を動かす時間は2時間弱。
最初にModule1をみんなでやったあとは各々好きなものを進めます。
手をあげるとエキスパートのメンターがきてくれるので詰まってるところ質問したり議論したり。
Module一覧
- Module 1 - Hello World
- Module 2 - Request Response
- Module 3 - Run a Job (.sync)
- Module 4 - Wait for a Callback with the Task Token
- Module 5 - Choice State and Map State
- Module 6 - Input and Output Processing
- Module 7 - API Gateway, Parallel State, Express workflows
- Module 8 - Error Handling
- Module 9 - AWS SDK service integrations
- Module 10 - Deploy with AWS CDK
- Module 11 - Deploy with AWS SAM
- Module 12 - Observability Resources
当日、自分がやったModule
Module1,3,4,5をやりました。
あまり詰まりはしませんでしたがドキュメント見ながらやったり、使われているリソースの中身を見たりで2時間弱フルで使いました。
Module1 - Hello World
パラメータで指定した秒数待機してから次のフローへ移るのを確認するというModule。
示された手順を実行したあとm指定パラメータを5から20に変更してみて、実際に長い時間(20秒)待つのを確認したりしました
{ "timer_seconds": 5 }
Module3 - Run a Job (.sync)
リクエストの完了を待たずに次のステップへ進むワークフロー(Responseパターン)を実行したあと、リクエスト完了まで待つように変更して挙動を確認するModule。
.syncサフィックスをつけるだけで完了まで待つようになるのを知らなかったので「へぇ〜」と思いました。
実行履歴を見てみると
Responseパターンではリクエスト登録だけで「TaskSucceeded」までイベントに遷移しているが
Syncパターンではリクエスト登録では「TaskSubmitted」というイベントに遷移し、実際に完了してから「TaskSucceeded」に遷移しているのを確認できた。
Module 4 - Wait for a Callback with the Task Token
StepFunctionsからSQSに対してタスク&トークンを発行し、それを受けたLambdaが処理実行後にコールバックするというModule。
これをやることでトークンをどうやって生成し、タスクに引き渡し、受け取った非同期サービス(今回はLambda)側でコールバックどうやっているのか理解できた。
トークンはASLのなかで "TaskToken.$": "$$.Task.Token" と書いているところでStepFunctionsが勝手に生成してくれそうだが、ドキュメント見ても確信がなかったので勇気を出して手をあげる。
来てくれたメンターに「"TaskToken.$": "$$.Task.Token" 」の部分を見せながら「Is this token generated by stepfunctions?」「Automatic?」ときいてみたら「Yes」x2と回答だったのであってるっぽい。もし答えがNoで詳細な説明があった場合、聞き取れたか危ういので安心したが、Noパターンのほうが勉強と英語の練習にはなったかもしれない。
コールバックはLambdaのコードで
var stepfunctions = new AWS.StepFunctions({apiVersion: '2016-11-23'});
~~
const params = {
output: "\"Callback task completed successfully.\"",
taskToken: taskToken
};
let response = await stepfunctions.sendTaskSuccess(params).promise();
としており
StateMachine(ワークフロー)名を指定/特定せずStepFunctionsサービスそのものにSendTaskSuccessしてトークン渡すだけなところが「へぇ〜」と思いました。
Module 5 - Choice State and Map State
Choice(分岐)とMap(配列に対して一連の処理をする)について学べるModule。
CloudFormationでスタックを作成しただけでは動く状態になっておらず、ヒントを元に改修するタイプ。
後半まで読んでしまうと、ヒントというか答えが載っている。
MapはPythonのMap関数のようなものだとイメージはついていたが
実際にStepFunctionsでどう定義するのか知りたかったのでASL定義を見たりしていた。
SQSにたまったメッセージをポーリングし、Mapでそれぞれのメッセージに同一の処理をするという内容でわかりやすい。Iteratorというフィールドの中に各配列の要素に対して行う処理を定義するっぽいが、フィールド定義のドキュメントはまだちゃんと読み込めていない。
re:InventでWorkShop初参加してみて
広い机で電源タップもあり、快適でした。
Workshopの説明はスクリーンに映し出される細かい文字も読めた方がわかりやすいので、前の方の席に座っておいて良かったと思います。
自分は道を聞いた時のヒアリングもわからない部分かなりあるくらいなので、手順がドキュメントになっているWorkshopをまず入れたのは正解だったかもしれない。同じテーブルの人がメンターに質問したりしているのを聞いて「あぁ言葉は違っても同じエンジニアなんだな」と当たり前のことを感じれたりもしました。
StepFunctionsについて
StepFunctionsは2016年のre:Inventで発表&リリースされたサービスです。
私は2016年6月から今の会社に入りAWSを触り始めたのですが、当時発表されてからStepFunctionsを題材にしたLTを作成し自社の忘年会やJAWS懇親会で喋ったり、年明けには某案件のバッチ処理のフロー制御にStepFunctionsを採用することを決め開発と運用も自分でしたので個人的に思い入れのあるサービスでした。
それから6年、バッチ処理で採用した以降はアップデートをざっく追ったり、同僚の設計や実装をレビューするくらい。自分で手を動かすことが数年なかったので今回はいいフォローアップの機会となりました。