Azure でクラウド規模の分析をスケーリングする

スケーラブルなデータ プラットフォームは、データの急速な増大に対応するために非常に重要です。 世界中で刻々と膨大な量のデータが生成されています。 使用可能なデータの量は、次の数年間で指数関数的に増加し続けることが予想されます。 データ生成の速度が増すにつれて、データ移動のスピードも増していきます。

データの量に関係なく、ユーザーは高速なクエリ応答を要求します。 結果を得るために待つ時間は時間単位ではなく分単位を期待しています。 この記事では、Azure のクラウド規模の分析ソリューションをスケーリングして、スピードに対するユーザーの要求を満し続ける方法について説明します。

はじめに

多くの企業は大規模なデータ プラットフォームのモノリスを抱えています。 これらのモノリスは、単一の Azure Data Lake Gen2 アカウントと、場合によっては単一のストレージ コンテナーを中心に構築されています。 1 つの Azure サブスクリプションが、すべてのデータ プラットフォーム関連のタスクに使用されている場合もよくあります。 サブスクリプション レベルのスケーリングは、ほとんどのアーキテクチャ プラットフォームに存在しないため、それによってユーザーが Azure サブスクリプションまたはサービス レベルの制限のいずれかに直面した場合に、Azure の継続的な導入が妨げられる可能性があります。 制約の一部はソフト制限ですが、それらの制限に達すると、データ プラットフォームに重大な悪影響を及ぼす可能性もあります。

データ プラットフォームを構築する場合は、組織の構造を考慮してください。 チームのデータの所有権と職務の責任に注意してください。 組織がチームに高度な自律性と分散所有権を与える場合は、データ メッシュ アーキテクチャが最適な選択肢です。

インジェスト、クレンジング、集計、サービス提供のタスクなど、ソリューションのさまざまなタスクを別々のチームが担当するという状況を避けます。 複数のチームに依存すると、速度が大幅に低下する可能性があります。 たとえば、サービス提供レイヤー上のデータ コンシューマーが新しいデータ資産をオンボードする必要がある場合や、特定のデータ資産に対して機能変更を実装する必要がある場合に、複数ステップのプロセスを進める必要があります。 この例では、ステップは次のようになります。

1. データ コンシューマーは、データ パイプライン ステージを担当するすべてのチームにチケットを送信します。
2. レイヤーは相互接続されているため、チームは同期して連携する必要があります。 新しいサービスによってデータ クレンジング レイヤーの変更が要求され、それがデータ集計レイヤーの変更につながり、それがサービス レイヤーの変更につながります。 変更は、すべてのパイプライン ステージに影響を与える可能性があります。
3. エンド ツー エンドのライフサイクル全体を見渡すことができないため、チームが変更の処理の可能性のある影響を確認することは困難です。 既存のコンシューマーとパイプラインへの影響を最小限に抑える明確に定義されたリリース計画を設計するために、連携する必要があります。 この依存関係管理により、管理オーバーヘッドが増加します。
4. 原則として、チームはデータ コンシューマーが要求するデータ資産に関する領域の専門家ではありません。 新しいデータセットの特徴やパラメーター値を理解するために、専門家に相談する必要があります。
5. すべての変更が実装されると、新しいデータ資産を使用する準備ができていることがデータ コンシューマーに通知されます。

大規模な各組織には、何千ものデータ コンシューマーがあります。 説明したような複雑なプロセスでは、一元化されたチームが部署のボトルネックになるため、大規模なアーキテクチャで速度が著しく低下します。 その結果、イノベーションが少なくなり、有効性が制限されます。 部署はサービスを離れて、代わりに独自のデータ プラットフォームを構築する決断を下す可能性があります。

スケーリングの方法

クラウド規模の分析では、2 つの主要な概念を使用して、スケーリングの課題に対処します。

• スケーリングにデータ ランディング ゾーンを使用する
• 分散型および非集中型のデータ所有権を可能にするために、スケーリングにデータ製品またはデータ統合を使用する

1 つのデータ ランディング ゾーンまたは複数のデータ ランディング ゾーンをデプロイできます。 データ ランディング ゾーンでは、データ管理ランディング ゾーンに接続することで、データを検出および管理できます。 各データ管理ランディング ゾーンは、1 つの Azure サブスクリプション内にあります。

サブスクリプションは、Azure の管理、課金、スケールの単位です。 それらは大規模な Azure 導入計画で重要な役割を果たします。

