データメッシュとは何ですか?

データメッシュは、分散型かつ非中心の所有権を通じてデータセキュリティに関する高度な課題を解決するアーキテクチャフレームワークです。組織には、さまざまな事業部門が提供する複数のデータソースがあり、分析のために統合する必要があります。データメッシュアーキテクチャは、異なるデータソースを効果的に統合し、一元管理されたデータ共有とガバナンスガイドラインを通じてそれらをリンクします。ビジネス部門は、共有データへのアクセス方法、アクセスするユーザー、およびアクセスされる形式を管理できます。データメッシュはアーキテクチャを複雑にしますが、データアクセス、セキュリティ、およびスケーラビリティを改善することによって高い効率を実現するものでもあります。

データメッシュはどのような課題を解決しますか?

組織は増え続けるデータボリュームにアクセスできますが、実用的なメリットを引き出すには、データをソート、フィルタリング、処理、および分析する必要があります。組織は、多くの場合、データ管理のためにエンジニアと科学者で構成される中心的なチームを活用します。チームは、次の目的のために、一元化されたデータプラットフォームを使用します。

  • すべての異なるビジネスユニット (またはビジネスドメイン) からデータを取り込む。
  • データを一貫性のある信頼できる有用な形式に変換する。例えば、チームは、システム内のすべての日付が共通の形式であることを確認したり、日報を要約したりすることができます。
  • 人間の担当者向けにレポートを生成し、アプリケーション用に XML ファイルを準備し、または他の方法により、データコンシューマーのためにデータを準備します。XML について読む »

データ量が増加するにつれて、組織は、以前と同じ俊敏性を維持するためにより多額のコストを負担しなければならないという課題に直面しています。モノリシックシステムは、次の理由によりスケールが困難です。

サイロ化されたデータチーム

中心的なデータチームには、専門のデータサイエンティストとエンジニアがいますが、ビジネスやドメインに関する知識は限られています。しかし、動機を明確に理解することなく、さまざまな一連の運用および分析ニーズを満たすデータを提供する必要があります。

変化に対する反応の遅さ

データエンジニアは通常、データを取り込み、中心的なデータレイクに保存する前にいくつかのステップを実行してそのデータを変換するパイプラインを実装します。リクエストされた変更は、パイプライン全体の変更を必要とします。中心的なチームは、競合する優先順位を管理しながら、ビジネスドメインに関する限られた知識をもって、これらの変更を行う必要があります。  

低い精度

ビジネスユニットは、データコンシューマーや中心的なデータチームから切り離されています。そのため、有意義かつ正確で、有用なデータを提供するインセンティブが欠けています。

データメッシュにはどのようなメリットがありますか?

時間の経過に伴って、データプラットフォームアーキテクチャにより、データコンシューマーに不満がたまり、データプロデューサーは切り離され、高すぎる負荷がデータ管理チームにかかっている状況が生じる可能性があります。データメッシュアーキテクチャは、ビジネスユニットがデータドメインに対する高度な自治権と所有権を持てるようにすることで、これらの課題の解決を試みます。データメッシュアーキテクチャのメリットを以下に示します。

民主的なデータ処理

データメッシュは、分散型ガバナンスフレームワーク内で有意義なデータプロダクトを作成するドメインエキスパートにデータコントロールを移管します。また、データコンシューマーは、データプロダクトへのアクセスをリクエストし、データ所有者から直接承認または変更を求めます。その結果、誰もが関連データに迅速にアクセスできるようになり、アクセスが迅速になることでビジネスの俊敏性が向上します。

向上した柔軟性

一元化されたデータインフラストラクチャはより複雑であり、維持および変更するには共同作業が必要です。代わりに、データメッシュは、中心的なシステムの技術的な実装を、ビジネスドメインに合わせて再編成します。これにより、中心的なデータパイプラインがなくなり、運用上のボトルネックやシステムの技術的な負担が軽減されます。

コスト効率

