Amazon Simple Workflow ServicesをAWSCLIで使ってみて理解する

ちょうどAWS上でワークフローが必要になるような業務を実装することになったので、アーキテクチャを考えてみました。
もちろん、それらのワークフローの実施が冗長化されており、同時にスケールすることも前提で。

…と、意気込んで以下のコンセプトを元にしたアーキテクチャ図を考えていました。

• １つの処理の流れの状態を常に持っている (どこまで進んだか、それぞれ中間でどのような結果となったか、など)
• それぞれの処理はLambdaで実装し、上記で示した状態を受け取る
• Lambdaも処理全体をコントロールするControllerと、具体的なサブタスクを実行するSubfunctionsに分ける
• 各Lambda Function自体は入力のみに依存した処理を実行できるのでステートレスを保てる
• Lambda Functionの終了時に後続作業がある場合は、入力を変更したメッセージを用意したSQSに投げる。 この時、必要であればDelayオプションを使って実行を遅延させる
• 処理途中のSQSのメッセージキューはポーリングされており、適切なタイミングで拾われ、再度Lambdaを実行させる (Lambda側では状態に基づいた処理を行い、何も無くなったら処理を終わらせる)

理論的には実装できなくもないですが、問題も数多く有ります。
例えば、次のようなものです。

• SQSのメッセージは2度以上取得される可能性があるため、実行を1度のみに保証する場合の作りこみが大変
• SQSの順序保証が無いため、実行順序が重要な場合は使いづらい
• １つの処理の流れが何処まで進んだかの可視化が難しい

どうしたものか…と悩んでいたのですが、前々からやけに概念を理解するのが難しそうで避けていたAmazon Simple Workflow Services (SWF) とほとんどそっくりな考え方であったのと、SQSの性質に基づく問題が解決できるということもあったので、本腰を入れてSWFを調べてみることにしました。

日本語の資料が少ないのもあれですが、SWFを紹介している資料は多くの場合はAWS Flow FrameworkというSWFを実装するためのライブラリを利用してSWFを紹介しているものが多かったです。
ただ、これだと個人的には非常に理解しづらかったので、AWSCLIから(ほぼ)APIレベルで機能を使ってみつつ、SWFの仕組みの理解をしようと試みました。
結果としては、APIだけを使ってみると非常にシンプルなできになっている上に、非常に汎用的で使い道も数多くありそう、という結論が得られました。