Hybrid Data Mesh Platform

凡例

概要

データメッシュ（Data Mesh）は Zhamak Dehghani が提唱した分散型データアーキテクチャの原則で、①ドメイン所有権、②データ as a プロダクト、③セルフサービス基盤、④連邦計算ガバナンス の4原則で構成される。中央集権的なデータレイク／DWHに起因する「ボトルネック化・文脈ロス・オーナーシップ欠如」を解消し、ドメイン組織にデータの所有権と説明責任を委譲する。

本構成は「ハイブリッド（一部中央集権）型」のデータメッシュ実装例である。純粋な分散型は運用コストとガバナンス設計の難易度が高いため、共通サービスアカウントに Lake Formation / Glue Data Catalog / RAM / IAM Identity Center を集約し、ドメインアカウント側で S3・Glue・Lambda による独自のデータプロダクト開発を可能にする。中央が「踏み台」ではなく「ガバナンス基盤」として機能し、ドメインの自律性を阻害しない構造が特徴。

中堅 SIer の顧客案件（複数部門横断のデータ活用）では、完全分散型よりこのハイブリッド型の方が段階的導入と運用移管がしやすく、Day1 から ROI を出しやすい。

データフロー

Ingest ソースシステムからの取り込み

Product ドメイン内データプロダクト生成

Govern 中央カタログ登録とポリシー適用

Event ドメイン間イベント連携

Consume 消費側フェデレーテッドクエリ

レイヤー構成

レイヤー	AWSサービス	用途
ソースシステム	ERP / CRM / POS（S3 Export）	既存業務システムからの日次/リアルタイム Export
取り込み Ingest	Kinesis Data Streams	ストリーミング取り込み、各ドメイン Raw Zone へファンアウト
ドメイン層 (Federated Ownership)	S3 (Raw + Curated), AWS Glue, AWS Lambda, API Gateway	各ドメインチームが独自に所有・運用。Raw → ETL → Curated → Product API の一気通貫
中央ガバナンス (Shared Services)	Glue Data Catalog, Lake Formation, Resource Access Manager (RAM), IAM Identity Center	統一メタデータ・権限管理・クロスアカウント共有・フェデレーテッド認証
イベントバックボーン	Amazon EventBridge (Custom Event Bus)	ドメイン間のイベント駆動連携。Domain Event 発行と購読
消費層 Consume	Amazon Athena, QuickSight, SageMaker, Bedrock	フェデレーテッドクエリ、BI、ML 学習、RAG/LLM アプリ
観測層	CloudWatch Metrics, CloudTrail Audit Logs	ETL メトリクス・LF 権限変更監査・クロスアカウント操作ログ

設計のポイント

1. ドメイン自律性とガバナンスの両立（ハイブリッド設計の肝）
純粋なデータメッシュは「中央は何も持たない」が理想だが、現実には Catalog・権限・監査が分散すると統制不能になる。本構成は 共通サービスアカウントに「薄い中央」 を置き、カタログとポリシーだけを集中させる。データ本体とコンピュートはドメインアカウントに残すことで、ドメインチームは自分たちの S3・Glue・Lambda を自由に運用できる。中央は「道路交通法」、ドメインは「各自の車両」という役割分担。

2. Lake Formation Tag-Based Access Control (LF-TBAC) によるスケーラブル権限管理
ドメインとデータプロダクトが増えても、個別 Grant を書かず LF タグ（例: domain=sales, sensitivity=pii） を付与するだけで権限が伝播する LF-TBAC が重要。実装では aws lakeformation create-lf-tag でタグ階層を先に設計し、タグ付与ルールを全ドメインで統一する。この設計を初期に固めないと、後から権限見直しで数週間溶ける。

3. データプロダクトは「API」を持たせる（単なる S3 バケットで終わらせない）
データメッシュ原則の「Data as a Product」を実装する際に、Curated S3 + Glue テーブルだけだと「ただのデータレイク」と変わらない。本構成では 各ドメインに Lambda + API Gateway の Product API を置き、データ仕様・SLA・ドキュメントを API レベルで約束する。消費側は「API として」データを購読するため、ドメイン側はスキーマ破壊的変更ができなくなり、契約ベースの開発が強制される。

4. EventBridge をドメイン間連携の唯一の公式経路にする
ドメイン A が別ドメインのデータを直接参照するのは 原則禁止（密結合の温床）。代わりに Domain Event を EventBridge に publish し、他ドメインは自分のタイミングで subscribe する。これにより、ドメイン間の実行順序依存・バッチウィンドウ合わせ・障害伝播が解消される。SageMaker・Bedrock も EventBridge を subscribe して、新規データプロダクト公開イベントを起点に ML 再学習や RAG インデックス再構築を自動化する。

5. 段階的導入戦略（Day1 は中央集権寄り → Day90 で完全メッシュ化）
いきなり完全分散型に飛び込むと、ドメインチームが AWS 運用に慣れていない場合に頓挫する。推奨は 3ステップ：(a) Day1 = 単一アカウント内でドメイン分離（本 IaC テンプレート）、(b) Day30 = Control Tower + 各ドメインアカウント切り出し、(c) Day90 = LF クロスアカウント共有＋各ドメインが独自 CI/CD 保有。各段階で ROI を出しながら組織の AWS 成熟度に合わせて移行する。

コスト概算

ap-northeast-1 (東京) リージョン基準の月額概算。実際の費用は利用量により変動します。為替レート: $1 = 150円（参考値）