データ ランディング ゾーンを使用したスケーリング

クラウド規模の分析の中心的な概念は、データ管理ランディング ゾーンとデータ ランディング ゾーンです。 それぞれを独自の Azure サブスクリプションに配置する必要があります。 それらを分離することで、職務を明確に分離し、最小特権の原則に従い、前に説明したサブスクリプションのスケーリングの問題に部分的に対処します。 クラウド規模の分析の最小限のセットアップには、1 つのデータ ランディング ゾーンと 1 つのデータ管理ランディング ゾーンが含まれます。

ただし、大規模なデータ プラットフォーム デプロイでは、最小限のセットアップでは不十分です。 企業は大規模なプラットフォームを構築し、時間の経過と共にデータと分析の取り組みを一貫して効率的にスケーリングするための投資を行います。 サブスクリプション レベルの制限を克服するために、クラウド規模の分析では、Azure ランディング ゾーンで説明されているように、スケーリングの単位としてサブスクリプションが使用されます。 この手法により、データ ランディング ゾーンをアーキテクチャにさらに追加することで、データ プラットフォームのフットプリントを増やせます。 さらに、データ ランディング ゾーンには 3 つのデータ レイクのセットが含まれているため、この手法を採用することにより、組織全体で 1 つの Azure Data Lake Gen2 が使用されるという問題にも対処します。 複数のドメインからのプロジェクトとアクティビティを複数の Azure サブスクリプションに分散できるため、スケーラビリティが向上します。

クラウド規模の分析アーキテクチャを実装する前に、組織で必要とするデータ ランディング ゾーンの数を決定します。 適切な意思決定を行うことが、効果的かつ効率的なデータ プラットフォームの基礎となります。

必要なデータ ランディング ゾーンの数は、特に次のような多くの要因に依存します。

• 組織の連携 (独自のデータ ランディング ゾーンが必要な部署の数など)
• 運用上の考慮事項 (組織が運用リソースと部署固有のリソースを配置する方法など)

適切なデータ ランディング ゾーン モデルを使用することで、データ製品とデータ資産をランディング ゾーン間で移動する将来の作業が最小限になります。 また、将来のビッグ データと分析の取り組みを効果的かつ一貫してスケーリングすることにも役立ちます。

デプロイするデータ ランディング ゾーンの数を決定するときは、次の要素を考慮します。

データ メッシュ アーキテクチャを実装する場合は、データ ランディング ゾーンとデータ ドメインを分散する方法を決定する際に、次の要素を考慮します。

その他の考慮事項については、サブスクリプションのクラウド導入フレームワーク ガイダンスを参照してください。

多くの組織が、エンタープライズ データ プラットフォーム内の効率的なスケーリングを望んでいます。 部署は、固有の要件を満たすために、独自のデータ ソリューションとアプリケーションを構築できる必要があります。 多くの既存のデータ プラットフォームはスケーラビリティと分散型所有権の概念に関連して構築されていないため、この機能を提供することは困難な可能性があります。 この欠点は、これらのデータ プラットフォームのアーキテクチャ、チーム構造、および運用モデルにはっきりと見られます。

データ ランディング ゾーンでは、組織内にデータ サイロは作成されません。 クラウド規模の分析に推奨されるネットワーク セットアップにより、ランディング ゾーン間の安全でインプレースのデータ共有が可能になり、さらにデータ ドメインと部署間でのイノベーションが可能になります。 詳細については、ネットワーク アーキテクチャの考慮事項に関するページを参照してください。

ID レイヤーについても同じことが当てはまります。 単一の Microsoft Entra テナントを使用する場合、複数のデータ ランディング ゾーン内のデータ資産へのアクセス権を ID に付与できます。 ユーザーと ID 認可プロセスの詳細については、データ アクセス管理に関するページを参照してください。

クラウド規模の分析では、共通のアーキテクチャを使用して、一貫性のあるガバナンスが支持されます。 アーキテクチャでは、ベースラインの機能とポリシーを定義します。 すべてのデータ ランディング ゾーンは、同一の監査と管理に従います。 チームは、データ パイプラインの作成、ソースの取り込み、およびレポートやダッシュボードなどのデータ製品の作成を行うことができます。 さらにチームは、必要に応じて Spark/SQL 分析を行うこともできます。 ポリシーの機能にサービスを追加することで、データ ランディング ゾーンの機能を強化できます。 たとえば、チームはビジネスの要件に対応するために、サードパーティ製のグラフ エンジンを追加できます。

