データ メッシュとは
データ メッシュは、大規模かつ複雑な組織にエンタープライズ データ プラットフォームを実装するためのアーキテクチャ パターンです。 データ メッシュは、1 つのプラットフォームと 1 つの実装チームを超える範囲で分析の導入をスケーリングするのに役立ちます。
バックグラウンド
分析に対する必要性は、目新しいことではありません。 組織は常にビジネス パフォーマンスを分析する必要があり、導入以降、コンピューターを使用して分析を行ってきました。 1980 年代頃、組織は、意思決定支援専用のデータベースを使用してデータ ウェアハウス ソリューションの構築を開始しました。 これらのデータ ウェアハウス ソリューションは、長期間組織の役に立ちました。
ただし、ビジネスが変化して、ますます多様なデータが生成されるようになると、リレーショナル データベースを使用するデータ ウェアハウス ソリューションが必ずしも最適なソリューションであるとは限らない場合があります。 2000 年代には、ビッグ データが一般的な用語になりました。 企業は、高速に生成される可能性がある大量で多様なデータの分析を可能にする新しいソリューションを採用しました。 これには、大量のデータを分析するデータ レイクやスケールアウト ソリューションのようなテクノロジが含まれます。
近年、多くの組織は、データ ウェアハウス テクノロジと最新のビッグ データ テクノロジを組み合わせた、最新のアーキテクチャおよび分析のパターンを使用することに成功しています。
ただし、一部の組織では、分析パターンを使用する分析ソリューションをデプロイするときに問題が発生します。 これらのソリューションは一般に、今でもモノリシック ソリューションとして実装されます。この場合、1 つのチームがプラットフォーム プロバイダーであり、データ統合を行うチームでもあります。 より小規模な組織や、チーム構成の観点で高度に集中化されている組織は、単一のチームを使用できます。 しかし、より大規模な組織では、単一チームのみを使用すると、多くの場合ボトルネックが生じます。 このボトルネックによって巨大なバックログが発生し、組織の一部が、データ統合サービスや分析ソリューションを待機する事態をもたらします。
このパターンは、組織が最新のデータ サイエンス ソリューションを採用するにつれて、ますます一般的になっています。 多くの最新のデータ サイエンス ソリューションでは、従来のビジネス インテリジェンス ソリューションがかつて必要としたよりも多くのデータが必要です。
近年、マイクロサービスをアプリケーション開発パターンとして使用するようになりましたが、それによってデータ ソースの数が増加するため、データ統合に関するバックログ増大のもう 1 つの要因になっています。
大きな組織で、単一チームが単一プラットフォームですべてのデータ インジェストを処理することも、問題になる可能性があります。 1 つのチームにあらゆるデータ ソースの専門家がいることはまれです。 ほとんどの組織は、ビジネスの観点から見ると、一元化されておらず分散されています。 事業単位や部署が異なると、業務の異なる部分を扱うため、データの専門家は通常、さまざまな部門にわたって散在しています。
これらの問題を解決するために、データ メッシュと呼ばれるパターンが導入されました。 データ メッシュの目標は、分散配置されているチームが、一元化されていない機敏な方法で情報の操作と共有を実施できるようにすることです。
データ メッシュは、組織面の変更も必要になる技術的なパターンです。 データ メッシュ アプローチの利点は、データ製品を公開して使用する、さまざまな分野にわたるチームを構築することによって実現されます。
データ メッシュ アーキテクチャを理解するうえで、基盤となる概念は以下のとおりです。
- データ ドメイン
- データ製品
- セルフサービス プラットフォーム
- フェデレーション ガバナンス
データ ドメイン
データ ドメインはデータ メッシュの基盤です。 データ ドメインの概念は、複雑なソフトウェア ソリューションをモデル化するためにソフトウェア開発でよく使用されるパラダイムであるドメイン駆動開発 (DDD) に由来します。 データ メッシュにおいて、データ ドメインはエンタープライズ データの周辺に境界を定義するための方法です。 ドメインは組織によって変わる可能性があり、場合によっては組織の周囲にドメインを定義できます。 その他の場合には、ビジネス プロセスやソースのシステムに基づいてデータ ドメインをモデル化することを選択できます。
データ ドメインには以下の 3 つの側面があります。
境界を選択することは、境界を長期的な所有権に委ねることになります。 これらは長期間にわたって存在しており、所有者を識別してきています。
ドメインは、理論上の概念だけでなく、現実と合致している必要があります。
ドメインにはアトミック整合性が備わっている必要があります。 領域間にお互いの関係がない場合は、それらをドメイン内で一緒に組み合わせないでください。
データ ドメインと、それらをどのように定義する必要があるかの詳細については、「データ ドメイン」を参照してください。
データ製品
データ製品は、データ メッシュのもう 1 つの重要なコンポーネントです。 データ製品の目的は、データの世界に製品の考え方を取り入れることです。 データ製品の導入を成功させるには、意図したユーザーに長期的なビジネス価値を提供する必要があります。 データ メッシュでは、1 つのデータ製品には、データ、コード資産、メタデータ、および関連するポリシーが含まれます。 データ製品は、API、レポート、テーブル、またはデータ レイク内のデータセットとして提供できます。
成功を収めるにはデータ製品が以下のようなものである必要があります。
- 使用できる: データ ドメインの直近に製品のユーザーが存在する必要があります。
- 価値がある: 製品に、時間が経過しても維持される価値がある必要があります。 長期的な価値がない場合には成功しません。
- 実現可能である: 製品は実現可能な必要があります。 実際に構築できない場合、製品は成功しません。 製品は、データ可用性と技術的観点の両方から、実現可能である必要があります。
データ製品のコード資産には、それを生成するコードと、それを提供するコードが含まれます。 コード資産には、製品と、製品の最終レポートの作成に使用されるパイプラインが含まれます。
データ製品に関する詳細については、「Azure でのクラウド規模の分析データ製品」を参照してください。
データ メッシュの使用に関する具体的なガイダンスについては、「データ製品とは」を参照してください。
セルフサービス プラットフォーム
データ メッシュの中核となっているのは、データ ドメインが独自にデータ製品を構築できるプラットフォームを備えていることです。 データ ドメインは、中央プラットフォームや中央プラットフォーム チームに強く依存することなく、ユーザーにとって適切なツールとプロセスを使用してデータ製品を定義する必要があります。 データ メッシュ内には、自律的な製品の開発と管理を行う自律的なチームがあります。
分散化を進め、データについて理解しているビジネス ユーザーと緊密に協力する一方で、ゼネラリストも自社のプラットフォーム上で作業することを念頭においてください。 ゼネラリストが存在するため、運用に専門的な知識を必要とする特殊なツールを、メッシュ ベースのプラットフォームの中核的基盤にすることはできません。
「セルフサービス データ プラットフォームの設計に関する考慮事項」で概要が説明されている実施方法を採用することで、セルフサービス プラットフォームを正しく実装できます。
フェデレーション ガバナンス
セルフサービス分散データ プラットフォームを採用するときには、ガバナンスにいっそうの重点を置く必要があります。 ガバナンスの欠如は、データ ドメイン全体にわたるサイロ化やデータの重複につながります。 ドメインに所属するチーム内およびデータ所有者の中に、ガバナンスの必要性を理解している人が存在するように、ガバナンスのフェデレーションを行います。
フェデレーション ガバナンスを作成するには、プラットフォームとデータ ニーズの両方に関連する自動ポリシーを実装します。 テストと監視には、高度な自動化を利用します。 標準、ポリシー、データ製品、コードとしてのプラットフォームのデプロイを処理するため、コード優先の実装戦略を採用します。
フェデレーション ガバナンスの側面を実装することの詳細については、「データ ガバナンスの概要」を参照してください。
まとめ
データ メッシュは、エンタープライズ データ プラットフォームを実装するうえで効果的な方法ですが、すべての組織にとって最適なソリューションではありません。 データ メッシュを導入するには、独立して作業することができる自律的なチームが必要です。 データ メッシュは、独立した事業単位があり、単一のプラットフォームと実装チームを超えて分析の導入をスケーリングする必要がある、大規模で複雑な組織で最適に機能します。
データ メッシュを使用する場合は、サイロを作成しないように、ガバナンスの実装時に特に注意を払ってください。 確実に成功を収めるには、実装の中心にデータに対する製品の考え方が常に備わっているようにします。