分散データアーキテクチャでは、バッチ処理と距離を置く代わりに、リアルタイムデータストリーミングの採用を促進します。リソース割り当てとストレージコストの可視性が向上するため、予算編成が改善され、コストが削減されます。

改善されたデータ検出

データメッシュモデルは、中心的なエンジニアリングチームの周囲にデータサイロが形成されるのを防ぎます。また、異なるビジネスドメインシステム内でデータアセットがロックされるリスクも軽減されます。代わりに、中心的なデータ管理フレームワークが、組織内で利用可能なデータを管理および記録します。例えば、ドメインチームは、データを中心的なレジストリに自動的に登録します。

強化されたセキュリティとコンプライアンス

データメッシュアーキテクチャは、ドメイン内およびドメイン間の両方でデータセキュリティポリシーを強制します。これらは、データ共有プロセスの一元的なモニタリングと監査を可能にします。例えば、すべてのドメインでログおよびトレースデータの要件を満たすことを強制できます。監査担当者は、データアクセスの使用状況と頻度を監視できます。

データメッシュにはどのようなユースケースがありますか?

データメッシュは、ビッグデータに関するあらゆる種類のユースケースをサポートできます。いくつかの例を以下に示します。

データ分析

複数のビジネス部門が、データ分析ワークロードのために、信頼性と質の高いデータをプロビジョニングします。チームはデータを使用して、プロジェクトのパフォーマンス、マーケティングの結果、運用データを示すカスタマイズされたビジネスインテリジェンスダッシュボードを作成できます。データサイエンティストは、機械学習プロジェクトを加速して、オートメーションの恩恵を最大限に引き出すことができます。

カスタマーケア

データメッシュは、サポートチームとマーケティングチーム向けに顧客の包括的なビューを提供します。例えば、サポートチームは関連データをプルして平均処理時間を短縮でき、マーケティングチームはキャンペーンで、適切な顧客層を確実にターゲットにすることができます。

規制に関する報告

規制上の目的に適うデータの量、適時性、および正確性に対するニーズは、規制当局と規制対象企業の両方に課題を投げかけています。すべての関係者が、データメッシュテクノロジーのアプリケーションから恩恵を享受できます。例えば、組織は、規制当局が一元的に管理するデータメッシュに報告データをプッシュできます。

サードパーティーのデータ

サードパーティーおよびパブリックデータセットを必要とするユースケースでデータメッシュテクノロジーを適用できます。外部データを別のドメインとして扱い、それをメッシュに実装して、内部データセットとの一貫性を確保できます。

データメッシュアーキテクチャの原則にはどのようなものがありますか?

組織は、データメッシュパラダイムを採用するために、次の 4 つの原則を実装する必要があります。

分散ドメイン駆動型アーキテクチャ

データメッシュアプローチは、データ管理の責任がビジネス部門またはドメインを中心として編成されることを提案します。ドメインチームは、ビジネス機能に関連する、またはビジネス部門によって作成されたデータの収集、変換、および提供に責任を負います。ドメインデータがデータソースから中心的なデータプラットフォームに流れる代わりに、特定のチームが簡単に利用できる方法でデータセットをホストおよび提供します。例えば、小売業者は、衣料品に関するデータを含む衣料品ドメインと、サイト訪問者の行動分析を含むウェブサイト行動ドメインを持つことができます。

製品としてのデータ

データメッシュの実装を成功させるには、すべてのドメインチームは、自らが提供するデータセットに製品の考え方を適用する必要があります。データアセットを製品とみなし、組織の他のビジネスチームやデータチームを顧客とみなす必要があります。

最高のユーザーエクスペリエンスを実現するには、ドメインデータプロダクトは次の基本的な質を備えている必要があります。

発見可能であること

各データプロダクトは、簡単に発見できるように、一元化されたデータカタログに登録されます。

アドレス可能であること

すべてのデータプロダクトは、データコンシューマーによるプログラムを使用したアクセスを容易にする一意のアドレスを備えるべきです。アドレスは通常、組織内で一元的に決定された命名基準に従います。