クラウド規模の分析では、データを保護し、さまざまなグループがデータ製品を検出できるようにするために、一元化されたカタログと分類が特に重視されます。

クラウド規模の分析アーキテクチャとデータ ランディング ゾーンの概念により、組織は時間の経過と共にデータ プラットフォームのサイズを簡単に増やすことができます。 段階的なアプローチで、データランディング ゾーンを追加できます。 顧客は最初に複数のランディング ゾーンを持つ必要はありません。 このアーキテクチャを導入する場合は、少数のデータ ランディング ゾーンと、それらに含めるデータ製品の優先順位を付けます。 適切な優先順位付けは、クラウド規模の分析デプロイを確実に成功させるのに役立ちます。

データ製品またはデータ統合によるスケーリング

各ランディング ゾーン内で、組織はデータ アプリケーションを使用してスケーリングできます。 データ アプリケーションは、読み取り最適化データ製品を他のデータ アプリケーションで使用できるようにするための機能をカプセル化する、データ アーキテクチャの単位またはコンポーネントです。 Azure では、データ アプリケーションはリソース グループの形式の環境であり、機能横断型チームがデータ ソリューションとワークロードを実装できるようにします。 関連付けられているチームは、インジェスト、クレンジング、集計、サービス提供タスクなど、データ ソリューションのエンド ツー エンドのライフサイクルに対応します。

クラウド規模の分析では、前に説明したデータ統合と責任の問題に対処します。 参照設計では、テーブル インジェストとソース システム統合のモノリシックな職能的責任ではなく、データ ドメインで駆動される分散アーキテクチャが提供されます。 機能横断型チームは、データ スコープのエンド ツー エンドの職能的責任と所有権を引き継ぎます。

データ処理ワークフローのすべてのタスクを担当する一元化された技術スタックとチームを持つ代わりに、複数の自律的な機能横断型データ統合チームにエンドツーエンドの責任を分散できます。 各チームはドメインまたはサブドメインの機能を所有しており、データ コンシューマーの要求に応じてデータセットを提供することが推奨されます。

これらのアーキテクチャの違いにより、データ プラットフォームの速度の増加につながります。 データ コンシューマーは、一連の一元化されたチームに依存したり、要求された変更の優先順位付けのために努力する必要がなくなります。 エンドツーエンドの統合ワークフローの所有権を引き継ぐチームが小さいほど、データ プロバイダーとデータ コンシューマーの間のフィードバック ループがはるかに短くなります。 このアプローチにより、優先順位付けの高速化、開発サイクルの高速化、開発プロセスの機敏性の向上が可能になります。 機能横断型データ統合チームはエンドツーエンドの技術的スタックと変更の影響を完全に認識しているため、チームはプロセスとリリース計画を同期する必要がなくなりました。 ソフトウェア エンジニアリング プラクティスを使用して単体テストと統合テストを実行し、コンシューマーへの全体的な影響を最小限に抑えることができます。

データ統合システムを所有するチームは、ソース システムも所有していることが理想的です。 このチームは、ソース システムに取り組むデータ エンジニア、データセットの領域の専門家 (SME)、クラウド エンジニア、およびデータ製品所有者で構成されている必要があります。 この種類の機能横断型チームを構築することは、外部チームとの必要なコミュニケーションの量を減らし、インフラストラクチャから実際のデータ パイプラインへの完全なスタックを開発する際に不可欠です。

データ プラットフォームの基盤は、ソース システムから統合されたデータセットです。 これらのデータセットにより、データ製品チームはビジネス ファクト テーブルにイノベーションを起こし、意思決定とビジネス プロセスを改善できます。 データ統合チームとデータ製品チームが、コンシューマーに SLA を提供し、すべての契約が満たされるようにする必要があります。 提供される SLA は、データ品質、タイムライン、エラー率、アップタイム、その他のタスクに関連する場合があります。

概要

クラウド規模の分析アーキテクチャのスケーリング メカニズムを使用することで、既知の技術的な制限を回避しながら、時間の経過と共に Azure 内でデータ資産を拡張します。 この記事で説明されている両方のスケーリング方法は、さまざまな技術的な複雑さを克服するのに役立ち、シンプルで効率的な方法で使用できます。

次の手順

• データの標準化