単一リージョンのデータ ランディング ゾーン接続

データ管理ランディング ゾーン、データ ランディング ゾーン、およびそれらの中のすべてのサービスは、単一リージョンのセットアップで同じリージョンにセットアップされます。 すべてのランディング ゾーンは、同じ接続ハブ サブスクリプション内にあります。 このサブスクリプションでは、ネットワーク仮想アプライアンス (Azure ファイアウォールなど)、ExpressRoute ゲートウェイ、仮想プライベート ネットワーク (VPN) ゲートウェイ、ハブ仮想ネットワーク、または仮想 WAN (vWAN ハブ) を含めることができる共有ネットワーク リソースがホストされます。

図 1: 単一リージョンの接続。

Azure ネットワーク サービスの現在の機能に基づいて、メッシュネットワーク アーキテクチャを使用することが推奨されます。 次の間に VNet ピアリングを設定する必要があります。

• 接続ハブとデータ管理ゾーン
• 接続ハブと各データ ランディング ゾーン
• データ管理ゾーンと各データ ランディング ゾーン
• 各データ ランディング ゾーン

この記事では、クラウド規模の分析のために検討した各ネットワーク アーキテクチャ オプションの長所と短所について説明します。

この記事の最初のセクションでは、データ管理ゾーンとすべてのデータ ランディング ゾーンが同じリージョンでホストされる単一リージョンのパターンについて説明します。

各設計パターンは、次の条件を使用して評価されます。

• [コスト]
• ユーザー アクセス管理
• サービス管理
• 帯域幅
• Latency

次のクロスデータ ランディング ゾーンのユース ケースを念頭に置いて、各設計オプションを分析します。

メッシュ ネットワーク アーキテクチャ (推奨)

クラウド規模の分析を導入する際は、ネットワーク メッシュ アーキテクチャを使用することが推奨されます。 テナント内に設定された既存のハブ アンド スポーク ネットワーク設計に加えて、ネットワーク メッシュ アーキテクチャを実装するためには 2 つの操作を行う必要があります。

• すべてのデータ ランディング ゾーン Vnet 間に Vnet ピアリングを追加します。
• データ管理ランディング ゾーンとすべてのデータ ランディング ゾーンの間に Vnet ペアリングを追加します。

このシナリオ例では、ストレージ アカウント A から読み込まれたデータは、2 つのデータ ランディング ゾーン Vnet 間に設定された Vnet ピアリング接続 (2) を通過します。 VM B ((3) および (4)) によって読み込まれて処理され、ローカルプライベート エンドポイント (5) を介して送信され、ストレージ アカウント B に格納されます。

このシナリオでは、データは接続ハブを通りません。 データ管理ランディング ゾーンと 1 つ以上のデータ ランディング ゾーンで構成されるデータ プラットフォーム内にとどまります。

図 2: メッシュ ネットワーク アーキテクチャ。

メッシュ ネットワーク アーキテクチャのユーザー アクセス管理

メッシュ ネットワーク アーキテクチャ設計では、データ アプリケーション チームが新しいサービス (プライベート エンドポイントを含む) を作成できるようになるために必要なものは 2 つだけです。

• データ ランディング ゾーン内の専用リソース グループへの書き込みアクセス
• 指定されたサブネットへの参加アクセス

この設計では、データ アプリケーション チームはプライベート エンドポイントを自分自身でデプロイできます。 プライベート エンドポイントを特定のスポークのサブネットに接続するために必要なアクセス権がある限り、チームは必要な接続を設定する際にサポートを必要としません。

概要:

メッシュ ネットワーク アーキテクチャのサービス管理

メッシュ ネットワーク アーキテクチャ設計では、単一障害点またはスロットリングとして機能するネットワーク仮想アプライアンスがありません。 接続ハブ経由で送信されるデータセットがないため、その仮想アプライアンスをスケールアウトする必要がなければ、中央の Azure プラットフォーム チームのオーバーヘッドが軽減されます。

これは、中央の Azure プラットフォーム チームが、データ ランディング ゾーン間で送信されるすべてのトラフィックを検査してログに記録できなくなることを示します。 ただし、クラウド規模の分析は、複数のサブスクリプションにまたがる一貫性のあるプラットフォームであり、スケーリングを可能にし、プラットフォームレベルの制限を克服するため、欠点にはなりません。

