前置き
今回は、各マイクロサービスの保有するコマンドもしくは、リードモデルを源泉として、
最終的な成果物であるデータプロダクトを作成するためのアーキテクチャパターンを紹介します。
すでにネタバレしてしまってますが、大きく分けて、
リードモデルを源泉とするパターン
コマンドモデルを源泉とするパターン
の２つに大きく分類されます。
それぞれの特性やメリデメを見ていきましょう。
パターン1：リードモデルを源泉とする（現実的なアプローチ）
こちらの方が割かし多いアプローチです。模式図は以下の通り。
仕組み
マイクロサービスが持つ読み取り専用のリードモデル（例: PostgreSQLのテーブル）
のデータを、ETL/ELTツールが定期的に抽出し、データウェアハウスなどにロードして、
分析用のデータプロダクトとします。
✅ メリット
実装が容易
リードモデルはすでに消費しやすいように整形された「最新の状態」を持っているため、
データパイプラインの構築が比較的簡単です。
分析価値の早期実現
実装が容易であるため、完璧ではないにせよ「十分な」品質のデータを、より早く分析チームに提供できます。これにより、ビジネスは迅速にデータ活用を開始できます。
要求スキルの平易さ
一般的なRDBに対する、従来型のETL/ELT処理の知識で対応可能です。
高度なストリームプロセッシングの専門知識は必ずしも必要ありません。
❌ デメリット
データ粒度の限界
リードモデルは「最新の状態」しか保持していないため、コンテキスト情報となる
「どのようにその状態に至ったか」 という詳細な変更履歴は失われています。
そのため、分析の深さに限界があります。
運用負荷
分析のための大規模なデータ抽出が、オンラインの業務を支えるリードモデルのパフォーマンスに影響を与える可能性があります。
ビジネス文脈の喪失
リードモデルは業務クエリ用に最適化された状態であり、イベントが本来持っていた
豊かなビジネス上の意味（例：TrialUserConvertedToPaidPlan）が、単なるステータス変更（status = 'PAID'）に情報圧縮されてしまっている可能性があります。
アーキテクチャの結合
分析データプロダクトのスキーマが、業務用リードモデルのスキーマに強く依存します。
アプリケーションチームが、自身の業務都合でリードモデルのスキーマを変更すると、
下流の分析パイプラインが連鎖的に破壊されるリスクがあります。
パターン2：イベントストアを源泉とする（理想的なアプローチ）
こちらはそんなに頻繁に出てくるものではないですが、イベントストアが源泉である分、
データ品質は、リードモデルの時よりも高くなります。
仕組み
分析用のデータパイプラインが、マイクロサービスのリードモデルではなく、
書き込み専用のイベントストア（例: Kafkaのトピック） を直接購読します。
✅ メリット
最高のデータ品質
「いつ、誰が、何をしたか」というビジネスプロセスの全履歴が、イベントとして完全に記録されています。これにより、遥かに深く、リッチな分析が可能になります。
完全な疎結合
分析用のデータ処理が、業務用の読み取りシステム（リードモデル）に一切負荷をかけません。これは、性能と耐障害性の観点からだと、非常に優れた設計です。
将来の分析への対応力
現在は不要でも、将来新しい分析軸（新しいリードモデル）が必要になった際に、過去の
イベント履歴を全て再生することで、いつでも新しいデータプロダクトを構築できます。
リアルタイム分析の実現
イベントストリームを直接処理することで、日次バッチのような時間差のある分析ではなく、リアルタイムでの分析が可能になります。
❌ デメリット
実装の複雑性
イベントストリームを直接処理し、分析可能な「状態」へと変換するには、より高度なストリームプロセッシングの技術が必要となり、パイプラインの実装は複雑になります。
データ量の増大とコスト
全ての変更履歴をイベントとして永続化するため、最新状態のみを保持するリードモデルに比べて、データストレージのコストは増大する傾向にあります。
高度なガバナンスの必要性
イベントは不変であり、一度記録されると修正が困難です。
そのため、イベントのスキーマをどうバージョン管理するか（スキーマレジストリ）、
個人情報をどう扱うかといった、より厳格なデータガバナンスが求められます。
特性の違う２つのデータパイプライン
【パターン2：イベントストアを源泉とする（理想的なアプローチ）】 では、
確かにデータ品質上は最高かもしれないですが、
・コマンドモデルからリードモデル
・コマンドモデルから分析モデル
の２つのデータパイプラインを考えないといけない。(図の緑と青線部分)
同じイベントストアという源泉から出発しても、そのデータの「消費者」であるリードモデルと分析モデルでは、目的と求められる品質特性が全く異なるため、それぞれに最適化された2つのデータパイプラインが必要になります。
①. リードモデルへのパイプライン（プロジェクター）
図の緑の矢印線のパイプラインです。
目的
アプリケーションのオンライン業務（例：画面表示）を支えるため、「現在の状態」 に
関するクエリに高速に応答すること。
求められる品質特性
・低レイテンシー
書き込みが、できるだけ速く読み取りに反映されること（Read-Your-Writes問題の緩和）。
・シンプルな変換
通常、イベントから１対１の関係に近い、単純なデータ変換が求められる。
データ構造
特定のIDで高速に検索できるような、正規化された、or ドキュメント形式のデータ構造。
②. 分析モデル（データプロダクト）へのパイプライン
図の青い矢印線のパイプラインです。
目的
BIツールや機械学習モデルといった、オフライン分析を支えるため、過去からの全履歴を
効率的に集計・分析できるようにすること。
求められる品質特性
・高スループット
大量の履歴データを一度に処理できる能力。
・複雑な変換および集約
複数のイベントを組み合わせたり、他のデータプロダクトと結合したりといった、
複雑なデータ加工が求められる。
データ構造
大規模なスキャンや集計に適した、非正規化されたワイドテーブルや、カラムナフォーマット（例: Parquet）。
※注意事項
この異なる2つの要求を、単一のデータパイプラインで同時に満たそうとすると、
どちらの要求も十分に満たせない、中途半端なものが出来上がってしまいます。
したがって、目的と要求が全く異なる2つの消費者のために、
それぞれに最適化された2つの異なるデータパイプラインを設計・運用
するのが、このパターンのベストプラクティスです。
ここまでのおさらい
結論として、
「リードモデルが源泉になる」は、多くの実用的なシナリオにおいて正しい
しかし、最高のデータ品質とシステムの疎結合性を追求するならば、イベントストアを直接の源泉とすることが、アーキテクチャの最終的な理想形と言えます。