仮想データセンター:ネットワークパースペクティブ

[アーティクル]
07/11/2023

オンプレミスから移行されたアプリケーションは、最小限のアプリケーション変更であっても、Azure のコスト効率の高い安全なインフラストラクチャのメリットを得られる場合があります。企業は機敏性を向上させたり、Azure の機能を活用できるように、アーキテクチャを適合させる必要があります。

Microsoft Azure では、ハイパースケールのサービスとインフラストラクチャ、エンタープライズレベルの機能と信頼性が提供されています。これらのサービスとインフラストラクチャには、ハイブリッド接続に関する多数の選択肢が用意されているため、お客様はインターネットまたはプライベートネットワーク接続経由でアクセスすることができます。また、Microsoft のパートナーも、Azure で実行するために最適化されたセキュリティサービスと仮想アプライアンスを用意して、強化された機能を提供できます。

Azure を使用すると、インフラストラクチャをクラウドにシームレスに拡張し、多層アーキテクチャを構築できます。

仮想データセンターとは

クラウドは、パブリック向けアプリケーションをホストするためのプラットフォームとして開始されました。企業はクラウドの価値を認め、社内の基幹業務アプリケーションの移行を始めました。これらのアプリケーションによってセキュリティ、信頼性、パフォーマンス、およびコストに関する考慮事項が増え、クラウドサービスの提供時に柔軟性がさらに必要とされました。新しいインフラストラクチャとネットワークサービスは、柔軟性を提供するように設計されています。新機能では、柔軟なスケーリング、ディザスターリカバリーなどの配慮がなされています。

当初、クラウドソリューションは、パブリック領域で単一の比較的独立したアプリケーションをホストするように設計され、数年間はうまく機能していました。その後、クラウドソリューションの利点が明らかになるにつれて、複数の大規模なワークロードがクラウドでホストされました。セキュリティ、信頼性、パフォーマンス、コストなどの懸念に対応することは、クラウドサービスのデプロイとライフサイクルに不可欠です。

以下のクラウド配置ダイアグラムの例は、セキュリティギャップが赤枠で強調表示されています。黄色の枠は、ワークロード間でネットワーク仮想アプライアンスを最適化する機会を示しています。

Diagram that shows a cloud deployment and networking virtual datacenter.

仮想データセンターは、エンタープライズワークロードに必要なスケールの実現に役立ちます。このスケールは、パブリッククラウドで大規模なアプリケーションを実行するときに発生する課題に対処する必要があります。

仮想データセンターの実装には、クラウド内のアプリケーションワークロード以上のものが含まれます。また、ネットワーク、セキュリティ、管理、DNS、Active Directory サービスも提供されます。企業が Azure に追加のワークロードを移行するときは、これらのワークロードをサポートするインフラストラクチャとオブジェクトを検討してください。優れたリソース管理により、データフロー、セキュリティモデル、コンプライアンスに関する個別の課題を抱えた、別々に管理される "ワークロードアイランド" の増殖を防ぐことができます。

仮想データセンターの概念により、独立していながら関連するエンティティの集まりを実装するための推奨事項と概要設計が提供されます。これらのエンティティには、多くの場合、共通のサポート関数、機能、およびインフラストラクチャがあります。ワークロードを仮想データセンターと考えると、規模の経済性からのコスト削減を認識するのに役立ちます。また、コンポーネントやデータフローの一元化によるセキュリティの最適化、および運用、管理、コンプライアンス監査を容易にするのにも役立ちます。

Note

仮想データセンターは、特定の 1 つの Azure サービスではありません。そうではなく、要件を満たすためにさまざまな Azure の機能が組み合わされています。仮想データセンターは、クラウドのリソースと機能を最適化するための、ワークロードと Azure の使用方法についての考え方です。これは、企業の組織的な役割と責任に配慮しながら Azure で IT サービスを提供するモジュール方式のアプローチを提供します。

仮想データセンターは、企業が次のシナリオで Azure にワークロードとアプリケーションをデプロイするのに役立ちます。

関連する複数のワークロードをホストする。
オンプレミス環境から Azure にワークロードを移行する。
複数のワークロード間に、共有または一元化されたセキュリティとアクセスの要件を実装する。
大企業向けに DevOps と一元化された IT を適切に組み合わせる。

仮想データセンターを実装する必要があるお客様

Azure の採用を決定したお客様は、すべてのアプリケーションから共通して使用される一連のリソースの効率的な構成を活用できるようになります。サイズによっては、単一のアプリケーションであっても、VDC 実装の構築に使用されるパターンとコンポーネントを利用することでメリットが得られます。

IT、ネットワーク、セキュリティ、またはコンプライアンスの一元化されたチームや部門が存在する組織もあります。 VDC を実装することで、ポリシーポイントの適用、責任の分担、基になる共通コンポーネントの一貫性の確保ができます。アプリケーションチームは、要件に適した自由度と制御を維持できます。

DevOps アプローチを採用した組織は、VDC の概念を使用して、Azure リソースの承認済みのポケットを提供することもできます。この方法により、サブスクリプションレベルで、または共通サブスクリプションのリソースグループ内のいずれかで、DevOps グループはそのグループ内を完全に制御できます。同時に、ネットワークとセキュリティの境界は準拠した状態を維持します。コンプライアンスは、ハブネットワークと一元管理されたリソースグループでの一元化されたポリシーによって定義されます。

仮想データセンターの実装に関する考慮事項

仮想データセンターの設計時には、次の非常に重要な問題を考慮してください。

ID とディレクトリサービス

ID とディレクトリサービスは、オンプレミスとクラウドの両方のデータセンターの主要な機能です。 ID は、VDC 実装内のサービスへのアクセスと認可のすべての側面を対象とします。承認されたユーザーおよびプロセスのみが Azure アカウントとリソースにアクセスできるようにするため、Azure は複数の種類の資格情報を認証に使います。これには、アカウントのパスワード、暗号化キー、デジタル署名、証明書が含まれます。 Microsoft Entra 多要素認証によって、Azure サービスにアクセスするための追加のセキュリティ層が提供されます。各種の簡単な認証オプション (電話、テキストメッセージ、モバイルアプリの通知) を使った強力な認証を使用することで、ユーザーは好きな方法を選択できます。

大企業では、VDC 内または VDC 間での個々の ID とその認証、認可、ロール、権限の管理について説明する ID 管理プロセスを定義する必要があります。このプロセスの目的は、コスト、ダウンタイム、および手作業の反復を減らしながら、セキュリティと生産性を向上させることです。

企業組織では、業種によって異なる、難しいサービスの組み合わせを要求される可能性があります。多くの場合、従業員には、関与するプロジェクトごとに異なるロールが割り当てられます。 VDC では、適切なガバナンスでシステムを稼働するために、それぞれに特定のロールが定義されたさまざまなチーム間での良好な協力が必要です。責任、アクセス、権限のマトリックスは複雑になる可能性があります。 VDC の ID 管理は、Microsoft Entra ID と Azure ロールベースのアクセス制御 (Azure RBAC) を使用して実装されます。

ディレクトリサービスは、日常的な項目とネットワークリソースを検索、管理、整理するための共有情報インフラストラクチャです。これらのリソースには、ボリューム、フォルダー、ファイル、プリンター、ユーザー、グループ、デバイス、その他のオブジェクトが含まれます。ネットワーク上の各リソースは、ディレクトリサーバーによってオブジェクトと見なされます。リソースに関する情報は、そのリソースまたはオブジェクトに関連付けられた属性のコレクションとして格納されます。

すべての Microsoft Online ビジネスサービスは、サインオンや他の ID のニーズに対応するために、Microsoft Entra ID に依存しています。 Microsoft Entra ID は、統合的で可用性の高い ID とアクセス管理のクラウドソリューションであり、コアのディレクトリサービス、高度な ID ガバナンス、およびアプリケーションアクセス管理を組み合わせたものです。 Microsoft Entra ID をオンプレミスの Active Directory と統合することで、クラウドベースのアプリケーションとローカルでホストされているオンプレミスアプリケーションのシングルサインオンを有効にすることができます。オンプレミスの Active Directory のユーザー属性は、Microsoft Entra ID に自動的に同期できます。

