AWSで実現するデータメッシュアーキテクチャ
はじめに
近年、「データ」の価値に注目が集まり、データ基盤をより効率的かつスケーラブルに実現することが不可欠となっています。
また、データの規模が拡大し、複数の部門やチームが関与する中でより効果的で民主的なデータ活用が求められるようになりました。
これまでのデータ基盤といえばデータレイクやデータウェアハウスが主流となっていましたが、こういった環境下では対応が難しくなってきています。
そこで本記事では、近年注目されているデータガバナンスを維持しながら分散型のデータ管理を実現することのできる「データメッシュ」の概念とそれをAWS上で実現する方法について解説します。
ドメイン駆動設計（DDD)の概要とデータ管理
データメッシュを実現する上で重要な概念が 「ドメイン駆動設計（DDD）」 となります。
ドメイン駆動設計ではシステムをビジネスドメインごとに分割し、各ドメインの責務を明確化します。
この考え方がデータメッシュの基盤になっています。
つまりドメイン駆動設計が行われたシステムが導入してあることがデータメッシュの前提と言えます。
※この部分がデータメッシュの導入が難しい一つの要因になっているのかなと…
ドメイン駆動設計とは
ドメイン駆動設計についてはそれだけで一つの記事が書けるほどのものなので、ここではさらっと概要だけの説明にとどめます。
ドメイン駆動設計は大規模組織向けの複雑なシステムを対象としたソフトウェア開発の手法となり、ビジネスドメインの知識をソフトウェア設計に統合することに重点を置いています。
対象となる事業活動（ドメイン）や課題を起点に、関係者が密に連携して開発を行います。
ドメイン駆動設計ではドメインモデルをソフトウェア開発の中心に据え、コードやコミュニケーションを常にドメインモデルと一体化させていきます。
ドメイン駆動設計は以下のような要素が重要となります。
ドメイン
「ドメイン」とは、システムが解決すべき特定のビジネス問題や課題の領域のことです。
例えば、ネットショッピングの場合、「商品管理」「注文管理」「在庫管理」「顧客管理」がそれぞれドメインとして分けられます。
ドメインはシステム開発の対象となるビジネスの本質を理解するための出発点となります。
このような業務にフォーカスした設計手法がドメイン駆動開発となります。
ユビキタス言語
開発チームとビジネスの担当者が、一貫した共通の言葉を使用してシステムの仕様や要件を定義します。
この共通の言葉を 「ユビキタス言語」 と呼びます。
そうすることで開発時の認識のずれを防ぐことができ、複雑な業務をシステムに落とし込むことが可能となります。
※通常の開発でも用語集を作ることもありますね。
ドメインモデル
「ドメインモデル」とはドメインの概念やルールを表現する抽象的なモデルのことです。
下記のような要素があります。
- ドメイン内の主要なエンティティや値オブジェクト
- ドメインに固有のルールやビジネスロジック
- これらの要素間の関係性
先ほどのネットショッピングを例にすると、下記のようなものとなります。
エンティティ: 「注文 (Order)」は一意の識別子を持つエンティティ
値オブジェクト: 「注文商品の明細 (OrderLineItem)」は数量や価格といった値で構成される値オブジェクト
ルール: 「注文の合計金額が0円の場合、注文は無効となる」といったビジネスルール
コンテキスト境界
「コンテキスト境界」とはドメイン駆動設計の中心となる概念です。
コンテキスト境界はドメインの解決空間に論理的な境界として設定し、複雑性を管理するために使用されます。
つまりドメイン全体（システム全体）を適切な範囲=コンテキストに分割し、それぞれ独立したモデルで管理するということです。
これにより各コンテキスト内での一貫性を保ちながら他のコンテキストとのやり取りが明確化されます。
先ほどのネットショッピングの例だと「商品管理コンテキスト」と「注文管理コンテキスト」はそれぞれ独立しており、異なるデータモデルやロジックを持つこととなります。
前述したユビキタス言語もこのコンテキスト内でのみ通用するものとなります。
ドメイン駆動設計の流れ
前述したような要素をもとに下記のような流れで開発を行います。
下記は一例であり、異なる方法を取ることもあります。
-
ドメインの理解：
対象となるビジネスドメインを分析し課題や概念をリストアップします。
ビジネスエキスパートやステークホルダーと密接に協力することが不可欠となります。 -
ユビキタス言語の定義：
ドメインの理解を基に、開発チームとビジネス担当者が共通して使用するユビキタス言語を定義します。
これにより、コミュニケーションの齟齬と要件の漏れを防ぎます。 -
ドメインのモデリング：
ビジネス要件をソフトウェアで実現するためのドメインモデルを設計します。
ビジネスルールや関係性を具体化していきます。 -
コンテキスト境界の設計：
ドメイン全体を適切なスコープに分割し、それぞれの領域（コンテキスト）を明確にします。
各コンテキストが独立した責務を持ち、異なるコンテキスト同士の依存を最小化します。 -
コンテキスト間の統合設計：
異なるコンテキスト境界間でのデータ連携や依存関係を設計します。
システム全体で整合性を保ちながら、適切な連携を実現する。 -
実装とフィードバック：
設計を実装し、フィードバックを得ながらモデルを進化させます。
ドメイン駆動設計では、ドメインモデルは固定的なものではなく常に進化するものと考えます。
こうしたドメイン駆動設計を行うことでより複雑なビジネス要件に対応した堅牢なシステムを構築することができます。
ドメイン駆動設計におけるデータ管理
ドメイン駆動設計において「データ」をどのように扱うかですが、こちらもデータをドメイン単位で管理・所有するものとなります。
データとデータを収集する仕組み、そして管理までドメインチームが責任をもって担当します。
これにより、ボトルネックの解消や、チームごとの独立性向上が可能となります。
先ほどの例であれば、「商品管理」「注文管理」「在庫管理」「顧客管理」のそれぞれのドメインが固有のデータをそれぞれのルールや収集方法で管理を行うということです。
データメッシュとは
データメッシュとは、従来行われていたような中央集権型のデータ管理から、ドメイン単位でのデータ管理に分散させ、ドメインチームがデータプロダクトを所有し運用するアプローチとなります。
前述したようなドメイン駆動の考え方に基づいたデータ管理手法となります。
データメッシュは以下の4つの原則に基づいて構成されます。
-
ドメイン別オーナーシップとアーキテクチャ
データを生成するチームがそのデータの所有権を持ち、その責任を負うという原則です。
従来の集中型データ管理（データレイクやデータウェアハウス）とは異なり、データの生成や活用を行うドメインチームが自分たちのデータの管理と提供を担当します。 -
プロダクトとしてのデータ
データを単なる副産物やリソースではなく、「プロダクト」として設計、開発、提供するという原則です。
プロダクトとしてのデータは、利用者に価値を提供し、使いやすく、高品質であることが求められます。 -
セルフサービス型データ基盤
データの提供や活用をサポートするために、各ドメイン所属の開発者やデータ利用者が自律的に操作できるデータ基盤を提供するという原則です。
セルフサービス型の仕組みによって、ドメインチームがデータプロダクトを迅速かつ効率的に提供できるようになります。 -
横断的なガバナンス
分散型アプローチを維持しつつ、一貫性とコンプライアンスを確保するためのガバナンスを横断的に実施するという原則です。
これは、中央集権的なトップダウン型ガバナンスではなく、各ドメインが独立性を持ちながら共通のルールに従うモデルです。
データメッシュではデータの管理責任がドメイン側に移るため、データの品質管理やマネジメントをドメイン側で担保する必要があります。
ドメイン側にデータ品質が左右されてしまうため、横断的なガバナンスがなにより重要となります。
また、データの収集も各ドメインに責任があるため、データを収集するETL等のデータエンジニアリング全般も各ドメインで対応する必要があります。
| 原則 | 目的 | メリット |
|---|---|---|
| ドメイン別オーナーシップ | データの所有と責任が明確化 | スケーラビリティと専門知識の活用 |
| プロダクトとしてのデータ | 高品質で利用者中心のデータ提供 | データ品質の向上と利用効率化 |
| セルフサービス型データ基盤 | 自律的にデータを管理・活用可能にする基盤の提供 | 開発効率の向上とインフラ負担の軽減 |
| 横断的なガバナンス | 一貫性と規制遵守を保つ分散型ガバナンス | 安全性の確保と全体的な統制 |
データメッシュの課題
前述したようにデータメッシュは大きなメリットがあるアーキテクチャとなります。
ただし、その実現にはいくつかの課題があります。
-
データの分散管理による複雑化
各ドメインにデータが分散されることで統制されたガバナンス管理が難しくなります。
また、各ドメイン間でのデータ連携や整合性を保つことが難しくなります。 -
ドメインごとのデータ所有の負担
各ドメインにデータ管理の主管が移るため、品質の担保や管理をドメイン側で行う必要が出てきます。
また、データプロダクトの管理にデータエンジニアリングスキルが求められます。 -
セルフサービスプラットフォームのコスト
データメッシュではデータの利用（分析）もセルフサービスとなります。BIやデータ分析の構築に金額や労力がかかります。
また、分散型アーキテクチャの維持に伴うコストも考える必要があります。
これ以外にも様々な課題がありますが、データの民主化を進めるにあたりデータメッシュは非常に魅力的なアーキテクチャとなります。
AWSで実現するデータメッシュアーキテクチャの例
Lake Formationでガバナンスを統制するパターン
AWSでデータメッシュを実現するにはGlue Data CatalogとLake Formationを活用することがポイントとなります。
これらのサービスを使うことでドメインごとのデータ所有と管理と横断的なガバナンスを比較的簡単に実現することが可能となります。
データプロデューサ
データプロデューサでは以下のサービスを活用します。
-
S3
S3はデータレイクとして機能します。このデータレイクに各ドメイン側でETL処理を行いデータを格納します。 -
Glue Crawler / Glue Data Catalog
S3に格納されたデータは、AWS Glue Crawlerを使用することでデータセットの検出が可能となります。検出したデータセットはAWS Data Catalogに登録され、テーブルとパーティションを追加し、その後スキーマの変更が検出可能となります。 -
Lake Formation
Glue CrawlerをLake Formationと連携させます。これによりデータメッシュ全体でLake Formationを使用したデータアクセス認証を行うことが可能となります。
ガバナンスコントローラ
-
Glue Data Catalog
データプロデューサ側でクロールされた情報はガバナンスコントローラ内のGlue Data Catalogにデータカタログエンティティ (データベース、テーブル、列、属性) を作成します。
これにより、データコンシューマ間でカタログを検索することが可能となります。 -
Lake Formation
Lake Formationにてコンシューマ側のアクセス許可を設定します。アクセスが許可されたもののみコンシューマよりアクセスが可能となります。許可はタグベースのアクセス制御に基づいて行われます。
この機能により全体のガバナンスを統制します。
データコンシューマ
-
Glue Data Catalog
ガバナンスコントローラより許可されたDBとテーブルのリンクが設定されます。これによりコンシューマ側でのデータアクセスが可能となります。 -
Lake Formation
Lake Formationにて、コンシューマアカウントの各IAMユーザーとロールに権限を付与します。
付与されたアクセス権限に基づいてAthenaやRedShiftにデータをロードします。
これによりコンシューマ側での権限を制御することが可能となります。
Amazon DataZoneでガバナンスを統制するパターン
Amazon DataZoneを使用してガバナンスを統制することも可能です。
こちらを採用する上での大きなポイントとしてはデータカタログで必要なデータを検索できる点とワークフローでデータのアクセス権をリクエストできる点となります。
Amazon DataZone は、AWS、オンプレミス、およびサードパーティのソース全体に保存されているデータを迅速かつ簡単にカタログ化、発見、共有、管理できるようにするデータ管理サービスです。Amazon DataZone を使用すると、組織のデータアセットを監督する管理者やデータスチュワードは、きめ細かい制御を使用してデータへのアクセスを管理および統制できます。
データプロデューサ
データプロデューサでは以下のサービスを活用します。
-
S3
S3はデータレイクとして機能します。このデータレイクに各ドメイン側でETL処理を行いデータを格納します。 -
Glue Crawler / Glue Data Catalog
S3に格納されたデータは、AWS Glue Crawlerを使用することでデータセットの検出が可能となります。検出したデータセットはAWS Data Catalogに登録され、テーブルとパーティションを追加し、その後スキーマの変更が検出可能となります。 -
Lake Formation
Glue CrawlerをLake Formationと連携させます。これによりデータメッシュ全体でLake Formationを使用したデータアクセス認証を行うことが可能となります。
ガバナンスコントローラ
-
Glue Data Catalog
データプロデューサ側でクロールされた情報はガバナンスコントローラ内のGlue Data Catalogにデータカタログエンティティ (データベース、テーブル、列、属性) を作成します。
これにより、データコンシューマ間でカタログを検索することが可能となります。 -
Lake Formation
ハイブリッドアクセスモードでデータプロデューサのデータ格納場所をLake Formationに登録し、テーブルメタデータをDataZoneビジネスデータカタログに公開します。 -
DataZone
Datazone内にデータポータルと呼ばれるデータカタログが構築されます。
ユーザはデータポータルを参照し、目的のデータプロダクトを検索します。
必要なデータがあればアクセス権をリクエストできます。DataZoneにはデータ所有者がリクエストの確認と承認に使用するアクセス管理ワークフローが組み込まれており、ワークフローによって許可申請が行われます。
この機能により全体のガバナンスを統制します。
データコンシューマ
-
Glue Data Catalog
DataZoneにより許可されたDBとテーブルのリンクが設定されます。これによりコンシューマ側でのデータアクセスが可能となります。 -
Lake Formation
Lake Formationにて、コンシューマアカウントの各IAMユーザーとロールに権限を付与します。
付与されたアクセス権限に基づいてAthenaやRedShiftにデータをロードします。
これによりコンシューマ側での権限を制御することが可能となります。
また、DataZoneではデータリネージ機能を使用することが可能となります。
この機能により以下のようなニーズを満たすことができます。
- 自分が作成したデータを誰が利用しているかを追跡したい
- データの出所を確認して分析に利用しているのが適切なデータか把握したい
AWSで構築する場合の課題
前述のようにAWSで構築することで簡単にデータメッシュを実現することが可能となります。
また、データメッシュの課題であったガバナンスはLake FormationやDataZoneを使用することで解決することが可能となります。
ただし、以下のような課題があります。
-
各ドメインでデータ収集の仕組みを構築する必要がある。
AWSに限った話ではありませんが、各ドメインでETL処理をはじめとしたデータ収集の仕組みを構築する必要があります。 -
データの品質を統制することができない。
Lake FormationやDataZoneを使用することでアクセス権のガバナンスを統制することはできますが、データの品質（欠損データや外れ値等）は全体でコントロールすることができません。 -
そもそも組織がドメイン駆動に対応している必要がある。
こちらもAWSに限った話ではありませんが、そもそも論としてドメイン駆動設計に基づいた組織構成とシステムが前提となっているため、既存のシステム次第では対応できない可能性があります。
データファブリック
データメッシュと同様に近年注目されているデータアーキテクチャに 「データファブリック」 があります。
データメッシュは組織や業務に重点を置いたデータ管理手法となりますが、データファブリックはテクノロジーに重点を置いたデータ管理手法となっています。
AIやMLを組み込み、データアクセスを簡素化することでデータの効率的な管理や分析を行うための手法となります。
こちらはメタデータを一元的に管理するアーキテクチャとなっており、組織体系に依存しないのでもしかするとデータメッシュよりは適用しやすいかもしれません。
そして、データメッシュは「分権化」、データファブリックは「統合」に焦点を当てており、用途や組織のニーズに応じて選択されます。
ここで一つ意識すべき事項として、データメッシュとデータファブリックは「技術」ではなく「概念」ということです。
データメッシュやデータファブリックの基本形はありますが、概念なので自由に形を変えることができます。
つまり、データメッシュにデータファブリックの要素を取り入れたり、組み合わせることも可能です。
例えばMicrosoft Fabricはその名の通り、データファブリックを構成するためのサービスとなりますが、ドメイン主導やデータプロダクト等のデータメッシュの概念も取り入れることもできます。
「ビジネス判断」にとって最適な「データ」を提供することがデータ基盤の目的となりますので、アーキテクチャの基本形にこだわりすぎずに、本来のビジネス価値を高めることを意識して構成を検討いただくのが良いのかなと思います。
それぞれの特徴は以下を参考にしていただければと思います。
| 項目 | データメッシュ | データファブリック |
|---|---|---|
| 定義 | 分散型のデータ管理アーキテクチャ。ドメインを単位としてデータを所有・運用し、データをプロダクトとして扱う手法。 | 組織全体のデータを接続し、統合するためのテクノロジーとツールのフレームワーク。 |
| 主な目的 | 自律的なデータ管理を通じてスケーラビリティと効率性を向上させること。 | データ統合とアクセス性の向上を目的とし、組織全体でデータを活用しやすくすること。 |
| アーキテクチャ | ドメイン駆動設計（DDD）に基づき、データをドメインごとに分散管理。 | 中央集約型で統合されたアーキテクチャを基盤とするが、異なるソースをシームレスに接続。 |
| データの所有権 | 各ドメインチームが責任を持ち、データプロダクトを提供。 | データ管理は中央集権的または自動化されたシステムが担当。 |
| 運用モデル | ドメインチームによるデータの運用（分権化）。 | 中央で構築されたシステムを用い、部門間でデータアクセスを統合（集中化）。 |
| 適用範囲 | 大規模で複雑な組織、特に多様なドメインが存在する場合に適用。 | 多数のデータソースを統合・接続する必要がある場合に適用可能。 |
| スケーラビリティ | チームごとにスケールできる分散型アプローチで高いスケーラビリティを実現。 | 高スループットと統合性を重視し、スケール可能な統一基盤を構築。 |
| 自動化 | セルフサービスデータプラットフォームを用いるが、自動化よりもチーム主導のデータ運用を重視。 | AIやMLによるデータ統合プロセスの自動化を重視。 |
まとめ
今回はデータメッシュの概念とAWSでの実現例を紹介しました。
AWSではAWS Lake FormationやAWS DataZoneを用いることで、データメッシュの原則に従いながら、効率的かつセキュアなデータ管理が可能です。
データメッシュの実現には以下のような要素が重要となります。
- ある程度の規模の組織である
- 組織や文化の変革に対応できる
- ドメインごとにデータチームを組織できる
組織変更は大規模な企業ほど理解や協力を得る事が難しく、これが導入を阻む大きな要因の一つだと思います。
データメッシュはドメイン駆動設計が反映された組織やシステムが前提とはなりますが、ガバナンス統制とデータの民主化を行うことができる魅力的なアーキテクチャだと思います。
ちなみに他のデータアーキテクチャと組み合わせることも可能です。
もし、データメッシュを構築することがあれば参考にしていただければ幸いです。
おまけ
データプロデューサ側のデータ収集は以下の記事が参考になるかもしれません。
データアーキテクチャは組み合わせることも可能です
データエンジニアリングに関するおすすめ書籍も参考にしていただければと思います。
Discussion