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
13
コレオグラフィ型サーガでのデータモデルの持ち方
Aja9tochin
September 19, 2025
Tweet
Share
More Decks by Aja9tochin
See All by Aja9tochin
5分でカオスエンジニアリングを分かった気になろう
pandayumi
0
360
DDD集約とサービスコンテキスト境界との関係性
pandayumi
3
340
業務改善原則を使った企画の重要性
pandayumi
0
29
セキュリティ視点以外の重要な脅威分析
pandayumi
0
14
脅威モデリングによるシフトレフト活動
pandayumi
0
8
ビジネスアーキテクチャにおける脅威分析
pandayumi
0
11
既存の脅威モデリング実施における新たな脅威とその対策に必要な思考
pandayumi
0
7
ADR運用におけるデータ利活用の考え方
pandayumi
0
380
Other Decks in Technology
See All in Technology
【SORACOM UG Explorer 2025】さらなる10年へ ~ SORACOM MVC 発表
soracom
PRO
0
150
Implementing and Evaluating a High-Level Language with WasmGC and the Wasm Component Model: Scala’s Case
tanishiking
0
180
会社を支える Pythonという言語戦略 ~なぜPythonを主要言語にしているのか?~
curekoshimizu
3
760
入院医療費算定業務をAIで支援する:包括医療費支払い制度とDPCコーディング (公開版)
hagino3000
0
110
様々なファイルシステム
sat
PRO
0
250
コンパウンド組織のCRE #cre_meetup
layerx
PRO
1
270
AWS DMS で SQL Server を移行してみた/aws-dms-sql-server-migration
emiki
0
240
組織全員で向き合うAI Readyなデータ利活用
gappy50
1
640
「最速」で Gemini CLI を使いこなそう! 〜Cloud Shell/Cloud Run の活用〜 / The Fastest Way to Master the Gemini CLI — with Cloud Shell and Cloud Run
aoto
PRO
1
180
AIでデータ活用を加速させる取り組み / Leveraging AI to accelerate data utilization
okiyuki99
1
450
webpack依存からの脱却!快適フロントエンド開発をViteで実現する #vuefes
bengo4com
4
3.4k
SQLAlchemy の select(User).where(User.id =="123") を理解してみる/sqlalchemy deep dive
3l4l5
3
440
Featured
See All Featured
A Tale of Four Properties
chriscoyier
161
23k
Building Better People: How to give real-time feedback that sticks.
wjessup
369
20k
A Modern Web Designer's Workflow
chriscoyier
697
190k
Being A Developer After 40
akosma
91
590k
Visualization
eitanlees
149
16k
How to Ace a Technical Interview
jacobian
280
24k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.2k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
640
Raft: Consensus for Rubyists
vanstee
140
7.2k
The Cost Of JavaScript in 2023
addyosmani
55
9.1k
Optimizing for Happiness
mojombo
379
70k
Become a Pro
speakerdeck
PRO
29
5.6k
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