1 人のグローバル管理者が、VDC 実装のすべてのアクセス許可を割り当てる必要があるわけではありません。代わりに、特定の各部門、ユーザーのグループ、またはディレクトリサービス内のサービスが、VDC 実装内の各自のリソースを管理するために必要なアクセス許可を持つことができます。アクセス許可を構成するにはバランスが必要です。アクセス許可が多すぎるとパフォーマンス効率が妨げられ、アクセス許可が少なすぎたり緩すぎたりするとセキュリティリスクが高まります。 Azure ロールベースのアクセス制御 (Azure RBAC) は、VDC 実装内のリソースに対してきめ細かいアクセス管理を実現することで、この問題への対処を支援します。

セキュリティインフラストラクチャ

セキュリティインフラストラクチャとは、VDC 実装の特定の仮想ネットワークセグメントにおけるトラフィックの分離を指します。このインフラストラクチャで、VDC 実装内のイングレスとエグレスを制御する方法を指定します。 Azure は、デプロイ間の許可されていない、および意図的でないトラフィックを防ぐマルチテナントアーキテクチャに基づいています。これは、仮想ネットワークの分離、アクセス制御リスト、ロードバランサー、IP フィルター、トラフィックフローポリシーを使用して行われます。ネットワークアドレス変換 (NAT) は、内部ネットワークトラフィックを外部トラフィックから分離します。

Azure ファブリックでは、テナントのワークロードにインフラストラクチャリソースを割り当て、仮想マシン (VM) との間の通信を管理します。 Azure ハイパーバイザーは、VM 間のメモリおよびプロセスの分離を強制し、ネットワークトラフィックをゲスト OS テナントに安全にルーティングします。

クラウドへの接続

仮想データセンターには、顧客、パートナー、または社内ユーザーにサービスを提供するために、外部ネットワークとの接続が必要です。この接続の必要性は、インターネットへの接続だけでなく、オンプレミスのネットワークとデータセンターへの接続も指します。

顧客は、パブリックインターネットと双方向にアクセスできるサービスを制御します。このアクセスは、 Azure Firewall または他の種類のネットワーク仮想アプライアンス (NVA)、ユーザー定義ルートを使用したカスタムルーティングポリシー、ネットワークセキュリティグループを使用したネットワークフィルタリングを使って制御されます。インターネットに接続するすべてのリソースは、Azure DDoS Protection で保護することをお勧めします。

企業は、仮想データセンターをオンプレミスのデータセンターや他のリソースに接続する必要がある場合があります。この Azure とオンプレミスネットワーク間の接続は、効果的なアーキテクチャを設計するときに不可欠な要素となります。この相互接続を作成するには、インターネット経由またはプライベート直接接続の 2 とおりの方法があります。

Azure サイト間 VPN は、オンプレミスのネットワークを Azure の仮想データセンターに接続します。このリンクは、セキュリティで保護された暗号化接続 (IPsec トンネル) を介して確立されます。 Azure サイト間 VPN 接続は柔軟性があり、迅速に作成でき、通常は追加のハードウェア調達は不要です。業界標準のプロトコルに基づいて、最新のネットワークデバイスは、インターネットまたは既存の接続パスを介して Azure への VPN 接続を作成できます。

ExpressRoute を使用すると、仮想データセンターとオンプレミスネットワークの間のプライベート接続が可能になります。 ExpressRoute 接続はパブリックインターネットを使わず、高いセキュリティ、信頼性、速度 (最大 100 Gbps)、および一貫した待機時間を提供します。 ExpressRoute により、プライベート接続に関連付けられたコンプライアンス規則のベネフィットが得られます。 ExpressRoute Direct を使用すると、10 Gbps または 100 Gbps で Microsoft ルーターに直接接続することができます。

通常、ExpressRoute 接続のデプロイでは、ExpressRoute サービスプロバイダーと連携する必要があります (ExpressRoute Direct は例外です)。迅速に開始する必要があるお客様の場合は、最初にサイト間 VPN を使用して、仮想データセンターとオンプレミスのリソース間の接続を確立するのが一般的です。サービスプロバイダーとの物理的な相互接続が完了したら、接続を ExpressRoute 接続に移行します。

多くの VPN または ExpressRoute 接続において、Azure Virtual WAN は、Azure を介してブランチ間接続を最適化し、自動化するネットワークサービスです。 Virtual WAN を使用すると、ブランチデバイスに接続して Azure と通信するように構成できます。接続と構成は、手動で行うことも、Virtual WAN パートナーを通じて推奨プロバイダーデバイスを使用して行うこともできます。推奨プロバイダーデバイスを使用すると、使いやすさ、接続の簡素化、および構成管理を実現できます。 Azure WAN の組み込みダッシュボードにはすぐに使用できるトラブルシューティング用分析情報が用意されているため、時間を節約でき、大規模なサイト間接続を簡単に表示することができます。また、Virtual WAN は、オプションの Azure Firewall と Firewall Manager を含むセキュリティサービスを Virtual WAN ハブに提供します。

クラウド内の接続

Azure Virtual Network と仮想ネットワークピアリングは、仮想データセンター内の基本的なネットワークコンポーネントです。仮想ネットワークは、仮想データセンターのリソースの分離境界を保証します。ピアリングを使用すると、同じ Azure リージョン内の異なる仮想ネットワーク間、リージョン間、および異なるサブスクリプション内のネットワーク間でも相互通信ができます。トラフィックフローは、仮想ネットワーク内とその間の両方で、ネットワークセキュリティグループ、ファイアウォールポリシー (Azure Firewall またはネットワーク仮想アプライアンス)、およびカスタムのユーザー定義ルートに対して指定されたセキュリティ規則のセットによって制御できます。

仮想ネットワークは、サービスとしてのプラットフォーム (PaaS) Azure 製品 (Azure Storage、Azure SQL、パブリックエンドポイントを持つその他の統合されたパブリックサービスなど) を統合するためのアンカーポイントです。サービスエンドポイントと Azure Private Link を使用して、パブリックサービスをプライベートネットワークと統合できます。パブリックサービスをプライベートにすることもできますが、それでも Azure マネージド PaaS サービスのベネフィットを享受できます。

仮想データセンターの概要

トポロジ

仮想データセンターは、ニーズとスケール要件に基づいて、次のような高レベルのトポロジのいずれかを使用して構築できます。

"フラットトポロジ" では、すべてのリソースが 1 つの仮想ネットワークにデプロイされます。サブネットではフロー制御と分離が許可されます。

"メッシュトポロジ" では、仮想ネットワークピアリングによって、すべての仮想ネットワークが相互に直接接続されます。

"ピアリングハブアンドスポークトポロジ" は、責任を委任された分散アプリケーションやチームに非常に適しています。

"Azure Virtual WAN トポロジ" では、大規模なブランチオフィスシナリオとグローバル WAN サービスをサポートできます。

ピアリングハブアンドスポークトポロジと Azure Virtual WAN トポロジではいずれも、通信、共有リソース、および一元化されたセキュリティポリシーに最適であるハブアンドスポーク設計が使用されています。ハブは、仮想ネットワークピアリングハブ (図では Hub Virtual Network と表示) または Virtual WAN ハブ (図では Azure Virtual WAN と表示) を使用して構築されます。 Azure Virtual WAN は、大規模なブランチ間と、ブランチから Azure への通信用に設計されています。また、仮想ネットワークピアリングハブですべてのコンポーネントを個別に構築する複雑さを回避する目的もあります。要件 (ハブ内にネットワーク仮想アプライアンスが必要など) によっては、仮想ネットワークピアリングハブの設計が必要になる場合があります。

ハブアンドスポークトポロジで、ハブは、異なるゾーン (インターネット、オンプレミス、スポーク) 間のすべてのトラフィックを制御および検査する中央ネットワークゾーンです。ハブアンドスポークトポロジは、IT 部門によるセキュリティポリシーの一元的な適用に役立ちます。また、構成の誤りや露出の可能性も低減されます。

