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