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