多くの場合、ハブには、スポークによって消費される共通のサービスコンポーネントが含まれています。共通の中央サービスの例を次に示します。

Windows Active Directory インフラストラクチャは、信頼されていないネットワークからアクセスするサードパーティがスポーク内のワークロードにアクセスする前にユーザー認証を行うために必要です。これには、関連する Active Directory フェデレーションサービス (AD FS) が含まれます
Azure DNS が使用されていない場合に、スポーク内のワークロードの名前付けを解決するため、およびオンプレミスやインターネット上のリソースにアクセスするために、Distributed Name System (DNS) サービスが使用されます
公開キー基盤 (PKI) は、ワークロードでシングルサインオンを実装するために使用されます
スポークネットワークゾーンとインターネット間の TCP と UDP トラフィックのフロー制御
スポークとオンプレミス間のフロー制御
(必要に応じて) スポーク間のフロー制御

仮想データセンターでは、複数のスポーク間で共有ハブインフラストラクチャを使用することで、全体的なコストを削減します。

各スポークのロールは、異なる種類のワークロードをホストできます。スポークは、同じワークロードの反復可能なデプロイのためのモジュール方式のアプローチも提供します。例として、開発/テスト、ユーザー受け入れテスト、運用前環境、運用環境があります。スポークでは、組織内のさまざまなグループを分離して有効にすることもできます。 DevOps グループは、スポークで実行できることの良い例です。スポーク内には、基本的なワークロードや、階層間のトラフィック制御を伴う複雑な多層ワークロードをデプロイできます。

サブスクリプションの制限と複数のハブ

重要

Azure デプロイのサイズに基づき、複数ハブの戦略が必要になる場合があります。ハブアンドスポーク戦略を設計するときに、"このリージョンで別のハブ仮想ネットワークを使用するようにこの設計をスケーリングできるだろうか?"、また "複数のリージョンに対応するようにこの設計をスケーリングできるだろうか?" を確認してください。スケーリング可能な設計を計画しておいて必要なかったとしても、計画を怠って必要になった場合よりもはるかに良いと言えます。

2 つ目の (またはそれ以上) のハブにスケーリングするタイミングは、通常スケールに固有の制限に基づく、いくつかの要因によって決まります。スケールの設計時には、サブスクリプション、仮想ネットワーク、および仮想マシンの制限を必ず確認してください。

Azure では、種類に関係なく、すべてのコンポーネントが Azure サブスクリプションにデプロイされます。異なる Azure サブスクリプションに Azure コンポーネントを分離することで、差別化されたレベルのアクセスと承認の設定など、さまざまな業種の要件を満たすことができます。

1 つの VDC の実装によって、多数のスポークをスケールアップできます。しかし、あらゆる IT システムと同様に、プラットフォームの制限があります。ハブのデプロイは、制限と制限 (仮想ネットワークピアリングの最大数など) がある特定の Azure サブスクリプションにバインドされます。詳細については、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。制限が問題になる可能性がある場合は、1 つのハブスポークから、ハブアンドスポークのクラスターにモデルを拡張することによって、さらにアーキテクチャをスケールアップできます。 1 つ以上の Azure リージョン内の複数のハブを、仮想ネットワークピアリング、ExpressRoute、Virtual WAN、またはサイト間 VPN を使用して接続できます。

複数のハブを導入すると、システムのコストと管理作業が増加します。これが正当化されるのは、エンドユーザーのパフォーマンスやディザスターリカバリーのために、スケーラビリティ、システムの制限、冗長性、リージョン間レプリケーションが必要な場合だけです。複数のハブが必要なシナリオでは、運用を容易にするため、すべてのハブで同じサービスのセットを提供する必要があります。

スポーク間の相互接続

1 つのスポーク (フラットネットワーク設計) 内に、複雑な多層ワークロードを実装できます。多階層の構成は、同じ仮想ネットワーク内の階層またはアプリケーションごとに 1 つのサブネットを使用して実装できます。トラフィック制御とフィルター処理は、ネットワークセキュリティグループとユーザー定義ルートを使用して行われます。

アーキテクトは、複数の仮想ネットワークに多層ワークロードをデプロイできます。仮想ネットワークピアリングにより、スポークは同じハブまたは異なるハブの他のスポークに接続できます。このシナリオの一般的な例は、アプリケーション処理サーバーが 1 つのスポーク (仮想ネットワーク) にあるケースです。データベースは別のスポーク (仮想ネットワーク) にデプロイされています。この場合、仮想ネットワークピアリングでこれらのスポークを相互接続することによって、ハブの通過を簡単に回避できます。ハブをバイパスすることで、そのハブにしか存在しない重要なセキュリティや監査ポイントがバイパスされないように、アーキテクチャとセキュリティを慎重に見直す必要があります。

ハブとして機能するスポークにスポークを相互接続することもできます。この方法では、2 レベルの階層が作成されます。上位レベル (レベル 0) のスポークが、階層の下位スポーク (レベル 1) のハブになります。 VDC 実装のスポークは、中央のハブにトラフィックを転送する必要があります。その後、オンプレミスネットワークまたはパブリックインターネットでそのトラフィックを宛先に転送できます。 2 レベルのハブのアーキテクチャでは複雑なルーティングが導入され、シンプルなハブスポーク関係のメリットが失われます。

Azure では複雑なトポロジを構成できますが、VDC の概念の中核となる原則の 1 つは再現性と単純さです。管理作業を最小限に抑えるために、単純なハブスポーク設計が、推奨される VDC 参照アーキテクチャです。

コンポーネント

仮想データセンターは、4 種類の基本的なコンポーネントで構成されています。インフラストラクチャ、境界ネットワーク、ワークロード、および監視です。

各コンポーネントの種類は、さまざまな Azure の機能とリソースで構成されます。 VDC 実装は、複数のコンポーネント種類のインスタンスと、同じコンポーネント種類の複数のバリエーションで構成されます。たとえば、異なるアプリケーションを表す、論理的に分離された多数の異なるワークロードインスタンスを使用できます。これらのさまざまなコンポーネント種類とインスタンスを使って VDC を構築します。

VDC の上記のおおまかな概念アーキテクチャでは、ハブスポークトポロジのさまざまなゾーンで使用されるさまざまなコンポーネントの種類が示されています。図では、アーキテクチャのさまざまな部分にインフラストラクチャコンポーネントが示されています。

一般的には、アクセス権と特権をグループベースにすることをお勧めします。個々のユーザーではなくグループを処理すれば、チーム間に一貫した管理方法を用意することでアクセスポリシーの保守が容易になり、構成エラーを最小限に抑えることに役立ちます。適切なグループにユーザーを割り当てたりそこから削除したりすることで、特定ユーザーの権限を最新に保つことができます。

各ロールグループの名前には、一意のプレフィックスを付加できます。このプレフィックスにより、グループが関連付けられているワークロードを識別しやすくなります。たとえば、認証サービスをホストしているワークロードでは、グループに AuthServiceNetOps、AuthServiceSecOps、AuthServiceDevOps、AuthServiceInfraOps という名前を付けます。一元化されたロール (特定のサービスに関係しないロール) には、Corp というプレフィックスを付けます (例: CorpNetOps)。

多くの組織では、次のグループのバリエーションを使って、ロールが大きく分類されています。

