仮想データセンター:ネットワーク パースペクティブ
オンプレミスから移行されたアプリケーションは、最小限のアプリケーション変更であっても、Azure のコスト効率の高い安全なインフラストラクチャのメリットを得られる場合があります。 企業は機敏性を向上させたり、Azure の機能を活用できるように、アーキテクチャを適合させる必要があります。
Microsoft Azure では、ハイパースケールのサービスとインフラストラクチャ、エンタープライズ レベルの機能と信頼性が提供されています。 これらのサービスとインフラストラクチャには、ハイブリッド接続に関する多数の選択肢が用意されているため、お客様はインターネットまたはプライベート ネットワーク接続経由でアクセスすることができます。 また、Microsoft のパートナーも、Azure で実行するために最適化されたセキュリティ サービスと仮想アプライアンスを用意して、強化された機能を提供できます。
Azure を使用すると、インフラストラクチャをクラウドにシームレスに拡張し、多層アーキテクチャを構築できます。
仮想データセンターとは
クラウドは、パブリック向けアプリケーションをホストするためのプラットフォームとして開始されました。 企業はクラウドの価値を認め、社内の基幹業務アプリケーションの移行を始めました。 これらのアプリケーションによってセキュリティ、信頼性、パフォーマンス、およびコストに関する考慮事項が増え、クラウド サービスの提供時に柔軟性がさらに必要とされました。 新しいインフラストラクチャとネットワーク サービスは、柔軟性を提供するように設計されています。 新機能では、柔軟なスケーリング、ディザスター リカバリーなどの配慮がなされています。
当初、クラウド ソリューションは、パブリック領域で単一の比較的独立したアプリケーションをホストするように設計され、数年間はうまく機能していました。 その後、クラウド ソリューションの利点が明らかになるにつれて、複数の大規模なワークロードがクラウドでホストされました。 セキュリティ、信頼性、パフォーマンス、コストなどの懸念に対応することは、クラウド サービスのデプロイとライフサイクルに不可欠です。
以下のクラウド配置ダイアグラムの例は、セキュリティ ギャップが赤枠で強調表示されています。 黄色の枠は、ワークロード間でネットワーク仮想アプライアンスを最適化する機会を示しています。
仮想データセンターは、エンタープライズ ワークロードに必要なスケールの実現に役立ちます。 このスケールは、パブリック クラウドで大規模なアプリケーションを実行するときに発生する課題に対処する必要があります。
仮想データセンターの実装には、クラウド内のアプリケーション ワークロード以上のものが含まれます。 また、ネットワーク、セキュリティ、管理、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 に自動的に同期できます。
特定の各部門、ユーザーのグループ、またはディレクトリ サービス内のサービスは、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 があります。 ワークロードからインターネットへのパケットも、ネットワークから送信される前に、境界ネットワーク内のセキュリティ アプライアンスを通過できます。 このフローにより、ポリシーの適用、検査、監査ができるようになります。
境界ネットワーク コンポーネントには次のものが含まれます。
- 仮想ネットワーク、ユーザー定義ルート、およびネットワーク セキュリティ グループ
- ネットワーク仮想アプライアンス
- Azure Load Balancer
- Azure Application Gateway と Web アプリケーション ファイアウォール (WAF)
- パブリック IP
- Azure Front Door と Web アプリケーション ファイアウォール (WAF)
- Azure Firewall と Azure Firewall Manager
- Standard の DDoS Protection
通常、中央 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
Monitoring
Network Watcher
Azure Monitor
Log Analytics
ベスト プラクティス
管理グループ
サブスクリプション管理
リソース グループ管理
Azure サブスクリプションの制限
次のステップ
- ハブ アンド スポーク トポロジの中核となるテクノロジである仮想ネットワーク ピアリングの詳細について確認します。
- Azure ロールベースのアクセス制御を使用するために Microsoft Entra ID を 実装します。
- 組織の構造、要件、ポリシーに適合する Azure ロールベースのアクセス制御を使用して、サブスクリプションおよびリソースの管理モデルを開発します。 最も重要なアクティビティは計画です。 再編成、合併、新しい製品ライン、およびその他の考慮事項が初期モデルに与える影響を分析し、将来のニーズと成長に合わせて調整できるようにします。