[レポート][API309] 高度なサーバーレスワークフローパターンとベストプラクティス #reinvent

はじめに

こんにちは、CX事業本部、re:Invent 2022 現地参加組の田中孝明です。

セッション概要

API309: Advanced serverless workflow patterns and best practices

AWS Step Functions Workflows を使用してアプリケーションを構築する経験豊富なサーバーレス開発者ですか?本番環境のワークロードで AWS Step Functions の機能を最大限に活用するためのガイドが必要ですか? Express Workflows と Standard Workflows のどちらを選択するか迷っていますか?または、マップ状態、並列状態、またはネストされたワークフローのどれを使用するか?このセッションでは、ワークフローとコストの最適化を構築するためのアーキテクチャのベストプラクティスと反復可能なパターンについて学び、安全で大規模で高性能なサーバーレスアプリケーションを構築するために使用できる便利なコードを見つけてください。実際の生産シナリオは、利点を示しています。

セッション

ここには、デプロイ可能なテンプレート、CDKテンプレート、いくつかの機能に関するブログ記事があります。 紹介ビデオや説明ビデオもたくさんあります。 ワークショップや新しい機能のワークショップ、コードサンプルもあります。

アプリケーションを作るときに、なぜ AWS Step Functions を使うべきだと思うのかその理由をお話しします。 AWS Step Functions Standard Workflows して実行する場合と、AWS Step Functions Express Workflows として実行する場合のさまざまなモードについて説明します。 ワークフローを最適化することでコストを削減する方法について、エラーを処理するためのいくつかのパターンについてもお話しします。 最後に Werner のキーノートで紹介された、AWS Step Functions を使ってスケーラビリティを実現する Distributed Map についてお話しします。

サービスに依存してアプリケーションを構築する場合、複数のサービスに依存しなければならないことが多くなります。 そうなると課題は、これらのサービス間でどのようにデータを受け渡すかということに変わってきます。

どのようにオーケストレーションするのか、アプリケーションにうまくマッチする非同期のイベント駆動のアプローチを使うのか。 AWSの多くの異なるリソースやサービスにまたがっているアプリケーションを可視化・構築・検査するのに、AWS Step Functions が役に立ちます。

AWS Step Functions は、ワークフローを作成できるAWSのサービスです。 ステップの出力を次のステップの入力に移動させることができます。それを条件論理分岐、並列状態ループという形でアレンジすることができるのです。 AWS Step Functions はサーバーレスです。利用するごとに料金が発生します。

DynamoDB からデータを取ってくる Lambda を書くとき、複数行のコードを書かなければならないのです。

AWS Step Functions に移行することで、多くの価値を得ることができます。 1ステップのワークフローで DynamoDB のアイテムを取得するだけですみます。 このワークフローは拡張性があり、リトライの設定もできますし、エラーをキャッチしてデッドレターキューに送る設定もできます。

AWS Step Functions でワークフローを実行するには、2つの方法があります。Standard Workflows と、Express Workflows です。

Standard Workflows は最初に作られたものです。これらは長寿命で1年まで稼働させることができます。また、非同期型です。Standard Workflows を起動したら応答を待つのではなく、他の手段で応答を取得する必要があります。 Express Workflows は2019年に導入されたものです。高いスループットを持ち、ステートをより速く移行できます。ある入力で Express Workflows を起動すると、重複して実行される可能性があるので、与えられた入力で何度実行しても同じ結果にする必要があります。これは同期で実行することも、非同期で実行することも可能です。Amazon API Gateway 経由でリクエストを送信し、同期的に実行できることが Express Workflows を選ぶきっかけになります。ただし、5分でタイムアウトする点には注意が必要です。

同期やタスク待ちのコールバックパターンを使いたい場合、Express Workflows として実行することはできない。また、一度だけ実行する必要がある場合は、Standard Workflows として実行しなければならない。 同じワークロードで両方のワークフローを使ったパターンです。 ネストされたパターンで、親の Standard Workflows から、同期型の Express Workflows の子ワークフローを呼び出すことで、Express Workflows のコストメリットと、Standard Workflows のメリットを得ることができます。

これはコールバックパターン、あるいは may be と呼ばれるものです。

アクションはSNS Topic の Publish で、トークン待ちと書かれています。SNS Topic にペイロードに SNS Topic の固有のタスク・トークンを追加しています。 AWS Step Functions は、他のサービスからそのトークンが戻ってくるまでこのタスクを待ちます（最長で1年間）。 AWS Step Functions に「これがさっきのトークンです、今すぐ続けてください」と伝えます。このパターンは、あらゆる種類の興味深いユースケースに広がっていきます。

