データメッシュ
はじめに
モノリシックなシステムからマイクロサービスに分割するにあたって、
データベースの分割も考慮する必要があります。
今回はそのアーキテクチャである「データメッシュ」について概説します。
※データメッシュは技術よりも組織や文化の設計の文脈で語られることも多いが、今回は技術寄りの話
（前置き）マイクロサービスの必要性
最初はモノリシックで十分（1アプリ + 1DB）
サービスを立ち上げたばかりの頃は、1つのアプリケーション＋1つのデータベースで十分です。
構成がシンプルなので開発コストも低く、スピード感をもって開発できます。
ただしサービスが成長すると、次第に「開発速度」や「運用性」に限界が見えてきます。
また、マルチプロダクト戦略を取る企業の場合は各プロダクトが独立していると共通するサービスの再開発が必要になってしまいます。
モノリシックの課題
モノリシックなシステムの特徴は以下です。
- 単一リポジトリ
- 単一デプロイ
- 単一DB
最初は扱いやすいですが、次のような課題を抱えやすくなります。
-
スケールが垂直方向のみ
（特にWriterデータベースは）サーバーを大きくする以外に拡張余地がない -
チーム間の依存で開発速度低下
あるチームの改修が別チームのコードやDBに影響する、そもそも影響範囲がわかりにくい。 - 障害の影響範囲が大きくなりがち
マイクロサービスへの分割
この課題を解決するために登場するのがマイクロサービスです。
- システムをサービスごとに独立化（例：認証、決済、会計）
- 各サービスが独自に開発・デプロイ可能
- チームごとに責任範囲を分割
- チーム間の依存の低減（逆コンウェイ戦略）
データベースは分割しなくて良いのか
ここで出てくるのが「データベースをどう扱うか」という問題です。
もしアプリをマイクロサービスに分割しても、DBを共用しているままでは依存関係が残ります。
共用DBの問題は以下のとおりです。
- スキーマ変更で全サービスに影響
- パフォーマンスのボトルネック
- トランザクションでサービス間が結合してしまう（ロック待ちなど）
→ 真の独立性を確保するには、DBも分割する必要があります。
データメッシュとは
この「アプリもDBもサービスごとに分離」した状態を支える考え方がデータメッシュです。
各サービスが独自のDBを持ち、APIやイベントで連携し、直接別サービスのDBを参照・変更するのはNGです。
図で表すと以下のようになります。
データメッシュを採用するにあたって考慮事項
データメッシュの4つの原則
-
ドメイン指向の分散型所有
各サービスが自分のDBを責任を持って管理する。外部から直接アクセスされず、APIやイベントで連携する。
データ同期の必要性 → 後述 -
データを製品として扱う
各サービスにおいてデータは他のサービスに提供することを意識してデータ設計する。 -
セルフサービス型のプラットフォーム
データ提供や利用を容易にする共通基盤やツールを整備する。（各チームで重複した作業は行わない） -
連邦型のガバナンス
セキュリティやメタデータ標準は全体で統制しつつ、ドメインごとに自律性を維持する。これにより全社的な一貫性とチームの独立性を両立できる。
データ同期
サービス間で整合性をどう取るかを明確に設計する必要がある。
リアルタイム同期にするのか、最終的整合性で割り切るのかはユースケースによって異なる。
エラー時のデータ補正
分散システムでは各サービス間のデータ不整合が発生する前提で考える必要があります。
そのため以下のようなリカバリの仕組みが必要です。
- リトライ機構
- データ整合性監視・補正ジョブ
データエンジニアの必要性
各サービスのエンジニアだけでは、複数サービス間のデータ管理を最適化するのは難しいです。
各サービスエンジニアで構成される委員会制でもある程度まわりますが、出来れば特定のエンジニア（チーム）に情報・責任を集約したほうが良いです。
そこでデータエンジニアを任用するのがお勧めです。
データエンジニアがいることで、以下のような役割を果たすことが出来ます。
- 各サービスからの独立性を担保
- データ設計や管理方法の標準化
- セキュリティやログの運用
まとめ
- モノリシック → マイクロサービスは組織・プロダクトの成長に合わせて重要 （逆コンウェイ戦略）
- ただし、共用DBではスケールしないので、各サービスが独自DBを持つべき → データメッシュ構成
- 各DBは独立し、サービス間でのデータ連携はAPI経由にて行われる
- データ同期・同期の監視・補正の仕組みが必要
- 各サービスでの自由度を持たせつつも統一されたガバナンス・管理体制が必要（出来ればデータエンジニアを任用）
Discussion