1 つのサブスクリプション内ですべてのリソースがホストされている場合、中央の Azure プラットフォーム チームは、中央接続ハブ内のすべてのデータも検査しなくなります。 それでもネットワーク セキュリティ グループ フロー ログを使用して、ネットワーク ログをキャプチャできます。 サービス固有の診断設定を使用して、他のアプリケーションおよびサービス レベルのログを統合して格納できます。

診断設定の Azure Policy 定義を使用して、これらのすべてのログを大規模にキャプチャできます。

さらにこの設計では、プライベート DNS ゾーンに基づいて Azure ネイティブ DNS ソリューションを作成することもできます。 プライベート DNS グループの Azure Policy 定義によって、DNS A レコードのライフサイクルを自動化できます。

概要:

メッシュ ネットワーク アーキテクチャのコスト

このネットワーク設計では、次に対してのみ課金されます。

• プライベート エンドポイント (1 時間あたり)
• プライベート エンドポイント経由で送信され、生データセットを読み込み (1)、処理済みのデータセットを格納する (6) イングレスおよびエグレス トラフィック

Vnet ピアリングは課金されません (2)。このため、このオプションは最小コストになります。

概要:

メッシュ ネットワーク アーキテクチャの帯域幅と待機時間

この設計には、データ ランディング ゾーン間のデータ交換のスループットを制限するネットワーク仮想アプライアンスがないため、既知の帯域幅や待機時間の制限がありません。 この設計の唯一の制限要因は、データセンターの物理的な制限 (光ファイバー ケーブルの速度) です。

概要:

メッシュ ネットワーク アーキテクチャの概要

クラウド規模の分析を導入する予定がある場合は、メッシュ ネットワーク設計を使用することが推奨されます。 メッシュ ネットワークでは、最小のコストで最大の帯域幅と短い待機時間が得られますが、ユーザーアクセス管理や DNS レイヤーに関して妥協はありません。

データ プラットフォーム内で他のネットワーク ポリシーを適用する必要がある場合は、中央ネットワーク仮想アプライアンスではなくネットワーク セキュリティ グループを使用します。

従来のハブ アンド スポークのアーキテクチャ (推奨されません)

ハブ アンド スポーク ネットワーク アーキテクチャ設計は最も明白なオプションであり、多くの企業が採用しているものです。 その中では、VM B から ストレージ アカウント A のデータにアクセスするために、ネットワーク推移性が接続ハブに設定されます。データは、2 つの Vnet ピアリング ((2) と (5)) と、接続ハブ内でホストされているネットワーク仮想アプライアンス ((3) と (4)) を横断します。 次に、データが仮想マシンによって読み込まれ (6)、ストレージ アカウント B に格納されます (8)。

図 3: ハブ アンド スポークのアーキテクチャ。

従来のハブ アンド スポーク アーキテクチャのユーザー アクセス管理

従来のハブ アンド スポーク設計では、データ アプリケーション チームが新しいサービス (プライベート エンドポイントを含む) を作成できるようにするために必要なものは 2 つだけです。

• データ ランディング ゾーン内のリソース グループへの書き込みアクセス
• 指定されたサブネットへの参加アクセス

この設計では、データ アプリケーション チームはプライベート エンドポイントを自分自身でデプロイできます。 プライベート エンドポイントを特定のスポークのサブネットに接続するために必要なアクセス権がある限り、チームは必要な接続を設定する際にサポートを必要としません。

概要:

従来のハブ アンド スポーク アーキテクチャのサービス管理

このネットワーク設計は、よく知られており、ほとんどの組織の既存のネットワーク セットアップと一貫性があります。 これにより、設計の解釈と実装が簡単になります。 さらに、プライベート DNS ゾーンを備えた一元化された Azure ネイティブ DNS ソリューションを使用して、Azure テナント内で FQDN 解決を提供することもできます。 プライベート DNS ゾーンを使用すると、Azure ポリシーを使用して DNS A レコードのライフサイクルを自動化することもできます。