生産ラインのように、個々のマイルストーンを達成しないと進めないようなワークロードがあるとします。

そしてタスク・トークンとともにイベントブリッジ・イベントバスにイベントを発信し、ワークフローはそこで一時停止します。 そのイベントを DynamoDB にトークンを保持させます。（ワークフローを再開するために必要）

一旦別のワークフローを実行し、それが終わると、DynamoDB からタスク・トークンを取り出して、「マイルストーン1が終わったから、先に進んでいいよ」と言って、マイルストーン2へと移行します。 マイルストーン2のタスク・トークンはそのままにしておきました。しかし、最長で1年間も待つのは嫌だとしましょう。ある時間内に何も起こらなかったとしましょう。15分以内にワークフローが終了しない場合、それ以上実行されないようにします。そこで、ハートビートと呼ばれるものを設定することができます。

6つのステートに加えて、何回forループを繰り返しても、必要なのはトークンを追加する前のステートだけです。 ワークフローから多くのステートを削除し、8つのステート遷移だけになりました。

彼は基調講演で、「すべてのものは常に失敗する」と言ったことで有名です。 AWS Step Functions には、失敗に対処するための素晴らしいメカニズムがあります。

これはサーガパターンと呼ばれるパターンです

例えば、予約システムがあって、ホテルを予約し、飛行機を予約し、車を予約するとします。これらは順次処理されるのでハッピーパスで終了せず、例えばホテルの予約タスクが失敗し、その失敗をキャッチしてホテルのブロックを解除できるようロールバックする必要があるとします。 ワークロードのどの部分が失敗したかによって、ウォーターフォール的にロールバックしたり、ロールバックしたりすることができます。

これはサーキットブレーカーと呼ばれるものです。DynamoDB でアプリケーションの全体的なステータスを管理し複数のリクエストを防ぐのに適しています。マイクロサービスや AWS Lambda に何度もリクエストするのを防ぐことができます。

AWS Step Functions をスケールアップする方法に並列処理と並行処理があります。 並列処理は少なくとも、同じ入力を別のステップや別のワークフローで処理することです。一方、並行処理とは、同じ手順で毎回異なる入力を行うことです。

お客様からは、AWS Step Functions がより大きな配列で同時処理できるようなアプリケーションを構築する方法をもっと増やしてほしいという要望がありました。Werner博士の基調講演でも言及された、Step Functions Distributed Map State は大きな出来事です。

Step Functions Distributed Map State は最大1万回の並列実行が可能です。JSONファイル、CSVファイル、ムービーファイル、画像など、何百万ものS3オブジェクトを繰り返し処理することができ、マップの中で AWS Lambda などを呼び出すこともできます。

マップステートには2つのモードがあります。 インライン・モードと分散モードです。

インラインモードは、マップステートを正式に表示するもので、分散モードは新しいバージョンです。 分散モードの場合、Standard Workflows か Express Workflows で実行するかを選択することができます。 先ほどの話を総合すると、ワークロードに適しているのであれば、デフォルトでエクスプレス・ワークフローとして実行することをお勧めします。また、バッチを設定することで、アイテムを一括して処理することも可能です。

Step Functions Distributed Map State のデモです。そして、サーバーレスGifジェネレーターと呼ばれるものを作りました。

S3 に mp4のムービーアイテムをドロップするとワークフローが起動します。 ワークフローはムービーの30秒ごとにGIFアニメーションを生成し、タイムラインのようなアプリケーションに入れることができるのです。

S3 に mp4のムービーアイテムをドロップするとワークフローが起動します。 ワークフローはムービーの30秒ごとにGIFアニメーションを生成し、タイムラインのようなアプリケーションに入れることができるのです。

ワークフローでは FFmpeg の AWS Lambda を使って、1回の Put が30秒だとしたらファイルにはいくつのGifアニメが必要なのか、それぞれのGIFアニメーションのメタデータの配列を作成し、S3 に保存します。

そして Step Functions Distributed Map State が起動するとその配列を取り出し、各GIFアニメーションに対して個別の AWS Lambda を実行し、それを S3 にエクスポートし直します。

このサンプルは22個の小さなクリップですが、5時間の映像に適用することもできます。うまくいけば、実行にかかる時間はほぼ同じになります。

所感

AWS Step Functions を使った様々なパターン、用途の違いから、新機能である Step Functions Distributed Map State の機能やデモなど盛り沢山な内容でした。ワークフローコレクションにも新たに追加されているようなので、是非活用していきたいです。