コレオグラフィ型サーガでのデータモデルの持ち方

Transcript

1. コレオグラフィ型 サーガでのデータ の持ち方 ビジネスアーキテクト 工藤由美
2. 自己紹介 勿論飛ばしマシュ。 不要プロセスを排除＝ECRSのE これぞアジャイル。 2025/9/19
3. 今回の論点構造 大論点:コレオグラフィ型サーガにおけるデータの持ち方はどうあるべきか? 中論点:なぜコレオグラフィ型では、コマンドモデル以外にもSagaローカル状態モデルを持つ必要があるのか? 中論点:3つの異なるデータ特性のモデルをどのように物理分割すべきか? 誰向け?:次の2つを共に満たす方向け もうすでに、オーケストレーション型のサーガで分散化を体験済 これから、さらに自律駆動型にして、より疎結合なマイクロサービスへ検討中 2025/9/19
4. オーケストレーションサーガ 構図: 特徴:分散の導入には最適だが、まだ疎結合ではない。 各種サービスは、自分のコマンドとリードだけ管理してればいい。 サーガの状態管理は、オーケストレーターが専門。 エラーハンドリングが行いやすい。 指揮者がいないと各種サービスの自律性がない 必ず指揮者を通して連携するので遅い。 コレオグラフィ型に比べたら密結合。 2025/9/19
5. なぜSagaローカル状態 モデルを持つ必要がある のか？ 2025/9/19
6. オーケストレーション型のころ 例) おとぎ話サーガ、パラレルサーガ 特徴:後述のコレオグラフィよりは密結合状態  オーケストレーターがサーガ全体の進捗状態を管理なので、シンプル  各種サービスは、コマンドモデルとリードモデルの最大2つのDBクラスタの管理  分散の導入時には、まずはオーケストレーションから始めるの推奨! メリット  各種サービスが自分の集約内の状態だけに集中できる  複雑な例外処理がコレオグラフィ型よりも圧倒的にシンプル デメリット  指揮者の指示ないと自律的に協調できない  オーケストレーター用のコンポーネント用意する手間 2025/9/19
7. コレオグラフィ型サーガの概念図 例) タイムトラベルサーガ、アンソロジーサーガとか(右図はだ いぶ簡略化してるので正確な図じゃないです) メリット  各種サービスが自律的に他サービスと協調できる  さらに疎結合なので、パフォーマンスとスケーラビリティ高 デメリット  オーケストレーターのやってたSaga責務の一部を各サービスが 分担して持つ必要あり  エラーハンドリングの複雑さ、マジ面倒 ※いきなり、コレオグラフィから始めるのマジやめれ? まずは、オーケストレーション型から地道にコツコツ!! 2025/9/19
8. なぜコマンドとSagaローカル状態をわける？ 結論）べき等性の保証のため ① 責務の違い コマンドモデル(イベントストア)の責務:自分のビジネスエンティティの状態変化を記録すること（「状態」の記録に集中） Sagaローカル状態の責務:外部から受け取ったイベントを処理済みか記録すること（べき等性の記録に集中） ② 技術的問題により イベントを受け取った際に、「このイベントを既に処理したか?」をイベントストアだけで判断しようとすると、複雑で非効率なク エリが必要。 イベントをトリガーとして生成された別のドメインイベントが、このイベントストア内に既に存在するか?といった検索を行わない といけない。→圧倒的に遅い!! 対して、processed_saga_eventsのような専用テーブルがあれば、「このevent_idは存在するか?」という非常に高 速な主キー検索で、べき等性を保証可能。 2025/9/19
9. 3つの異なるデータ特性 のモデルの分け方 2025/9/19
10. 方法①物理的に1つにまとめる メリット データの鮮度はもっとも高い(すべてが同じトランザクション内) 一番シンプルな構成なので、実装難易度もっとも低い デメリット すべてが同じ特性のDBに詰め込まれる。 耐障害性は極めて低い ※最初にここから始めるのは、アリよりのありだが、コマンドと リードの分離されていない時のみの適用に限定される。 2025/9/19
11. 方法②すべてを別々のDBで実装、、、 メリット 3つのそれぞれの特性に応じたものを選べる 耐障害性が高い デメリット :お金と手間が超かかる 複数の異なるDB基盤と、それらを繋ぐデータ同期パイプライ ンを自前で構築・管理する必要があり、非常に複雑。 よって、以下が現実的落としどころ。 いきなりの導入は基本やめておく。(可逆性も低い) 特定のマイクロサービス内のデータだけに、必要に応じて後か ら採用する、最終手段みたいなもの。 2025/9/19
12. 方法③HTAPを使う(HTAP+Saga用RDB) メリット コマンドとリードの間のプロジェクター用意しなくていい コマンドとリードの間のデータ鮮度が高＆強い整合性 Sagaの状態モデルが分離されているため、ワークフローの追跡という 重要なプロセスの耐障害性が確保されてる デメリット HTAP DB自体は書き込み・読み取り両方のプロセスに影響する単 一障害点となりうる HTAP自体の専門知識と高度な運用が求められる コマンドモデルとSagaローカル状態モデルが非同期・結果整合性 HTAPの専門スキルがあり、データ品質がどのくらい必 要かわからない場合には、ここから始めるのもあり。 2025/9/19
13. 方法④統一イベントストア+リードモデル用DB オーケの頃は、Saga状態モデルはステートモデル メリット 全ての状態変化が不変の唯一の真実イベントとして記録され るため、完璧な監査証跡となり、データの信頼性が最高レベル。 耐障害性は最高レベル。イベントストア（Kafkaなど）は非常 に可用性が高く、書き込み処理が失われることはほぼない。 最悪、リードモデルがダウンしてもプロセスは継続できる。 デメリット リードモデルは結果整合性となるため、データ鮮度は低い イベントソーシング＆CQRSという、分散システムの中でも特に 高度な設計概念の深い理解と実装能力が求められる。 でも、個人的にはこれが一番オススメ!(超主観) 2025/9/19
14. どういうロードマップがある？ すでにコマンドとリードが物理的に分かれてる→④から開始し、その後必要に応じて②へ移行 サービス内のコマンドとリードが一緒のDBである ①から始める→リードモデルだけ後から物理分割して④を目指す まずは先にコマンドモデルとリードモデルを分離→コマンドモデルのイベントストアにSagaローカル状態モデル追加 2025/9/19
15. まとめと伏線 オーケストレーション型でやってくれていたサーガの状態モデルのマネジメントを、コレオグラフィ型では各種サー ビスが分散保有する必要がある。 コマンドモデル、リードモデル、サーガ状態モデルの3種類の責務のデータをどのように物理分割するのか?の 4パターン。 次回は、段階的にオーケストレーターからコレオグラフィのモデルへの移行あたりを振れられたらいいな。 2025/9/19
16. ハイブリッドに結局落ち着く すべてをコレオグラフィ型のサーガにするなんて、 割とムリゲーだし、やりすぎ。 右図のような形に結局落ち着く。 なので、 コマンドモデル＋リードモデル 今日のコマンド・リード・Saga状態モデル のハイブリッドになるのが現実。 2025/9/19