Corp という名前の中央 IT チームが、インフラストラクチャコンポーネントを制御するための所有者権限を持ちます。コンポーネントの例として、ネットワークとセキュリティがあります。このグループには、サブスクリプションの共同作業者のロールとスポークのネットワーク共同作成者権限が必要であり、ハブを制御できる必要があります。多くの場合、大規模な組織では、これらの管理責任を複数のチームが分担します。たとえば、ネットワーク運用 (CorpNetOps) グループはネットワークだけを担当し、セキュリティ運用 (CorpSecOps) グループはファイアウォールとセキュリティポリシーを担当します。この場合、カスタムロールの割り当て用に 2 つの異なるグループを作成する必要があります。
AppDevOps という名前の開発/テストグループが、アプリまたはサービスワークロードをデプロイする役割を担います。このグループには、IaaS デプロイの仮想マシン共同作成者のロール、または 1 つ以上の PaaS 共同作成者のロールが割り当てられます。詳細については、Azure の組み込みロールに関するページを参照してください。場合によっては、開発とテストチームは、ハブまたは特定のスポーク内のセキュリティポリシー (ネットワークセキュリティグループ) とルーティングポリシー (ユーザー定義ルート) を表示できる必要があります。その場合、このグループには、ワークロードの共同作成者のロールに加え、ネットワーク閲覧者のロールも必要になります。
CorpInfraOps または AppInfraOps という名前の運用とメンテナンスグループが、運用環境のワークロードを管理する役割を担います。このグループは、運用サブスクリプションのワークロードのサブスクリプション共同作成者である必要があります。一部の組織では、運用環境と中央ハブサブスクリプションにおけるサブスクリプション共同作成者のロールを持つエスカレーションサポートチームグループが必要かどうかを評価することもあります。この別のグループによって、運用環境における潜在的な構成の問題が修正されます。

VDC は、ハブを管理する中央 IT チームグループがワークロードレベルで対応するグループを持つように設計されています。中央 IT チームは、ハブリソースを管理することに加え、サブスクリプションに対する外部アクセスと最上位のアクセス許可を制御できます。また、ワークロードグループは、それぞれの仮想ネットワークのリソースとアクセス許可を中央 IT チームから独立して制御することもできます。

仮想データセンターは、さまざまな基幹業務にわたって複数のプロジェクトを安全にホストできるように、パーティション分割されています。すべてのプロジェクトでさまざまな分離環境 (開発、UAT、運用) が必要になります。これらの環境ごとに Azure サブスクリプションを分けると、自然な分離を実現できます。

上の図は、Azure のコンポーネントがデプロイされている組織のプロジェクト、ユーザー、グループ、環境の間の関係を示しています。

通常、IT の環境 (または階層) は、複数のアプリケーションがデプロイされて実行されるシステムです。大規模な企業では、開発環境 (変更が行われてテストされる場所) と運用環境 (エンドユーザーが使うもの) が使われます。これらの環境は分離されており、多くの場合、その間には複数のステージング環境があります。それによって、段階的デプロイ (ロールアウト)、テスト、および問題が発生した場合のロールバックを実行できます。デプロイアーキテクチャは大きく異なりますが、通常、開発 (DEV) で始まって運用 (PROD) で終わる基本的なプロセスは同じです。

これらの種類の多層環境の一般的なアーキテクチャには、開発とテスト用の DevOps、ステージング用の UAT、および運用環境が含まれます。組織では、1 つまたは複数の Microsoft Entra テナントを使用して、これらの環境に対するアクセスと権限を定義できます。前の図では、DevOps および UAT 用と運用専用の 2 つの異なる Microsoft Entra テナントが使われている場合が示されています。

異なる Microsoft Entra テナントが存在すると、必然的に環境間が分離されます。中央 IT チームなどの同じユーザーグループは、異なる Microsoft Entra テナントにアクセスするための異なる URI を使用して認証する必要があります。これにより、チームはプロジェクトの DevOps または運用環境のロールまたはアクセス許可を変更できます。環境にアクセスするときに、環境ごとに異なるユーザー認証が存在すると、人的エラーが原因で発生する可能性のある停止や他の問題が減少します。

コンポーネントの種類: インフラストラクチャ

このコンポーネントの種類には、ほとんどのサポートインフラストラクチャが存在します。また、一元化された IT、セキュリティ、コンプライアンスのチームが時間の大半を費やす部分でもあります。

インフラストラクチャコンポーネントは、VDC 実装のさまざまなコンポーネントに相互接続を提供し、ハブとスポークの両方に存在します。インフラストラクチャコンポーネントの管理と保守の責任は、通常、中央 IT チームまたはセキュリティチームに割り当てられます。

IT インフラストラクチャチームの主要なタスクの 1 つは、企業全体にわたって一貫した IP アドレススキーマを保証することです。 VDC 実装に割り当てられたプライベート IP アドレス空間は、一貫性があり、オンプレミスのネットワークで割り当てられたプライベート IP アドレスと重複していない必要があります。

オンプレミスのエッジルーター上または Azure 環境内の NAT は、IP アドレスの競合を回避できますが、インフラストラクチャコンポーネントが複雑になります。管理の簡単さが VDC の主な目標の 1 つです。 NAT を使用して IP に関する問題を処理することは、有効なソリューションですが、推奨されるソリューションではありません。

インフラストラクチャコンポーネントは次の機能を備えています。

