AWS Step Functionsの、分散アプリ構築・運用手法としてのユニークさ：AWS re:Invent 2016（2/2 ページ）
米Amazon Web Services（AWS）が「AWS re:Invent 2016」で発表した「AWS Step Functions」は、ユニークなサービスだ。分散アプリケーションの開発・運用を新たな形で実現するツールと表現できる。
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ファンクションを呼び出している。
また、Bray氏は、原因は必ずしも分からないが、ファンクションを1回実行しても失敗し、何回か再実行するケースがあることを説明し、こうしたときのためにエラーを受けてリトライするプロセスを紹介している。
AWS Lambdaを超えた利用が広がる可能性も
「マイクロサービス」「分散アプリケーション」というと、現在に至るまで、コンテナ環境を考えるケースが多い。一方、イベントドリブンなステートレスアプリケーションの構築・運用手法として、AWS Lambdaのようなサーバレスコンピューティングが登場している。小型でシンプルなLambdaファンクションを使い、機動的に一定の処理を書いて実行できるのは便利だが、複数のLambdaファンクションを相互連携させて、より複雑な処理を行おうとすると、気軽に使える柔軟な仕組みがなかった。Step Functionsは、こうした問題を解決する機能だという。AWS Lambdaがコンテナ環境を完全に代替することはなくとも、Step Functionsがその守備範囲を広げることで、「分散アプリケーション」の構築・運用における選択肢の1つとして、考えられやすくなってくる。
本記事の冒頭でも触れたが、現在のところAWSはStep Functionsを、主にAWS Lambdaのための機能として紹介している。だが、実際にはコンテナ、仮想インスタンス、オンプレミスのさまざまなアプリケーションを、Step Functionsで連携させることができる。Step Functionsは、アプリケーション構築・運用における「レイヤ」の概念を越えて、処理プロセスを迅速に構築し、テスト・運用を楽にするツールとして使われていく可能性がある。
Copyright © ITmedia, Inc. All Rights Reserved.