この記事は インフォマティカ Advent Calendar 2022 Day14 の記事として書かれています。
はじめに
データマネジメントのエバンジェリストをやっているもりたくです。
本日は、先日解説した「データファブリック」と並んで関心の高いデータマネジメントワードである「データメッシュ」について解説したいと思います。
この記事を読んだ人が「データメッシュとは何でどう実現すべきものか、データファブリックとの違いは何か？」を少しでも理解できれば嬉しく思います。
データメッシュとは何か？
データメッシュという用語は、2019年にZhamak Dehghaniによって最初に定義されています。よりディープにデータメッシュについて知りたい方は、本記事を読んだ後に、以下の情報を熟読することをお薦めします。
- How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh： なぜデータメッシュが必要とされるのか
- Data Mesh Principles and Logical Architecture： データメッシュとは何を実現することか
本記事では、上記の原典よりも簡単にデータメッシュの概要を解説することを目指します。
データメッシュとは、Wikiによれば、以下と定義されています。
Eric Evansのドメイン駆動設計理論とManuel PaisとMatthew Skeltonのチームトポロジー理論を引用し、ドメイン指向のセルフサービス設計によって分散型データアーキテクチャを構築する社会技術的アプローチである。データメッシュでは、分析データの責任を中央のデータチームからドメインチームに移し、データプラットフォームチームはドメインにとらわれないデータプラットフォームを提供する。
私は最初にこの定義を読み、すぐにその全体像をイメージすることができませんでした。
しかし、情報を集めるにつれて、以下の理解に辿り着きました。
データメッシュとは、データを1箇所で中央集権的に管理するのではなく、分散化を良しとして管理するアプローチのこと
今も昔もSingle Source of Truth（信頼できる唯一の情報源) という名のもとに、「データ利活用を効率的に推進するためには、あらゆるデータを一つのデータレイクやデータウェアハウスに集めて管理しましょう」という話は良く聞くと思います。かく言う私も、そのようなプレゼンをイベントですることも少なくないです。
しかし、データメッシュはこの考え方に逆行し、「データは必ずしも一箇所に集めなくても良いよ、事業部などの各組織でちゃんと管理してくれればデータはどこにあってもOKよ」という考え方です。
従って、データメッシュはデータ管理における王道ともいえる中央集権管理に戦いを挑む、新しい考え方と言えます。
Centralize （集中化）： 大規模な集中型データプラットフォームの構築をめざす
VS
Decentralize（分散化）： 個別組織が管理する分散型データプラットフォームの構築をめざす（データメッシュ）
引用元：Developers Summit 2022; Microservices, Data, and Data Mesh; CONFLUENT, Shinichi Hashimoto
なぜ、データの集中化ではなく分散化を良しとするのか？
この疑問に回答するには、何年も前から存在する、データウェアハウスにデータを集めれば全部OK、という神話の限界に目を向ける必要があります。
私は企業内で事業部横断のデータ利活用を推進するDX推進やデータマネジメントオフィスの方と話す機会があります。そこで最近よく耳にするのが以下のようなお話です。
- 「各グループ会社や事業部は既に個別のデータレイクやデータウェアハウス、BIツール環境を持っている」
- 「今さらデータレイクを一つに統合し、移行するようにガイドしても従ってくれそうもないし、工数とお金が膨大にかかる」
- 「日本だけでなく海外支社や事業部も含めて統制を取るのが難しい」
- 「海外支社はこちらの言うことなんて聞いてくれない」
- 「国ごとにデータにまつわる規制の内容が異なっており、国境を越えてデータを集めて良いかの判断がつかない」
- 「そもそも本当にデータを一箇所に統合する必要があるのか、どんなメリットがあるのか」
企業の規模が大きければ大きいほど、更にそこで取り扱っているビジネスが多様化していればいるほど、このデータ集中化に課題を持つ傾向は強い印象があります。実際、先日のデータファブリックの記事の一節「データの複雑性の拡大」でも説明したように、企業が取り扱うデータの複雑性は年々増す一方です。この環境下において、一つの中央集権チームが各事業部のビジネスニーズやプロセスを的確に理解しながら、データにまつわる規制やニーズを全て完璧に把握し、統制管理していくのは技術的にも、ワークロード的にも困難になることが多いです。特に、諸外国のデータ規制を一人の人が全て把握するのはもはや困難で、もしそれができる人がいたら希少価値は極めて高いため、独立してデータ専門のコンサルタントとして世界を股にかけて活躍した方が良いと思います。
複雑化するデータプライバシー規制やアジャイルに生まれてくるデータ利活用のニーズ、これらに適応しながら将来的に取り扱うデータの量や種類、そこに関わる企業や組織、ユーザーの数、ビジネスの数をスケールさせていくのは簡単ではありません。むしろ集中化して管理するには管理のキャパ的に限界があり、無理ゲーになっている企業も多いです。そこで、集中化するのを諦めて発想を転換し、データの提供側と利用側の両方の組織で自律的に分散管理できるようにしてしまえ、というのがデータメッシュを推す世の中の流れではないかと私は感じています。
ただここで言いたいのは、データメッシュはデータの集中化を否定しているわけではありません。集中化が困難な状況に陥っている人達に対し、あくまで分散化して管理する別の選択肢を提示してあげているのに他ならないのだと思っています。
更に、集中管理するものがゼロかというとそうではなく、あくまで分散管理できるものは各ドメインに任せ、必要最低限の集中管理だけしよう、という柔軟且つ現実的なアプローチでもある点は、私がデータメッシュの好きなポイントとも言えます。
データメッシュの4つの規律と目指すべき世界
データメッシュは、データの分散化を推進する上で4つの規律（Principles）を定義しています。というのも、各ドメインにあたる組織が規律やルールなく完全自由にデータを取り扱ってしまっては、企業としてデータを"管理"しているとは言えなくなってしまうからです。特に、「ドメイン横断でのデータ利活用も企業としては勿論実現していきたい」ので、ドメインを横断する一定のルールは設ける必要があります。そこで定義されているのが以下4つの規律になります。
| No | Principles | 規律 |
|---|---|---|
| 1 | Domain-oriented decentralized data ownership and architecture | ドメイン別オーナーシップとデータ分散アーキテクチャ |
| 2 | Data as a product | データのプロダクト化 |
| 3 | Self-serve data infrastructure as a platform | セルフサービス型データプラットフォーム |
| 4 | Federated computational governance | 横断的なデータガバナンス |
なお、この4つの規律を解説する上で、2022年のデブサミでShinichi Hashimoto氏が説明し、公開されている「Microservices, Data, and Data Mesh」の資料からいくつか絵をお借りしながら、独自解説していこうと思います。
（Zhamak Dehghani氏が公開している絵よりも直感的にイメージが掴みやすいです）
1. ドメイン別オーナーシップとデータ分散アーキテクチャ
引用元：Developers Summit 2022; Microservices, Data, and Data Mesh; CONFLUENT, Shinichi Hashimoto
データメッシュにおける最も重要な考え方の一つとして、各事業ドメイン（マーケティング、営業、開発、製造、人事、財務などの組織単位）でデータに対して責任を持つことが求められます。つまり、自ドメイン内のデータに対してオーナシップを持つということです。
自ドメイン内でのデータ利活用において、必要なデータを収集して保有し、分析等に使えるようにデータ品質を維持向上させ、規制に準拠した安心安全なデータ管理とビジネスへの利活用を行うことは、各ドメインの責任のもとで行います。各ドメインが自ら責任を持ち、自律的に管理することによって、企業全体におけるデータ利活用が将来的にスケールしたとしても、その管理の複雑さを各ドメインに分散し、現実的な管理を継続運用できるという考え方です。
但し、この規律のみが進み過ぎると、各ドメインが完全独立したガラパゴスな島や独自の帝国となるのを許してしまい、データ利活用が逆に停滞するリスクを含みます。結果、ドメインを跨るデータの利活用（これには企業横断のデータ利活用、他社、他業種との共創も含まれる）が実現できなくなります。これはデータメッシュが目指すデータ利活用のスケールを支える理念とは異なるものであり、これを回避する必要があります。そこで、その他の規律が重要となってきます。
例えば、昨今では開発事業部はマーケティングや営業、サポートといった各事業部が持つ顧客データを分析し、顧客が真に求めている満足度の高い商品開発を進めるようなケースも多いです。このようなケースでは、営業やサポート事業部は自ら管理する顧客データを責任もって整備し、彼らにとってのデータに対するユーザー、とも言える他事業部へ公開することが求められます。つまり、ドメイン横断のデータ利活用のニーズを実現するために、各ドメインは他ドメインから求められるデータの品質、安全性、アクセス性などを担保し、提供する責務も持ちます。
この他ドメインから求められる特別なデータ、ドメイン横断で共有すべきデータを生み出すためには、データそのものを企業内の価値あるプロダクトとして丁寧に取り扱うことが求められ、その品質を自律的に担保するためにセルフサービスで使えるデータ管理ツールやプラットフォームも必要で、更にドメイン横断でデータ共有するための最低限のルールと統制された運用が求められます。
ここからは、それら3つの規律を解説していきます。
2. データのプロダクト化
引用元：Developers Summit 2022; Microservices, Data, and Data Mesh; CONFLUENT, Shinichi Hashimoto
他ドメインに提供するデータは、まるで自社の実際のプロダクト、製品であるかのように取り扱うことが求められます。そしてデータを使用する側のユーザーも、そのプロダクトの顧客として取り扱うことが求められます。なぜならば、ユーザーとしても、どこに存在するかわからない、品質が保証されない、プライバシーや規制の観点から安全性が担保されていない、アクセスするのに大変なデータは誰も使いたいと思わないためです。
以上より、各ドメインは他ドメインに提供するデータをプロダクトとして扱うために、以下の特性をサポートすることが求められます。
| 特性 | 概要 |
|---|---|
| Discoverable | 発見しやすい |
| Addressable | 所在や形式が明確でアクセスしやすい |
| Trustworthy | データ品質が担保されて信頼性がある |
| Self-Describing | 分析に利用しやすいように収集・整備されていて理解しやすい説明も記述されている |
| Inter operable (Governed by open standards) | 他ドメインのデータと組合せて使えるように標準に準拠している |
| Secure | プライバシーや規制に違反するリスクを管理できている |
各特性はドメインの責任の下で担保することが求められますが、データの提供側と使用側の双方が満足するためには相互理解が必要です。そこで、後述する別の規律、横断的なデータガバナンスとして担保すべき基準をデータ標準として定め、これを共通ルールとして管理運用することが求められます。
なお、他ドメインからのデータのアクセス方法としてはAPIが推奨されていたりしますが、実運用ではそれだけに拘る必要はないと考えています。大量データの一括提供を求めるケース、ストリーミングによる連続したデータの提供を求めるケース、少量データをリアルタイムで求めるケース（これはAPIが最適である）など、利用ユースケースに応じて提供形態を変えるのが理想的です。実際、Data Management at Scaleを執筆しているPiethein Strengholt氏は、自社の事例を紹介する際に、データのアクセス方法として上記の3つのユースケースに対応することを標準として決めて運用していると説明しています。
また、各ドメインが”自ら”責任を持ってこのデータプロダクトの特性を担保するためには、自分たちで全てマネージできる必要があります。もしその担保を情シスなどの他部門に依頼していては、そこに作業が集中してしまい、分散化の意味がなくなってしまいます。そこで必要となってくるのが、データ特性を各ドメインが”セルフサービス”で担保するためのツールであり、データプラットフォームです。
3. セルフサービス型データプラットフォーム
引用元：Developers Summit 2022; Microservices, Data, and Data Mesh; CONFLUENT, Shinichi Hashimoto
各ドメインの人たちは、その全てがITの専門家ではありません。従って、データプロダクトの特性を自ら担保するためには、使いやすいツールやデータプラットフォームの助けが必要です。
ここでは各特性をサポートする関連ツールを紹介しておきます。これらのツールは基本的にはITスキルに依存せず、誰でも扱えることが求められます。従って、プログラミングが必要なツールではなく、GUIベースでノーコード・ローコードで使えるツールが求められます。また、インストールやインフラ運用といった手間も極力排除したいため、クラウドネイティブなSaaS型で提供されるツールであることが望ましいです。
| 特性 | 関連ツール | ツールて提供するサポート概要 |
|---|---|---|
| Discoverable | データカタログ | メタデータ管理をすることで発見しやすくする |
| Addressable | データカタログとデータマーケットプレイス | メタデータ管理をすることで所在や形式、アクセス方法が明確になる |
| Trustworthy | データ品質 | データ品質の可視化、クレンジングを行うことで品質を担保する |
| Self-Describing | ETL/ELT/データプレパレーションツールとデータカタログ | データの収集・変換を容易に行い、更にその説明をメタデータとして補記できる |
| Inter operable (Governed by open standards) | データ品質とマスタデータ管理、API管理 | 他ドメインのデータと組合せるためのリファレンスデータ、マスタデータの標準化を行い、API経由のデータアクセスを可能にする |
| Secure | データカタログとデータガバナンス | PIIデータなどの機微データの分類を行い、それに則って管理ポリシーとプロセスを決めて統制を可能にする |
これらのツール機能が全て一つのセルフサービス型データプラットフォームとして提供されることによって、全てのドメインのあらゆる人が、責任あるデータプロダクトを分散化して整備することが可能になります。
4. 横断的なデータガバナンス
一部引用させていただき独自描写した図、引用元：Developers Summit 2022; Microservices, Data, and Data Mesh; CONFLUENT, Shinichi Hashimoto
最後に、ドメイン横断で均質な特性を持つデータプロダクトを整備・共有しながら継続的に運用していくために、全ドメイン共通のポリシーと標準化ルールの定義、組織と人材の育成と確立、プロセスの設計と実装、ITプラットフォームの整備、といった横断的なデータガバナンスの実現が必要です。この実現には、横断的なデータガバナンスの推進に責務を持つデータガバナンスオフィスチームを組閣し、運用していくのが一般的です。
データガバナンスと聞いて何から手を付けたら良いかわからない場合、ドメイン横断でデータを共有するための目的とゴール設定、更にそれを実現するための共通プラットフォームと運用ルール、共有する上で担保すべきデータ特性の最低限の受入基準の定義からスタートするのがお薦めです。それらが定義・実現さえすれば、一定レベルのドメイン横断のデータ利活用が可能となるため、後は継続的な運用カイゼンを行っていくことで理想的な運用に近づけていくことが可能となります。最初から完璧なデータガバナンスを求めてしまうと、その実現のハードルが高くなりすぎて、結果企画検討だけで計画倒れするケースもあるので注意ください。
これはデータメッシュに限らず、一般的なデータマネジメントにおけるデータガバナンスにおいても同様のプラクティスが推奨されています。データメッシュ特有の要素は、あくまでデータ特性を担保する方法については、各ドメインの独自性を許容してあげることです。この遊びの柔軟性を持つレイヤーを組み込むことによって、データ利活用をスケールしていく際に増していくデータの複雑性を全体統制することなく、運用することが可能となります。
以上まとめると、データメッシュはイイ感じに最低限のドメイン横断のデータガバナンスルールを設けながら、誰もが使えるイイ感じのセルフサービス型ツールとデータプラットフォームを利用し、各ドメインが自律的に責任を持ってデータプロダクトを整備し、ドメイン内外のデータ利活用のスケールを可能とするアプローチです。
各ドメインが自律的に動けるような人材とケーパビリティを持つことにも繋がるため、もし実現できれば、DXを推進していく上で頼りがいのある強固な組織や人材も同時に生み出すことができます。ただ一方で、各ドメインでの自律的な活動が期待できないような組織の場合、その実現は簡単な道ではないとも言えるでしょう。
インフォマティカと共に実現するデータメッシュ
ここからはデータメッシュの実現に向けて必要となる、セルフサービス型データプラットフォームについて具体的にご紹介したいと思います。
インフォマティカのデータマネジメントクラウド（正式名称はIntelligent Data Management Cloud、略称はIDMC）は、以下5つの特徴を持っているため、データメッシュの実現を強力にサポートすることができます。
| No | 特徴 | メリット |
|---|---|---|
| 1 | オールインワン | 包括的なデータ管理サービスをオールインワンのプラットフォームの中で利用できるため、全てのデータ特性の担保を効率的に実現できる |
| 2 | マルチクラウド・ハイブリッド対応 | あらゆるクラウドレイクハウス（AWS、Azure、GCP、Oracle Cloud、Snowflake、Databricksなど）、BIツール（Tableau、Power BIなど）、クラウドアプリケーション（Salesforce、SAP S/4HANA、ServiceNow、Workdayなど）、オンプレミスアプリケーション（SAP ECC、Oracle DB、IBM Db2など）に接続可能なコネクターを持つため、各ドメインが使うデータサービスの分散化を許容しながらドメイン横断の統一的なデータ管理を実現できる |
| 3 | ノーコード・ローコード | データ管理サービスは全て非ITユーザーでも操作可能なノーコード・ローコードのツールとして提供されるため、各ドメインでのセルフサービスによる自律的なデータ特性の担保が可能となる |
| 4 | クラウドネイティブ、AIサポート | データ管理サービスは全てクラウドネイティブなサービスとして提供されるため、データ利活用が広がっても簡単にスケールできる。更に、CLAIREというデータマネジメント専用のAIがその運用をサポートするため、自動化された効率的なデータ管理を実現できる |
| 5 | エンタープライズ対応 | 超大規模スケールでもサポート可能なエンタープライズ対応のマイクロサービス・アーキテクチャで構成されていて、且つデータガバナンスにも対応しているため、エンタープライズ規模でも安心して利用できる |
リファレンスアーキテクチャ：マルチクラウド・ハイブリッド対応のデータメッシュ
参考までに、データマネジメントクラウドとクラウドエコシステムによって実現する、マルチクラウド・ハイブリッド対応のデータメッシュのリファレンスアーキテクチャを紹介します。
このアーキテクチャは、データメッシュが求める4つの規律を兼ね備え、分散化を許可しながらも統一されたセルフサービス型のデータプラットフォームです。
オレンジ色のレイヤーにあるドメイン横断のデータ管理サービスは、全てデータマネジメントクラウドが提供します。そして、中央の青緑色の多重のData ProductsとData Accessレイヤーは、各ドメインで選んだ多様なクラウドレイクハウス（Amazon Redshift、Azure Synapse、Google BigQuery、Oracle Autonomous DB、Snowflake、Databricksなどを組合せて）で構成することが可能です。データマネジメントクラウドはマルチクラウド・ハイブリッド対応のコネクターを持っているため、この2つのレイヤーを柔軟に接続し、フェデレ―テッドな横断管理が可能となります。
1 各ドメインで、データ統合（Data Integration）サービスを使用することで、コーディング不要であらゆるデータソースから各ドメインで選択したクラウドレイクハウスやデータマートにデータを収集・格納することができます。またその際には、データを分析しやすい形式に変換するデータ統合の他、データ品質（Data Quality）サービスを使用することで、データプロファイリングによる健康診断を行い、問題があればデータクレンジングを行ってデータ品質を容易に向上させることができます。
2 データカタログ（Data Catalog）サービスを使用することで、分散化したあらゆるデータソースやあらゆるクラウドレイクハウス上のメタデータを自動スキャンし、解析してドメイン横断のメタデータカタログを自動生成することができます。その際には、PIIデータなどのデータ分類を自動化し、ガバナンスのきいたSecureなデータ管理を実現することもできます。システムメタデータ（データアイテム、データパターン、リレーションシップ、データリネージなど）、ビジネスメタデータ（ポリシー、ビジネス用語、管理プロセスなど）、オペレーショナルメタデータ（アクセス権限、データ品質スコアなど）といったあらゆるメタデータの横断的な管理をサポートします。
3 ドメイン横断のデータ共有のポータルとなる、データマーケットプレイス（Data Marketplace）サービスを使用することで、ガバナンスのきいたドメイン横断のデータ利活用を簡単に実現することができます。データカタログと連動しているため、データカタログの中で管理されているデータの中で、データプロダクトとして他ドメインに公開したい特別なデータのみをデータマーケットプレイス上にデプロイすることができます。結果、データプロダクトと自ドメイン内のみで取り扱うデータの2種類を各ドメインで独自管理することができます。あらゆるユーザーがこのデータマーケットプレイスを参照し、他ドメインのデータプロダクトを簡単に発見・理解することができます。
4 ユーザーはデータマーケットプレイス上で欲しいデータプロダクトを見つけたら、Amazonでショッピングをする感覚で、データへのアクセスをデータ提供ドメインに対してリクエストすることができます。リクエスト後にはワークフローが起動され、プライバシーや規制の観点でデータ利用上問題が無いか、データ提供ドメイン内でレビューが行われ、問題がなければ承認後にデータアクセス手段を提供することができます。この仕組みにより、データ利用ドメインは安心安全にガバナンスのきいたデータをドメイン横断で利用することができます。
5/6/7/8 データアクセス手段は、ETL/ELTツールによる大量データの一括連携、ストリーミングデータの連携、REST-APIによるリアルタイム連携など、データ利活用のビジネスユースケースに合わせてデータマーケットプレイス上で選択し、リクエストすることが可能です。各手段はデータ統合、API＆アプリケーション統合（API & App Integration）サービスを使用することで、簡単に準備することができます。こうしてデータ提供ドメインと利用ドメインがデータマーケットプレイスを通じてコミュニケーションを取ることにより、分散化されたデータ環境の中でもドメイン横断のデータ利活用を実現できます。
なお、ドメイン横断でデータを組合せて横串分析などを行う場合、データの組合せの軸となるリファレンスデータ、マスタデータは統合管理されている（統一まではされていなくても良い）必要があります。もしこれが統合管理されていない場合、データ分析の軸が揃わなくなってしまうため、ドメイン横断のデータの利活用は実質困難に陥ります。これを回避するため、本リファレンスアーキテクチャにおいては、マスタデータ管理（MDM & 360 Application）サービスを1.のデータ整備のプロセスに組み込んで解決することができます。
以上のクラウド・サービスを包括的に使用することで、マルチクラウド・ハイブリッド対応のデータ分散化を許容した、データメッシュの世界を実現することができます。
データファブリックとデータメッシュの違い
データメッシュについて解説してきましたが、ここまで読んだ方ならば、データファブリックとデータメッシュの違いについて、多少想像はつきますでしょうか。
分散化したデータ環境におけるデータ管理や、データ利活用の将来的なスケールに備えている点、理想的なデータ管理を追求している点などは共通していると言えますが、実態としてその内容は異なります。
その違いについて整理したものがこちらの図になります。
一言で言えば、データファブリックが技術的な要素に重点を置いているのに対し、データメッシュは組織的・文化的な規律に重点を置いている点が大きく異なっていると言えます。しかし、その理念などには共通項も多いため、両方共に組合せて採用可能なものであると思っていただいて問題ないと思います。
おわりに
本記事では、「データメッシュとは何でどう実現すべきものか、データファブリックとの違いは何か？」についてご紹介しました。少しはその理解のお役に立てていれば幸いです。
2022年の私が体験した傾向として、データファブリックと比較してデータメッシュを目指したいという相談を顧客から貰う機会は少なかったです。一方で、コンサルタントファームの方々は、日本企業のデータの分散化の現状や中央集権の困難さを憂う人が多いのか、データメッシュの方により注目している人が多いような印象を受けました。この傾向から察するに、来年以降はデータメッシュに関する相談が増える可能性が高いのではないかと思っています。
なお、データファブリックやデータメッシュの考え方は、その全てを採用しなくても、企業のデータマネジメントをデザインしていく上で参考になる要素は多いと思います。偶然でもこの記事に辿り着いた人がこれらの考え方に関心を持ち、そこから日本のデータマネジメントが更に高度化され、データ利活用が少しでも活発化していけば嬉しく思います。
最後までお読みいただき、ありがとうございました。