この設計のもう 1 つの利点は、トラフィックが中央ネットワーク仮想アプライアンス経由でルーティングされるので、あるスポークから別のスポークに送信されるネットワーク トラフィックをログに記録して検査できます。

この設計の欠点の 1 つは、中央の Azure プラットフォーム チームがルート テーブルを手動で管理する必要があることです。 これは、複数のデータ ランディング ゾーン間でデータ資産の共有を可能にするスポーク間の推移性を確保するために必要です。 ルート管理は時間の経過と共に複雑でエラーが発生しやすくなる可能性があるため、事前に検討する必要があります。

このネットワーク セットアップのもう 1 つの欠点は、中央ネットワーク仮想アプライアンスの設定方法です。 ネットワーク仮想アプライアンスは単一障害点として機能し、障害が発生した場合にデータ プラットフォーム内で重大なダウンタイムが発生する可能性があります。 さらに、データ プラットフォーム内でデータセットのサイズが大きくなり、クロスデータ ランディング ゾーンのユースケースの数が増えるにつれて、中央ネットワーク仮想アプライアンス経由で送信されるトラフィックが増えます。

時間がたつと、これにより数ギガバイトどころか数テラバイトものデータが中央インスタンス経由で送信されるようになる可能性があります。 既存のネットワーク仮想アプライアンスの帯域幅は、多くの場合に 1 桁または 2 桁ギガバイトのスループットだけに制限されるため、中央ネットワーク仮想アプライアンスは、データ ランディング ゾーン間のトラフィック フローが極端に制限され、データ資産の共有可能性が制限されるボトルネックになる可能性があります。

この問題を回避する唯一の方法は、複数のインスタンスにまたがって中央ネットワーク仮想アプライアンスをスケールアウトすることです。この設計には大きなコストの影響があります。

Summary:

従来のハブ アンド スポーク アーキテクチャのコスト

このネットワークでは、ストレージ アカウントのプライベート エンドポイントに対し時間単位で課金されます。 プライベート エンドポイント経由で送信され、生データセットを読み込み (1)、処理済みのデータセットを格納する (8) イングレスおよびエグレス トラフィックに対しても課金されます。

お客様には、1 つの VNet ピアリング (5) のイングレスとエグレスに対して課金されます。 前述のように、最初の Vnet ピアリングは課金されません (2)。

このネットワーク設計 ((3) と (4)) を使用すると、中央ネットワーク仮想アプライアンスのコストが高くなります。 追加のライセンスを購入し、要求に基づいて中央ネットワーク仮想アプライアンスをスケールアウトするか、Azure Firewall で行われるようにギガバイト単位で処理された料金を支払う必要があります。

概要:

従来のハブ アンド スポーク アーキテクチャの帯域幅と待機時間

このネットワーク設計には、重大な帯域幅の制限があります。 プラットフォームの拡大に伴って中央ネットワーク仮想アプライアンスが重大なボトルネックになり、クロスデータ ランディング ゾーンのユース ケースとデータセット共有が制限されます。 また、時間が経過するにつれてデータセットの複数のコピーが作成される可能性もあります。

この設計は待機時間にも大きく影響し、リアルタイム分析シナリオで特に重要になります。

概要:

従来のハブ アンド スポーク アーキテクチャの概要

このハブ アンドスポーク ネットワーク設計にはアクセス管理といくらかのサービス管理の利点がありますが、サービス管理と帯域幅と待機時間の重大な制限により、このネットワーク設計はクロスデータ ランディング ゾーンのユース ケースには推奨できません。

プライベート エンドポイント プロジェクション アーキテクチャ (推奨されません)

もう 1 つの設計オプションは、すべての各ランディング ゾーンにわたるプライベート エンドポイントのプロジェクションです。 この設計では、ストレージ アカウント A のプライベート エンドポイントが各ランディング ゾーンに作成されます。 これは、データ ランディング ゾーン A の VNet に接続されているデータ ランディング ゾーン A の最初のプライベート エンドポイント、データ ランディング ゾーン B の VNet に接続されている 2 番目のプライベート エンドポイントというようにつながっていきます。

