はじめに
Forrester社の調査によると、企業内の全データの60パーセントから73パーセントが分析に使用されないままになっている。一方、アクセンチュアが最近行った調査では、データから具体的で測定可能な価値を実現できていると回答した企業はわずか32パーセント、データおよびアナリティクスプロジェクトから実用性の高い洞察や提言が得られたと回答した企業はわずか27パーセントにとどまっている。
データの利活用が進まない原因として、中央集権的なデータ管理による組織的スケーリング課題が挙げられる。データ利活用の推進とともに、データ生産者とデータ利用者の数は増加しているのに対し、中央での一元的なデータ管理がボトルネックになるためである。
そこで、データ基盤の組織的なスケーリング課題を解決するためにデータメッシュという考え方が生まれた。データメッシュは技術的なスケーリング課題ではなく、組織的なスケーリング課題に重点をおくことで、データ基盤のパラダイムシフトを促している。そこで今回はデータメッシュのコンセプトについて説明する。
データの利活用が進まない原因
データの利活用が進まない2つの代表的なアプローチがあるが、そのどちらも根本的な原因は組織的なスケールに失敗しているからである。
データメッシュとは何か
Thoughtworks社のZhamak Dehghani氏が2019年に「How to Move Beyond Monolithic Data Lake to Distributed Data Mesh」で紹介したアーキテクチャパターンのこと。従来の中央集権的なデータ管理の課題を解決し、データの利活用を推進するために、各ドメインによる企業のデータ管理に対する分散化されたアプローチを採用している。
データを 1 つの大きなリポジトリとして捉えるのではなく、独立したデータプロダクトの集合体として捉えることで、データの所有権と責任レベルを向上させることを目指している。
データメッシュアーキテクチャ
点線はデータの共有を表し、青色のコンポーネントは各ドメインを表している。また灰色のコンポーネントは全ドメインの共通部分になっており、標準化やディスカバリ、データガバナンスを担保することで、データのサイロ化を防ぐ役割を担っている。
データメッシュアーキテクチャの特徴
中央のデータレイクが必要なく、各ドメイン(Data Nodes)が、保有するデータのオーナーシップを担っている。
各ドメインは必要なデータを中央のデータレイクを通すことなく、直接対象のドメインから提供されている。
各ドメイン間の共通部分としてData Hub(Data Infrastructure)が存在し、データ活用のための標準化やディスカバリ、データガバナンスの担保を担っている。
データメッシュプラットフォームは、意図的に設計された分散データアーキテクチャであり、相互運用性のための集中的なガバナンスと標準化のもと、共有され調和したセルフサービス型のデータインフラによって実現される。
サイロ化されたデータ基盤との大きな違い
データメッシュのコンセプトがデータ基盤のサイロ化を推奨しているわけではないことに注意する必要がある。データのサイロ化を防ぐためにデータレイクが生まれたという歴史的な背景があるが、データメッシュはデータの物理的な一元化をすることなく、データのサイロ化を防ぐ仕組みを導入している。代表的な仕組みとしては、クロスドメインのリネージとカタログ機能などが存在する。
データメッシュの思想
データメッシュの本質は、技術的なスケールングに対する解決策ではなく、組織的なスケーリングに対するパラダイムシフトである。
中央集権的なデータ管理から、「ドメイン主導によるデータオーナーシップ」に移行することで、「データそのものをプロダクト」として捉え、ドメインデータの質の向上とデータプロダクトのエコシステムを実現する。そのために必要なのが、「プラットフォームとしてのセルフサービス型データ基盤」と「ドメインと中央による分担管理型データガバナンス」である。
データメッシュを支える4つのコンセプトについて以下で詳しく説明する。
1. ドメイン主導によるデータオーナーシップ
データメッシュが、既存のデータアーキテクチャと大きく異なる点は、データのドメイン主導によるオーナーシップの分散化を推進していることである。 ドメインデータから最大の価値を生み出すには、ドメインの専門知識を蓄積し、ドメイン専門家自身が重要な決定を下す権限と、その決定を実行する能力(スキルやリソース)の両方が必要である。前述に加えて、実行に伴う責任もドメインが担うことで、実行と責任を一元化し、ドメインにオーナーシップを与える。
ドメイン主導のオーナーシップにより、部分的なアウトソーシングなしでドメイン自身で問題を解決することができるため、効率が大幅に改善される。つまりデータのオーナーシップの分散化によって、多様化するデータソースと付随するアプリケーションにおいてより良いスケーラビリティを実現することを目指している。
ドメインとは何か
ドメインとは、一般的に共通のビジネス目的のために組織された人々の集まりのことを指す。eコマースサイトを例にすると、ユーザー、マーチャント、製品、マーケティングなどがある。
データ所有権の一元化の課題
これまで数多くのデータチームが経験してきたように、データ作成者とデータ消費者の間に断絶があると、最終的にデータからビジネス価値を引き出す際に問題となる。 中央集権的なデータ環境では、あるドメインで作成されたデータの最終的な所有者と責任が誰にあるのかが不明確になりがちだからである。
中央集権型のデータ管理では、データは最終的に業務部門の外部のデータチームに渡され、データエンジニアやアナリストが、データを理解し価値を引き出そうとしている。しかし、アナリストとデータの作成者が断絶していることで、分析時にボトルネックが発生する。例えば分析に必要な変更や追加情報の作成に時間がかかりすぎ、アナリストの仕様に合わせてデータが更新される頃には、データが不要になっていたり、追加変更が判明していたりするという「非効率性」が発生する。またデータ作成者とデータ利用者の間につながりがなければ、フィードバックが失われ、データの価値が損なわれることも多い。
ドメイン主導のデータオーナーシップ
データプロダクトのドメイン主導のオーナーシップとは、最も専門的な知識を持つ人（ドメイン）がデータプロダクトのオーナーとなることで、品質、メタデータ、パフォーマンスなどに責任を持つことを意味する。ドメインは、自分たちが作成したデータ、すなわちデータの取り込み、変換、エンドユーザーへの提供について責任を負う。データの所有権と責任をドメインに戻すことで、データの所有権を移転することなく、データ価値を失うことなく、データについて最も詳しい人々が分析用にデータを準備し提供することができる。
ドメイン主導のデータオーナーシップとは、プロダクトオーナーと開発者が以下のような責任を持つことを意味する。
(1) データプロダクトの作成と、他のドメインやエンドユーザーへの提供。
(2) データが確実にアクセス可能で、使用可能で、利用可能で、定義された品質基準を満たしていること。
(3) ユーザーからのフィードバックに基づきデータプロダクトを進化させ、使用されなくなった、または関連性がなくなったデータプロダクトは取り除くこと。
(4) データプロダクトを組織内に普及させ、「マーケティング」を推進すること。
ドメイン主導のテクノロジースタック選定
ドメインは、ドメイン環境内で自分たちのデータプロダクト開発を可能にするテクノロジースタックを決定する必要がある。例えば、あるドメインはPIIや財務データに対してより信頼性の高いアップストリーム環境を必要とするかもしれないし、サードパーティのパートナーからデータを取り込むかもしれない。そのためドメインは、各ドメインデータに最適なデータ取り込み、変換、提供ツールを選定する必要がある。一方でデータプロダクトの形式は標準化され、組織全体で標準化された方法で提供される必要があり、これによりデータプロダクトユーザのシームレスな作業を可能にしている。
2. プロダクトとしてのデータ
データメッシュを実現するにはデータをプロダクトとして扱うことで、組織におけるデータの価値を高め、全社的にデータが価値ある投資であると理解することが重要である。
データプロダクトとは何か
データプロダクトとは、あるドメインから提供され、下流のユーザーが消費してビジネス価値を生み出すデータのことを指す。データプロダクトを作成、分析し、ビジネス知識と組み合わせることで、データドリブンな意思決定を目指している。
データメッシュは、データプロダクトとアーキテクチャはドメイン主導のオーナーシップで進める一方で、データ自体は組織全体でプロダクトとして共有されることを目的としている。データメッシュを深く理解するにはデータを副産物ではなく、それ自体をビジネスプロダクトとして扱うというドラスティックな発想の転換が必要である。
3. プラットフォームとしてのセルフサービス型データ基盤
既存のプラットフォームや技術の多くは、データチームによって一元化され、全ドメインのデータを取得・共有することを前提に構築されている。これはレガシーインフラと旧来のテクノロジーの限界によって必要とされた部分が大きいが、クラウドコンピューティングや簡単に拡張できるハードウェアやアプリケーションの登場によって、これらの限界はもはや存在しなくなった。
中央集権的インフラストラクチャ・モデルでは、データプロダクトを開発するドメインは、提供されたソフトウェアで作業することを余儀なくされることが最大の課題となる。例えば、ストレージとコンピューティングリソースが中央によって独占的に扱われている場合、ドメインは中央と協力してドメイン固有の変更を行う必要がある。その場合、「最も声の大きい」ドメインが、他のドメインには通用しない方法でインフラストラクチャを変更する場合も少なくない。一方，ドメイン固有の目標やデータを考慮せずに，中央のデータアーキテクチャ設計をドメインに押し付けると，他のドメイン用に最適化されたツールやインフラのために，非効率でフラストレーションのたまるドメインも発生しがちである。
そこでデータメッシュでは、データエンジニアリングに特化した能力を持たないドメインチームが、データプロダクトを自律的に作成、開発、維持できるようなセルフサービスツールを提供することで、ドメインによるデータオーナーシップを可能にした。
セルフサービス型データ基盤とは
セルフサービス型データ基盤の背景にある考え方は、ビジネスは論理的に自律したドメインで構成されており、各ドメインはビジネス機能、製品、またはプロセスをサポートするだけでなく、データプロダクトを生成するため、そのためのデータインフラが必要であるという考え方である。各ドメインは、その基盤となるデータインフラを自分で管理するのではなく、中央IT組織が提供するセルフサービスデータプラットフォームを利用できるようにすることが必要である。このプラットフォームにより、ドメインは高品質のデータの構築に集中することができ、最終的にはデータ分析という形でビジネス価値を獲得することができる。
プラットフォーム自体は、中央IT組織が構築・保守し、ドメインに依存しないことが重要である。これにより、各ドメインの必要に応じてカスタマイズや拡張が可能になる。さらに中央のIT当局による設計やベンダーの制約に阻まれることなく、各ドメインのエンジニアが構築・保守するエンドツーエンドのソリューションを自由に成熟・設計できるようになることで、最終的には、効率的な設計と、一般的に一貫性のあるデータプロダクトの作成が可能になる。
セルフサービス型データ基盤を構成するリソースとツール
監視、ロギング、アラート
監査
クエリーのパフォーマンス、並行処理
コスト構造および効率性
オブザーバビリティ(可観測性)
カタログ、リネージ
統合ID管理
スケーラビリティ（水平方向および垂直方向）
ユーザビリティ(SQLなど)
統一的なアクセス制御
分析エンジンとの相互運用性
データストレージ
中央IT組織とドメインのそれぞれに求められる役割と責任
セルフサービス型データ基盤プラットフォームは、データプロダクト開発者がデータ基盤構築の追加タスクで過負荷にならないようにするために、絶対に必要である。データエンジニア、アナリスト、インフラエンジニアは、特に負荷の高い3つの職種であり、各グループは、前例のない規模でドメインや機能を横断する専門知識を発揮することが期待されている。どの役割も過負荷にならないようにするには、職務と責任を明確に分けることが重要である。
その1つの方法として、データインフラをデータとインフラの2つのエンティティに分割することが挙げられる。
データとは、データモデル、スキーマ、変換ルール、ETL/ELTパイプライン、メタデータ、および関連するドメイン固有の知識のアプリケーションを指す。これはドメインに責任がある。
インフラストラクチャーとは、ドメインがデータプロダクトを作成し、維持するためのリソースを指す。これにはドメイン固有のデータプロダクトの作成に使用するツールやリソースのインストール、メンテナンス、アップグレード、スケーリングが含まれる。これは中央IT組織の責任である。
上記のように、セルフサービス型データ基盤プラットフォームの責任には範囲があり、組織がその範囲のどこに位置するかは、ドメインと中央IT組織が一緒になって明確に定義し、合意する必要がある。
4. ドメインと中央による分担管理型データガバナンス
いくつかのガバナンス活動や標準はメッシュレベルで定義され実施されなければならないが、メッシュレベルでは特定のビジネス知識がないため、実施する上で課題が生じることがある。そのため、ドメイン横断的な標準を設定することで、ドメイン間の共通性を持たせることが必要になる。
データメッシュは、ドメインに十分な自律性を持たせながらガバナンスを遵守するために、ドメインと中央IT組織の間で責任を分担することを提案している。そのためにはガバナンスのどの側面を共通で処理し、どの側面をドメインで処理するかについて、ドメインをまたいだ合意を形成することが必要である。
ドメインと中央による分担管理型データガバナンスとは
データメッシュは、中央集権的なデータチームやアーキテクチャから分散型モデルへのパラダイムシフトである。一方でガバナンスについては、メッシュレベルで設定されるものもあれば、ドメインの裁量に委ねられるものも存在する。データメッシュでは、ドメインと中央による分担管理型データガバナンスモデルにより、責任の共有を可能にしている。
一般的には、中央IT組織は、データ系統の報告、ドメイン間の標準、認証、およびグローバルリスクとコンプライアンスの標準とポリシーの明確化を担当することが多い。そしてデータ品質（定義と測定）、データの出所、権限付与、データの分類、コンプライアンスと用語の標準への準拠、ドメイン間のデータ実体標準化の定義などは、多くの場合でドメインが担当する。
ガバナンスの定義
ガバナンスには非常に多くのものが含まれるが、ここでは適切なデータを適切な人に適切なタイミングで届けることに焦点をあてて議論する。よってデータガバナンスの観点から以下を検討する必要がある。
セキュリティ：適切な人が認証され、データを使用する権限を与えられているか
コンプライアンス：データは、GDPR、RTBFなど、必要なあらゆるポリシーに従っているか
可用性：許可されたユーザーがデータにアクセスできるか
品質：データの品質が何らかの形で定量化され、ユーザーに伝えられているか
エンティティの標準化：ドメイン間で用語の統一がなされているか
Provenance：誰がそのデータに責任を持ち、どこから来たのかが明確になっているか
データメッシュを実現するには
データメッシュは以下のステップを経て実現される。
(1) 中央がドメインのニーズに基づいてベンダーやツールを選択し、ドメインのニーズに合わせてインフラを長期的に進化させる。
(2) ドメインは提供されたデータプラットフォームを利用して、それぞれのドメインの要件に最も効率的かつ合理的な方法でデータプロダクトを作成・管理する。
(3) ガバナンスの中央集権的な部分（企業レベルで定義されるグローバルガバナンスの懸念事項）は、インフラストラクチャープラットフォームレベルで実施される。
(4) ドメイン固有のガバナンスは、ドメインがセルフサービスインフラプラットフォームを使用して実施する。
(5) データプロダクトはデータ利用者に公開され、中央IT組織が提供・保守するインフラやツールの中で利用される。
まとめ
今回はデータメッシュのコンセプトについてまとめた。次回はデータメッシュを実現するための詳細なステップと実際にどんなデータ基盤を選べば良いのかについてまとめたい。
