AWS Step Functionsの、分散アプリ構築・運用手法としてのユニークさ：AWS re:Invent 2016（2/2 ページ）

[三木泉，＠IT]

JSONを活用、ビジュアルなワークフロー画面も使える

　Step Functionsでは、一連のアプリケーションワークフローを「State Machine」と呼び、これをJSON形式で記述する。同サービスで使う記述言語はBray氏が定義、「Amazon States Language」という名称で公開している。

　State MachineはCLIで指定することもできるが、AWS ConsoleにおけるStep Functionsのコンソールでテンプレートを活用して入力することも可能。

　各State Machineは、単一あるいは複数のStateの連続で表現される。Stateのタイプとしては、Lambdaファンクションなどの実行を記述するTask Stateの他、実行形態を示すChoice State（条件分岐）、Parallel State（並列処理）、Wait State（タイマー処理）などがある。

　下はTask Stateの例。TypeではTask Stateであることを宣言。実行するLambdaファンクションをResourceとして指定し、Nextでは実行後に引き継ぐState名を指定している。

"HelloWorld": {
  "Type": "Task",
  "Resource": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorld",
  "Next": "NextState",
}

　State Machineを構築すると、下図のようにプレビュー画面でグラフィカルに表現される。実行すると、このグラフィカルな画面と履歴画面で、実行結果を逐一示す。良好に実行されたステップは、順次緑色に変わっていく。こうして、実行状況を自動的にほぼリアルタイムで可視化する。障害が発生した場合も、どこで起こったのかが即座にトレースできるようになっている。

アプリケーションのフローがグラフで表示される。実行すると、成功したタスクは緑色で示される。また、各タスクの実行結果については、履歴から詳細に追跡できる。

　下は、Bray氏が示した条件分岐の例。JSON PATHを指定して取り出した値に応じて、別のLambdaファンクションを呼び出している。

Step Functionsのベータテストに参加した「THE TAKE」というWebサービス企業が試した例。グラフではこのようになっている

JSONでは、値に応じて別のLambdaファンクションを次に呼び出す条件分岐を行っている。

　また、Bray氏は、原因は必ずしも分からないが、ファンクションを1回実行しても失敗し、何回か再実行するケースがあることを説明し、こうしたときのためにエラーを受けてリトライするプロセスを紹介している。

Lambdaファンクションの実行エラーが返ってくると、最大10回再実行するプロセス

AWS Lambdaを超えた利用が広がる可能性も

　「マイクロサービス」「分散アプリケーション」というと、現在に至るまで、コンテナ環境を考えるケースが多い。一方、イベントドリブンなステートレスアプリケーションの構築・運用手法として、AWS Lambdaのようなサーバレスコンピューティングが登場している。小型でシンプルなLambdaファンクションを使い、機動的に一定の処理を書いて実行できるのは便利だが、複数のLambdaファンクションを相互連携させて、より複雑な処理を行おうとすると、気軽に使える柔軟な仕組みがなかった。Step Functionsは、こうした問題を解決する機能だという。AWS Lambdaがコンテナ環境を完全に代替することはなくとも、Step Functionsがその守備範囲を広げることで、「分散アプリケーション」の構築・運用における選択肢の1つとして、考えられやすくなってくる。

　本記事の冒頭でも触れたが、現在のところAWSはStep Functionsを、主にAWS Lambdaのための機能として紹介している。だが、実際にはコンテナ、仮想インスタンス、オンプレミスのさまざまなアプリケーションを、Step Functionsで連携させることができる。Step Functionsは、アプリケーション構築・運用における「レイヤ」の概念を越えて、処理プロセスを迅速に構築し、テスト・運用を楽にするツールとして使われていく可能性がある。