データ メッシュの金融機関シナリオ
このシナリオは、スケーラビリティと データ メッシュ アーキテクチャにクラウド規模の分析を使用したいお客様向けです。 ランディング ゾーン、データ統合、データ製品を含む複雑なシナリオを示します。
顧客プロファイル
架空の企業であるウッドグローブ銀行は、世界的なフットプリントを持つ大規模な金融サービス会社です。 Woodgrove Bank のデータは、オンプレミスとクラウドのデプロイ システムに格納されます。 Woodgrove Bank のアーキテクチャ内には、統合マーケティングと統合レポートのためのデータ ウェアハウス システムがいくつかあります。 このアーキテクチャには、計画外の分析とデータ検出のための複数のデータ レイクが含まれています。 Woodgrove Bank アプリケーションは、主に API ベースまたはイベント ベースのアプリケーション統合パターンを介して相互接続されます。
現在の状況
Woodgrove Bank では、データ ウェアハウスが複雑であるため、さまざまな場所にデータを分散することは困難です。 新しいデータの統合には時間がかかり、データを複製する必要があります。 Woodgrove Bank では、ポイントツーポイント接続のため、エンド ツー エンドのデータランドスケープを監視することは困難です。 銀行は、集中的なデータ消費の需要を過小評価しました。 新しいユース ケースが次々と導入されます。 データの所有権や品質、コストなどのデータ ガバナンスは制御が困難です。 Woodgrove Bank はデータがどこに存在するかを正確に把握していないため、規制を最新の状態に保つことは困難です。
アーキテクチャ ソリューション: データ メッシュ
過去数年間、組織はデータがあらゆるものの中心にあることを認識しています。 データは、新しい効率を開き、イノベーションを促進し、新しいビジネスモデルのロックを解除し、顧客満足度を向上させます。 企業は、大規模なデータなどのデータドリブンメソッドを使用することが最優先事項です。
すべての組織メンバーがデータのより深い価値にアクセスできる段階に到達することは困難です。 従来の緊密に相互接続されたシステム、一元化されたモノリシック プラットフォーム、複雑なガバナンスは、データから価値を生み出す大きな障壁となる可能性があります。
データ メッシュについて
Zhamak Dehghani が造語するデータ メッシュの概念には、データ、テクノロジ、プロセス、および組織が含まれます。 概念的には、さまざまなドメインが独自のデータを使用するデータを管理するためのアクセス可能なアプローチです。 データ メッシュは、従来のデータの一元化という考えに挑戦します。 データ メッシュは、データを 1 つの巨大なリポジトリとして見るのではなく、独立したデータ製品の分解を考慮します。 この一元化された所有権からフェデレーション所有権への移行は、一般的にクラウドネイティブ テクノロジを使用して設計された最新のセルフサービス データ プラットフォームによってサポートされます。
データ メッシュの概念を構成要素に分割する場合は、次の点を考慮する必要があります。
- 製品としてのデータ: 各 (組織) ドメインは、そのデータをエンドツーエンドで運用します。 アカウンタビリティは、ドメイン内のデータ所有者にあります。 パイプラインは、ドメイン自体の最上位の懸念事項になります。
- フェデレーション コンピューティング データ ガバナンス: 各データ所有者が他のデータを信頼し、そのデータ製品を共有できるようにするには、エンタープライズ データ ガバナンス機関を確立する必要があります。 ガバナンス機関は、データの品質、データの所有権の一元的な可視性、データ アクセス管理、およびデータプライバシー ポリシーを実装します。
- Domain-Oriented データ所有権: 企業は、ドメイン指向設計の原則を適用して、メッシュ内の各データ ドメイン ノードを定義してモデル化することを理想的に行う必要があります。
- Self-Serve Data Platform: データ メッシュには、ユーザーが技術的な複雑さを取り除き、個々のデータユース ケースに集中できるセルフサービス データ プラットフォームが必要です。
Cloud-Scale Analytics
製品としてのデータの考え方とセルフサービス プラットフォーム モデルは、Microsoft では初めてではありません。 Microsoft では、分散プラットフォーム、ドメイン間のパイプライン、フェデレーション所有権、および説明データのベスト プラクティスを長年にわたって観察しました。
Woodgrove Bank は、クラウド規模の分析を使用してデータ メッシュに移行できます。 クラウド規模の分析は、最新のデータ プラットフォームを設計して迅速にデプロイするためのオープンソースで規範的なブループリントです。 これは Azure のベスト プラクティスと設計原則と組み合わせられ、Azure Well-Architected Framework に準拠しています。 クラウド規模の分析により、企業は 80% の所定の視点を得られ、残りの 20% はカスタマイズ可能です。
クラウド規模の分析は、企業にデータ メッシュに対する戦略的な設計パスを提供し、そのようなアーキテクチャを迅速に設定するために使用できます。 データ管理用のコア データ プラットフォーム サービスを含むブループリントを提供します。
最も高いレベルでは、クラウド規模の分析ではデータ管理機能が使用されます。データ管理機能は、データ管理ランディング ゾーンを通じて有効になります。 このゾーンは、(セルフサービス) プラットフォームの組織のフェデレーション データ ガバナンスと、データ製品を通じてビジネス価値を促進するデータ ドメインを担当します。 このアプローチの利点は、同じ標準に準拠しながら技術的な複雑さを取り除くということです。 これにより、テクノロジが急増しないようにします。 また、企業は小さなフットプリントでモジュール式を開始し、時間の経過と共に成長することもできます。
次の図に示すように、データ管理ランディング ゾーンは、すべてのデータ ドメインを囲みます。 すべてのドメインを接着し、Woodgrove Bank が探している監視を提供します。
クラウド規模の分析では、データ製品の配布時に共通のアーキテクチャを使用する一貫性のあるガバナンスの適用も推奨されます。 フレームワークにより、ドメイン間の直接通信が可能になります。 データを保護し、グループがデータを検出できるように中央のカタログ化と分類に重点を置くことで、制御が維持されます。 データ資産の上に Umbrella が付きます。
データ ドメイン
クラウド規模の分析を戦略的なパスとして使用する場合は、アーキテクチャの分解と、その結果の細分性を考慮する必要があります。 データ メッシュは、テクノロジの境界に従わないでデータを分解します。 代わりに、ドメイン駆動設計 (DDD) の原則を適用します。これは、大規模な組織向けの複雑なシステムを含むソフトウェア開発のアプローチです。 DDD は、マイクロサービスなどの最新のソフトウェアおよびアプリケーション開発プラクティスに影響を与えるため、一般的です。
ドメイン駆動型設計のパターンの 1 つは、境界付きコンテキストと呼ばれます。 境界付きコンテキストは、複雑さを管理しやすくするために、ドメインのソリューション空間の論理境界を設定します。 チームは、データを含め、変更できる側面と、他のユーザーとの調整を必要とする共有依存関係を理解することが重要です。 データ メッシュは、境界付きコンテキストを受け入れます。 このパターンを使用して、組織がデータ ドメインを中心に調整し、製品としてのデータの配信に重点を置く方法を説明します。 各データ ドメインは、独自のテクノロジ スタックを使用して複数のデータ製品を所有し、運用します。これは他のデータとは独立しています。
データ製品
このようなデータ ドメインの内部アーキテクチャを拡大すると、その中にデータ製品が見つかると予想されます。
データ製品は、データを使用する企業内の特定のニーズを満たします。 データ製品は、ドメイン間でデータを管理、整理、理解し、得られた分析情報を提示します。 データ製品は、1 つまたは複数のデータ統合または他のデータ製品からのデータから得られます。 データ製品はデータ ドメインと密接に連携し、利害関係者やデザイナーが同意した同じ構築された正式な言語を継承します。 データを生成する各ドメインは、これらのデータ製品を他のドメインで使用できるようにする役割を担います。
データ製品の迅速な提供に役立つクラウド規模の分析では、データ分散と統合パターン用のテンプレートが提供されます。 このフレームワークは、多様なコンシューマーのニーズに対応するためのデータ バッチ、ストリーミング、分析を提供します。
クラウド規模の分析の 1 つの優れた点は、ドメインとデータ製品の編成方法です。 各データ ドメインは、1 つのデータ ランディング ゾーンと一致します。これは、論理コンストラクトであり、クラウドスケールの分析アーキテクチャにおけるスケールの単位です。 これにより、データの保持とデータ ワークロードの実行が可能になり、分析情報と価値が生成されます。 各データ製品は、データ ランディング ゾーン内の 1 つのリソース グループと一致し、すべてのデータ ランディング ゾーンと管理ゾーンがサブスクリプションと一致します。 このアプローチにより、実装と管理が容易になります。
すべてのクラウド規模の分析テンプレートは、データ管理ランディング ゾーンから同じポリシー セットを継承します。 テンプレートは、データの検出可能性、ガバナンス、セキュリティ、コスト管理、オペレーショナル エクセレンスに必要なメタデータを自動的に提供します。 複雑なオンボード、統合、テストを必要とせずに、新しいデータ ドメインをすばやくオンボードできます。
次の図は、データ製品の外観を示しています。
データ製品を構築するための実用的なアプローチは、ソース、データの発生元、または使用するユース ケースに合わせることです。 どちらの場合も、基になる (複雑な) アプリケーション データ モデルの抽象ビューを提供する必要があります。 技術的な詳細を非表示にし、集中的なデータ消費を最適化する必要があります。 論理的にデータをグループ化する Azure Synapse ビューまたは Parquet ファイルは、さまざまなデータ ドメイン間でデータ製品を共有する方法の例です。
次に、データの検出可能性、実証、使用状況、系列に取り組む必要があります。 実証済みのアプローチは、Microsoft Purview などのデータ ガバナンス サービスを使用して、すべてのデータを登録することです。 クラウド規模の分析でのデータ統合は、メタデータの登録を同時に実行するデータ製品を構築できるため、ドットを完全に接続します。
データ ドメインと Microsoft Purview コレクションを調整することで、個々のドメインからすべてのデータの配信元、系列、データ品質の詳細、および消費情報を自動的にキャプチャします。 このアプローチでは、複数のデータ ドメインと製品を、各環境のすべてのメタデータを格納する一元化されたガバナンス ソリューションに接続できます。 利点は、すべてのメタデータを一元的に統合し、さまざまなコンシューマーが簡単にアクセスできるようにすることです。 このアーキテクチャを拡張して、新しいデータ製品を登録できます。
次の図は、クラウド規模の分析を使用するクロスドメイン データ メッシュ アーキテクチャを示しています。
ネットワーク設計では、最小限のコストを使用して単一障害点と帯域幅の制限を排除することで、データ製品をドメイン間で共有できます。 セキュリティを確保するために、Microsoft ゼロ トラスト セキュリティ モデルを使用できます。 クラウド規模の分析では、最小特権の
マネージド ID を使用して、最小限の特権アクセス モデルに従うことができます。 このモデルのアプリケーションとサービスには、データ製品へのアクセスが制限されています。 今後のデータ ポリシーを含む Azure ポリシーは、セルフサービスを有効にし、すべてのデータ製品内で大規模に準拠リソースを適用するために使用されます。 この設計により、一元化されたデータ ガバナンスと監査を通じて完全に制御しながら、データ アクセスを統一できます。
未来に向けて進化する
クラウド規模の分析は、データ メッシュを念頭に置いて設計されています。 クラウド規模の分析は、組織が多くのデータ ドメイン間でデータを共有できる実証済みのアプローチを提供します。 このフレームワークを使用すると、ドメインは選択を自律的に行うことができます。また、データ管理サービスを使用してドメインをリングフェンスすることでアーキテクチャを管理します。
データ メッシュを実装する場合は、ドメインを論理的にグループ化して整理します。 このアプローチにはエンタープライズ ビューが必要であり、組織にとって文化的な変化である可能性があります。 このシフトでは、データを製品として提供する責任を負うデータ ドメインと所有者の間でデータの所有権をフェデレーションする必要があります。 また、チームは、データ管理ランディング ゾーンによって提供される一元化された機能に準拠する必要があります。 この新しいアプローチでは、個々のチームが現在の義務を放棄する必要があり、これは抵抗を生み出す可能性があります。 一定の政治的選択を行い、集中型アプローチと分散型アプローチのバランスを取る必要がある場合があります。
個々のドメインのアーキテクチャにランディング ゾーンを追加することで、データ メッシュ アーキテクチャをスケーリングできます。 これらのランディング ゾーンでは、仮想ネットワーク ピアリングを使用して、データ管理ランディング ゾーンとその他のすべてのランディング ゾーンに接続します。 このパターンを使用すると、ゾーン間でデータ製品とリソースを共有できます。 別のゾーンに分割すると、Azure サブスクリプションとリソース全体にワークロードを分散できます。 この方法では、データ メッシュを有機的に実装できます。
詳細情報
Microsoft リソース:
データ メッシュの創設者 Zhamak Dehghani による記事: