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

by shibutani

Embed

Start on current slide

Slide 1

Slide 1 text

メッセージキュー型の非同期処理から Temporal 移行へ ── アーキテクチャ選定と浸透のための取り組み shibutani / @s_k_526 2026 年 4 月 27 日 Background Job Talk

Slide 2

Slide 2 text

自己紹介 shibutani / @s_k_526 株式会社 LayerX Platform Engineering 部 Enabling チーム 2025年新卒入社最近はCLI盆栽に勤しむ（特にcc〇〇とかagent- 〇〇を作っています） © LayerX Inc. 2

Slide 3

Slide 3 text

今日の内容

Slide 4

Slide 4 text

今日の内容 © LayerX Inc. メッセージキュー型の非同期処理から Temporal への移行浸透のための取り組み①：Protobuf からのインフラコード生成浸透のための取り組み②：コンテキスト伝搬浸透のための取り組み③：Temporal向け認可トークン 4

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

前提：対象システムの構造システム構成非同期処理が必要な場面 © LayerX Inc. マルチテナントシステムのバックエンド複数の Connect RPC サーバーがドメインごとに分かれて稼働長時間・重い処理が日常的に存在ドキュメント処理パイプライン LLM を使った長時間処理 6

Slide 7

Slide 7 text

これまでの非同期処理基盤 Source EventBridge SQS Worker Connect RPC Server © LayerX Inc. EventBridge → SQS → Worker → Connect RPC のパイプライン 7

Slide 8

Slide 8 text

この構成のメリットとデメリットメリットデメリット © LayerX Inc. 非同期処理が通常の Connect RPC と同じ形で書ける開発、デバッグに既存のエコシステムがそのまま利用できる同期と非同期のリクエストが同じ Connect RPC サーバーに到達非同期は重く長いので、同期 API のレイテンシ・スループットを劣化させる状態永続化も無く、途中再開やリトライロジックがアプリ側に必要 8

Slide 9

Slide 9 text

独立した非同期処理基盤が欲しい要件 → これらを満たす基盤として、Temporal を採用 © LayerX Inc. 同期処理とワークロードを物理的に分離状態永続化・途中再開・リトライを基盤側で担保運用の可視性（実行状況・失敗調査） 9

Slide 10

Slide 10 text

Temporal とは © LayerX Inc. Workflow を中心とする Durable Execution エンジン Workflow の状態を自動永続化 → 障害が起きても続きから再開可能 Worker / Task Queue モデルで処理の分散・スケールを担保実行状況・履歴をWeb UI で可視化・失敗リトライも Web UIで可能 10

Slide 11

Slide 11 text

どう組み込むか ── アーキテクチャ選定

Slide 12

Slide 12 text

比較検討した 3 案 Option 概要 A EventBridge → SQS -> Worker → Temporal B 各サービスから直接 Workflow を起動 C EventBridge → Lambda → Temporal © LayerX Inc. 12

Slide 13

Slide 13 text

A: 既存Worker拡張の問題点 SQS と Temporal Task Queue の二重管理 StartWorkflow Source EventBridge SQS Worker Connect RPC Server Temporal © LayerX Inc. Temporal 自体がキューイング・リトライ・可視化を備えるそれなのに SQS 側のキューも並行で運用 13

Slide 14

Slide 14 text

A: 既存Worker拡張の問題点既存 Worker の責務肥大化 StartWorkflow Source EventBridge SQS Worker Connect RPC Server Temporal © LayerX Inc. 元々 RPC コール特化の設計そこに Temporal 起動が乗り、単一 Worker が 2 種類の下流を抱える 14

Slide 15

Slide 15 text

B: 直接 Workflow 起動する場合の問題点サービス間の依存関係記述が分散する StartWorkflow StartWorkflow Source A Temporal Source B © LayerX Inc. サービス境界を超えるようなイベントの場合に、依存関係が各サービス内に記述されるシステム全体として依存関係のトラッキングが困難になる 15

Slide 16

Slide 16 text

