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

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

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

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

仮想データセンターとは

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

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

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

0

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

仮想データセンター (VDC) の実装には、クラウド内のアプリケーション ワークロード以上のものが含まれます。 また、ネットワーク、セキュリティ、管理、およびその他のインフラストラクチャ (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 は複数の種類の資格情報を認証に使います。これには、アカウントのパスワード、暗号化キー、デジタル署名、証明書が含まれます。 Azure Multi-Factor Authentication では、お客様が好みの方法を選択できる各種の簡単な確認オプション (電話、テキスト メッセージ、またはモバイル アプリ通知) による強力な認証を使用して、Azure サービスにアクセスするための追加のセキュリティ レイヤーが提供されます。

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

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

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

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

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

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

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

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

クラウドへの接続

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

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

企業によっては、仮想データセンターをオンプレミスのデータセンターや他のリソースに接続する必要があります。 この 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 StorageAzure SQL、パブリック エンドポイントを持つその他の統合されたパブリック サービスなど) を統合するためのアンカー ポイントでもあります。 サービス エンドポイントAzure Private Link を使用して、パブリック サービスをプライベート ネットワークと統合できます。 パブリック サービスをプライベートにすることもできますが、それでも Azure マネージド PaaS サービスのベネフィットを享受できます。

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

トポロジ

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

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

11

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

12

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

13

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

14

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

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

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

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

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

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

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

重要

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

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

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

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

2

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

スポーク間の相互接続

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

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

3

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

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

コンポーネント

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

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

4

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

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

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

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

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

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

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

5

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

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

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

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

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

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

