メッセージキュー型の非同期処理から Temporal 移行へ

Transcript

1. メッセージキュー型の非同期処理から Temporal 移行へ ── アーキテクチャ選定と浸透のための取り組み shibutani / @s_k_526 2026 年 4 月 27 日 Background Job Talk
2. 自己紹介 shibutani / @s_k_526 株式会社 LayerX Platform Engineering 部 Enabling チーム 2025年新卒入社 最近はCLI盆栽に勤しむ（特にcc〇〇とかagent- 〇〇を作っています） © LayerX Inc. 2
3. 今日の内容
4. 今日の内容 © LayerX Inc. メッセージキュー型の非同期処理から Temporal への移行 浸透のための取り組み①：Protobuf からのインフラコード生成 浸透のための取り組み②：コンテキスト伝搬 浸透のための取り組み③：Temporal向け認可トークン 4
5. 1. メッセージキュー型の非同期処理から Temporal への移行
6. 前提：対象システムの構造 システム構成 非同期処理が必要な場面 © LayerX Inc. マルチテナントシステムのバックエンド 複数の Connect RPC サーバーがドメインごとに分かれて稼働 長時間・重い処理が日常的に存在 ドキュメント処理パイプライン LLM を使った長時間処理 6
7. これまでの非同期処理基盤 Source EventBridge SQS Worker Connect RPC Server © LayerX Inc. EventBridge → SQS → Worker → Connect RPC のパイプライン 7
8. この構成のメリットとデメリット メリット デメリット © LayerX Inc. 非同期処理が通常の Connect RPC と同じ形で書ける 開発、デバッグに既存のエコシステムがそのまま利用できる 同期と非同期のリクエストが同じ Connect RPC サーバーに到達 非同期は重く長いので、同期 API のレイテンシ・スループットを劣化させる 状態永続化も無く、途中再開やリトライロジックがアプリ側に必要 8
9. 独立した非同期処理基盤が欲しい 要件 → これらを満たす基盤として、Temporal を採用 © LayerX Inc. 同期処理 とワークロードを物理的に分離 状態永続化・途中再開・リトライを基盤側で担保 運用の可視性（実行状況・失敗調査） 9
10. Temporal とは © LayerX Inc. Workflow を中心とする Durable Execution エンジン Workflow の状態を自動永続化 → 障害が起きても続きから再開可能 Worker / Task Queue モデルで処理の分散・スケールを担保 実行状況・履歴をWeb UI で可視化・失敗リトライも Web UIで可能 10
11. どう組み込むか ── アーキテクチャ選定
12. 比較検討した 3 案 Option 概要 A EventBridge → SQS -> Worker → Temporal B 各サービスから直接 Workflow を起動 C EventBridge → Lambda → Temporal © LayerX Inc. 12
13. A: 既存Worker拡張の問題点 SQS と Temporal Task Queue の二重管理 StartWorkflow Source EventBridge SQS Worker Connect RPC Server Temporal © LayerX Inc. Temporal 自体がキューイング・リトライ・可視化を備える それなのに SQS 側のキューも並行で運用 13
14. A: 既存Worker拡張の問題点 既存 Worker の責務肥大化 StartWorkflow Source EventBridge SQS Worker Connect RPC Server Temporal © LayerX Inc. 元々 RPC コール特化の設計 そこに Temporal 起動が乗り、単一 Worker が 2 種類の下流を抱える 14
15. B: 直接 Workflow 起動する場合の問題点 サービス間の依存関係記述が分散する StartWorkflow StartWorkflow Source A Temporal Source B © LayerX Inc. サービス境界を超えるようなイベントの場合に、依存関係が各サービス内に記述される システム全体として依存関係のトラッキングが困難になる 15
16. B: 直接 Workflow 起動する場合の問題点 1:N 起動の責務が発火元に寄る StartWorkflow StartWorkflow Source A Temporal Source B © LayerX Inc. 1イベントから複数 Workflow を起動する場合、発火元が順次 StartWorkflow を呼ぶ 片方だけ失敗した際のリトライ、フォールバックを発火元が自前で管理する必要 16
17. C: EventBridge → Lambda → Temporal を採用 publish StartWorkflow Source EventBridge Lambda Temporal © LayerX Inc. キュー基盤は Temporal Task Queue に一元化 専用 Lambda を新設、既存 Worker と責務を分離 1:N 起動・リトライは EventBridge / Lambda 側で吸収 EvB がバッファとなり、Temporal 障害が発火元に直接波及しない 17
18. Before / After Before Source EventBridge SQS Worker Connect RPC Server After publish StartWorkflow Source EventBridge Lambda Temporal Proto 由来の ⽣成ルーティング テーブル © LayerX Inc. 18
19. 2. 浸透のための取り組み① Protobuf からのインフラコード生成
20. Protobuf 一枚で Source から Temporal まで繋がる © LayerX Inc. Workflow / Activity の Go コードは cludden/protoc-gen-go-temporal で生成 protobuf option を用いて ルーティングコードを生成する内製 protoc pluginを用意 20
21. 3. 浸透のための取り組み② コンテキスト伝搬
22. コンテキスト伝搬 コンテキストとは なぜTemporalで問題になるのか © LayerX Inc. 1リクエストの処理を通して引き回したい横断情報 テナント ID / リクエスト ID 分散トレース情報 (trace ID / span ID) Workflow と Activity は別プロセス・ネットワーク分離で動作 Go の context.Context や Node.js の AsyncLocalStorage はそのまま渡らない 非同期処理でもこれらの横断情報は引き継ぎたい 22
23. Goの場合 Temporal SDK 公式の ContextPropagator インターフェースの実装を内製ライブラリで提供 © LayerX Inc. Client → Workflow → Activity の各境界で Header 経由で値を受け渡し Workflow / Activity 内では context.Context に載せ替えて参照 アプリは Worker / Client 起動時に注入し、 context.Context から取り出すだけ 23
24. TypeScriptの場合 TS SDK の Interceptor + AsyncLocalStorage で自作 © LayerX Inc. Client → Workflow → Activity の各境界で Header 経由で値を受け渡し Workflow / Activity 内では AsyncLocalStorage に載せ替えて参照 24
25. 4. 浸透のための取り組み③ Temporal向け認可トークン
26. なぜ専用の認可トークンが必要になるのか ここでいう認可トークンとは なぜ Temporal で問題になるのか © LayerX Inc. API 呼び出し時に「誰として呼んだか」を示す情報 Temporal Activity からAPIを叩く際にも必要 WorkflowはDurable → 中断、再開を許容される長寿命 Activityは何度もリトライされ得る → 冪等が前提 上記より通常の短命な認可トークンは使えない 26
27. トークン引き換え方式 引き換え ContextPropagator 再引き換え User Token API Server Workflow ⽤ Token Workflow / Activity User Token 社内 API / 外部 API © LayerX Inc. StartWorkflow のタイミングで、認可トークンを Workflow 専用の長寿命認可トークンに引き換える コンテキスト伝搬で Workflow / Activity に伝搬 Activity 内で再度認可トークンに引き換える 27
28. まとめ
29. まとめ © LayerX Inc. 移行：ワークロード混在と状態永続化不足を解消するため Temporal を採用 アーキテクチャ：EventBridge → Lambda → Temporal の構成を採用 浸透に向けて①：Protobuf からのインフラ生成の仕組み作り 浸透に向けて②：コンテキスト伝搬の仕組み作り 浸透に向けて③：冪等なActivity向けの認可トークン発行方式の整備 29
30. ご清聴ありがとうございました