ストレージ アカウント B と、データ ランディング ゾーン内の他のサービスにも同じことが当てはまる可能性があります。 データ ランディング ゾーンの数を n として定義した場合、少なくともすべてのストレージ アカウントとデータ ランディング ゾーン内の他のサービスに対しても n 個のプライベート エンドポイントが作成される可能性があります。 その結果、プライベート エンドポイントの数が指数関数的に増加します。

図 4: プライベート エンドポイント プロジェクション アーキテクチャ。

特定のサービスのすべてのプライベート エンドポイント (ストレージ アカウント A など) は同じ FQDN (storageaccounta.privatelink.blob.core.windows.net など) を持つため、このソリューションでは、DNS レイヤーにプライベート DNS ゾーンを使用して解決できない課題が発生します。 代わりに、要求元の送信元/IP アドレスに基づいて DNS 名を解決できるカスタム DNS ソリューションが必要です。 これにより、データ ランディング ゾーン A の Vnet に接続されているプライベート エンドポイントに VM A を接続し、データランディング ゾーン B の Vnet に接続されているプライベート エンドポイントに VM B を接続できます。これは、Windows サーバーベースのセットアップで行うことができますが、アクティビティ ログと Azure Functions の組み合わせを使用して DNS A レコードのライフサイクルを自動化することもできます。

このセットアップでは、ローカル プライベート エンドポイント経由でデータセットにアクセスすることで、ストレージ アカウント A で生のデータセットを VM B に読み込むことができます (1)。 データセットを読み込んで処理した ((2) と (3)) 後に、ローカル プライベート エンドポイントに直接アクセスして、それをストレージ アカウント B に格納できます (4)。 このシナリオでは、データは VNet ピアリングを横断できません。

プライベート エンドポイント プロジェクション アーキテクチャのユーザー アクセス管理

ユーザー アクセス管理へのこの設計のアプローチは、メッシュ ネットワーク アーキテクチャのアプローチと似ています。 ただし、この設計では、他のデータ ランディング ゾーンに対するアクセス権を要求し、指定されたデータ ランディング ゾーンと Vnet 内だけでなく、他のデータ ランディング ゾーンとそれらの各 Vnet にもプライベート エンドポイントを作成することができます。

このため、データ アプリケーション チームは、新しいサービスを自分自身で作成できるようにするために、2 つではなく 3 つのものを必要とします。

• 指定されたデータ ランディング ゾーン内のリソース グループへの書き込みアクセス
• 指定されたサブネットへの参加アクセス
• それらの各ローカル プライベート エンドポイントを作成するための他のすべてのデータ ランディング ゾーン内のリソース グループとサブネットへのアクセス

このネットワーク設計では、データ アプリケーション チームがすべてのデータ ランディング ゾーンごとにアクセス許可を必要とするため、アクセス管理レイヤーの複雑さが増します。 また、この設計は時間の経過と共に混乱し、RBAC の不整合につながる可能性もあります。

データ ランディング ゾーン チームとデータ アプリケーション チームに必要なアクセス権が与えられていない場合、「従来のハブ アンド スポーク アーキテクチャ (推奨されません)」で説明されている問題が発生します。

Summary:

プライベート エンドポイント プロジェクション アーキテクチャのサービス管理

ここでもメッシュ ネットワーク アーキテクチャの設計と同様に、このネットワーク設計には、単一障害点として機能したり、スループットをスロットリングしたりするネットワーク仮想アプライアンスがないという利点があります。 また、接続ハブを介してデータセットを送信しないことで、仮想アプライアンスをスケールアウトする必要がないため、中央の Azure プラットフォーム チームの管理オーバーヘッドも削減されます。 これは、中央の Azure プラットフォーム チームが、データ ランディング ゾーン間で送信されるすべてのトラフィックを検査してログに記録できなくなることを示します。 ただし、クラウド規模の分析は、複数のサブスクリプションにまたがる一貫性のあるプラットフォームであり、スケーリングを可能にし、プラットフォームレベルの制限を克服するため、欠点にはなりません。

