目次
- AWS Simple Workflow とは
- なぜ Aws Simple Workflow なのか
表参道rb#12でSWFとMicroservicesについて発表して、SWF使おう！はやってないけど！みたいな話をしました。
そうしたら、お前がまず広めていってSWFの人になればいいよ、みたいな意見を貰ったので、全く流行ってないと思われるSimple WorkflowについてOutputしていこうと思います。ちゃんとサンプルコードとか載せていきたいです(夢想)
あと、間違ってたことがあったら言ってください！(予防線)
Aws Simple workflow とは
概略的な何か
Amazon Web Service が提供するワークフローを構築するためのサービスです。
大体今回書く話はこのスライドに書いてある気がします
ここでいうワークフローとは、いわゆる業務フローみたいなものです。大嫌いな あまり好きではない出張のためのスタンプラリーとか、工場のラインとかそういうモノです。
Aws Simple Workflow(以下SWF) ではワークフローを設計、コーディングする為のライブラリを提供し、ワークフローを動作させるためのQueueやAPIやユーティリティを提供します。
また、本質的にはSWFはJSONをやりとりするAPI通信さえできれば言語は問わないので、任意の言語でSWFを用いてワークフローを作ることが出来ます。
SWFにおける用語等について
| 用語 | 意味 |
|---|---|
| Workflow | 実行する一連の処理全て |
| Domain | Workflow を実行する領域。あんまりこれの意味がわからない。多分業務ドメイン |
| ActivityType | Workflowを構成する、処理を表す |
| AcitivtyWorker | ActivityTaskを実際に処理するワーカー |
| Decider | ActivityTaskが処理された後に、次の処理を決定するワーカー |
| WorkflowExecution | Workflowを流れる、処理されるタスク |
| ActivityTask1 | ActivityWorkerに処理をされる為のWorkflowExecution |
| DecitionTask1 | Deciderに処理をされる為のWorkflowExecution |
この方の記事のほうがわかりやすい気がします。→ http://qiita.com/uzresk/items/5401e8617d628f0ef9a9
タスクという言葉が多いけど、僕が上手に抽象化できていないことの現れ
SWFを使った処理の流れ
文字起こし
- まず何かしらが
WorkflowExecutionをスタートさせ、DecistionTasks(DeicitionTaskのQueue)に積みます -
DeciderWorkerがDecitionTasksをPoolingしているので、DeciderWorkerがまずWorkflowExeuctionを取得します。 -
DeciderWorkerがWorkflowExeuctionが次にいくべきActivityTypeを知っているので、WorkflowExecutionの情報を見て決定し、該当のActivityType AのQueue(ActivityTasks)にEnqueueします。 -
ActivityTasksをPoolingしているActivityWorkerがWorkflowExecutionを取得し、処理を行います -
ActivityWorkerは処理の結果や付随させたい情報等をWorkflowExecutionに書き込み、完了通知と共にDecisionTasksにEnqueueします。 -
DeciderWorkerは相変わらずDecisionTasksをPoolingしています -
3と同様に次のActivityTypeを決定します。今度はActivityType Aが完了しているという情報がWorkflowExecutionに詰まっているので、ActivityType BのActivityTasksにEnqueueします。 - これまた同様に、
ActivityWorkerはActivityTasksをPoolingしているので、Dequeueして処理を行います。 - ここで処理を完了したいので、
WorkflowExecutionを完了させます。
SWFが提供してくれること、AWS-SDKが提供してくれること
上記画像において、SWFのIconがある部分がAWSが処理を担ってくれる部分です。
また、SWFのIconに向かう矢印の操作はSDKが提供してくれています。
よって、最低限開発者が実装すべき点は以下です。
- 「XXという状態の
WorkflowExectuionの場合は、次はこのActivityTypeへいく」という判断をするDecider -
ActivityTasksをpoolingして、処理を実際に実行するActivityWorker
意外とシンプルなように見えますね
なぜ SWF なのか
Amazon Simple Workflow Casual Talk by Kenichi TAKAHASHI
殆どは↑のスライドに詰まっています。
更に補足すると、SWFの最も優れていると考えているのは以下の点においてです。
- SWFとのやりとり、SWF内でのやりとりは全て一意のトランザクションIDが振られており、追跡、失敗、復旧が容易
- SWFとのやりとり、SWF内でのやりとりにおける全てのEventは記録されており、追跡、分析が容易
- SWFのAPIを叩け、JSONを扱うことさえできれば言語も場所も問われないため、複数アーキテクチャ上から利用することも出来る
- スライドでも言及されているが、
ActivityType内での処理において人の手によって完了される事を想定されており、その完了を待つことが出来る。
- 上記特性のため、Queueからの受信は一回のみ（な、はず。何回か「同じ
ActivityTaskを取得したとしか思えないエラー」に出会った記憶が……) - 全てのEvent2が記録され、且つそのEventにトランザクションIDを付与し続ける事が出来るので、
ActivityType内での処理も適切にロギングできれば全ての行動を追跡出来る。 - ユースケースとして、オンプレミスとクラウドの共存状態が想定されているので、言語やアーキテクチャを問わないのはSWFのシステム上目指している事っぽい。
人の手によって完了される事を想定している？
工場のラインを考えるとわかりやすいです。
自動化されている部分は、全てのプログラム上で処理が進んでいき、ActivityTaskの取得から完了まで自動で行えばよいです。
しかし、目見チェックなどが必要な工程になったら、人が処理を完了させるまで次の工程に進んではいけません。
同じことを実現する事が出来るということです。
というか、ユースケースとしてこういう業務上のワークフローを想定していると思う。
次回予告
ここまではチュートリアル記事とかにも書いてあったりして、日本語記事も多いです。
今回は概要についてのみでしたが、深い実装の話とか今後していきたいと思います。
一応
Sansanでは名刺のデータ化において、一日数十万のWorkflowExecutionを処理しています。
(自称)世界一のSWFユーザーであるSansanはエンジニアを募集しています。
なんかデータ化の部署の募集要項が公式HPにないんですけど……