B: 直接 Workflow 起動する場合の問題点 1:N 起動の責務が発火元に寄る StartWorkflow StartWorkflow Source A Temporal Source B © LayerX Inc. 1イベントから複数 Workflow を起動する場合、発火元が順次 StartWorkflow を呼ぶ片方だけ失敗した際のリトライ、フォールバックを発火元が自前で管理する必要 16

Slide 17

Slide 17 text

C: EventBridge → Lambda → Temporal を採用 publish StartWorkflow Source EventBridge Lambda Temporal © LayerX Inc. キュー基盤は Temporal Task Queue に一元化専用 Lambda を新設、既存 Worker と責務を分離 1:N 起動・リトライは EventBridge / Lambda 側で吸収 EvB がバッファとなり、Temporal 障害が発火元に直接波及しない 17

Slide 18

Slide 18 text

Before / After Before Source EventBridge SQS Worker Connect RPC Server After publish StartWorkflow Source EventBridge Lambda Temporal Proto 由来の⽣成ルーティングテーブル © LayerX Inc. 18

Slide 19

Slide 19 text

2. 浸透のための取り組み① Protobuf からのインフラコード生成

Slide 20

Slide 20 text

Protobuf 一枚で Source から Temporal まで繋がる © LayerX Inc. Workflow / Activity の Go コードは cludden/protoc-gen-go-temporal で生成 protobuf option を用いてルーティングコードを生成する内製 protoc pluginを用意 20

Slide 21

Slide 21 text

3. 浸透のための取り組み② コンテキスト伝搬

Slide 22

Slide 22 text

コンテキスト伝搬コンテキストとはなぜTemporalで問題になるのか © LayerX Inc. 1リクエストの処理を通して引き回したい横断情報テナント ID / リクエスト ID 分散トレース情報 (trace ID / span ID) Workflow と Activity は別プロセス・ネットワーク分離で動作 Go の context.Context や Node.js の AsyncLocalStorage はそのまま渡らない非同期処理でもこれらの横断情報は引き継ぎたい 22

Slide 23

Slide 23 text

Goの場合 Temporal SDK 公式の ContextPropagator インターフェースの実装を内製ライブラリで提供 © LayerX Inc. Client → Workflow → Activity の各境界で Header 経由で値を受け渡し Workflow / Activity 内では context.Context に載せ替えて参照アプリは Worker / Client 起動時に注入し、 context.Context から取り出すだけ 23

Slide 24

Slide 24 text

TypeScriptの場合 TS SDK の Interceptor + AsyncLocalStorage で自作 © LayerX Inc. Client → Workflow → Activity の各境界で Header 経由で値を受け渡し Workflow / Activity 内では AsyncLocalStorage に載せ替えて参照 24

Slide 25

Slide 25 text

4. 浸透のための取り組み③ Temporal向け認可トークン

Slide 26

Slide 26 text

なぜ専用の認可トークンが必要になるのかここでいう認可トークンとはなぜ Temporal で問題になるのか © LayerX Inc. API 呼び出し時に「誰として呼んだか」を示す情報 Temporal Activity からAPIを叩く際にも必要 WorkflowはDurable → 中断、再開を許容される長寿命 Activityは何度もリトライされ得る → 冪等が前提上記より通常の短命な認可トークンは使えない 26

Slide 27

Slide 27 text

トークン引き換え方式引き換え ContextPropagator 再引き換え User Token API Server Workflow ⽤ Token Workflow / Activity User Token 社内 API / 外部 API © LayerX Inc. StartWorkflow のタイミングで、認可トークンを Workflow 専用の長寿命認可トークンに引き換えるコンテキスト伝搬で Workflow / Activity に伝搬 Activity 内で再度認可トークンに引き換える 27

Slide 28

Slide 28 text

まとめ

Slide 29

Slide 29 text

まとめ © LayerX Inc. 移行：ワークロード混在と状態永続化不足を解消するため Temporal を採用アーキテクチャ：EventBridge → Lambda → Temporal の構成を採用浸透に向けて①：Protobuf からのインフラ生成の仕組み作り浸透に向けて②：コンテキスト伝搬の仕組み作り浸透に向けて③：冪等なActivity向けの認可トークン発行方式の整備 29

Slide 30

Slide 30 text

ご清聴ありがとうございました