マイクロサービス時代のワークフローシステム 〜Netflix Conductor を例に〜 1

自己紹介 松下正嗣 Java プログラマー/ アーキテクト。クレディセゾン社で、ソフトウ ェア開発内製化に取り組んでいます。 最初の仕事は研修講師->SI の現場へ。 大学/ 大学院と文系でした。 趣味は演劇( 役者やる人) 2

お話しする内容 ちょっと国外で流行り出しているワークフローシステムとは何か いわゆる申請承認を扱うシステムではない いくつかの事例 ワークフローシステムが求められている背景。 OSS プロダクトのデモ 3

ワークフローシステムとは？ " もともと1 回限りのバッチパイプラインが継続的に結果を更新しなけ ればならないというビジネス上の要求に対応しきれなくたってしまっ ている... こうしたニーズに直面したに直面したGoogle は2003 年にWorkflow と いうシステムを開発したました。これは継続的な処理を大規模に行え るようにしたものです。" 『SRE サイトリラアビリティエンジニアリング』 25 章 データ処理のパイプライン 4

ワークフローシステムとは？ タスクを実行するワーカーとそれを制御するコントローラ スケーラブル(worker/controller ともに) 冪等でシンプルなタスクをworker が実行し、controller が制御する 人のタスクも組み込むことも可能。 worker Controller worker worker task 記録 割り当て 完了 制御 5

既存ツールとの比較 バッチ処理と呼ばれる長期/ スケジュールタスク ジョブスケジューラ(cron/ 商用スケジューラ/Apache Aireflow/ そ の他) スループットの大きい非同期処理には対応していない。 ジョブ実行サービスを立てることで準オンラインに対応している 場合も多いが、ジョブネット/ フローがスケジューラ管理。 6

既存ツールとの比較 主にシステム間連携に利用されるメッセージキューシステム/ オンラ イン非同期 メッセージングシステム/ ストリーミングシステム(IBM MQ/Rabbit MQ/Kafka) リトライや結果整合性は担保できるがフロー全体の管理とデータ 整合性確保は課題。DB などで頑張ることになる。 フロー制御が標準化されたものではなく、コードで頑張ることに なる 7

海外でのプロダクトの誕生 Temporal Uber で開発されたCadence をfork してビジネス化 Temporal のCTO はuber の前はAWS のStep Function の前身AWS Flow のエンジニア Thoutworks Tech Radar でも言及 Temporal のサービスはGo で書かれている。 worker はgo のほか、Java やNode.js やpython で記述可能 8

Temporal のアーキテクチャ 9

Temporal のWorkflow 様々な言語のSDK で記述。 workflow とtask(Temporal の中ではActivity) を全てコードで記述 // Workflow interface @WorkflowInterface public interface YourWorkflow { @WorkflowMethod String yourWFMethod(Arguments args); } 10

Conductor Netflix で開発されたデータパイプラインOSS 。独立してorkes 社 がビジネス化。 Conductor をベースにしたデータ処理基盤maestro をNetflix が最 近公開 Spring Boot ベースで記述 worker はJava だけではなく、Go やPhthon 、Clojure などでも 実装可能 11

Conductor のアーキテクチャ 12

Conductor のWorkflow Json で記述。GUI 機能あり。フロー制御あり。 workflow から呼ぶタスクはコード 13

実は結構いろんなコンポーネントやストレージサービ スが必要なので、自前で運用するのは結構めんどいっ て特徴が。 。 。 。商用サービスが成立する理由。 。 。 14

求められる背景 ジョブスケジューラでは対応できない、長期/ 短期の継続的データ更新パ イプラインの必要性 自動テストとCI/CD への対応 スケーラビリティ/ 低レイテンシー 分散システムの要求 処理が分散されたフロー全体の整合性の確保とリトライや例外処理/ サ ーガパターン 一時停止/ リトライ/ 作業との連携等の柔軟なビジネスフローの実現 ️ -> ビジネスロジックの時間的疎結合化 15

