Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コレオグラフィ型サーガでのデータモデルの持ち方
Search
Aja9tochin
September 19, 2025
Technology
0
7
コレオグラフィ型サーガでのデータモデルの持ち方
Aja9tochin
September 19, 2025
Tweet
Share
More Decks by Aja9tochin
See All by Aja9tochin
5分でカオスエンジニアリングを分かった気になろう
pandayumi
0
310
DDD集約とサービスコンテキスト境界との関係性
pandayumi
3
310
業務改善原則を使った企画の重要性
pandayumi
0
27
セキュリティ視点以外の重要な脅威分析
pandayumi
0
12
脅威モデリングによるシフトレフト活動
pandayumi
0
8
ビジネスアーキテクチャにおける脅威分析
pandayumi
0
11
既存の脅威モデリング実施における新たな脅威とその対策に必要な思考
pandayumi
0
4
ADR運用におけるデータ利活用の考え方
pandayumi
0
350
Other Decks in Technology
See All in Technology
Modern_Data_Stack最新動向クイズ_買収_AI_激動の2025年_.pdf
sagara
0
120
PythonとLLMで挑む、 4コマ漫画の構造化データ化
esuji5
0
120
業務自動化プラットフォーム Google Agentspace に入門してみる #devio2025
maroon1st
0
170
C# 14 / .NET 10 の新機能 (RC 1 時点)
nenonaninu
1
1.1k
北海道の人に知ってもらいたいGISスポット / gis-spot-in-hokkaido-2025
sakaik
0
190
pprof vs runtime/trace (FlightRecorder)
task4233
0
140
Why React!?? Next.jsそしてReactを改めてイチから選ぶ
ypresto
9
3.6k
Azure SynapseからAzure Databricksへ 移行してわかった新時代のコスト問題!?
databricksjapan
0
110
動画データのポテンシャルを引き出す! Databricks と AI活用への奮闘記(現在進行形)
databricksjapan
0
120
AIを導⼊しても、 開発⽣産性は"爆増"していない なぜ?
kinosuke01
4
3.6k
入門 FormObject / An Introduction to FormObject #kaigionrails
expajp
2
1.4k
コンテキストエンジニアリングとは? 考え方と応用方法
findy_eventslides
4
810
Featured
See All Featured
RailsConf 2023
tenderlove
30
1.2k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
Building an army of robots
kneath
306
46k
The Cult of Friendly URLs
andyhume
79
6.6k
What's in a price? How to price your products and services
michaelherold
246
12k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
560
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
45
2.5k
Into the Great Unknown - MozCon
thekraken
40
2.1k
How to Ace a Technical Interview
jacobian
280
23k
Transcript
コレオグラフィ型 サーガでのデータ の持ち方 ビジネスアーキテクト 工藤由美
自己紹介 勿論飛ばしマシュ。 不要プロセスを排除=ECRSのE これぞアジャイル。 2025/9/19
今回の論点構造 大論点:コレオグラフィ型サーガにおけるデータの持ち方はどうあるべきか? 中論点:なぜコレオグラフィ型では、コマンドモデル以外にもSagaローカル状態モデルを持つ必要があるのか? 中論点:3つの異なるデータ特性のモデルをどのように物理分割すべきか? 誰向け?:次の2つを共に満たす方向け もうすでに、オーケストレーション型のサーガで分散化を体験済 これから、さらに自律駆動型にして、より疎結合なマイクロサービスへ検討中 2025/9/19
オーケストレーションサーガ 構図: 特徴:分散の導入には最適だが、まだ疎結合ではない。 各種サービスは、自分のコマンドとリードだけ管理してればいい。 サーガの状態管理は、オーケストレーターが専門。 エラーハンドリングが行いやすい。 指揮者がいないと各種サービスの自律性がない 必ず指揮者を通して連携するので遅い。 コレオグラフィ型に比べたら密結合。 2025/9/19
なぜSagaローカル状態 モデルを持つ必要がある のか? 2025/9/19
オーケストレーション型のころ 例) おとぎ話サーガ、パラレルサーガ 特徴:後述のコレオグラフィよりは密結合状態 オーケストレーターがサーガ全体の進捗状態を管理なので、シンプル 各種サービスは、コマンドモデルとリードモデルの最大2つのDBクラスタの管理 分散の導入時には、まずはオーケストレーションから始めるの推奨!
メリット 各種サービスが自分の集約内の状態だけに集中できる 複雑な例外処理がコレオグラフィ型よりも圧倒的にシンプル デメリット 指揮者の指示ないと自律的に協調できない オーケストレーター用のコンポーネント用意する手間 2025/9/19
コレオグラフィ型サーガの概念図 例) タイムトラベルサーガ、アンソロジーサーガとか(右図はだ いぶ簡略化してるので正確な図じゃないです) メリット 各種サービスが自律的に他サービスと協調できる さらに疎結合なので、パフォーマンスとスケーラビリティ高 デメリット
オーケストレーターのやってたSaga責務の一部を各サービスが 分担して持つ必要あり エラーハンドリングの複雑さ、マジ面倒 ※いきなり、コレオグラフィから始めるのマジやめれ? まずは、オーケストレーション型から地道にコツコツ!! 2025/9/19
なぜコマンドとSagaローカル状態をわける? 結論)べき等性の保証のため ① 責務の違い コマンドモデル(イベントストア)の責務:自分のビジネスエンティティの状態変化を記録すること(「状態」の記録に集中) Sagaローカル状態の責務:外部から受け取ったイベントを処理済みか記録すること(べき等性の記録に集中) ② 技術的問題により イベントを受け取った際に、「このイベントを既に処理したか?」をイベントストアだけで判断しようとすると、複雑で非効率なク エリが必要。
イベントをトリガーとして生成された別のドメインイベントが、このイベントストア内に既に存在するか?といった検索を行わない といけない。→圧倒的に遅い!! 対して、processed_saga_eventsのような専用テーブルがあれば、「このevent_idは存在するか?」という非常に高 速な主キー検索で、べき等性を保証可能。 2025/9/19
3つの異なるデータ特性 のモデルの分け方 2025/9/19
方法①物理的に1つにまとめる メリット データの鮮度はもっとも高い(すべてが同じトランザクション内) 一番シンプルな構成なので、実装難易度もっとも低い デメリット すべてが同じ特性のDBに詰め込まれる。 耐障害性は極めて低い ※最初にここから始めるのは、アリよりのありだが、コマンドと リードの分離されていない時のみの適用に限定される。 2025/9/19
方法②すべてを別々のDBで実装、、、 メリット 3つのそれぞれの特性に応じたものを選べる 耐障害性が高い デメリット :お金と手間が超かかる 複数の異なるDB基盤と、それらを繋ぐデータ同期パイプライ ンを自前で構築・管理する必要があり、非常に複雑。 よって、以下が現実的落としどころ。 いきなりの導入は基本やめておく。(可逆性も低い)
特定のマイクロサービス内のデータだけに、必要に応じて後か ら採用する、最終手段みたいなもの。 2025/9/19
方法③HTAPを使う(HTAP+Saga用RDB) メリット コマンドとリードの間のプロジェクター用意しなくていい コマンドとリードの間のデータ鮮度が高&強い整合性 Sagaの状態モデルが分離されているため、ワークフローの追跡という 重要なプロセスの耐障害性が確保されてる デメリット HTAP DB自体は書き込み・読み取り両方のプロセスに影響する単 一障害点となりうる
HTAP自体の専門知識と高度な運用が求められる コマンドモデルとSagaローカル状態モデルが非同期・結果整合性 HTAPの専門スキルがあり、データ品質がどのくらい必 要かわからない場合には、ここから始めるのもあり。 2025/9/19
方法④統一イベントストア+リードモデル用DB オーケの頃は、Saga状態モデルはステートモデル メリット 全ての状態変化が不変の唯一の真実イベントとして記録され るため、完璧な監査証跡となり、データの信頼性が最高レベル。 耐障害性は最高レベル。イベントストア(Kafkaなど)は非常 に可用性が高く、書き込み処理が失われることはほぼない。 最悪、リードモデルがダウンしてもプロセスは継続できる。 デメリット リードモデルは結果整合性となるため、データ鮮度は低い
イベントソーシング&CQRSという、分散システムの中でも特に 高度な設計概念の深い理解と実装能力が求められる。 でも、個人的にはこれが一番オススメ!(超主観) 2025/9/19
どういうロードマップがある? すでにコマンドとリードが物理的に分かれてる→④から開始し、その後必要に応じて②へ移行 サービス内のコマンドとリードが一緒のDBである ①から始める→リードモデルだけ後から物理分割して④を目指す まずは先にコマンドモデルとリードモデルを分離→コマンドモデルのイベントストアにSagaローカル状態モデル追加 2025/9/19
まとめと伏線 オーケストレーション型でやってくれていたサーガの状態モデルのマネジメントを、コレオグラフィ型では各種サー ビスが分散保有する必要がある。 コマンドモデル、リードモデル、サーガ状態モデルの3種類の責務のデータをどのように物理分割するのか?の 4パターン。 次回は、段階的にオーケストレーターからコレオグラフィのモデルへの移行あたりを振れられたらいいな。 2025/9/19
ハイブリッドに結局落ち着く すべてをコレオグラフィ型のサーガにするなんて、 割とムリゲーだし、やりすぎ。 右図のような形に結局落ち着く。 なので、 コマンドモデル+リードモデル 今日のコマンド・リード・Saga状態モデル のハイブリッドになるのが現実。 2025/9/19