すべてのリソースが 1 つのサブスクリプション内でホストされる場合、中央の接続ハブでトラフィックは検査されません。 それでも、ネットワーク セキュリティ グループのフロー ログを使用してネットワーク ログをキャプチャできます。また、他のアプリケーションおよびサービス レベルのログを、サービス固有の診断設定を使用して統合および保存できます。 これらのログはすべて Azure ポリシーを使用して大規模にキャプチャできます。 一方、必要なプライベート エンドポイントの指数関数的な増加によって、データ プラットフォームで必要なネットワーク アドレス空間が増加するため、これは最適ではありません。

このネットワーク アーキテクチャに関する主な懸念事項は、前述の DNS の課題です。 プライベート DNS ゾーンの形式で Azure ネイティブ ソリューションを使用することはできないため、このアーキテクチャでは、要求元の送信元/IP アドレスに基づいて FQDN を解決できるサード パーティ ソリューションが必要です。 また、プライベート DNS A レコードを自動化するためのツールとワークフローを開発し管理する必要もあります。これは、提案されたAzure Policy 駆動型ソリューションと比較して管理オーバーヘッドが大幅に増加します。

プライベート DNS ゾーンを使用して分散 DNS インフラストラクチャを作成できますが、これにより DNS アイランドが作成され、テナント内の他のランディング ゾーンでホストされているプライベート リンク サービスにアクセスしようとしたときに、最終的に問題が発生します。 したがって、この設計は実行可能なオプションではありません。

概要:

プライベート エンドポイント プロジェクション アーキテクチャのコスト

このネットワーク設計では、プライベート エンドポイント (1 時間あたり) と、生のデータセットを読み込み (1)、処理済みのデータセットを格納する (4) ために、それらのプライベート エンドポイント経由で送信されるイングレスおよびエグレス トラフィックに対してのみ課金されます。 ただし、データ プラットフォームのプライベート エンドポイントの数の指数関数的な増加のため、追加コストが予想されます。 1 時間あたりで課金されるため、追加コストの金額は、作成されるプライベート エンドポイントの数によって大きく異なります。

Summary:

プライベート エンドポイント プロジェクション アーキテクチャの帯域幅と待機時間

この設計には、データ ランディング ゾーン間のデータ交換のスループットを制限するネットワーク仮想アプライアンスがないため、既知の帯域幅と待機時間の制限がありません。 この設計の唯一の制限要因は、データセンターの物理的な制限 (光ファイバー ケーブルの速度) です。

概要:

プライベート エンドポイント プロジェクション アーキテクチャの概要

このネットワーク アーキテクチャにおけるプライベート エンドポイントの指数関数的な増加により、どのプライベート エンドポイントがどの場所でどの目的で使用されているかを追跡できなくなる可能性があります。 また、アクセス管理の問題や DNS レイヤーの複雑さによる制限もあります。 これらの問題のため、クロスデータ ランディング ゾーンのユース ケースでは、このネットワーク設計は推奨できません。

接続ハブ アーキテクチャのプライベート エンドポイント (推奨されません)

もう 1 つのネットワーク オプションは、接続ハブでプライベート エンドポイントをホストし、それらをハブ Vnet に接続することです。 このソリューションでは、企業 Vnet 上のサービスごとに 1 つのプライベート エンドポイントをホストします。 ほとんどの企業の既存のハブ アンド スポーク ネットワーク アーキテクチャと、このソリューションでは接続ハブがプライベート エンドポイントをホストするという事実から、推移性は必要ありません。 接続ハブとデータ ランディング ゾーンの間の VNet ピアリングにより、直接アクセスが可能になります。

VM B のストレージ アカウント A に格納されているデータセットを読み込むために、データが接続ハブとデータ ランディング ゾーンの間の単一の Vnet ピアリングを横断します。そのデータセットが読み込まれて処理されると ((3) と (4))、データは同じ Vnet ピアリングを 2 回目に横断して (5)、最終的にハブ Vnet に接続されたプライベート エンドポイントを介してストレージ アカウント B に格納されます (6)。

図 5: 接続ハブ アーキテクチャのプライベート エンドポイント。

接続ハブ アーキテクチャのユーザー アクセス管理

このネットワーク設計では、データ ランディング ゾーン チームとデータ アプリケーション チームは、プライベート エンドポイントをハブ Vnet に接続するために 2 つのものが必要です。

