リージョン間データ ランディング ゾーン接続
複数の Azure リージョンにプレゼンスがあり、複数の地域でデータ プラットフォームとデータ アプリケーションをホストする必要がある場合、接続は少し複雑になります。
複数リージョンのデプロイでは、通常、個々の Azure の場所に接続ハブ サブスクリプションがあります。 たとえば、米国東部と西ヨーロッパの両方で実行されているサービスがある場合は、各リージョンの共有ネットワーク リソースを使用して接続ハブ サブスクリプションを設定します。 共有ネットワーク リソースには次のものが含まれます。
- ネットワーク仮想アプライアンス (Azure Firewall など)
- ExpressRoute ゲートウェイ
- VPN ゲートウェイ
- ハブ仮想ネットワーク (ハブ アンド スポーク アーキテクチャ内) または vWAN ハブ (vWan セットアップ内)
図 1: リージョン間接続。
ハブ スポーク スポーク ハブ アーキテクチャでは、接続ハブの仮想ネットワークは、多くの場合、グローバル仮想ネットワーク ピアリングを使用して接続されます。 大規模な環境の場合、一般的な代替手段は ExpressRoute Global Reach を使用することです。 どの接続オプションを選択しても、複数の地域にわたるスポーク ネットワーク間のグローバル ルーティングと接続を実現できます。 つまり、どちらの接続サブスクリプションでもトラフィックがブロックされない場合、ネットワーク仮想アプライアンス、ネットワーク セキュリティ グループ、ルート テーブルを使用して、リージョン間でデータを移動できます。
重要
この記事とネットワーク セクションのその他の記事では、データを共有する部門間の概要について説明します。 ただし、これは最初の戦略ではなく、最初に基本レベルから開始する必要があります。
最終的にデータ ランディング ゾーン間で推奨されるセットアップを実装できるように、ネットワークを設計します。 データ管理ランディング ゾーンがガバナンスのためにランディング ゾーンに直接接続されていることを確認します。
グローバル仮想ネットワーク ピアリング (推奨)
直接グローバル仮想ネットワーク ピアリングを使用して、リージョン間でデータ ランディング ゾーンを接続できます。 このセットアップでは、前の例のシナリオを続行すると、西ヨーロッパの仮想マシンは、ハブとスポークまたは vWAN のネットワーク アーキテクチャに依存することなく、米国東部ストレージ アカウントのプライベート エンドポイントに直接アクセスします。 データは、仮想マシンによってプライベート エンドポイント経由で直接読み込まれ、処理された後、西ヨーロッパのストレージ アカウントに格納されます。
グローバル仮想ネットワーク ピアリングでのユーザー アクセス管理
提案されているリージョン間データ ランディング ゾーンの接続オプションのいずれに対しても、特に長所と短所はありません。
概要: 
/
グローバル仮想ネットワーク ピアリングでのサービス管理
グローバル仮想ネットワーク ピアリングには、単一障害点またはスループットの調整として機能するネットワーク仮想アプライアンスはありません。 データは接続ハブを介して送信されないため、接続ハブ内の仮想アプライアンスとゲートウェイをスケーリングする必要はありません。 このスケーリング不足により、コア Azure プラットフォーム チームの管理オーバーヘッドが軽減されます。 また、個々のリージョン間接続を許可リストする必要はありません。 データ チームは、ルート テーブルの変更を待つ必要なく、他のリージョンのデータ ランディング ゾーンからデータにアクセスできます。
このネットワーク設計では、中央の Azure プラットフォーム チームは、レイヤー 7 ファイアウォールを使用してすべてのトラフィックを検査してログに記録することはできなくなります。 ただし、クラウド規模の分析シナリオは、複数のサブスクリプションにまたがる一貫性のあるプラットフォームであり、スケールを可能にし、プラットフォーム レベルの制限を克服するため、欠点ではありません。 ネットワーク セキュリティ グループ フロー ログを使用して、ネットワーク ログをキャプチャできます。 サービス固有の診断設定を使用して、他のアプリケーション とサービス レベルのログを統合して格納できます。
診断設定の Azure Policy 定義
一部のシナリオでは、規制や法的な影響が原因で制限する必要があります。 たとえば、特定のデータセットを粒子状のデータセンター内に留める必要があるローカル規制があるため、リージョン間でデータを転送することはできません。 ネットワーク セキュリティ グループを利用して、この種の規則に準拠し、トラフィックを米国東部から西ヨーロッパに一方向に移動することのみを許可し、その逆は許可しません。 ネットワーク セキュリティ グループ内では、米国東部からのトラフィックが拒否され、西ヨーロッパからのトラフィックが許可されていることを確認できます。
このソリューションアプローチは帯域幅と待機時間に影響を与えません。また、複数のリージョンのデータセットを組み合わせながら、お客様は準拠を維持できます。 このオプションは DNS アーキテクチャにも影響せず、Azure プライベート DNS ゾーンに基づく Azure ネイティブ ソリューションを使用できます。
概要:
グローバル仮想ネットワーク ピアリングのコスト
手記
ピアリングされたネットワーク経由でプライベート エンドポイントにアクセスする場合、VNet ピアリングではなく、プライベート エンドポイント自体に対してのみ課金されます。 「FAQ: ピアリングされたネットワークからプライベート エンドポイントにアクセスするときの課金のしくみ」の公式声明を読むことができます。.
このネットワーク設計では、プライベート エンドポイント (1 時間あたり) と、それらを介して送信されるすべてのイングレス トラフィックとエグレス トラフィックに対して課金されます。 また、リージョン間のトラフィックに対して データ転送コスト を支払う必要があります。 ただし、グローバル仮想ネットワーク ピアリングのイングレスとエグレスのコストは課金されません。さらに、従来のスポーク-ハブ-ハブ-スポーク オプションに比べて大きなコスト メリットがあります。
概要:
グローバル仮想ネットワーク ピアリングの帯域幅と待機時間
グローバル仮想ネットワーク ピアリングの帯域幅と待機時間への影響は、従来のスポーク ハブ ハブ スポーク オプションよりも低くなります。 グローバル仮想ネットワーク ピアリングには、リージョン間データ ランディング ゾーンのデータ交換のホップ数が少なく、スループットを制限するネットワーク仮想アプライアンスはありません。 リージョン間トラフィックで実現できる帯域幅と待機時間を示す唯一の事柄は、データセンターの物理的な制限 (光ファイバー ケーブル、ゲートウェイ、ルーターの速度) です。
概要:
グローバル仮想ネットワーク ピアリングの概要
異なるリージョンのデータ ランディング ゾーン間のグローバル仮想ネットワーク ピアリングは、特にリージョン間のデータ トラフィックがデータ プラットフォーム内で増加するにつれて、大きな利点を提供します。 これにより、コア Azure プラットフォーム チームのサービス管理が簡素化されます。特に、待機時間が短く、帯域幅が広い必要があるユース ケースにメリットがあります。 また、従来のスポークハブスポーク設計オプションよりもコスト面で大きなメリットがあります。
従来のスポーク-ハブ-ハブ-スポーク設計 (非推奨)
リージョン間データ転送のもう 1 つのオプションは、従来のスポーク‐ハブ‐スポーク設計モデルです。 このシナリオ例では、西ヨーロッパでホストされているデータ ランディング ゾーン A の仮想マシンが、米国東部でホストされているデータ ランディング ゾーン B からストレージ アカウントに格納されているデータセットを読み込む場合、データは 2 つのローカル仮想ネットワーク ピアリング (ハブとスポーク間の接続)、1 つのグローバル仮想ネットワーク ピアリング (ハブ間の接続)、2 つのゲートウェイまたはネットワーク仮想アプライアンスを走査してから、仮想マシンによって読み込まれ、ローカル ストレージに戻ります。アカウント。
従来のスポーク－ハブ－スポーク設計におけるユーザーアクセス管理
提案されているリージョン間データ ランディング ゾーンの接続オプションのいずれに対しても、特に長所と短所はありません。
概要: /
従来のスポーク-ハブ-ハブ-スポーク設計でのサービス管理
このソリューション アプローチはよく知られており、他のリージョン間接続パターンと一致しているため、導入と実装が簡単になります。 また、DNS アーキテクチャに影響はなく、Azure プライベート DNS ゾーンに基づく Azure ネイティブ ソリューションを使用できます。
この接続オプションは、正しく設定するとシームレスに動作しますが、欠点があります。 多くの場合、リージョン間のトラフィックは既定で拒否され、ケース バイ ケースで有効にする必要があります。 チームが仮想マシンとリージョン間ストレージ アカウントの間の特定の接続ごとに許可リストを作成できるように、必要なリージョン間データ アクセス要件ごとに、コア Azure プラットフォーム チームにチケットを送信する必要があります。 このプロセスにより、管理オーバーヘッドが大幅に増加します。 また、必要なデータにアクセスできないため、データ プロジェクト チームの速度が低下します。
また、このオプションでは、接続ハブは単一障害点として機能します。 ネットワーク仮想アプライアンスまたはゲートウェイのダウンタイムでは、接続と対応するデータ プラットフォームが失敗します。 また、接続ハブ内のルートを誤って構成するリスクも高くなります。 この構成ミスにより、データ プラットフォームで重大なダウンタイムが発生し、一連の依存ワークフローとデータ製品の障害が発生する可能性があります。
このソリューション アプローチを使用するときは、リージョン間で転送する必要があるデータの量を監視する必要があります。 時間の経過とともに、この監視には、中央インスタンスを通過する数ギガバイトまたはテラバイトのデータが含まれる場合があります。 ネットワーク仮想アプライアンスの帯域幅は、多くの場合、1 桁または 2 桁のギガバイトスループットに制限されるため、アプライアンスは、リージョン間のトラフィック フローとデータ資産の共有可能性を制限する重要なボトルネックとして機能する可能性があります。 このボトルネックのため、共有ネットワーク リソースにはスケーリング メカニズムが必要になり、多くの場合、時間がかかり、コストがかかり、テナント内の他のワークロードに影響を与える可能性があります。
概要:
従来のスポーク-ハブ-ハブ-スポーク設計のコスト
手記
ピアリングされたネットワーク経由でプライベート エンドポイントにアクセスする場合、VNet ピアリングではなく、プライベート エンドポイント自体に対してのみ課金されます。 「FAQ: ピアリングされたネットワークからプライベート エンドポイントにアクセスするときの課金のしくみ」の公式声明を読むことができます。.
従来のスポーク ハブ ハブ スポーク設計では、2 つのストレージ アカウントのプライベート エンドポイント (1 時間あたり) と、それらを介して送信されるすべてのイングレス およびエグレス トラフィックが課金されます。 また、1 つのローカル仮想ネットワーク ピアリングのイングレス トラフィックとエグレス トラフィックと、接続ハブ間のグローバル仮想ネットワーク ピアリングに対しても課金されます。 ただし、前のメモで説明したように、最初の仮想ネットワーク ピアリングに対しては課金されません。
また、中央ネットワーク仮想アプライアンスでは、このネットワーク設計を選択すると、大幅なコストが発生します。 このコストは、Azure Firewall と同様に、需要に基づいてアプライアンスをスケーリングするために追加のライセンスを購入するか、処理されたギガバイトごとに料金を支払う必要があるためです。
概要:
従来のスポーク ハブ スポーク設計における帯域幅と待機時間
このネットワーク設計には、帯域幅に重大な制限があります。 中央ネットワーク仮想アプライアンスは、プラットフォームが拡大するにつれて重要なボトルネックになり、リージョン間のデータ ランディング ゾーンのユース ケースとデータセットの共有が制限されます。 また、データセットの複数のコピーが時間の経過と同時に作成される可能性も高くなります。 この設計は待機時間にも大きく影響します。これは、データが多数のホップを通過するため、リアルタイム分析シナリオで特に重要です。
概要:
従来のスポーク-ハブ-ハブ-スポークの設計
スポーク・ハブ・ハブ・スポーク設計は、多くの組織でよく知られており、確立されているので、既存の環境でも簡単に確立できます。 ただし、サービス管理、コスト、帯域幅、待機時間には大きな欠点があります。 これらの問題は、リージョンをまたがるユース ケースの数が増えるにつれて特に顕著になります。
結論
グローバル仮想ネットワーク ピアリング は、コスト効率が高く、管理が容易で、リージョン間で信頼性の高い接続を提供 従来のスポーク ハブ スポーク 設計よりも多くの利点があります。 従来のスポークハブハブスポーク設計は、データ量とリージョン間のデータ交換の必要性が低い場合に実行可能なオプションですが、リージョン間で交換する必要があるデータの量が増えるにつれて、グローバル仮想ネットワーク ピアリング アプローチを使用することをお勧めします。
次の手順
- Azure でテナント間のプライベート エンドポイント接続を制限する
- クラウド規模の分析のためのリソースの編成