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
GopherCon Tour 概略
logica0419
2
160
PLaMoの事後学習を支える技術 / PFN LLMセミナー
pfn
PRO
8
2.9k
Pythonによる契約プログラミング入門 / PyCon JP 2025
7pairs
4
2.2k
VCC 2025 Write-up
bata_24
0
140
"複雑なデータ処理 × 静的サイト" を両立させる、楽をするRails運用 / A low-effort Rails workflow that combines “Complex Data Processing × Static Sites”
hogelog
3
1.3k
履歴 on Rails: Bitemporal Data Modelで実現する履歴管理/history-on-rails-with-bitemporal-data-model
hypermkt
0
1.7k
stupid jj tricks
indirect
0
7.4k
BtoBプロダクト開発の深層
16bitidol
0
130
#普通の文系サラリーマンチャレンジ 自分でアプリ開発と電子工作を続けたら人生が変わった
tatsuya1970
0
750
2重リクエスト完全攻略HANDBOOK / Double Request Handbook
shoheimitani
5
7k
Tomorrow graphlib, Let us use everybody
hayaosuzuki
0
140
“2件同時配達”の開発舞台裏 〜出前館PMが挑んだダブルピック実現に向けた体験設計〜
demaecan
0
160
Featured
See All Featured
A Tale of Four Properties
chriscoyier
160
23k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Visualization
eitanlees
148
16k
Optimizing for Happiness
mojombo
379
70k
Learning to Love Humans: Emotional Interface Design
aarron
274
40k
Typedesign – Prime Four
hannesfritz
42
2.8k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
20k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
Docker and Python
trallard
46
3.6k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
880
It's Worth the Effort
3n
187
28k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
600
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