仮想ハブ拡張パターン

Azure Private Link
Azure DNS
Azure Firewall
Azure Virtual WAN

独自のネットワークの持ち込みを使用する従来のハブスポーク トポロジでは、ハブ仮想ネットワークを完全に操作できます。 ハブに共通のサービスをデプロイし、ワークロード スポークで使用できるようにすることができます。 これらの共有サービスには、多くの場合、DNS リソース、カスタム NVA、Azure Bastion などが含まれます。 ただし、Azure Virtual WAN を使用する場合は、アクセスの制限と、仮想ハブにインストールできるものに関する制限があります。

たとえば、従来のハブスポーク ネットワーク アーキテクチャで Private Link と DNS 統合を実装するには、プライベート DNS ゾーンを作成してハブ ネットワークにリンクします。 仮想マシンのリモート アクセスの計画には、リージョン ハブの共有サービスとして Azure Bastion が含まれる場合があります。 ハブに Active Directory VM などのカスタム コンピューティング リソースをデプロイすることもできます。 Virtual WAN では、これらの方法は使用できません。

この記事では、仮想ハブに直接デプロイできないスポークに共有サービスを安全に公開する方法に関するガイダンスを提供する、仮想ハブ拡張パターンについて説明します。

Architecture

仮想ハブ拡張は、単一の共有サービスをワークロード スポークに公開する、仮想ハブに接続された専用のスポーク仮想ネットワークです。 仮想ハブ拡張を使用して、多くのワークロード スポークに、共有リソースへのネットワーク接続を提供できます。 この使用例は、DNS リソースです。 拡張を使用して、スポーク内の多くの宛先への接続を必要とする一元化されたリソースを含めることもできます。 この使用例は、一元化された Azure Bastion デプロイです。

ハブ拡張パターンを示す図。

図 1: ハブ拡張パターン

このアーキテクチャの Visio ファイルをダウンロードします。

  1. Azure Bastion 用の仮想ハブ拡張。 この拡張を使用すると、スポーク ネットワーク内の仮想マシンに接続できます。
  2. DNS 用の仮想ハブ拡張。 この拡張を使用すると、プライベート DNS ゾーン エントリをスポーク ネットワーク内のワークロードに公開できます。

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

仮想ハブ拡張は、多くの場合、ネットワーク内でコア機能を提供しているため、ビジネス クリティカルと見なされます。 拡張は、ビジネス要件に合わせ、障害軽減戦略を持ち、スポークのニーズに合わせてスケーリングする必要があります。

標準的な運用手順には、すべての拡張の回復性のテストと信頼性の監視を含める必要があります。 これらの手順では、アクセスとスループットの要件を検証する必要があります。 各拡張には、意味のある正常性モデルが必要です。

この拡張のサービス レベル目標 (SLO) を明確にし、それに対する信頼性を正確に測定します。 Azure サービス レベル アグリーメント (SLA) と、拡張内の各コンポーネントのサポート要件を把握します。 この知識は、ターゲット SLO の上限を設定し、サポートされている構成を理解するのに役立ちます。

セキュリティ

ネットワークの制限。 拡張はしばしば多くのスポークで使用されたり、多くのスポークへのアクセスを必要としますが、すべてのスポークからのアクセスやすべてのスポークへのアクセスは必要ない場合があります。 可能な場合は、ネットワーク セキュリティ グループの使用や、セキュリティ保護付き仮想ハブ経由でのトラフィックのエグレスなど、使用可能なネットワーク セキュリティ制御を使用します。

データとコントロール プレーンのアクセス制御。 拡張にデプロイされたすべてのリソースのベスト プラクティスに従い、リソースのコントロール プレーンとデータ プレーンへの最小限の特権アクセスを提供します。

コストの最適化

ワークロードと同様に、コストの制御に役立てるために、拡張のリソースに対して適切な SKU サイズが選択されていることを確認します。 営業時間やその他の要因により、一部の拡張で予測可能な使用パターンが発生する可能性があります。 パターンを理解し、それに対応できる弾力性とスケーラビリティを提供します。

共有サービスとして、ワークロード リソースは通常、エンタープライズ アーキテクチャで比較的長いデューティ サイクルを持ちます。 Azure の予約、予約容量の価格、Azure 節約プランなどの事前購入オファリングを使用して、コスト削減を使用することを検討してください。

オペレーショナル エクセレンス

単一責任の原則 (SRP) に準拠するように仮想ハブ拡張をビルドします。 各拡張は 1 つのオファリング用である必要があるため、1 つのスポークで関連のないサービスを組み合わせないでください。 各拡張が専用のリソース グループに存在するようにリソースを整理して、Azure のポリシーとロールの管理を容易にすることができます。

これらの拡張を、コードとしてのインフラストラクチャを使用してプロビジョニングし、各拡張のニーズとライフサイクルをサポートするビルドおよびリリース プロセスを用意する必要があります。 拡張は事実上、ビジネス クリティカルであることが多いため、各拡張に対して厳格なテスト方法と安全なデプロイ プラクティスを用意することが重要です。

明確な変更制御とエンタープライズ コミュニケーション計画を立てることが不可欠です。 実行中のディザスター リカバリー (DR) 訓練や、計画的または予期しないダウンタイムについて、利害関係者 (ワークロード所有者) とコミュニケーションをとる必要がある場合があります。

これらのリソースに対して確実な動作正常性システムが用意されていることを確認します。 すべての拡張のリソースで適切な Azure Diagnostics 設定を有効にし、ワークロードの正常性を理解するために必要なすべてのテレメトリとログをキャプチャします。 共有サービス拡張の予期しない動作中のカスタマー サポートとのやり取りをサポートするために、操作ログとメトリックの長期保存を検討してください。

パフォーマンス効率

拡張は一元化されたサービスです。 負荷の変更を処理するようにスケール ユニットを設計するには、以下を理解する必要があります。

  • 組織が拡張に求めていること。
  • 容量計画の要件。
  • 時間の経過とともにスポークがどのように拡大するか。

スケール ユニットを設計するには、配置されているメトリックとサービスのスケールの制限に基づいて、拡張内の各コンポーネントをどのように個別にスケーリングするかをテストして文書化します。 一部の拡張では、必要なスループットを実現するために、複数のインスタンス間で負荷分散が必要になる場合があります。

実装例

Private Link DNS 拡張: DNS 用の仮想ハブ拡張の確立に関する記事では、Private Link シナリオで単一リージョンの DNS 参照をサポートするように設計された仮想ハブ拡張について説明されています。

次の手順

Azure Virtual WAN のハブスポーク ネットワーク トポロジ