ビジネスロジックの疎結合化 紙での業務フローは本質的に疎結合。最終的に結果が整合すれば良 い。 ビジネスはコンピュータの中だけで完結しない。ユーザーとの連 絡、物理的な流通、人手による入力などによる対応がある。それら をうまくマネージできることがデジタルサービスには必須。 従来運用や人手で統合できなかったビジネスフローを実現する意味 で真のDX/ 新しいサービスには不可欠な基盤なのではないか。 16

ビジネスロジックの疎結合化 uber eats のサービス 注文- 店舗- ドライバー- 顧客を繋ぎ、イレギュラーな状態になると 多様なアクターが回復行動を行い、それがサービス上で実現す る。 住所が登録されてない、不在。商品作成の遅れ。 。 。etc 17

現実に使えるの？ Conductor OSS を例に 18

Conductor のストレージ デフォルトではキューをRedis で処理し、データストレージは RDB 、履歴等はelastic search でインデックス化 そこまでスループットを求めないならPostgreSQL でも可能。 19

Conductor の基礎概念 workflow タスクを実行するフロー。Json で記述する フロー制御やリトライを行う Task ワークフロー内で実行されるタスク ビルドインされたシステムタスクとworker が実行するタスクがある 20

開発手順 workflow とタスク API で登録 Task 定義 Simple タスクはworker を開発して実行。タスク名を持つタスクが実 行される。 21

Java Worker Worker インタフェースを実装する。 public class SampleJavaWorker implements Worker { private final String taskDefName; public SampleJavaWorker(String taskDefName) { this.taskDefName = taskDefName; } @Override public String getTaskDefName() { return taskDefName; } } 22

Java Worker Worker インタフェースを実装する。 //続き @Override public TaskResult execute(Task task) { System.out.println(task.getInputData()); TaskResult result = new TaskResult(task); result.setStatus(TaskResult.Status.COMPLETED); return result; } } 23

polling の設定と開始 main メソッドなどに記述する TaskClient taskClient = new TaskClient(); taskClient.setRootURI("http://localhost:8080/api/"); Worker worker1 = new SampleJavaWorker("task_1"); Worker worker2 = new SampleJavaWorker("task_2"); Worker worker3 = new SampleJavaWorker("sample.task1"); // Create TaskRunnerConfigurer TaskRunnerConfigurer configurer = new TaskRunnerConfigurer.Builder (taskClient, List.of(worker1, worker2,worker3)) .withThreadCount(3) .build(); configurer.init(); 24

実際の実行 API/UI 経由でworkflow を開始。 開始中のワークフローは実行ID 単位で一時停止/ 再実行など自由に できる SQS などのイベントとの連動も可能 workflow からworkflow を呼び出すなども可能 25

その他考慮点 バージョニング ワークフローにバージョンを指定することが可能 同じ名前でバージョン指定でworkflow を実行した場合、最新が実行される。 タスク設計の考慮事項 リトライが発生するため冪等性を担保すること SQS などのイベントとの連動も可能 冗長性 server の冗長化をする場合はEureka でマスターを決める worker も冗長化可能 26

まとめ conductor について 手軽に小規模スループットなら十分利用可能と思われる。 スケジュール機能など一部機能がOSS では制限されており、本格 的に利用するには商用版を使うことも検討してもいいかもしれな い。 temporal の方がOSS としての機能は充実しているが、管理がより 煩雑。その分スループットの大きいシステムでも対応できる。 27

まとめ 各種のサービスや業務フローを統合するワークフローシステムは魅 力的なデジタルサービスを開発するには不可欠であるという気がし ている。 OSS をベースにするか、商用製品を作るか、はたまた自分たちでユ ースケースにあった同等もしくはより狭いユースケースに特化した ものを開発するのか。 28

参考記事 Temporal というマイクロサービスオーケストレーションについて SRE サイトリライアビリティエンジニアリング サーガパターン データモデリングでドメインを駆動する──分散／疎結合な基幹系シ ステムに向けて 29