• 接続ハブ サブスクリプション内のリソース グループへの書き込みアクセス許可
• ハブ Vnet への参加アクセス許可

接続ハブは、組織の Azure プラットフォーム チーム用に指定されており、組織の必要な共有ネットワーク インフラストラクチャ (ファイアウォール、ゲートウェイ、ネットワーク管理ツールを含む) のホスト専用です。 このネットワーク オプションでは、エンタープライズ規模のランディング ゾーンの基本原則のアクセス管理の原則に従っていないため、設計に矛盾が生じます。 そのため、ほとんどの Azure プラットフォーム チームはこの設計オプションを承認しません。

概要:

接続ハブ アーキテクチャのサービス管理

メッシュ ネットワーク アーキテクチャの設計に似ていますが、この設計には、単一障害点として機能したり、スループットをスロットリングしたりするネットワーク仮想アプライアンスがありません。 また、接続ハブを介してデータセットを送信しないことで、仮想アプライアンスをスケールアウトする必要がないため、中央の Azure プラットフォーム チームの管理オーバーヘッドも削減されます。 これは、中央の Azure プラットフォーム チームが、データ ランディング ゾーン間で送信されるすべてのトラフィックを検査してログに記録できなくなることを示します。 ただし、クラウド規模の分析は、複数のサブスクリプションにまたがる一貫性のあるプラットフォームであり、スケーリングを可能にし、プラットフォームレベルの制限を克服するため、欠点にはなりません。

すべてのリソースが 1 つのサブスクリプション内でホストされる場合、中央の接続ハブでトラフィックは検査されません。 それでも、ネットワーク セキュリティ グループのフロー ログを使用してネットワーク ログをキャプチャできます。また、他のアプリケーションおよびサービス レベルのログを、サービス固有の診断設定を使用して統合および保存できます。 これらのログはすべて Azure ポリシーを使用して大規模にキャプチャできます。

また、この設計により、プライベート DNS ゾーンに基づく Azure ネイティブ DNS ソリューションを作成でき、Azure ポリシー を使用して DNS A レコード ライフサイクルを自動化することもできます。

概要:

接続ハブ アーキテクチャのコスト

このネットワーク設計では、プライベート エンドポイント (1 時間あたり) と、生のデータセットを読み込み (1)、処理済みのデータセットを格納する (6) ために、それらのプライベート エンドポイント経由で送信されるイングレスおよびエグレス トラフィックに対してのみ課金されます。

概要:

接続ハブ アーキテクチャの帯域幅と待機時間

この設計には、データ ランディング ゾーン間のデータ交換のスループットを制限するネットワーク仮想アプライアンスがないため、既知の帯域幅と待機時間の制限がありません。 この設計の唯一の制限要因は、データセンターの物理的な制限 (光ファイバー ケーブルの速度) です。

概要:

接続ハブ アーキテクチャのプライベート エンドポイントの概要

このネットワーク アーキテクチャ設計には複数の利点がありますが、前述のアクセス管理の不整合により、基準に達しません。 したがって、この設計アプローチは推奨できません。

単一リージョンのデータ ランディング ゾーン接続の結論

レビューしたすべてのネットワーク アーキテクチャ オプションとそれらの長所と短所から、メッシュ ネットワーク アーキテクチャが明らかな勝者です。 それにはスループットとコストと管理に大きな利点があるため、クラウド規模の分析をデプロイするときに使用することが推奨されます。 ピアリング スポーク仮想ネットワークはこれまで一般的でなく、ドメインや部署間でのデータセットの共有で問題が発生していました。

クラウド規模の分析は、複数のサブスクリプションにまたがる一貫性のあるソリューションとして見ることができます。 単一サブスクリプションのセットアップでは、ネットワーク トラフィック フローはメッシュ ネットワーク アーキテクチャのフローと同じです。 単一サブスクリプション セットアップ内では、ユーザーはプラットフォームのサブスクリプション レベルの制限とクォータに達する可能性が最も高くなります。クラウド規模の分析ではこれを回避することを目的としています。

次の手順

• リージョン間データ ランディング ゾーン接続