サービス	構成	Dev (月額)	Prod (月額)
S3 (9バケット)	Raw×3 + Curated×3 + Athena結果 + Audit + KMS	$5-20 (750-3,000円)	$20-100 (3,000-15,000円)
AWS Glue (3 ETL Job)	3ドメインの ETL (2 DPU each)	$15-60 (2,250-9,000円)	$60-300 (9,000-45,000円)
Glue Data Catalog	3 Database + テーブル管理	$1-5 (150-750円)	$5-20 (750-3,000円)
Lake Formation	Tag-Based Access Control	$0 (無料)	$0 (無料)
Kinesis Data Streams	Ingestion (2 shards)	$30-60 (4,500-9,000円)	$60-150 (9,000-22,500円)
Lambda (3 Product API)	100万〜1000万req/月	$5-20 (750-3,000円)	$20-100 (3,000-15,000円)
API Gateway (REST)	Product API フロント	$3-10 (450-1,500円)	$10-50 (1,500-7,500円)
EventBridge	Domain Event Bus (カスタム)	$0-2 (0-300円)	$2-10 (300-1,500円)
Athena	Federated Query	$5-30 (750-4,500円)	$30-100 (4,500-15,000円)
QuickSight	BI Dashboards (ユーザー数依存)	$5-30 (750-4,500円)	$50-400 (7,500-60,000円)
SageMaker	ML Training/Inference	$50-150 (7,500-22,500円)	$100-500 (15,000-75,000円)
Bedrock	RAG / LLM 推論（トークン課金）	$5-50 (750-7,500円)	$50-500 (7,500-75,000円)
RAM	Resource Access Manager	$0 (無料)	$0 (無料)
IAM Identity Center	フェデレーテッド認証	$0 (無料)	$0 (無料)
CloudWatch	Metrics / Logs	$10-20 (1,500-3,000円)	$20-80 (3,000-12,000円)
CloudTrail	Audit Logs (LF権限変更追跡)	$2-10 (300-1,500円)	$10-50 (1,500-7,500円)
KMS	S3/Kinesis 暗号化キー	$1-5 (150-750円)	$5-20 (750-3,000円)
合計		$137-472 (約20,550-70,800円)	$442-2,380 (約66,300-357,000円)

前提条件: Dev = 3ドメイン × 500GB、Prod = 3ドメイン × 2TB、QuickSight 10ユーザー（Dev）/ 50ユーザー（Prod）、Bedrock = Claude Haiku相当の軽量RAG。本構成は単一アカウント簡略版のため、実運用の Multi-Account 展開時はアカウント間データ転送費（RAM/クロスアカウントS3 GET）が別途必要。

コスト最適化: (1) S3 Intelligent-Tiering で Raw Zone のコールドデータを自動 Glacier 移行、(2) Glue Job を Spot Worker（-80%）+ Job Bookmarks で差分実行、(3) Athena Query Result Reuse で重複課金を回避、(4) SageMaker は Savings Plans で最大 64% 割引、(5) QuickSight は Capacity Pricing に切替で 51+ユーザーで Per-User より割安、(6) Bedrock は Prompt Caching（最大 90% 割引）を活用。Day90 以降の完全分散型展開時は、Control Tower の Budget Alert でアカウント単位の上限を自動設定すること。

学習ポイント

• データメッシュの 4 原則 — Zhamak Dehghani が提唱した ①ドメイン所有権、②Data as a Product、③セルフサービス基盤、④連邦計算ガバナンスの 4 原則を押さえる。純粋分散と完全集中の間のトレードオフを意識し、組織の成熟度に応じて「どこまで中央集権にするか」を設計段階で決めることが、プロジェクトの成否を左右する。
• IAM と Lake Formation の役割分担 — IAM はサービス認証、Lake Formation はデータ認可（テーブル・列・行レベル）を担当する。両者を混同すると権限設計が破綻する。特に LF-TBAC（Tag-Based Access Control）は 50 テーブルを超えた段階で個別 Grant が破綻するため、最初から必須で導入する。タグ階層設計は後戻りが非常に高コスト。
• 契約ベースのデータプロダクト設計 — 生 S3 バケットを直接共有すると、消費者が schema-on-read で勝手に使い、ドメイン側がスキーマ変更できなくなる。Lambda + API Gateway で Product API を挟むことで、スキーマ・SLA・ドキュメントを契約として明示でき、Producer/Consumer の責任分界点を API 層で固定できる。これはマイクロサービスアーキテクチャと同じ発想。
• Pub/Sub で密結合を解消する原則 — ドメイン間の同期 API 呼び出しは密結合の温床で、障害伝播・実行順序依存・バッチウィンドウ調整の問題を引き起こす。EventBridge / Kafka / SNS などの Pub/Sub アーキテクチャで時間的・空間的デカップリングを実現することで、ドメインが独立に進化できるようになる。データメッシュ以外にも普遍的に通用する設計思想。
• 大規模組織変革は段階的に導入する — Big Bang 移行は組織のスキル・ツール習熟度・運用体制が追いつかず頓挫する典型パターン。Day1（単一アカウントでドメイン分離） → Day30（Control Tower でアカウント切り出し） → Day90（LF クロスアカウント + 各ドメイン独自 CI/CD）のような段階設計で、各フェーズで ROI を出しながら進める。これは SIer の提案書作成時にも必ず意識すべき原則。

データレイクハウスとの違い（一言）

観点	Data Lakehouse（Medallion）	Data Mesh（本構成）
所有権	中央データ基盤チーム	各ドメインチーム（分散）
データ配置	中央 S3 に集約	各ドメインの S3 に分散、カタログのみ中央
主役	Medallion 層（Bronze/Silver/Gold）	Data Product（Curated S3 + Product API）
適合ケース	単一ドメインの品質段階管理	複数ドメイン横断・組織スケール対応
中央の役割	全データを管理	カタログ・権限・認証のみ（本構成）