ID とディレクトリサービス: Azure 内のすべてのリソース種類へのアクセスは、ディレクトリサービスに保存されている ID によって制御されます。ディレクトリサービスは、ユーザーのリストだけでなく、特定の Azure サブスクリプション内のリソースへのアクセス権も格納しています。これらのサービスは、クラウドに存在することも、Active Directory に保存されているオンプレミスの ID と同期させることもできます。
仮想ネットワーク: 仮想ネットワークは VDC の主要コンポーネントの 1 つで、これを使用すると、Azure プラットフォームにトラフィックの分離境界を作成できます。仮想ネットワークは、1 つまたは複数の仮想ネットワークセグメントで構成され、それぞれが特定の IP ネットワークプレフィックス (サブネット、IPv4 またはデュアルスタック IPv4/IPv6 のいずれか) を持ちます。仮想ネットワークにより、IaaS 仮想マシンと PaaS サービスがプライベート通信を確立できる内部境界領域が定義されます。ある仮想ネットワーク内の VM (および PaaS サービス) は、別の仮想ネットワーク内の VM (および PaaS サービス) と直接通信できません。これは、両方の仮想ネットワークが、同じ顧客によって同じサブスクリプションに作成された場合でも当てはまります。分離は、顧客の VM と通信が仮想ネットワーク内でプライベートであることを保証する重要な特性です。ネットワーク間接続が必要な場合、以下の機能でそれをどのように実現できるかについて説明します。
仮想ネットワークピアリング: VDC のインフラストラクチャを作成するために使用される基本的な機能は、仮想ネットワークピアリングです。これは、同じリージョン内の 2 つの仮想ネットワークを接続します。この接続は、Azure データセンターネットワークを介して、またはリージョンをまたがる Azure の世界規模のバックボーンを使用して行われます。
仮想ネットワークサービスエンドポイント: サービスエンドポイントにより、PaaS 空間を含めるように仮想ネットワークのプライベートアドレス空間が拡張されます。さらに、このエンドポイントでは、仮想ネットワークの ID が直接接続を介して Azure サービスまで拡張されます。エンドポイントを使用することで、重要な Azure サービスリソースを仮想ネットワークに限定することができます。
Private Link: Azure Private Link を使用すると、仮想ネットワーク内のプライベートエンドポイント経由で Azure PaaS サービス (Azure Storage、Azure Cosmos DB、および Azure SQL Database など) と Azure でホストされている顧客またはパートナーのサービスにアクセスできます。仮想ネットワークとサービスの間のトラフィックは、Microsoft のバックボーンネットワークを経由して、パブリックインターネットからの公開を排除します。また、独自のPrivate Link サービスを仮想ネットワークに作成し、そのサービスを顧客に非公開で配信することもできます。 Azure Private Link を使用した設定と消費のエクスペリエンスは、Azure PaaS サービス、顧客所有サービス、共有パートナーサービス間で一貫しています。
ユーザー定義ルート: 仮想ネットワーク内のトラフィックは、システムルーティングテーブルに基づいて既定でルーティングされます。ユーザー定義ルートはカスタムルーティングテーブルであり、ネットワーク管理者はそれを 1 つ以上のサブネットに関連付けることで、システムルーティングテーブルの動作を上書きし、仮想ネットワーク内の通信パスを定義できます。ユーザー定義ルートが存在すると、スポークからのトラフィックが、特定のカスタム VM、またはハブとスポークの両方に存在するネットワーク仮想アプライアンスとロードバランサーを通過することが保証されます。
ネットワークセキュリティグループ: ネットワークセキュリティグループは、IP 送信元、IP 送信先、プロトコル、IP 送信元ポート、IP 送信先ポート (レイヤー 4 の 5 タプルとも呼ばれる) のトラフィックフィルターとして機能するセキュリティ規則のリストです。ネットワークセキュリティグループは、サブネット、Azure VM に関連付けられた仮想 NIC のどちらか一方または両方に適用できます。ネットワークセキュリティグループは、ハブとスポークに正しいフロー制御を実装するうえで不可欠です。ネットワークセキュリティグループによって提供されるセキュリティのレベルは、どのポートをどのような目的で開くのかによって決まります。ユーザーは、iptables や Windows ファイアウォールなどのホストベースのファイアウォールを使用して、VM ごとの追加フィルターを適用できます。
DNS: DNS により、仮想データセンター内のリソースの名前解決が提供されます。 Azure は、パブリックとプライベートの両方の名前解決用に DNS サービスを提供します。プライベートゾーンでは、仮想ネットワーク内と仮想ネットワーク間の名前解決が提供されます。プライベートゾーンは、同じリージョン内の複数の仮想ネットワーク間、および複数のリージョンとサブスクリプション間にまたがることができます。パブリック解決の場合、Azure DNS は、DNS ドメインのホスティングサービスであり、Microsoft Azure インフラストラクチャを使用した名前解決を提供します。 Azure でドメインをホストすることで、その他の Azure サービスと同じ資格情報、API、ツール、課金情報を使用して DNS レコードを管理できます。
管理グループ、サブスクリプション、およびリソースグループの管理。サブスクリプションでは、Azure にリソースの複数のグループを作成する自然な境界が定義されています。この分離は、関数、ロールの分離、または課金用です。サブスクリプションのリソースは、リソースグループと呼ばれる論理コンテナーにまとめられています。リソースグループは、仮想データセンターのリソースを整理するための論理グループを表します。組織に多数のサブスクリプションがある場合は、それらのサブスクリプションのアクセス、ポリシー、コンプライアンスを効率的に管理する方法が必要になることがあります。 Azure 管理グループの範囲は、サブスクリプションを上回ります。管理グループと呼ばれるコンテナーにサブスクリプションを整理して、管理グループにガバナンス条件を適用します。管理グループ内のすべてのサブスクリプションは、管理グループに適用された条件を自動的に継承します。階層ビューでこれら 3 つの機能を表示するには、クラウド導入フレームワークのリソースの整理に関する記事を参照してください。
Azure ロールベースのアクセス制御 (Azure RBAC): Azure RBAC は、特定の Azure リソースにアクセスするための組織のロールと権限をマップできます。これにより、ユーザーを特定のアクションのサブセットのみに制限できます。 Microsoft Entra ID をオンプレミスの Active Directory と同期している場合は、オンプレミスで使用しているものと同じ Active Directory グループを Azure で使用できます。 Azure RBAC では、関連するスコープ内のユーザー、グループ、アプリケーションに適切なロールを割り当てることで、アクセス権を付与できます。ロール割り当てのスコープには、Azure サブスクリプション、リソースグループ、または単独のリソースを指定できます。 Azure RBAC では、アクセス許可を継承できます。親スコープでロールが割り当てられると、その親に含まれる子へのアクセス権も付与されます。 Azure RBAC を使用すると、職務を分離し、職務を実行するために必要な範囲のアクセス権だけをユーザーに付与できます。たとえば、ある従業員がサブスクリプションで仮想マシンを管理できる一方で、他の従業員が同じサブスクリプション内で SQL Server データベースを管理できます。

コンポーネントの種類:境界ネットワーク

境界ネットワーク (DMZ ネットワークとも呼ばれます) のコンポーネントは、インターネット接続と共に、オンプレミスまたは物理データセンターのネットワークを接続します。境界には通常、ネットワークやセキュリティのチームの多大な時間投資が必要です。

受信パケットは、スポーク内のバックエンドサーバーとサービスに到達する前に、ハブ内のセキュリティアプライアンスを通過できます。例として、ファイアウォール、IDS、IPS があります。ワークロードからインターネットへのパケットも、ネットワークから送信される前に、境界ネットワーク内のセキュリティアプライアンスを通過できます。このフローにより、ポリシーの適用、検査、監査ができるようになります。

境界ネットワークコンポーネントには次のものが含まれます。

通常、中央 IT チームとセキュリティチームは、境界ネットワークの要件の定義と運用を担当します。

上の図では、インターネットとオンプレミスネットワークにアクセスする 2 つの境界の適用が示されており、どちらも DMZ ハブに存在します。 DMZ ハブでは、Web アプリケーションファイアウォール (WAF) または Azure Firewall の複数のファームを使って、多数の業種をサポートするようにインターネットへの境界ネットワークをスケールアップできます。このハブは、必要に応じて VPN または ExpressRoute 経由でのオンプレミスの接続も許可します。

Note

上の図の DMZ Hub で、仮想ネットワーク、ユーザー定義ルート、ネットワークセキュリティグループ、VPN ゲートウェイ、ExpressRoute ゲートウェイ、Azure Load Balancer、Azure Firewall、Firewall Manager、DDOS などの多くの機能をまとめて Azure Virtual WAN ハブにバンドルできます。 Azure Virtual WAN ハブを使用すると、ハブ仮想ネットワークと VDC の作成が容易になります。これは、Azure Virtual WAN ハブをデプロイするときに、複雑なエンジニアリングのほとんどが Azure によって処理されるためです。

仮想ネットワーク。ハブは、通常、さまざまな種類のサービスをホストする複数のサブネットを含む仮想ネットワークに構築されます。これらのサービスでは、Azure Firewall、NVA、WAF、および Azure Application Gateway のインスタンスを介してインターネットとの間のトラフィックをフィルタリングして検査します。

ユーザー定義ルート。ユーザー定義ルートを使用し、ファイアウォール、IDS/IPS、その他の仮想アプライアンスをデプロイできます。これらのセキュリティアプライアンスを経由してネットワークトラフィックをルーティングすることで、セキュリティ境界ポリシーの適用、監査、検査が可能になります。ユーザー定義ルートはハブとスポークのどちらにでも作成でき、VDC 実装で使用される特定のカスタム VM、ネットワーク仮想アプライアンス、ロードバランサーをトラフィックが通過することを保証します。スポーク内の仮想マシンから生成されたトラフィックが正しい仮想アプライアンスに転送されるようにするには、スポークのサブネットにユーザー定義ルートを設定する必要があります。これは、内部ロードバランサーのフロントエンド IP アドレスをネクストホップとして設定することによって行います。内部ロードバランサーは、内部トラフィックを仮想アプライアンス (ロードバランサーのバックエンドプール) に分散させます。

Azure Firewall は、Azure Virtual Network リソースを保護するマネージドネットワークセキュリティサービスです。これは、高可用性とクラウドのスケーラビリティを備えた、ステートフルなマネージドファイアウォールです。サブスクリプションと仮想ネットワークをまたいでアプリケーションとネットワークの接続ポリシーを一元的に作成、適用、記録できます。 Azure Firewall では、仮想ネットワークリソースに静的パブリック IP アドレスが使用されます。これにより、仮想ネットワークから送信されるトラフィックを外部のファイアウォールで識別できます。サービスはログ記録と分析を行うために Azure Monitor と完全に統合されます。

Azure Virtual WAN トポロジを使用する場合は、Azure Firewall Manager が、クラウドベースのセキュリティ境界に対して集約型セキュリティポリシーとルート管理を提供するセキュリティ管理サービスです。これは、ハブおよびスポークの各アーキテクチャを簡単に作成できる Microsoft の管理対象リソースである Azure Virtual WAN ハブと連携して動作します。セキュリティとルーティングのポリシーがハブに関連付けられている場合は、セキュリティ保護付き仮想ハブと呼ばれます。