信頼できること

データプロダクトは、文書化するイベントの現実をデータがどの程度正確に反映しているかについて、許容可能なサービスレベルの目標を定義します。例えば、注文ドメインは、顧客の住所と電話番号を検証した後にデータを発行できます。

自己記述的

すべてのデータプロダクトは、組織によって決定された標準の命名規則に従う、適切に記述された構文とセマンティクスを備えています。

セルフサービスのデータインフラストラクチャ

分散データアーキテクチャでは、すべてのドメインが独自のデータパイプラインを設定して、独自のデータプロダクトをクリーンアップ、フィルタリング、およびロードする必要があります。データメッシュは、セルフサービスデータプラットフォームの概念を導入して、作業の重複を回避します。データエンジニアは、すべてのビジネスユニットが自らのデータプロダクトを処理および保存できるようにテクノロジーを設定します。このように、セルフサービスインフラストラクチャは責任の分割を可能にします。データエンジニアリングチームはテクノロジーを管理し、ビジネスチームはデータを管理します。

フェデレーションデータガバナンス

データメッシュアーキテクチャは、組織内の共有責任としてセキュリティを実装します。リーダーシップは、ドメイン全体に適用できるグローバルな基準とポリシーを決定します。同時に、分散型データアーキテクチャにより、ドメイン内での標準とポリシーの実装に関する高度な自治が可能になります。

組織内でデータメッシュを構築するにはどうすればよいでしょうか?

データメッシュは、パンデミック後に勢いを増した新しい概念です。組織は、特定のユースケース用のデータメッシュを構築する試みにおいて、さまざまなテクノロジーを試しています。ただし、エンタープライズデータメッシュを組織全体で採用することは、まだ一般的ではありません。データメッシュの実装に至るための明確な道筋はありませんが、いくつかの提案があります。

既存のデータを分析する

データメッシュを構築する前に、既存のデータをカタログ化し、関連するビジネスドメインを特定する必要があります。特定の調和ルールに従うことが、ドメイン間でデータを効果的に相関させるための鍵となります。例えば、フィールドタイプのフォーマット設定、メタデータフィールド、およびデータプロダクトのアドレス規則のグローバル標準を定義する必要があります。

グローバルデータガバナンスポリシーを実装する

フェデレーテッドデータガバナンスでは、中心的な IT チームが、データメッシュに関するレポート、認証、およびコンプライアンスの基準を特定する必要があります。また、データプロダクトの所有者がデータセットをホストするときに適用する詳細なアクセスコントロールを定義することもできます。データプロデューサーはデータ品質を定義および測定しますが、中心的なガバナンスポリシーはデータプロデューサーが決定する際のガイドとして役立ちます。

セルフサービスデータプラットフォームを構築する

セルフサービスデータプラットフォームは、誰でも新しいドメインデータプロダクトを構築できるように、汎用的である必要があります。また、基盤となる技術的な複雑さが表出しないようにし、インフラストラクチャコンポーネントをセルフサービスで提供する必要があります。含めるべき機能を以下にいくつか示します。

  • データの暗号化
  • データプロダクトスキーマ
  • ガバナンスとアクセスコントロール
  • データプロダクトの発見 (カタログ登録や公開など)
  • データプロダクトのログ記録とモニタリング
  • パフォーマンスの改善を目的としたキャッシング

設定やスクリプトなどのオートメーションを構築して、データプロダクトを作成するためのリードタイムを短縮することもできます。

適切なテクノロジーを選択する

データウェアハウスやデータレイクなど、従来から存在するストレージシステムも、データメッシュを強化できます。必要なのは、それらの使用をモノリシックシステムから複数の分散型データリポジトリに移行することだけです。データメッシュは、クラウドプラットフォームとクラウド中心のテクノロジーの採用も可能にします。クラウドインフラストラクチャは、データメッシュの構築に必要な運用コストと労力を削減します。データメッシュアーキテクチャをサポートするには、豊富な機能を備えたデータ管理サービスを提供するクラウドプロバイダーを選択する必要があります。また、レガシーシステムとのデータ統合要件も考慮する必要があります。