6

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

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

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

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

  • ID とディレクトリ サービス。 Azure のすべてのリソース種類へのアクセスは、ディレクトリ サービスに格納された ID によって制御されます。 ディレクトリ サービスは、ユーザーのリストだけでなく、特定の Azure サブスクリプション内のリソースへのアクセス権も格納しています。 これらのサービスは、クラウドのみに存在することも、Active Directory に格納されたオンプレミスの ID と同期することもできます。
  • Virtual Network。 Virtual Network は、VDC の主要コンポーネントの 1 つであり、Azure プラットフォーム上にトラフィックの分離境界を作成できるようにします。 仮想ネットワークは、1 つまたは複数の仮想ネットワーク セグメントで構成され、それぞれが特定の IP ネットワーク プレフィックス (サブネット、IPv4 またはデュアルスタック IPv4/IPv6 のいずれか) を持ちます。 仮想ネットワークにより、IaaS 仮想マシンと PaaS サービスがプライベート通信を確立できる内部境界領域が定義されます。 ある仮想ネットワーク内のVM (および PaaS サービス) と異なる仮想ネットワーク内の VM (および PaaS サービス) は、両方の仮想ネットワークが同じお客様によって同じサブスクリプションの下で作成された場合でも、直接通信することはできません。 分離は、顧客の VM と通信が仮想ネットワーク内でプライベートであることを保証する重要な特性です。 ネットワーク間接続が必要な場合、以下の機能でそれをどのように実現できるかについて説明します。
  • 仮想ネットワーク ピアリング。 VDC のインフラストラクチャの作成に使用される基本的な機能は、仮想ネットワーク ピアリングです。これは、Azure データ センター ネットワーク経由、またはリージョンをまたがる Azure の世界規模のバックボーンを使用して、同じリージョンの 2 つの仮想ネットワークを接続します。
  • Virtual Network サービス エンドポイント。 サービス エンドポイントにより、PaaS 空間を含めるように、仮想ネットワークのプライベート アドレス空間が拡張されます。 さらに、このエンドポイントでは、仮想ネットワークの ID が直接接続を介して Azure サービスまで拡張されます。 エンドポイントを使用することで、重要な Azure サービス リソースへのアクセスを仮想ネットワークのみに限定することができます。
  • Private Link。 Azure Private Link を使用すると、仮想ネットワーク内のプライベート エンドポイント経由で Azure PaaS サービス ( Azure StorageAzure Cosmos DBAzure 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 リソースにアクセスするための組織のロールと権限をマップでき、ユーザーをアクションの特定のサブセットのみに制限できます。 Azure Active Directory をオンプレミスの Active Directory と同期している場合は、オンプレミスで使用しているものと同じ Active Directory グループを Azure で使用できます。 Azure RBAC では、関連するスコープ内のユーザー、グループ、アプリケーションに適切なロールを割り当てることで、アクセス権を付与できます。 ロール割り当てのスコープには、Azure サブスクリプション、リソース グループ、または単独のリソースを指定できます。 Azure RBAC では、アクセス許可を継承できます。 親スコープでロールが割り当てられると、その親に含まれる子へのアクセス権も付与されます。 Azure RBAC を使って、職務を分離し、職務の実行に必要なアクセス権のみをユーザーに付与することができます。 たとえば、ある従業員がサブスクリプションで仮想マシンを管理できる一方で、他の従業員が同じサブスクリプション内で SQL Server データベースを管理できます。

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

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

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

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

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

7

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

Note

上の図の DMZ Hub で、仮想ネットワーク、ユーザー定義ルート、ネットワーク セキュリティ グループ、VPN ゲートウェイ、ExpressRoute ゲートウェイ、Azure ロードバランサー、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 アプリケーションを保護します。 Application Gateway は、インターネット接続ゲートウェイ、または内部的にのみ使用されるゲートウェイのいずれかとして構成できるほか、この両方を組み合わせて使用することも可能です。

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

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

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

8

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

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

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

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

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

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

  • メトリックは、特定の時点におけるシステムの何らかの側面を表す数値です。 メトリックは軽量であり、リアルタイムに近いシナリオをサポートできます。 Azure Monitor が収集した多くの Azure リソースのデータは、Azure portal の [Overview]\(概要\) ページで参照できます。 たとえば、任意の仮想マシンを見てみると、パフォーマンス メトリックが表示されたいくつかのグラフが表示されます。 いずれかのグラフを選択すると、データが Azure portal のメトリック エクスプローラーで開かれ、複数のメトリックの値を時系列にグラフ化できます。 グラフは、対話形式で表示したり、ダッシュボードにピン留めして他の視覚化と一緒に表示したりできます。

  • ログには、種類ごとに異なるプロパティ セットを持つレコードに編成されたさまざまな種類のデータが含まれます。 イベントとトレースは、パフォーマンス データと共にログとして格納されます。これらはすべて分析のために組み合わせることができます。 Azure Monitor で収集したログ データは、収集データをすばやく取得、統合、分析するクエリを使用して分析できます。 ログは Log Analytics に格納され、そこからクエリが実行されます。 Azure portal で Log Analytics を使用してクエリを作成してテストした後、これらのツールを使用してデータを直接分析するか、クエリを保存して視覚化またはアラート ルールで利用できます。

9

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

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

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

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

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

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) メッセージング、パブリッシュとサブスクライブの機能が提供されます。

10

これらの例は、Azure で作成できるワークロードの種類のほんの一部を示しているにすぎません。基本的な Web および SQL アプリから、最新の IoT、ビッグ データ、Machine Learning、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 ManagerAzure Front Door の両方で、さまざまな VDC 実装内のリッスン エンドポイントのサービス正常性が定期的にチェックされ、これらのエンドポイントに障害が発生した場合は、次に最も近い VDC に自動的にルーティングされます。 Traffic Manager は、リアルタイムのユーザー測定と DNS を使用して、ユーザーを最も近いもの (または、障害時は次に最も近いもの) にルーティングします。 Azure Front Door は、100 個を超える Microsoft バックボーン エッジ サイトのリバース プロキシであり、エニーキャストを使用して最も近いリッスン エンドポイントにユーザーをルーティングします。

まとめ

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

References

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

次のステップ

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