ネットワーク仮想アプライアンス。ハブでは、インターネットにアクセスする境界ネットワークは、通常、Azure Firewall インスタンスあるいはファイアウォールまたは Web アプリケーションファイアウォール (WAF) のファームによって管理されます。

さまざまな業種で一般的に多くの Web アプリケーションが使用され、これらは種々の脆弱性や悪用の可能性に悩まされる傾向があります。 Web アプリケーションファイアウォールは、Web アプリケーションと HTTP/HTTPS に対する攻撃を汎用ファイアウォールよりも効果的に検出するために使用される特殊な種類の製品です。従来のファイアウォールテクノロジと比較すると、WAF は脅威から内部 Web サーバーを保護するための特定の機能セットを備えています。

Azure Firewall または NVA ファイアウォールでは、スポークでホストされているワークロードを保護し、オンプレミスネットワークへのアクセスを制御する一連のセキュリティ規則を備えた共通のコントロールプレーンが使用されます。 Azure Firewall にはスケーラビリティが組み込まれているのに対し、NVA ファイアウォールはロードバランサーの背後で手動でスケーリングすることができます。一般に、ファイアウォールファームは WAF ほど特化したソフトウェアではありませんが、エグレスおよびイングレスのあらゆる種類のトラフィックをフィルター処理して検査する、より広範なアプリケーションスコープを備えています。 NVA アプローチを使用している場合は、Azure Marketplace で入手してデプロイできます。

インターネットから送信されるトラフィックには、Azure Firewall インスタンスまたは NVA の特定のセットを使用することをお勧めします。オンプレミスから送信されるトラフィックには、別のセットを使用します。両方にファイアウォールの同じセットを使用すると、2 つのネットワークトラフィックセットの間にセキュリティ境界が提供されないため、セキュリティリスクになります。個別のファイアウォールレイヤーを使用すると、セキュリティ規則のチェックの複雑さが軽減され、どの規則がどの受信ネットワーク要求に対応しているかが明確になります。

Azure Load Balancer が提供する高可用性レイヤー 4 (TCP、UDP) サービスは、負荷分散セットで定義されているサービスインスタンス間に受信トラフィックを分散できます。フロントエンドエンドポイント (パブリック IP エンドポイントまたはプライベート IP エンドポイント) からロードバランサーに送信されたトラフィックは、アドレス変換をして、またはしないで、バックエンド IP アドレスプール (ネットワーク仮想アプライアンスや仮想マシンなど) のセットに再配信できます。

Azure Load Balancer では、さまざまなサーバーインスタンスの正常性をプローブできます。インスタンスがプローブに応答しない場合、ロードバランサーは異常なインスタンスへのトラフィックの送信を停止します。仮想データセンターでは、外部ロードバランサーがハブとスポークにデプロイされています。ハブでは、ファイアウォールインスタンス間にトラフィックを効率的にルーティングするためにロードバランサーが使用されます。スポークでは、アプリケーショントラフィックを管理するためにロードバランサーが使用されます。

Azure Front Door (AFD) は、Microsoft による高可用性かつスケーラブルな Web アプリケーションアクセラレーションプラットフォーム、グローバル HTTP ロードバランサー、アプリケーション保護、コンテンツ配信ネットワークです。 AFD は、Microsoft のグローバルネットワークのエッジの 100 を超える箇所で動作し、動的 Web アプリケーションと静的コンテンツを構築、操作、スケールアウトできるようにします。 AFD を使用すれば、世界レベルのエンドユーザーパフォーマンス、統一されたリージョン/スタンプのメンテナンス自動化、BCDR の自動化、統一されたクライアント/ユーザー情報、キャッシュ、サービスの分析情報がアプリケーションに提供されます。

プラットフォームでは以下が提供されます。

パフォーマンス、信頼性、およびサービスレベルアグリーメント (SLA) のサポート。
コンプライアンス認定。
Azure によって開発、運用、およびネイティブでのサポートが行われる監査可能なセキュリティプラクティス。

Azure Front Door には、一般的な脆弱性やウィルス感染から Web アプリケーションを保護する Web アプリケーションファイアウォール (WAF) も用意されています。

Azure Application Gateway は専用の仮想アプライアンスであり、マネージドアプリケーション配信コントローラーが提供されます。これは、レイヤー 7 のさまざまな負荷分散機能をお客様のアプリケーションに提供します。これにより、CPU を集中的に使用する SSL 終了をアプリケーションゲートウェイにオフロードし、Web ファームのパフォーマンスを最適化できます。また、着信トラフィックのラウンドロビン分散、Cookie ベースのセッションアフィニティ、URL パスベースのルーティング、単一のアプリケーションゲートウェイの背後で複数の Web サイトをホストする機能など、その他のレイヤー 7 ルーティング機能も用意されています。アプリケーションゲートウェイの WAF SKU の一部として、Web アプリケーションファイアウォール (WAF) も提供されます。この SKU は、一般的な Web の脆弱性や悪用から Web アプリケーションを保護します。アプリケーションゲートウェイは、インターネットに接続するゲートウェイまたは内部専用ゲートウェイとして、あるいは両方を組み合わせて構成できます。

パブリック IP。 Azure の一部の機能を使用して、インターネットからリソースにアクセスできるように、サービスエンドポイントをパブリック IP アドレスに関連付けることができます。このエンドポイントでは、NAT を使用して、Azure の仮想ネットワーク上の内部アドレスとポートにトラフィックをルーティングします。これは、外部トラフィックが仮想ネットワークに到達するための主な経路です。パブリック IP アドレスを構成することで、仮想ネットワークに渡されるトラフィックと、そのトラフィックが仮想ネットワークのどこでどのように変換されるのかを決定することができます。

Azure DDoS Protection では、Basic サービスレベルに加えて、特に Azure Virtual Network リソースに合わせてチューニングされた追加の軽減機能が提供されます。 DDoS Protection は簡単に有効化でき、アプリケーションの変更は不要です。保護ポリシーは、専用のトラフィック監視および機械学習アルゴリズムによってチューニングされます。ポリシーは、仮想ネットワークにデプロイされたリソースに関連付けられているパブリック IP アドレスに適用されます。例としては、Azure Load Balancer、Azure Application Gateway、および Azure Service Fabric のインスタンスがあります。攻撃中および履歴の表示のために、システムによって生成されたログをAzure Monitor ビューからほぼリアルタイムで使用できます。アプリケーションレイヤー保護は、Azure Application Gateway Web アプリケーションファイアウォール経由で追加できます。 IPv4 と IPv6 の Azure パブリック IP アドレスに対して保護が提供されます。

ハブアンドスポークトポロジでは、仮想ネットワークピアリングとユーザー定義ルートを使用して、トラフィックを適切にルーティングします。

この図では、ユーザー定義ルートによって、トラフィックが、ExpressRoute ゲートウェイ経由でオンプレミスに渡される前に、スポークからファイアウォールに確実に送信されます (ファイアウォールポリシーによってこのフローが許可されている場合)。

コンポーネントの種類: 監視

監視コンポーネントは、他のすべての種類のコンポーネントからの可視性とアラートを提供します。すべてのチームは、アクセス権を持っているコンポーネントとサービスの監視にアクセスできます。一元的なヘルプデスクまたは運用チームは、これらのコンポーネントによって提供されるデータへの統合アクセスが必要です。

Azure では、Azure がホストするリソースの動作を追跡するために、さまざまな種類のログサービスと監視サービスが提供されています。 Azure でのワークロードのガバナンスと制御は、ログデータの収集だけでなく、報告された特定のイベントに基づいてアクションをトリガーできることにも基づいています。