組織全体の文化の変容を開始する

今日では、複数のデータプロダクトを使用してデータメッシュを簡単に構築するために必要なテクノロジーとツールが存在しています。バッチとストリーミングの統合への移行は、Amazon EMR などのツールを使用することで、これまで以上に簡単になりました。ただし、小規模なプロジェクトを超えてデータメッシュをスケーリングするには、これまでの一元的なデータアーキテクチャからのパラダイムシフトが必要です。次の点を強調して伝える必要があります。

  • 抽出とロードを介したデータの検出と使用
  • 後日の大量のバッチ処理を介したリアルタイムのデータ処理
  • 中心的なデータプラットフォームアーキテクチャを介した分散型データプロダクトの所有権

現在、データテクノロジーは多くの場合、アーキテクチャの決定を左右します。データメッシュはこの流れを逆転させ、代わりにドメインデータプロダクトを中心に据えて、テクノロジーの決定を推進します。

データメッシュとデータレイクはどのように異なりますか?

データレイクは、その規模を問わず、すべての構造化データと非構造化データを前処理なしで保存できるリポジトリです。一元的なデータプラットフォームにおいては、データレイクは、考えられるすべてのソースからのデータを格納するためのコアテクノロジーです。

データメッシュは、データレイクを異なる方法で使用するデータ管理パラダイムです。データレイクは、もはやアーキテクチャ全体の中心ではありません。代わりに、データプロダクトを実装するために使用したり、セルフサービスインフラストラクチャの一部として使用したりできます。

データレイクについて読む »

データメッシュとデータファブリックはどのように異なりますか?

データファブリックはもう 1 つの最新のアーキテクチャであり、機械学習とオートメーションを使用してさまざまなクラウド環境とデータパイプラインをエンドツーエンドで統合します。これは、テクノロジーに詳しくないユーザーに対して、統一感をもってデータを統合して提示する、基盤となるインフラストラクチャ上のテクノロジーレイヤーと考えることができます。例えば、意思決定者はデータファブリックを使用してすべてのデータを 1 か所で表示し、異なるデータセットを関連付けます。

データファブリックとデータメッシュには、統合された効果的なデータ管理という同様の目標があります。例えば、中心的なデータレイクがあり、データインジェストのために AWS のサービスを使用しているとします。同時に、データ変換のためにレガシーインフラストラクチャを有しています。データファブリックは両方のシステムを統合し、既存のパイプラインを変更することなく統一されたビューを提供します。

したがって、データファブリックはテクノロジーを使用して既存のインフラストラクチャと連携します。一方、データメッシュの実装では、基盤となるインフラストラクチャ自体を変更する必要があります。ビジネスドメイン全体で、データ管理の「push-and-ingest」(プッシュアンドインジェスト) モデルを「serve-and-pull」(サーブアンドプル) モデルに変更する必要があります。

AWS はデータメッシュアーキテクチャをどのようにサポートできますか?

AWS でのモダンデータアーキテクチャ」には、組織内でデータメッシュや他の最新のデータアーキテクチャを実装するために使用できるいくつかのサービスが一覧表示されています。パフォーマンスを犠牲にすることなく、データプロダクトとデータメッシュインフラストラクチャを低コストで迅速に構築できます。

使用できる AWS のサービスの例を次に示します。

今すぐ無料アカウントを作成して、AWS でのデータメッシュの使用を開始しましょう。

データメッシュの次のステップ

追加の製品関連リソースを見る
アナリティクスサービスを確認 
無料のアカウントにサインアップする

AWS 無料利用枠にすぐにアクセスできます。

サインアップ 
コンソールで構築を開始する

AWS マネジメントコンソールで構築を始めましょう。

サインイン