クラウド規模の分析は設計によってモジュール化されており、プロジェクトが移行されているか、新しく開発され、Azure にデプロイされているかに関係なく、データと分析のワークロードをサポートする基本的なランディング ゾーンから始めることができます。 このアーキテクチャにより、組織はスケール ポイントに関係なく、必要に応じて小規模に開始し、ビジネス要件と共にスケーリングすることができます。
顧客プロファイル
この参照アーキテクチャは、分析ワークロードを Azure にデプロイする準備ができているビジネスの単位を特定したお客様に最適です。 このアーキテクチャでは、ビジネス ユニットがデータ資産を管理するために使用できる単一のランディング ゾーンをデプロイします。 Azure に移行する準備ができたら、他のビジネス ユニットにランディング ゾーンを追加する柔軟性が提供されます。
Adatum Corporation は、大規模で国際的な企業です。 本社の一元化された事業単位に加えて、会計、マーケティング、販売、サポート、運用など、独自の事業単位を持つ子会社を世界中に持っています。
これらの異なるグループはすべて、独自のデータを生成しています。 多くのビジネス ユニットには、分析チームが埋め込まれています。 中央の IT 組織は、使用中のほとんどのデータ プラットフォームを提供してきましたが、いくつかの部署が不正になり、独自のソリューションを実装しています。 データ プラットフォームは、さまざまなクラウド サービスとオンプレミス ソリューションで構成されています。
この会社のビジョンは、すべてのデータの信頼できる単一のソースである、集中型の分析プラットフォームを用意することです。 多様な利害関係者が一つの技術を受け入れることは困難になっています。 新しいデータが作成され、新しいオプションが利用可能になる速度を考えると、一元化の計画の早期草案もすぐに古くなります。 一方、企業の営業チームは現在のソリューションを上回っており、新しい分析を使用して新しい市場セグメントを追求する必要があります。
Adatum は、この問題を解決するために、Azure にクラウド規模の分析パターンを実装することにしました。 企業は、クラウド規模の分析により、企業の営業チームは現在データ プラットフォームを移行できると確信していますが、参加する準備ができたら、他のビジネス ユニットに対応できる十分な柔軟性を提供します。
現在の状況
Adatum 企業販売グループは、従来の ERP および CRM システムを使用して販売トランザクションを処理します。 これらのシステムのデータは、組織全体の利害関係者がデータにアクセスし、さまざまなプロジェクトのために強化できるように、別の分析プラットフォームにエクスポートする必要があります。
アーキテクチャ ソリューション
この参照アーキテクチャでは、すべての ESA 実装に必要なデータ管理ランディング ゾーンと、企業の販売部門が使用できる単一のデータランディング ゾーンをデプロイします。
データ管理ランディング・ゾーン
すべてのクラウド規模の分析の重要な概念は、1 つのデータ管理ランディング ゾーンを持つことです。 このサブスクリプションには、すべてのランディング ゾーンで共有されるリソースと、ファイアウォールやプライベート DNS ゾーンなどの共有ネットワーク コンポーネントが含まれます。 また、データとクラウド ガバナンスのためのリソースも含まれています。 Microsoft Purview と Databricks Unity カタログは、テナント レベルでサービスとしてデプロイされます。
データ アプリケーション
ランディング ゾーンには、2 つの データ アプリケーションがあります。 最初の統合では、顧客に関連するデータが取り込まれます。 この手順には、顧客レコードとその関連レコード (住所、連絡先、担当地域の割り当て、連絡先履歴など) が含まれます。 このデータは Adatum CRM システムからインポートされます。
2 番目のデータ アプリケーションは、販売トランザクションを取り込みます。 これには、トランザクション ヘッダー、品目の詳細、出荷レコード、支払が含まれます。 これらのレコードはすべて、Adatum ERP システムから取り込まれます。
これらの統合では、データの変換や強化は行われません。 ソース システムからデータをコピーし、分析プラットフォームに格納するだけです。 これにより、多くのデータ製品は、ソース システムに別の負担をかけずに、スケーラブルな方法でデータを使用できます。
データ製品
この例では、Adatum には 1 つのデータ製品があります。 この製品は、2 つのデータ アプリケーションの生データを結合し、新しいデータセットに変換します。 そこから、ビジネス ユーザーは、Microsoft Power BI などのツールを使用して追加の分析とレポートを行うことができます。
図 1: アーキテクチャの図。 この図では、すべての Azure サービスが表されているわけではありません。 アーキテクチャ内でのリソースの編成方法の主要な概念を強調するために簡略化されています。
根拠
販売トランザクションと顧客を独自のデータ ランディング ゾーンに配置しないのはなぜですか?
企業がクラウド規模の分析に関して最初に行う必要がある決定の 1 つは、データ資産全体をランディング ゾーンに分割する方法です。 互いに頻繁に通信するデータ ソリューションは、同じランディング ゾーンに含める強力な候補です。 この決定により、企業はピアリングされた VNet 間でのデータの移動に関連するコストを削減できます。 この例では、売上トランザクション データが顧客データにリンクされることが多くなります。 そのため、これらの関連するデータ アプリケーションを同じデータ ランディング ゾーンに格納するのが理にかなっています。
ランディング ゾーンに関する追加の考慮事項は、データを担当するチームが組織内でどのように調整されるかです。 この場合、2 つのデータ アプリケーションは異なるチームによって所有されますが、それらのチームは両方とも Adatum の営業部門とマーケティング部門の一部です。
販売トランザクションと顧客が 1 つのデータ アプリケーションを共有してみませんか?
顧客データと販売トランザクション データを独自のデータ アプリケーションで分離することで、これらのドメインの分野の専門家が特定のデータ製品に最適な意思決定を行えるようにします。 ユーザーは、互いに競合することなく、ニーズに最も適したアクセス パターン、インジェスト エンジン、ストレージ オプションを選択できます。
たとえば、CRM システムに関する専門知識を持つチームは、顧客データ アプリケーションを担当します。 チームのスキル セットと CRM システムで使用されるテクノロジに基づいて、ニーズに最も適したツールを決定します。 これらの決定が販売トランザクション チームでも機能するかどうか心配する必要はありません。 そのチームは独自のツールセットを使用しており、顧客のチームの要件を満たすために妥協する必要はありません。
販売チームを新しいデータ プラットフォームに移行する理由
この例では、企業の営業チームが最初に新しいクラウド規模の分析に移行します。 ソリューションは、他の何よりもスケーラブルに設計されています。 他のビジネス ユニットを移行する準備ができたら、ワークロードに対応するためにさらにランディング ゾーンを追加できます。
どのように将来的に進化するには?
スケーリングは、アーキテクチャにランディング ゾーンを追加することで実現されます。 これらのランディング ゾーンでは、仮想ネットワーク ピアリングを使用して、データ管理ランディング ゾーンとその他のすべてのランディング ゾーンに接続します。 このメッシュ パターンにより、データ製品とリソースをゾーン間で共有できます。 異なるゾーンに分割することで、ワークロードは Azure サブスクリプションとリソースに分散されます。 この手順により、企業は Azure サービスの制限に達するのを回避し、データ資産の拡大を続けられます。
次のステップ
Azure でクラウド規模の分析を行う Relecloud シナリオに進みます。
詳細については、以下を参照してください。