Azure Monitor。 Azure には、監視領域において特定の役割やタスクを個別に実行するサービスが複数用意されています。これらのサービスを組み合わせることにより、アプリケーションやそれらを支える Azure リソースからシステム生成ログを収集、分析し、それに対処するための包括的なソリューションが提供されます。また、オンプレミスの重要なリソースを監視して、ハイブリッド監視環境を構築することもできます。アプリケーションの包括的な監視戦略を策定するための最初のステップは、利用可能なツールとデータの把握です。

Azure Monitor には、次の 2 つの基本的な種類のログがあります。

メトリックは、特定の時点におけるシステムの何らかの側面を表す数値です。それらは軽量であり、ほぼリアルタイムのシナリオをサポートできます。 Azure Monitor で収集された多くの Azure リソースのデータは、Azure portal のそれぞれの概要ページで参照できます。たとえば、任意の仮想マシンを見てみると、パフォーマンスメトリックが表示されたいくつかのグラフが表示されます。いずれかのグラフを選択すると、データが Azure portal のメトリックエクスプローラーで開かれ、複数のメトリックの値を時系列にグラフ化できます。グラフは、対話形式で表示したり、ダッシュボードにピン留めして他の視覚化と一緒に表示したりできます。
ログには、種類ごとに異なるプロパティセットを持つレコードに編成されたさまざまな種類のデータが含まれます。イベントとトレースは、パフォーマンスデータと共にログとして格納されます。これらはすべて分析のために組み合わせることができます。 Azure Monitor で収集したログデータは、収集データをすばやく取得、統合、分析するクエリを使用して分析できます。ログは Log Analytics に格納され、そこからクエリが実行されます。 Azure portal で Log Analytics を使用してクエリを作成してテストしたり、これらのツールを使用してデータを直接分析したり、視覚化またはアラートルールで使用するためにクエリを保存したりできます。

Azure Monitor でさまざまなソースからデータを収集することができます。ご自分のアプリケーション、オペレーティングシステム、およびそれが依存するサービスから、Azure プラットフォーム自体に至るまで、アプリケーションのさまざまな階層のデータ監視を検討することができます。 Azure Monitor は、以下のそれぞれの層からデータを収集します。

アプリケーション監視データ: プラットフォームを問わず、記述したコードのパフォーマンスと機能に関するデータ。
ゲスト OS 監視データ: アプリケーションが実行されているオペレーティングシステムに関するデータ。この OS は Azure、別のクラウド、またはオンプレミスで実行できます。
Azure リソース監視データ: Azure リソースの操作に関するデータ。
Azure サブスクリプション監視データ: Azure サブスクリプションの操作と管理、および Azure 自体の正常性と操作に関するデータ。
Azure テナントの監視データ: Microsoft Entra ID など、テナントレベルの Azure サービスの操作に関するデータ。
カスタムソース: オンプレミスのソースから送信されたログも含めることができます。たとえば、オンプレミスのサーバーイベントや、ネットワークデバイスの syslog 出力などです。

データの監視が役立つのは、コンピューティング環境の運用の可視性が高まる場合のみです。 Azure Monitor には、アプリケーションやそれが依存するリソースに関する貴重な分析情報を提供するいくつかの機能やツールが含まれています。 Application Insights や Azure Monitor for containers などの監視ソリューションと機能では、アプリケーションや特定の Azure サービスのさまざまな側面に関する詳細な分析情報が提供されます。

Azure Monitor の監視ソリューションは、特定のアプリケーションまたはサービスに関する分析情報を提供するロジックのパッケージ化されたセットです。それには、アプリケーションまたはサービスの監視データを収集するためのロジック、そのデータを分析するためのクエリ、視覚化のためのビューが含まれています。各種の Azure サービスおよびその他のアプリケーションの監視を実現するために、複数の監視ソリューションが Microsoft とパートナーから入手できます。

そのような豊富なデータのコレクションを使用し、特に手動クエリだけでは十分ではない環境で発生するイベントに対してプロアクティブな対策を取ることが重要です。 Azure Monitor のアラートは、重大な状態を事前に通知し、場合によっては是正措置を試行します。メトリックに基づくアラートルールにより、数値に基づくほぼリアルタイムのアラートが提供されます。ログに基づくアラートルールでは、複数のソースからのデータにまたがる複雑なロジックを使用できます。 Azure Monitor のアラートルールは、複数のルール間で共有できる、受信者およびアクションの一意なセットを含むアクショングループを使用します。ユーザーの要件に基づき、アクショングループでは、アラートによって外部アクションを起動したり、ITSM ツールと統合させたりする Webhook を使用できます。

Azure Monitor では、カスタムダッシュボードを作成することもできます。 Azure ダッシュボードを使用すると、メトリックとログの両方を含むさまざまな種類のデータを組み合わせて Azure portal の 1 つのウィンドウにまとめることができます。ダッシュボードは、他の Azure ユーザーと共有することもできます。 Azure Monitor のすべての要素は、任意のログクエリやメトリックグラフの出力と合わせて、Azure ダッシュボードに追加できます。たとえば、メトリックのグラフ、アクティビティログの表、Application Insights の使用状況グラフ、ログクエリ結果を示すタイルを組み合わせて 1 つのダッシュボードを作成できます。

最後に、Azure Monitor データは Power BI のネイティブソースです。 Power BI は、さまざまなデータソースにわたって対話型の視覚化を提供するビジネス分析サービスです。組織内外の他のユーザーがデータを使用できるようにする効果的な手段でもあります。 Azure Monitor からログデータを自動的にインポートするように Power BI を構成して、これらの追加の視覚化を利用できます。

Azure Network Watcher は、Azure の仮想ネットワーク内のリソースの監視、診断、メトリックの表示、ログの有効化/無効化を行うツールを提供します。これは、次のような機能を提供する多面的なサービスです。

仮想マシンとエンドポイント間の通信を監視する。
仮想ネットワーク内のリソースとそれらの関係を表示する。
VM との間で発生するネットワークトラフィックフィルターの問題を診断する。
VM からのネットワークルーティングの問題を診断する。
VM からの送信接続を診断する。
VM との間のパケットをキャプチャする。
仮想ネットワークゲートウェイと接続に関する問題を診断する。
Azure リージョンとインターネットサービスプロバイダー間の相対待ち時間を確認する。
ネットワークインターフェイスのセキュリティ規則を表示する。
ネットワークメトリックを表示する。
ネットワークセキュリティグループとの間のトラフィックを分析する。
ネットワークリソースの診断ログを表示する。

コンポーネントの種類:ワークロード

ワークロードコンポーネントは、実際のアプリケーションとサービスが存在する場所です。これは、アプリケーション開発チームが時間の大半を費やす部分です。

ワークロードの可能性は無限です。次に示すのは可能なワークロードの種類のほんの一部です。

内部アプリケーション: 基幹業務アプリケーションは、企業の業務に不可欠です。これらのアプリケーションには、一般的な特性がいくつかあります。

対話型: データを入力すると、結果またはレポートが返されます。
データドリブン: データベースや他のストレージに頻繁にアクセスするデータ集約型です。
統合型: 組織の内外の他のシステムとの統合を提供します。

顧客向け Web サイト (インターネット接続または社内向け): ほとんどのインターネットアプリケーションは Web サイトです。 Azure では、IaaS 仮想マシンまたは Azure Web Apps サイト (PaaS) のいずれかを使用して、Web サイトを実行できます。 Azure Web Apps は仮想ネットワークと統合して、スポークネットワークゾーンに Web アプリをデプロイします。プライベート仮想ネットワークからは、インターネット経由でルーティングできないプライベートアドレスを介してリソースにアクセスできるので、社内向け Web サイトでパブリックインターネットエンドポイントを公開する必要はありません。

ビッグデータ分析: データをより大規模ボリュームにスケールアップする必要がある場合、リレーショナルデータベースは、データの極端な負荷や非構造化の性質により、適切に動作しない可能性があります。 Azure HDInsight は、全範囲に対応した、クラウドでのオープンソースの企業向けマネージド分析サービスです。 Hadoop、Apache Spark、Apache Hive、LLAP、Apache Kafka、Apache Storm、R などのオープンソースフレームワークを使用できます。HDInsight。場所ベースの仮想ネットワークへのデプロイがサポートされます。それを仮想データセンターのスポーク内のクラスターにデプロイできます。

