Temporal: 新しいワークフロー基盤を試してみようという話

Temporalとは

Uberで作られた信頼性の高いワークフロー/非同期実行基盤であるCadenceをforkして作られたもの。Cadenceを作った人たちがTemporal Technorogyというスタートアップを起業して作ったらしい。マネジメントサービスを提供してお金にしようとしているみたい。

なぜ試したいのか。

最初の動機は社内の昔ながらのジョブスケジューラ(日立のJP1/富士通のSystem Walker Operation Manager/IBM Tivoli/NTTデータのHinemos)から、もっとDev Opsとか開発者フレンドリーさであったり、クラウドとの親和性でったりしたものがないかと探していた。

ワークフローシステムとは

他の選択肢も色々検討してた。そもそもワークフローシステムと一口で言ってもかなり色んなユースケースだったり、ニュアンスの違いがある。自分が色々調べながら思ったのは以下のような分類。

システム運用/データ処理自動化

伝統的なジョブスケジューラは基本的には「システム運用」の自動化を目指したもので、インフラエンジニアとか運用エンジニア、今だとSREなんかが触るものとして設計されているように思われる。

Jenkins/Algo workflow/Apatche Airflow/Prefectなんかも結構その系統と思われる。

最近ではデータ分析が盛んになったので、プログラマーではないMLエンジニア、という新しいカテゴリも出てきたが、上記の比較的モダンなワークフローシステムはそういったニーズも意識して改善されているように思われる。

非エンジニア向けのローコードワークフロー

基本的にはアプリケーションの機能として提供されているもの。Saleforceであったり、oktaであったり、非エンジニアでも編集できるようになっている。

アプリケーションとしてのワークフロー

第3のカテゴリとしては、製品としてはActiviti/Camundaなどが該当する。よりプログラマーが扱うことを想定したワークフローシステム。

アプリケーションの中にワークフローが組み込まれるという形になる。多くの場合、そのアプリケーションはイベント駆動/非同期処理方式になり、その機能も備えている場合も多い。最近ではマイクロサービスを意識したSagaパターンの基盤として売り出そうとしているみたい。

ワークフローシステムの曖昧さ

ワークフローシステムは、結構面倒なのが、上記三つのカテゴリが意外とそれぞれが別のカテゴリの役割に担える傾向があること。伝統的なSIの開発では業務ロジックになる部分をジョブスケジューラのジョブネットで表現していた。結局ジョブスケジューラが無ければ、業務ロジックをテストできないってことになる。

プログラマー中心主義

自分のチームは基本は全員プログラマーで、どっちかというとプログラマーがインフラも見るって形になっている。当初はApatche AirflowやAlgo workflow(k8s使うので)を検討したのだけど、やはり、ワークフローを通常のコードと同じようなプロセスでテストやCIに乗せられるってこと、非同期処理なんかのニーズも増えていることもあり、３つ目のカテゴリであるActiviti/Camundaも試しに触って見てたりした。

そんな中、Java屋には有名なアメリカのソフトウェア開発コンサルティング会社Thoutworks のTechnorogy RaderにこのTemporalが紹介されていた。

Temporalのアーキテクチャと思想

システムアーキテクチャ

Temporalはワークフローを実行するworkerプロセスとそれを管理するサービス群(Temporal Cluster)の２種類に分けれれる。

https://docs.temporal.io/diagrams/temporal-platform-simple.svg

Temporal Clusterはgoで書かれており、workerは様々な言語で開発可能なSDKが提供されている。gRPCでworkerとClusterは接続され、登録されたワークフローの実行をworkerが行う。Clusterはworkerがワークフロー実行することをリトライなどを駆使して保証してくれる。

これは、CEOの人がAWS/Azure/Uberなんかでやってて、得た知見をもとにしているみたい。

ワークフローの書き方

ワークフローはそれぞれのSDKで普通にプログラミング言語で書く。Javaだとインタフェースを駆使してかく。ワークフローの内部でActivityを呼び出し、その結果などを判定してフローをコードで書いていく。普通のコードなので、普通にテストが書ける。

TemporalではActivityはリトライを繰り返し、実行されることを保証させ、ワークフローは一度だけ確実に成功するってのが典型的な設計。リトライしないように設計することもできるが、その場合も実行するときにworkerが落ちてた時などはworkerが復旧して接続されるまで待ってくれる。これをTemporalはDurable Executionと言っている。

Activityは決定論的に記述することが推奨される。まあ、何度やっても結果が同じってことで冪等性ってことなのかな、と思っている。DBインサートとかの場合には、一意のキーを使ってそれを実現しろ、って言ってますな。

良いと思った点。

  • 色んな言語でかける。ビジネスロジックはJavaで、基盤的なところはgoで、とか。
  • プログラミングなので、なんかあってもどうにでもなる。
  • ビジネスロジックと切り離せるため、移行が容易
  • 信頼性の考え方がわかりやすい。

実は何より良かったのは、結構触ってみて、すぐ動かせたってこと。そして、複雑な要件を検討したところ、本当に色々考えられていて、かなり多くのユースケースに問題なく適用できそうってことを確認できた。

例えば、 - 長時間かかる大量ファイル処理 - ワークフローのアップデート/バージョンアップ - 監視/障害時調査と復旧 - 性能/データ量

チームのシニアエンジニアに見せても、パッと見て、「良さそう！」と印象を持ったとのこと。

加えて、slack見るとかなりちゃんとサポートしてくれているみたい。

実績

一応実績見ると、多分、CEOの人の人脈ありきだと思うけど、Netflix/ Datadog/ BOXみたいな誰もが知る優良企業でも使われているみたい。