イベントとメッセージング:Azure Event Hubs は、ビッグデータのストリーミングプラットフォームであり、イベントインジェストサービスでもあります。 1 秒間に何百万ものイベントを受信して処理することができます。待機時間が短く、保持時間を構成できるため、大量のデータを Azure に取り込み、複数のアプリケーションから読み取ることができます。 1 つのストリームで、リアルタイムとバッチベースの両方のパイプラインをサポートできます。

Azure Service Bus により、アプリケーションとサービス間に信頼性の高いクラウドメッセージングサービスを実装できます。クライアントとサーバー間の非同期のブローカーメッセージング、構造化された先入れ先出し (FIFO) メッセージング、パブリッシュとサブスクライブの機能が提供されます。

これらの例は、Azure 内に作成できるワークロードの種類のほんの一部にすぎません。基本的な Web と SQL アプリから、IoT、ビッグデータ、機械学習、AI、その他の最新のものまで、あらゆるものを作成できます。

高可用性: 複数の仮想データセンター

ここまで、この記事では、単一の VDC の設計に注目し、回復性に寄与する基本的なコンポーネントとアーキテクチャについて説明してきました。 Azure には、Azure Load Balancer、NVA、可用性ゾーン、可用性セット、スケールセット、および運用サービスに確実な SLA レベルを組み込むのに役立つその他の機能があります。

ただし、仮想データセンターは一般的に単一のリージョン内に実装されるため、そのリージョン全体に影響を与える停止に対して脆弱な場合があります。高可用性を求めるお客様は、異なるリージョンにデプロイされた 2 つ以上の VDC 実装に同じプロジェクトをデプロイして、サービスを保護する必要があります。

SLA の懸念事項に加えて、いくつかの一般的なシナリオでは、複数の仮想データセンターを実行するとメリットがあります。

エンドユーザーまたはパートナーのリージョンへの配置またはグローバルな配置。
ディザスターリカバリーの要件。
負荷やパフォーマンスのためにデータセンター間でトラフィックを転送するメカニズム。

リージョンへの配置/グローバルな配置

Azure データセンターは世界中の多数のリージョンに存在します。複数の Azure データセンターを選択する場合、地理的な距離と待機時間という関連する 2 つの要因を考慮してください。ユーザーエクスペリエンスを最適化するには、各仮想データセンター間の距離と、各仮想データセンターからエンドユーザーへの距離を評価します。

仮想データセンターをホストする Azure リージョンは、組織が運営されている法的管轄の規制要件に準拠している必要があります。

障害復旧

ディザスターリカバリー計画の設計は、ワークロードの種類と、さまざまな VDC 実装間でワークロードの状態を同期する機能によって変わります。理想的に、ほとんどのお客様は高速フェールオーバーメカニズムを希望しています。そして、この要件により、複数の VDC 実装で実行されているデプロイ間でアプリケーションデータの同期が必要となる場合があります。ただし、ディザスターリカバリー計画を設計する場合は、ほとんどのアプリケーションがこのようなデータの同期によって発生する可能性がある待機時間の影響を受けやすい点を考慮することが重要です。

異なる VDC 実装内のアプリケーションの同期とハートビート監視には、ネットワークを介した通信が必要です。異なるリージョンの複数の VDC 実装は、次の方法で接続できます。

同じ Virtual WAN 内のリージョンにわたって各 Azure Virtual WAN ハブに組み込まれているハブ間通信。
リージョンをまたいでハブを接続する仮想ネットワークピアリング。
ExpressRoute のプライベートピアリング (各 VDC 実装内のハブが同じ ExpressRoute 回線に接続されている場合)。
企業バックボーン経由で接続されている複数の ExpressRoute 回線と、ExpressRoute 回線に接続された複数の VDC 実装。
各 Azure リージョン内の VDC 実装のハブゾーン間のサイト間 VPN 接続。

通常、Virtual WAN ハブ、仮想ネットワークピアリング、または ExpressRoute の接続がネットワーク接続に適しています。これは、Microsoft バックボーンを通過するときの帯域幅と、一貫性のある待機時間のレベルが高いためです。

ネットワーク認定テストを実行して、これらの接続の待機時間と帯域幅を検証し、その結果に基づいて同期または非同期のデータレプリケーションが適切かどうかを判断します。また、最適な目標復旧時間 (RTO) の観点からこれらの結果を比較検討することも重要です。

ディザスターリカバリー: あるリージョンから別のリージョンへのトラフィックの転送

Azure Traffic Manager と Azure Front Door の両方によって、さまざまな VDC 実装内のリッスンエンドポイントのサービス正常性が定期的にチェックされます。これらのエンドポイントで障害が発生すると、Azure Traffic Manager と Azure Front Door は次に近い VDC に自動的にルーティングします。 Traffic Manager は、リアルタイムのユーザー測定と DNS を使用して、ユーザーを最も近いもの (または、障害時は次に最も近いもの) にルーティングします。 Azure Front Door は、100 個を超える Microsoft バックボーンエッジサイトのリバースプロキシであり、エニーキャストを使用して最も近いリッスンエンドポイントにユーザーをルーティングします。

まとめ

移行に対する仮想データセンターのアプローチは、Azure リソースの使用を最適化し、コストを削減し、システムのガバナンスを簡素化するスケーラブルなアーキテクチャを作成することです。仮想データセンターは通常、(仮想ネットワークピアリングまたは Virtual WAN ハブのいずれかを使用する) ハブおよびスポークのネットワークトポロジに基づきます。ハブで提供される一般的な共有サービスと、特定のアプリケーションおよびワークロードがスポークにデプロイされます。仮想データセンターは、中央 IT、DevOps、運用とメンテナンスなどのさまざまな部門がそれぞれの特異的役割を果たしながら互いに協力し合うという、会社での役割の構造に一致しています。仮想データセンターは、Azure への既存のオンプレミスのワークロードの移行をサポートしていますが、クラウドネイティブのデプロイにも多くの利点をもらたします。

References

このドキュメントで説明した Azure の機能の詳細をご覧ください。

ネットワーク機能
Azure 仮想ネットワーク
 ネットワークセキュリティグループ
 サービスエンドポイント
 Private Link
ユーザー定義ルート
 ネットワーク仮想アプライアンス
 パブリック IP アドレス
 Azure DNS

負荷分散
Azure Front Door
Azure Load Balancer (レイヤー 4)
Application Gateway (レイヤー 7)
Azure の Traffic Manager

接続
仮想ネットワークピアリング
 仮想プライベートネットワーク
 Virtual WAN
ExpressRoute
ExpressRoute Direct

ID
Microsoft Entra ID
Microsoft Entra 多要素認証
 Azure ロールベースのアクセス制御
 Azure 組み込みロール

Monitoring
Network Watcher
Azure Monitor
Log Analytics

ベストプラクティス
管理グループ
 サブスクリプション管理
 リソースグループ管理
 Azure サブスクリプションの制限

Security
Azure Firewall
Firewall Manager
Application Gateway の WAF
Front Door の WAF
Azure DDoS

その他の Azure サービス
Azure ストレージ
 Azure SQL
Azure Web Apps
Azure Cosmos DB
HDInsight
Event Hubs
Service Bus
Azure IoT
Azure Machine Learning

次のステップ

ハブアンドスポークトポロジの中核となるテクノロジである仮想ネットワークピアリングの詳細について確認します。
Azure ロールベースのアクセス制御を使用するために Microsoft Entra ID を実装します。
組織の構造、要件、ポリシーに適合する Azure ロールベースのアクセス制御を使用して、サブスクリプションおよびリソースの管理モデルを開発します。最も重要なアクティビティは計画です。再編成、合併、新しい製品ライン、およびその他の考慮事項が初期モデルに与える影響を分析し、将来のニーズと成長に合わせて調整できるようにします。

仮想データセンター:ネットワーク パースペクティブ