次の方法で共有

Azure でのミッション クリティカルなワークロードのネットワークと接続

  • [アーティクル]

推奨されるグローバルに分散されたアクティブ/アクティブな設計アプローチの下では、ネットワークはミッションクリティカルなアプリケーションを実現するための基本領域となります。

この設計領域では、アプリケーション レベルでのさまざまなネットワーク トポロジのトピックについて調べ、必要な接続と冗長トラフィック管理を検討します。 具体的には、ミッションクリティカルなアプリケーションのための安全でスケーラブルなグローバル ネットワーク トポロジの設計のヒントを与えることを目的としたクリティカルな考慮事項と推奨事項に焦点を当てます。

重要

この記事は、Azure Well-Architected のミッション クリティカルなワークロード シリーズの一部です。 このシリーズに慣れていない場合は、「ミッション クリティカルなワークロードとは何ですか?」から始めることをお勧めします。

グローバル トラフィック ルーティング

複数のアクティブなリージョン デプロイ スタンプを使用するには、各アクティブ スタンプにトラフィックを分散するグローバル ルーティング サービスが必要になります。

Azure Front Door、Azure Traffic Manager、Azure Standard Load Balancer は、マルチリージョン アプリケーション全体のグローバル トラフィックを管理するために必要なルーティング機能を提供します。

代わりに、サード パーティのグローバル ルーティング テクノロジを検討することもできます。 これらの選択肢は、Azure ネイティブ グローバル ルーティング サービスの使用を置き換えたり拡張したりするために、ほぼシームレスにスワップインできます。 一般的な選択肢としては、CDN プロバイダーによるルーティング テクノロジがあります。

このセクションでは、Azure ルーティング サービスの主な違いについて調べ、さまざまなシナリオを最適化するためにそれぞれをどのように使用できるのかを明確にします。

設計上の考慮事項

  • 1 つのリージョンにバインドされたルーティング サービスは、単一障害点とリージョンの停止に関する重大なリスクを表します。

  • アプリケーション ワークロードにモバイルまたはデスクトップ クライアント アプリケーションなどのクライアント制御が含まれている場合は、クライアント ルーティング ロジック内にサービスの冗長性を備えることができます。

    • Azure Front Door や Azure Traffic Manager などの複数のグローバル ルーティング テクノロジに対しては、冗長性に関する検討を並行して行うことができます。クライアントは、特定の障害条件が満たされたときに代替テクノロジにフェールオーバーするように構成されます。 複数のグローバル ルーティング サービスの導入により、エッジ キャッシュと Web Application Firewall の機能、および SSL オフロードの証明書管理とイングレス パスのアプリケーション検証に関する複雑性が大幅に増します。
    • すべてのレベルの Azure プラットフォーム障害に対するグローバル ルーティングの回復性を提供するために、サード パーティ テクノロジを検討することもできます。

  • Azure Front Door と Traffic Manager には機能の違いがあることから、冗長性を目的として 2 つのテクノロジを並置する場合、一貫性のある許容可能なレベルのサービスを維持するためには、異なるイングレス パスまたは設計の変更が必要になります。

  • Azure Front Door と Azure Traffic Manager は、マルチリージョンの冗長性と可用性が組み込まれたグローバル分散サービスです。

    • これらの回復性があるルーティング サービスのグローバルな可用性を脅かすのに十分な大きさのスケールの仮説的な障害シナリオは、カスケード障害と相関障害の観点からアプリケーションにとっての広範なリスクを提示します。
      • このスケールの障害シナリオが発生する可能性があるのは、ほぼすべての Azure サービスのグローバル プラットフォームの依存関係として機能する Azure DNS や Microsoft Entra ID などの共有されている基本サービスが原因の場合だけです。 冗長な Azure テクノロジが適用されている場合は、セカンダリ サービスでも利用不可能な状態やデグレードしたサービスが発生する可能性が高くなります。
      • グローバル ルーティング サービスの障害シナリオは、サービス間の依存関係を通じて主要なアプリケーション コンポーネントに使用される他の多くのサービスに大きな影響を与える可能性が極めて高いと言えます。 サード パーティ テクノロジが使用されている場合でも、根本的な問題の幅広い影響によってアプリケーションは異常な状態になる可能性が高いと言えます。つまり、Azure 上のアプリケーション エンドポイントへのルーティングは、いずれにしろあまり意味がないということです。

  • グローバル ルーティング サービスの冗長性が軽減策を提供できるのは、グローバルな停止の影響がそのルーティング サービス自体に制限されるという非常に数の少ない仮説的な障害シナリオに対してだけです。

    グローバルな停止のシナリオに対してより広範な冗長性を提供するために、マルチクラウドのアクティブ/アクティブのデプロイ アプローチを検討することができます。 マルチクラウドのアクティブ/アクティブのデプロイ アプローチは運用上の大きな複雑性をもたらし、それによって仮説的なグローバルな停止のリスクをはるかに上回る重大な回復性に関するリスクが生じることになります。

  • クライアント制御ができないシナリオでは、すべてのアクティブなデプロイ リージョンに統合されたエントリ ポイントを提供するため、1 つのグローバル ルーティング サービスに依存関係を設定する必要があります。

    • これらは、独立して使用されると、グローバルな依存関係が原因でサービス レベルの単一障害点となります。これは組み込みのマルチリージョンの冗長性と可用性が提供されている場合でも同様です。
    • 選択したグローバル ルーティング サービスによって提供される SLA は、考慮されるデプロイ リージョンの数に関係なく、達成可能な複合 SLO の最大値を表します。

  • クライアント コントロールが不可能な場合、運用上の軽減策は、グローバルな停止によってプライマリ サービスが無効になった場合のセカンダリ グローバル ルーティング サービスへの移行のプロセスを定義するものと考えることができます。 1 つのグローバル ルーティング サービスから別のグローバル ルーティング サービスへの移行は、通常は数時間続く長いプロセスであり、これは DNS 伝播を考慮するとなおさらです。

  • 一部のサード パーティのグローバル ルーティング サービスは、100% の SLA を提供しています。 しかし、これらのサービスによって過去に実際に提供された SLA は通常、100% を下回ります。

    • これらのサービスは利用不能に対する金銭的な補償を提供していますが、これは最終的には人命に関わる安全性が重要となるような利用不能性の影響が大きい場合にはほとんど意味がありません。 そのため、宣伝されている文面上の SLA が 100% の場合でも、テクノロジの冗長性または十分な運用上の軽減策を検討する必要があります。

Azure Front Door

  • Azure Front Door では、Microsoft グローバル バックボーン ネットワークを活用するために、TCP を分割した Anycast プロトコルを使用して、グローバル HTTP/S 負荷分散と最適化された接続が実現します。

    • 各バックエンド エンドポイントに対する接続数が維持されます。
    • 受信クライアント要求は、まず送信元クライアントに最も近いエッジ ノードで止められます。
    • 必要なトラフィック検査の後、要求は既存の接続を使用して Microsoft バックボーン経由で適切なバックエンドに転送されるか、エッジ ノードの内部キャッシュから応答が返されます。
    • このアプローチは、バックエンド接続経由で大量のトラフィックを送信する場合に効率的です。

  • エッジ ノードから静的コンテンツを提供する組み込みキャッシュを提供します。 これは、多くのユース ケースにおいて、専用の Content Delivery Network (CDN) の必要性をなくすことにもつながります。

  • Azure Web Application Firewall (WAF) は Azure Front Door 上で使用でき、これは世界中の Azure ネットワーク エッジの場所にデプロイされるため、Front Door によって配信されるすべての受信要求はネットワーク エッジで検査されます。

  • Azure Front Door は、Azure DDoS Protection Basic を使用して DDoS 攻撃からアプリケーション エンドポイントを保護します。 Azure DDoS Standard は、その他のより高度な保護機能と検出機能を提供し、Azure Front Door に対する追加レイヤーとして追加できます。

  • Azure Front Door は、フル マネージドの証明書サービスを提供します。 証明書ライフサイクルを管理する必要のないエンドポイントの TLS 接続セキュリティを実現します。

  • Azure Front Door Premium はプライベート エンドポイントをサポートし、トラフィックがインターネットから直接 Azure 仮想ネットワークへと流れることを可能にします。 これにより、Azure Front Door Premium 経由でバックエンドにアクセスできるようにするための VNet 上でのパブリック IP の使用の必要がなくなります。

  • Azure Front Door は、正常性プローブと一定間隔で呼び出されるバックエンド正常性エンドポイント (URL) を利用して、バックエンドが通常通り動作しているかを反映する HTTP 状態コードを返します。HTTP 200 (OK) 応答は正常な状態を表します。 特定のエッジ ノードの観点から、バックエンドが異常な状態を示すとすぐに、そのエッジ ノードはそこからの要求の送信を停止します。 したがって、異常なバックエンドは、遅延なしでトラフィックの流れから透過的に削除されます。

  • HTTP/S プロトコルのみをサポートします。

  • Azure Front Door WAF と Application Gateway WAF が提供する機能セットはわずかに異なりますが、どちらも組み込みルールとカスタム ルールをサポートし、検出モードと防止モードのどちらかで動作するように設定できます。

  • Front Door のバックエンド IP 空間は変更される可能性がありますが、Microsoft は Azure IP 範囲とサービス タグとの統合を保証します。 Azure IP 範囲とサービス タグにサブスクライブして、変更や更新に関する通知を受け取ることができます。

  • Azure Front Door は、以下に示すようにさまざまな負荷分散構成をサポートしています。

    • 待機時間ベース: 要求の待機時間に基づいて、クライアントから "最も近い" バックエンドにトラフィックをルーティングする既定の設定。
    • 優先度ベース: プライマリ バックエンドが利用不可能でない限りは、常にプライマリ バックエンドにトラフィックを送信する必要があるアクティブ/パッシブのセットアップに適しています。
    • 重み付け: 特定の割合のトラフィックが特定のバックエンドに送信されるカナリア デプロイに適用されます。 複数のバックエンドに同じ重みが割り当てられている場合は、待機時間ベースのルーティングが使用されます。

  • 既定では、Azure Front Door は待機時間ベースのルーティングを使用し、クライアントの発信元によっては、一部のバックエンドが他のバックエンドよりもずっと多くの受信トラフィックを受け取ることになる可能性があります。

  • 一連のクライアント要求を同じバックエンドで処理する必要がある場合は、フロントエンドでセッション アフィニティを構成できます。 これはクライアント側の Cookie を使用して、バックエンドがまだ利用可能な場合に、最初の要求と同じバックエンドに後続の要求を送信します。

Azure の Traffic Manager

  • Azure Traffic Manager は、DNS リダイレクト サービスです。

    • 実際の要求ペイロードは処理されない代わりに、Traffic Manager は選択されたトラフィック ルーティング方法に対して構成されたルールに基づいて、プール内のバックエンドの 1 つの DNS 名を返します。
    • その後、バックエンド DNS 名は、クライアントによって直接呼び出される最終的な IP アドレスに解決されます。

  • DNS 応答は、指定された Time-To-Live (TTL) 期間にわたってクライアントによってキャッシュおよび再利用され、この期間中に行われた要求は、Traffic Manager の介入なしでバックエンド エンドポイントに直接送信されます。 追加の接続手順を排除することで、Front Door と比較した場合のコスト上の利点を提供します。

  • 要求はクライアントからバックエンド サービスに対して直接実行されるため、バックエンドによってサポートされているプロトコルはすべて利用できます。

  • Azure Front Door と同様に、Azure Traffic Manager もバックエンドが正常で通常通り動作しているかどうかを把握するために正常性プローブを利用します。 別の値が返されたり、何も返されない場合、ルーティング サービスは問題が発生していることを認識し、その特定のバックエンドへの要求のルーティングを停止します。

    • ただし、クライアントは DNS TTL の有効期限が切れ、Traffic Manager サービスから新しいバックエンド エンドポイントが要求されるまで異常なバックエンドへの接続の作成を続けるため、Azure Front Door とは異なり、この異常なバックエンドの削除は即座には行われません。
    • さらに、TTL が期限切れになった場合でも、パブリック DNS サーバーがこの値を尊重するという保証はないため、DNS 伝播には実際には長い時間がかかる可能性があります。 これは、トラフィックが一定期間、異常なエンドポイントに送信され続ける可能性があることを意味します。

Azure Standard Load Balancer

重要

Cross-Region Standard Load Balancer は、技術的な制限付きのプレビューとして利用可能です。 この選択肢は、ミッションクリティカルなワークロードには推奨されません。

設計の推奨事項

  • HTTP/S シナリオのプライマリ グローバル トラフィック ルーティング サービスとして Azure Front Door を使用します。 Azure Front Door は、最適化されたトラフィック ルーティング、透過的なフェールオーバー、プライベート バックエンド エンドポイント (Premium SKU を使用)、エッジ キャッシュ、Web Application Firewall (WAF) との統合を提供するため、HTTP/S ワークロードでは強く推奨されます。

  • クライアント制御が可能なアプリケーション シナリオでは、クライアント側のルーティング ロジックを適用して、プライマリ グローバル ルーティング テクノロジが失敗するフェールオーバー シナリオを検討してください。 1 つのサービス SLA では十分でない場合は、冗長性を強化するために、2 つ以上のグローバル ルーティング テクノロジを並列に配置する必要があります。 グローバルなサービス障害が発生した場合に冗長なテクノロジにルーティングするには、クライアント ロジックが必要です。

    • 全体的な証明書管理エクスペリエンスとフェールオーバーのためのルーティング ロジックを簡略化するために、異なるグローバル ルーティング サービスのそれぞれに 1 つずつを適用するために、2 つの個別の URL を使用する必要があります。
    • セカンダリ フェールオーバー サービスとしてはサード パーティのルーティング テクノロジの使用を優先します。これにより最も数が多いグローバルな障害のシナリオが軽減され、業界をリードする CDN プロバイダーによって提供される機能によって一貫した設計アプローチが可能になります。
    • また、個別のルーティング サービスではなく、単一のリージョン スタンプへの直接的なルーティングについても検討する必要があります。 これによりサービスのレベルは低下することになりますが、設計のアプローチははるかにシンプルになります。

次の図は、冗長なグローバル ロード バランサー構成とプライマリ グローバル ロード バランサーとして Azure Front Door を使用するクライアント フェールオーバーを示しています。

ミッションクリティカルなグローバル ロード バランサー構成

重要

Azure プラットフォーム内でのグローバルな障害のリスクを真に軽減するには、2 つ以上のクラウド プロバイダー上でホストされるアクティブなデプロイ スタンプと、グローバル ルーティングに使用される冗長なサード パーティのルーティング テクノロジを備えたマルチクラウドのアクティブ/アクティブのデプロイ アプローチを検討する必要があります。

Azure は、他のクラウド プラットフォームと効果的に統合できます。 しかし、マルチクラウド アプローチはさまざまなデプロイ スタンプ定義と、異なるクラウド プラットフォーム上での運用の正常性の表現によって、運用上の複雑性をもたらすため、このアプローチは適用しないことが強く推奨されます。 逆にこの複雑性は、グローバル プラットフォームの停止という仮説的なリスクをはるかに上回るアプリケーションの通常の運用内での膨大な回復性に関するリスクをもたらします。

  • 推奨はされませんが、Azure Front Door へのグローバル ルーティング冗長性のために Azure Traffic Manager を使用する HTTP(s) ワークロードでは、Azure Front Door を通過する許容可能なトラフィックのために Web Application Firewall (WAF) を Application Gateway にオフロードすることを検討してください。
    • これにより、標準のイングレス パスに対する追加の障害点と、管理とスケーリングを行うべき追加のクリティカルパス コンポーネントが導入され、グローバルな高可用性を確保するための追加コストも発生することになります。 しかし、これは Azure Front Door と Azure Traffic Manager を通して、WAF の実行だけでなくプライベート アプリケーション エンドポイントの観点からも、許容可能なイングレス パスと許容できないイングレス パスの間の一貫性を提供することで、障害シナリオを大幅に簡略化します。
    • 障害シナリオでのエッジ キャッシュの喪失は全体的なパフォーマンスに影響を与えるため、これは許容できるサービスのレベルまたは軽減設計アプローチと合致する必要があります。 一貫性のあるサービスのレベルを確保するには、両方のパスで、エッジ キャッシュをサード パーティ CDN プロバイダーにオフロードすることを検討してください。

2 つの Azure グローバル ルーティング サービスの代わりに、サードパーティーのグローバル ルーティング サービスを検討することをお勧めします。 業界をリードするほとんどの CDN プロバイダーは、Azure Front Door で提供されるものとほぼ同じエッジ機能を提供するため、最大レベルの障害軽減策とよりシンプルな設計アプローチが提供されます。

Azure Front Door

  • Azure Front Door マネージド証明書サービスを使用して TLS 接続を有効にし、証明書のライフサイクルを管理する必要をなくします。

  • Azure Front Door Web Application Firewall (WAF) を使用して、SQL インジェクションなどの一般的な Web の悪用や脆弱性からの保護をエッジで提供します。

  • Azure Front Door の組み込みキャッシュを使用して、エッジ ノードから静的コンテンツを提供します。

    • ほとんどの場合、これによって専用の Content Delivery Network (CDN) の必要もなくなります。

  • X-Azure-FDID を使用するヘッダー ベースのフィルタリングを通して受信要求を検証するようにアプリケーション プラットフォームのイングレス ポイントを構成して、すべてのトラフィックが構成された Front Door インスタンスを通過するようにします。 また、Front Door サービス タグを使用する IP ACLing を構成して、トラフィックが Azure Front Door バックエンド IP アドレス空間と Azure インフラストラクチャ サービスからのものであることを検証します。 これにより、トラフィックが Azure Front Door を通過して流れることがサービス レベルで保証されますが、構成された Front Door インスタンスの使用を確認するにはヘッダー ベース フィルタリングも必要になります。

  • カスタム TCP 正常性エンドポイントを定義して、基本的なリファレンス実装によって提供される例内の Azure Cosmos DB など、データ プラットフォーム レプリカを含むリージョン デプロイ スタンプ内の重要なダウンストリーム依存関係を検証します。 1 つ以上の依存関係が異常になった場合、正常性プローブは返される応答内でこれを反映して、リージョン スタンプ全体を循環から取り出すことができるようにする必要があります。

  • アプリケーション全体での統合されたデータ シンクと単一の運用ビューを実現するために、正常性プローブの応答がログされ、Azure Front Door によって公開されているすべての運用データをグローバルな Log Analytics ワークスペースに取り込んでいることを確認します。

  • ワークロードが極端に待機時間の影響を受けやすい場合を除き、デプロイされたリソースを最も効果的に使用するために、考えられるリージョン スタンプのすべてにトラフィックを均等に分散させます。

    • これを実現するには、"待機時間感度 (追加待機時間)" パラメーターを、バックエンドのさまざまなリージョン間の待機時間の違いに対応するのに十分な高い値に設定します。 全体的なクライアント要求の待機時間の観点から、アプリケーション ワークロードにとって受け入れられる許容範囲を確保します。

  • セッション アフィニティは、アプリケーションで必要な場合を除き、有効にしないでください。これは、トラフィック分散のバランスに悪影響を及ぼす可能性があります。 完全にステートレスなアプリケーションでは、ミッションクリティカルなアプリケーションの推奨される設計アプローチに従えば、どんな要求もリージョン デプロイのいずれかで処理できます。

Azure の Traffic Manager

  • HTTP/S 以外のシナリオでは Azure Front Door の代わりに Traffic Manager を使用します。 機能の違いにより、キャッシュと WAF の機能と TLS 証明書の管理に関する設計上の決定に違いが生じます。

  • Traffic Manager イングレス パスの各リージョン内で、Azure Application Gateway を使用する WAF 機能を検討する必要があります。

  • バックエンドが異常になった場合に、異常なバックエンド エンドポイントを循環から削除するために必要な時間を最適化するために、適度に低い TTL 値を構成します。

  • Azure Front Door における場合と同様に、カスタム TCP 正常性エンドポイントを定義することで、リージョン デプロイ スタンプ内のクリティカルなダウンストリーム依存関係を検証する必要があります。これは、正常性エンドポイントによって提供される応答に反映される必要があります。

    ただし、Traffic Manager では、サービス レベルのリージョン フェールオーバーに対する追加の検討が必要になります。 これは、'dog legging' のように、依存関係の障害による異常なバックエンドの削除に関連して発生する可能性のある遅延を軽減するためであり、DNS レコードに対して低い TTL を設定できない場合は特に重要になります。

  • Azure Traffic Manager をプライマリ グローバル ルーティング サービスとして使用する場合は、エッジ キャッシュを実現するために、サード パーティ CDN プロバイダーを検討する必要があります。 サード パーティ サービスがエッジ WAF 機能も提供する場合は、イングレス パスを簡略化し、可能な場合は Application Gateway の必要性をなくすことを検討する必要があります。

アプリケーション配信サービス

ミッションクリティカルなアプリケーションのネットワーク イングレス パスでは、安全で、信頼性が高く、スケーラブルなイングレス トラフィックを確保するためのアプリケーション配信サービスも検討する必要があります。

このセクションでは、主要なアプリケーション配信機能を調べることによるグローバル ルーティングに関する推奨事項をメインとし、Azure Standard Load Balancer、Azure Application Gateway、Azure API Management などの関連サービスについて検討します。

設計上の考慮事項

  • TLS 暗号化は、ミッションクリティカルなアプリケーションへの受信ユーザー トラフィックの整合性を確保するために不可欠であり、TLS オフロードでは受信トラフィックの暗号化を解除するためにスタンプのイングレスの時点でのみ適用されます。 TLS オフロードでは、トラフィックを復号化するための TLS 証明書の秘密キーが必要です。

  • Web Application Firewall は、SQL インジェクションやクロス サイト スクリプティングなどの一般的な Web の悪用や脆弱性に対する保護を提供し、ミッションクリティカルなアプリケーションの望みうる最大限の信頼性を達成するために不可欠です。

  • Azure WAF は、マネージド ルール セットを使用して、上位 10 件の OWASP 脆弱性に対してすぐに使用できる保護を提供します。

    • カスタム ルールを追加することで、マネージド ルール セットを拡張することもできます。
    • Azure WAF は、Azure Front Door、Azure Application Gateway、Azure CDN (現状パブリック プレビュー段階) のいずれかの中で有効にすることができます。
      • 各サービスで提供される機能は若干異なります。 たとえば、Azure Front Door WAF はレート制限、ジオフィルタリング、ボット保護を提供しますが、これらは App Gateway WAF 内ではまだ提供されていません。 ただし、これらはすべて組み込みルールとカスタム ルールの両方をサポートしており、検出モードと防止モードのどちらかで動作するように設定できます。
      • Azure WAF のロードマップは、すべてのサービス統合で一貫性のある WAF 機能セットが提供されることを保証します。

  • 必要な脆弱性保護を提供するには、NVA などのサード パーティ WAF テクノロジや Kubernetes 内の高度なイングレス コントローラーなどを検討することもできます。

  • 使用されるテクノロジに関係なく、最適な WAF 構成には通常、微調整が必要となります。

    Azure Front Door

  • Azure Front Door は HTTP と HTTPS トラフィックのみを受け入れ、既知の Host ヘッダーを持つ要求のみを処理します。 このプロトコル ブロックは、複数のプロトコルとポートにわたるボリューム型攻撃、および DNS 増幅攻撃と TCP ポイズニング攻撃を軽減するのに役立ちます。

  • Azure Front Door はグローバルな Azure リソースであるため、構成はすべてのエッジの場所にグローバルにデプロイされます。

    • リソース構成を大規模に分散することで、1 秒あたり数十万の要求を処理できます。
    • 構成の更新は、ルートやバックエンド プールも含めてシームレスであり、デプロイ時のダウンタイムを発生させません。

  • Azure Front Door は、クライアント側の SSL 証明書に関してフル マネージド証明書サービスと独自の証明書持ち込み方法の両方を提供しています。 フル マネージド証明書サービスは、シンプルな運用アプローチを提供し、証明書管理をソリューションの単一領域内で実行することで全体的な設計の複雑さを軽減させます。

  • Azure Front Door は、証明書の有効期限が切れるリスクを回避するために、証明書の有効期限の少なくとも 60 日前に "マネージド" 証明書を自動ローテーションします。 セルフマネージド証明書を使用している場合は、既存の証明書の有効期限の 24 時間前までに更新された証明書をデプロイする必要があります。そうしないと、クライアントが証明書の有効期限切れのエラーを受け取る可能性があります。

  • 証明書の更新によってダウンタイムが発生するのは、Azure Front Door で "マネージド" と "独自の証明書の使用" を切り替える場合だけです。

  • Azure Front Door は、既定で Front Door に統合されている Azure DDoS Protection Basic によって保護されています。 これは、常時オンのトラフィック監視、リアルタイムの軽減策を提供するだけでなく、一般的なレイヤー 7 の DNS クエリ フラッドやレイヤー 3/4 のボリューム型攻撃に対する防御も提供します。

    • これらの保護は、DDoS 攻撃に直面した場合でも Azure Front Door の可用性を維持するのに役立ちます。 分散型サービス拒否 (DDoS) 攻撃は、不正なトラフィックでリソースを過負荷にすることで、ターゲットのリソースを利用できなくすることができます。

  • Azure Front Door はグローバル トラフィック レベルの WAF 機能も提供するのに対して、Application Gateway WAF は各リージョン デプロイ スタンプ内で提供される必要があります。 機能には、一般的な攻撃から保護するファイアウォール規則セット、ジオフィルタリング、アドレス ブロック、レート制限、署名照合が含まれます。

    Azure Load Balancer

  • Azure Basic Load Balancer SKU は SLA のサポート対象外であり、Standard SKU と比較していくつかの機能の制約があります。

設計の推奨事項

  • 証明書管理ライフサイクルをシンプルにしたままセキュリティを維持するために、できるだけ少ない場所で TLS オフロードを実行します。

  • TLS オフロードが発生するポイントから実際のアプリケーション バックエンドに対しては、暗号化された接続 (例: HTTPS) を使用します。 アプリケーション エンドポイントがエンド ユーザーの目に触れることはないため、azurewebsites.net や cloudapp.net などの Azure マネージド ドメインをマネージド証明書と共に使用できます。

  • HTTP(S) トラフィックに関しては、パブリックに公開されているすべてのエンドポイントのイングレス パス内で WAF 機能が適用されていることを確認します。

  • 1 つのサービスの場所で (Azure Front Door を使用してグローバルに、または Azure Application Gateway を使用してリージョン別に) WAF 機能を有効にします。これによって構成の微調整がシンプルになり、パフォーマンスとコストが最適化されます。

    攻撃を直接ブロックするように防止モードで WAF を構成してください。 防止モードのパフォーマンスの低下が大きすぎる場合は、検出モードでのみ WAF を使用してください (つまり、疑わしい要求はログしますが、ブロックはしません)。 暗黙的な追加のリスクを完全に理解し、ワークロード シナリオの特定の要件に完全に合わせて調整する必要があります。

  • 最も機能豊富な Azure ネイティブ機能セットを提供し、グローバル エッジで保護を適用する、Azure Front Door WAF の使用を優先してください。これにより、全体的な設計が簡素化され、さらに効率が向上します。

  • Azure API Management は、多数の API を外部クライアントまたは別のアプリケーション チームに公開する場合にのみ使用します。

  • マイクロサービス ワークロード内の内部トラフィック分散シナリオには、Azure Standard Load Balancer SKU を使用します。

    • Availability Zones にデプロイすると、99.99% という SLA が提供されます。
    • 診断やアウトバウンド規則などの重要な機能が提供されます。

  • Azure DDoS ネットワーク保護を使用して、各アプリケーション仮想ネットワーク内でホストされているパブリック エンドポイントを保護します。

キャッシュと静的コンテンツ配信

画像、JavaScript、CSS、その他のファイルなどの静的コンテンツの特別な扱いは、全体的なユーザー エクスペリエンスだけでなく、ソリューションの全体的なコストにも大きな影響を与える可能性があります。 エッジで静的コンテンツをキャッシュすることで、クライアントの読み込み時間を短縮できる可能性があり、これによってより良いユーザー エクスペリエンスがもたらされ、関連するバックエンド サービスでのトラフィック、読み取り操作、コンピューティング能力のコストが削減される可能性があります。

設計上の考慮事項

  • ソリューションがインターネット経由で公開するすべてのコンテンツが動的に生成されるわけではありません。 アプリケーションは、静的アセット (画像、JavaScript、CSS、ローカライズ ファイルなど) と動的コンテンツの両方を提供します。
  • キャッシュはバックエンド サービスの負荷を軽減し、エンド ユーザーにとってのコンテンツ アクセスの待機時間を短縮するため、頻繁にアクセスされる静的コンテンツを持つワークロードではキャッシュの利点が大いに生かせます。
  • キャッシュは、Azure Front Door または Azure Content Delivery Network (CDN) を使用して Azure 内でネイティブに実装できます。
    • Azure Front Door は、静的コンテンツと動的コンテンツを分割するための Azure ネイティブ エッジ キャッシュ機能とルーティング機能を提供します。
      • Azure Front Door 内に適切なルーティング ルールを作成することで、/static/* トラフィックを静的コンテンツに透過的にリダイレクトできます。
    • Azure CDN サービスを使用して、重要な静的コンテンツ ボリューム用の本格的なコンテンツ配信ネットワークを確立することで、より複雑なキャッシュのシナリオを実装することができます。
      • Azure CDN サービスは、コスト効率が高くなる可能性は高いですが、アプリケーション設計の他の領域で推奨される同等の高度なルーティングと Web Application Firewall (WAF) 機能は提供しません。 ただし、Akamai や Verizon などのサード パーティ ソリューションの同様のサービスと統合を行うための柔軟性は提供します。
    • Azure Front Door と Azure CDN サービスを比較する際には、以下の判断要因について確認する必要があります。
      • 必要なキャッシュ ルールをルール エンジンを使用して実現することができるかどうか。
      • 保存されるコンテンツのサイズと関連コスト。
      • ルール エンジンの実行に対する 1 か月あたりの価格 (Azure Front Door 上の要求ごとに課金されます)。
      • 送信トラフィックの要件 (価格は宛先によって異なります)。

設計の推奨事項

  • 画像ファイルのサイズ指定コピーなどの決して変更されない、またはまれにしか変更されない生成された静的コンテンツでもキャッシュの利点を生かすことができます。 キャッシュは、URL パラメーターに基づいて、さまざまなキャッシュ期間で構成できます。
  • ユーザーへのコンテンツの配信を静的と動的で区別し、関連するコンテンツをキャッシュから配信して、バックエンド サービスの負荷を軽減し、エンド ユーザーのパフォーマンスを最適化します。
  • グローバル ルーティングには Azure Front Door を使用するべきという強い推奨 (ネットワークと接続の設計領域) と Web Application Firewall (WAF) の目的を考慮すると、ギャップがない限りは Azure Front Door のキャッシュ機能の使用を優先することが推奨されます。

仮想ネットワークの統合

ミッションクリティカルなアプリケーションは通常、他のアプリケーションや依存システムとの統合の要件を含んでおり、これらは Azure、別のパブリック クラウド、またはオンプレミスのデータ センター上でホストされている可能性があります。 このアプリケーション統合は、ネットワークレベルの統合を通じて、公開エンドポイントとインターネット、またはプライベート ネットワークを使用して実現できます。 最終的に、アプリケーション統合を実現する方法は、ソリューションのセキュリティ、パフォーマンス、信頼性に大きな影響を与え、その他の設計領域内の設計上の判断に強い影響を与えます。

ミッションクリティカルなアプリケーションは、3 つの包括的なネットワーク構成のいずれかを使用してデプロイでき、これによってアプリケーション統合がネットワーク レベルでどのように行われるかが決まります。

  1. 企業ネットワーク接続を使用しないパブリック アプリケーション。
  2. 企業ネットワーク接続を使用するパブリック アプリケーション。
  3. 企業ネットワーク接続を使用するプライベート アプリケーション。

注意事項

Azure ランディング ゾーン内にデプロイする場合は、構成 1 はオンライン ランディング ゾーン内にデプロイする必要がありますが、2) と 3) はネットワークレベルの統合を促進するために企業に接続されたランディング ゾーン内にデプロイする必要があります。

このセクションでは、これらのネットワーク統合シナリオについて調べ、統合要件が最適に満たされるように、Azure 仮想ネットワークと関連する Azure ネットワーク サービスの適切な使用方法を確認します。

デザインに関する考慮事項

仮想ネットワークなし

  • 最もシンプルな設計アプローチは、仮想ネットワーク内にはアプリケーションをデプロイしないというものです。

    • 検討されるすべての Azure サービス間の接続は、完全にパブリック エンドポイントと Microsoft Azure バックボーンを介して提供されます。 Azure 上でホストされるパブリック エンドポイント間の接続は、Microsoft バックボーンのみを経由し、パブリック インターネットは経由しません。
    • Azure 外の外部システムへの接続は、パブリック インターネットによって提供されます。

  • この設計アプローチでは、さまざまなサービス コンポーネントと依存ソリューション間のアクセスの制御を提供するために、"セキュリティ境界としての ID" を採用します。 これは、セキュリティがそれほど重要とはならないシナリオで許容されるソリューションとなる可能性があります。 すべてのアプリケーション サービスと依存関係がパブリック エンドポイントを介してアクセスできることで、これらは未承認アクセスの取得を目指す攻撃ベクトルに対して脆弱になります。

  • この設計アプローチは、すべての Azure サービスに対して適用できるわけではありません。これは、AKS などの多くのサービスが基盤となる仮想ネットワークに関する厳しい要件を持っているためです。

隔離された仮想ネットワーク

  • 不要なパブリック エンドポイントに関連するリスクを軽減するために、アプリケーションを他のネットワークに接続されていないスタンドアロン ネットワーク内にデプロイすることができます。

  • 受信クライアント要求には、インターネットに公開されるパブリック エンドポイントが必要にはなりますが、それ以降のすべての通信は、プライベート エンドポイントを使用して仮想ネットワーク内で行うことができます。 Azure Front Door Premium を使用する場合は、エッジ ノードからプライベート アプリケーション エンドポイントに直接ルーティングを行うことが可能です。

  • アプリケーション コンポーネント間のプライベート接続は仮想ネットワーク経由で行われますが、外部依存関係を持つすべての接続は引き続きパブリック エンドポイントに依存します。

    • Azure プラットフォーム サービスへの接続はプライベート エンドポイントを使用して確立することができます (サポートされている場合)。 別のダウンストリーム アプリケーションなど、他の外部依存関係が Azure 上に存在する場合、接続はパブリック エンドポイントと Microsoft Azure バックボーンを介して提供されます。
    • Azure 外の外部システムへの接続は、パブリック インターネットによって提供されることになります。

  • 外部依存関係に関するネットワーク統合要件がないシナリオでは、隔離されたネットワーク環境内にソリューションをデプロイすることで、設計の柔軟性を最大限に高めることができます。 より広範なネットワーク統合に付随するアドレス指定とルーティングの制約はなくなります。

  • Azure Bastion は、仮想ネットワーク上にデプロイでき、Azure VM への安全な RDP/SSH 接続を提供するフル プラットフォーム マネージド PaaS サービスです。 Azure Bastion 経由で接続する場合、仮想マシンにパブリック IP アドレスは必要ありません。

  • アプリケーション仮想ネットワークの使用は、CI/CD パイプライン内でかなりのデプロイの複雑性をもたらします。これは、アプリケーションのデプロイを容易にするには、プライベート ネットワークでホストされているリソースへのデータ プレーンとコントロール プレーンの両方のアクセスが必要になるためです。

    • CI/CD ツールが必要なアクションを実行できるようにするには、安全なプライベート ネットワーク パスを確立する必要があります。
    • プライベート ビルド エージェントをアプリケーション仮想ネットワーク内にデプロイすることで、仮想ネットワークによってセキュリティ保護されたリソースへのアクセスをプロキシ経由にすることができます。

接続された仮想ネットワーク

  • 外部ネットワーク統合の要件があるシナリオでは、さまざまな接続オプションを使用して、アプリケーション仮想ネットワークを Azure 内の他の仮想ネットワーク、別のクラウド プロバイダー、またはオンプレミス ネットワークに接続できます。 たとえば、一部のアプリケーション シナリオでは、オンプレミスの企業ネットワーク内でプライベートにホストされている他の基幹業務アプリケーションとのアプリケーションレベルの統合が検討されるかもしれません。

  • このアプリケーション ネットワーク設計は、特にアドレス指定やルーティングなどのトピックに関して、より広範なネットワーク アーキテクチャの方針に沿うものである必要があります。

  • ネットワーク統合が検討される場合、複数の Azure リージョンまたはオンプレミス ネットワーク上の重複する IP アドレス空間は、大きな衝突を引き起こします。

    • 仮想ネットワーク リソースは、追加のアドレス空間を考慮するように更新できますが、ピアリングされたネットワークの仮想ネットワーク アドレス空間が変更されると、ピアリング リンク上の同期が必要になり、これによってピアリングが一時的に無効になります。
    • Azure は各サブネットで 5 つの IP アドレスを予約しており、アプリケーション仮想ネットワークと包含サブネットに適したサイズを決定する際にはこれを考慮する必要があります。
    • Azure Bastion、Azure Firewall、Azure Virtual Network Gateway などの一部の Azure サービスには専用サブネットが必要になります。 これらのサービス サブネットは、将来のスケール要件を考慮しつつ、サービスの現在のインスタンスすべてをサポートするのに十分な大きさではあっても、アドレスを無駄に浪費するほどは大きくないようにする必要があるため、そのサイズは非常に重要です。

  • オンプレミスまたはクラウド間のネットワーク統合が必要な場合、Azure には、安全な接続を確立するための 2 つの異なるソリューションが用意されています。

    • ExpressRoute 回線は、最大 100 Gbps の帯域幅を提供するようにサイズ設定できます。
    • 仮想プライベート ネットワーク (VPN) は、ハブ アンド スポーク ネットワークでは最大 10 Gbps、Azure Virtual WAN では最大 20 Gbps の合計帯域幅を提供するようにサイズ設定できます。

Note

Azure ランディング ゾーン内でのデプロイを行う場合は、必要なオンプレミス ネットワークへの接続はすべてランディング ゾーンの実装によって提供する必要があることに注意してください。 この設計では、Virtual WAN またはハブ アンド スポーク ネットワーク設計を使用して、ExpressRoute や Azure 内のその他の仮想ネットワークを使用できます。

  • 追加のネットワーク パスとリソースを含めることで、アプリケーションが正常性を維持できるようにするための信頼性と運用上の考慮事項が増えることになります。

設計の推奨事項

  • ミッション クリティカルなソリューションを可能な限り Azure 仮想ネットワーク内にデプロイして不要なパブリック エンドポイントを削除し、アプリケーション攻撃面を制限してセキュリティと信頼性を最大化することをお勧めします。

    • Azure プラットフォーム サービスへの接続にはプライベート エンドポイントを使用します。 データ流出リスクが許容される、または代替制御を通して軽減される場合は、Private Link をサポートしていないサービスに対してサービス エンドポイントを検討することができます。

  • 企業ネットワーク接続を必要としないアプリケーション シナリオでは、すべての仮想ネットワークを、新しいリージョン デプロイの実行時に置き換えられるエフェメラルなリソースとして扱います。

  • 他の Azure またはオンプレミス ネットワークに接続する場合、アプリケーション仮想ネットワークはエフェメラルとして扱うべきではありません。それによって仮想ネットワーク ピアリングと仮想ネットワーク ゲートウェイ リソースが関係する箇所で大きな複雑性が発生するためです。 仮想ネットワーク内の関連アプリケーション リソースはすべてエフェメラルなままに保ち、更新されたリージョン デプロイ スタンプのブルーグリーン デプロイを実現するために並列サブネットを使用する必要があります。

  • プライベート ネットワーク経由でのアプリケーション統合を容易にするために企業ネットワーク接続が必要なシナリオでは、リージョン アプリケーション仮想ネットワークに使用される IPv4 アドレス空間が他の接続ネットワークと重複しないようにし、仮想ネットワーク リソースを更新してダウンタイムを発生させることなく、必要なスケーリングを容易にするために適切なサイズになるようにしてください。

    • プライベート インターネット (RFC 1918) 用のアドレス割り当てからの IP アドレスのみを使用することが強く推奨されます。
      • 利用できるプライベート IP アドレス (RFC 1918) に制限がある環境では、IPv6 の使用を検討します。
      • パブリック IP アドレスの使用が必要な場合は、所有されているアドレス ブロックのみが使用されていることを確認します。
    • Azure 内の IP アドレス指定に関する組織計画に合わせて、アプリケーション ネットワーク IP アドレス空間がオンプレミスの場所または Azure リージョン上の他のネットワークと重複しないようにします。
    • IP アドレス空間が無駄にならないよう、不必要に大きなアプリケーション仮想ネットワークは作成しないでください。

  • Azure CNI はよりリッチな機能セットをサポートするため、AKS ネットワーク統合ではこれの使用を優先します。

    • アプリケーションを制限されたアドレス空間内に収めるため、利用可能な IP アドレスの範囲が限られているシナリオでは Kubenet を検討します。

    • AKS ネットワーク統合には Azure CNI ネットワーク プラグインの使用を優先し、利用可能な IP アドレスの範囲が限られているシナリオでは Kubenet を検討します。 詳細については、「マイクロセグメント化と Kubernetes ネットワーク ポリシー」を参照してください。

  • オンプレミスのネットワーク統合が必要なシナリオでは、安全でスケーラブルな接続を確保するために Express Route の使用を優先します。

    • Express Route または VPN に適用される信頼性レベルがアプリケーション要件を完全に満たしていることを確認します。
    • 必要な場合に追加の冗長性を提供するには、クロス接続された ExpressRoute 回線や、フェールオーバー接続メカニズムとしての VPN の使用など、複数のネットワーク パスを考慮する必要があります。

  • クリティカルなネットワーク パス上のすべてのコンポーネントが、関連するユーザー フローの信頼性と可用性の要件に合うものであることを確認します。この際、これらのパスと関連コンポーネントの管理が中央 IT チームのアプリケーション チームによって提供されているかどうかは関係ありません。

    Note

    Azure ランディング ゾーン内へのデプロイと、より広範な組織のネットワーク トポロジとの統合を行う場合は、基盤ネットワークを Microsoft のベストプラクティスに準拠させるためのネットワーク ガイダンスを検討します。

  • Azure リソースのデータ プレーンにアクセスしたり管理操作を実行するには、Azure Bastion またはプロキシされたプライベート接続を使用します。

インターネット エグレス

インターネット エグレスは、ミッションクリティカルなアプリケーションが以下のコンテキストで外部通信を行うための基本的なネットワーク要件です。

  1. 直接的なアプリケーション ユーザー操作。
  2. Azure 外の外部依存関係とのアプリケーション統合。
  3. アプリケーションで使用される Azure サービスに必要な外部依存関係へのアクセス。

このセクションでは、セキュリティ、信頼性、持続可能なパフォーマンスを確保しながらインターネット エグレスを実現する方法について調べ、ミッションクリティカルなコンテキストで推奨されるサービスの主要なエグレス要件を明らかにします。

デザインに関する考慮事項

  • 多くの Azure サービスは、さまざまな管理機能とコントロール プレーン機能が意図通りに動作するために、パブリック エンドポイントへのアクセスを必要とします。

  • Azure は、仮想マシンまたは仮想ネットワーク上のコンピューティング インスタンスに対して、Azure NAT Gateway や Azure Load Balancer などのさまざまな直接的なインターネット送信接続方法を提供しています。

  • 仮想ネットワーク内からのトラフィックがインターネットに送信される際には、ネットワーク アドレス変換 (NAT) が実行される必要があります。 これは、ネットワーク スタック内で発生するためシステム パフォーマンスに影響を与える可能性があるコンピューティング操作です。

  • NAT が小規模で実行される場合、パフォーマンスへの影響はごくわずかなはずですが、送信要求の数が多い場合は、ネットワークの問題が発生する可能性があります。 これらの問題は通常、'ソース NAT (または SNAT) ポートの枯渇" という形で現れます。

  • Azure App Service などのマルチテナント環境では、各インスタンスが利用できる送信ポートの数は限られています。 これらのポートが枯渇すると、新しい送信接続を開始できなくなります。 この問題は、プライベート/パブリック エッジ トラバーサルの数を減らすか、Azure NAT Gateway などのよりスケーラブルな NAT ソリューションを使用することで軽減できます。

  • 送信トラフィックは、NAT の制限に加えて、必要なセキュリティ検査の影響も受ける場合があります。

    • Azure Firewall は、ネットワーク エグレスをセキュリティで保護するために適切なセキュリティ機能を提供します。

    • Azure Firewall (または同等の NVA) は送信トラフィック フローの細かい制御を提供するため、Kubernetes エグレス要件を満たすために使用できます。

  • 大量のインターネット エグレスは、データ転送料金を発生させます。

Azure NAT Gateway

  • Azure NAT Gateway がサポートする割り当て送信 IP アドレスごとの TCP と UDP の接続数は 64,000 個です。

    • 1 つの NAT ゲートウェイに対して最大 16 個の IP アドレスを割り当てることができます。
    • 既定の TCP アイドル タイムアウトは 4 分です。 アイドル タイムアウトが大きい値に変更されると、フローはより長く保持され、これによって SNAT ポート インベントリの負荷が増加します。

  • NAT ゲートウェイでは、すぐに利用可能なゾーン分離を提供できません。 ゾーン冗長を取得するには、ゾーン リソースを含むサブネットを、対応するゾーン NAT ゲートウェイと一致させる必要があります。

設計の推奨事項

  • 送信インターネット接続の数は NAT パフォーマンスに影響を与えるため、最小限に抑えます。

    • 多数のインターネットにバインドされた接続が必要な場合は、Azure NAT Gateway を使用して送信トラフィック フローを抽象化することを検討します。

  • 送信インターネット トラフィックを制御して検査するための要件が存在する場合は、Azure Firewall を使用します。

    • Azure Firewall が Azure サービス間のトラフィックを検査するためには使用されていないことを確認します。

Note

Azure ランディング ゾーン内でデプロイを行う場合は、基盤プラットフォームの Azure Firewall リソース (または同等の NVA) の使用を検討します。 インターネット エグレス用の中央プラットフォーム リソースに依存関係がある場合、そのリソースと関連するネットワーク パスの信頼性レベルは、アプリケーション要件にしっかり合うものである必要があります。 障害シナリオで起こり得る運用アクションを知らせるために、このリソースからの運用データはアプリケーションでも利用できるようにする必要があります。

送信トラフィックに関連する大規模な要件がある場合は、うるさい隣人のシナリオなどの中央で共有されたリソースの使用に関連するリスクを軽減するために、ミッションクリティカルなアプリケーション用の専用の Azure Firewall リソースを検討する必要があります。

  • Virtual WAN 環境内にデプロイする場合は、グローバル ファイアウォール ポリシーを通して組織のセキュリティ態勢が監視されるようにするために、専用のアプリケーション Azure Firewall インスタンスを一元管理するための Firewall Manager を検討する必要があります。
  • アプリケーション ポリシーの自律性を実現するために、増分ファイアウォール ポリシーが、ロールベースのアクセス制御を介してアプリケーション セキュリティ チームに委任されていることを確認します。

ゾーン間とリージョン間の接続

アプリケーション設計では独立したリージョン デプロイ スタンプを強く推奨していますが、多くのアプリケーション シナリオでは、サービスが低下している状況でも、異なるゾーンまたは Azure リージョン内にデプロイされたアプリケーション コンポーネント間のネットワーク統合が引き続き必要になる場合があります。 ゾーン間とリージョン間の通信を実現する方法は、全体的なパフォーマンスと信頼性に大きな影響を与えます。このセクションの考慮事項と推奨事項ではこれについて確認します。

デザインに関する考慮事項

  • ミッションクリティカルなアプリケーションのアプリケーション設計アプローチでは、単一リージョン内のすべてのコンポーネント レベルでゾーン冗長を適用した独立したリージョン デプロイの使用が推奨されています。

  • 可用性ゾーン (AZ) は、Azure リージョン内の物理的に隔離されたデータ センターの場所であり、単一データ センターのレベルまでの物理的および論理的な障害分離を提供します。

    ゾーン間通信では、2 ミリ秒未満のラウンドトリップ待機時間が保証されます。 ゾーン間の距離とファイバー パスがさまざまであることから、ゾーンの待機時間にはわずかな差異が存在します。

  • 可用性ゾーンの接続はリージョンの特性に依存するため、エッジの場所を介してリージョンに入るトラフィックは、その宛先に到達するためにゾーン間でルーティングする必要がある場合があります。 ゾーン間ルーティングと '光の速度' の制約が存在することから、これによって約 1 ミリ秒から 2 ミリ秒の待機時間が追加されますが、これが影響を与えるのは極端に敏感なワークロードだけとなるはずです。

  • 可用性ゾーンは単一サブスクリプションのコンテキスト内の論理エンティティとして扱われるため、異なるサブスクリプションが同じリージョンに対する異なるゾーン マッピングを持つ場合があります。 たとえば、サブスクリプション A 内のゾーン 1 が、サブスクリプション B 内のゾーン 2 と同じ物理データ センターに対応する可能性があります。

  • アプリケーション コンポーネント間の通信が極端に多いアプリケーション シナリオでは、アプリケーション層を複数のゾーンにわたって分散させることで、かなりの待機時間とコストの増加が生じる可能性があります。 デプロイ スタンプを単一ゾーンに制限し、複数のスタンプを異なるゾーンにわたってデプロイすることで、設計内でこれを軽減することが可能です。

  • 異なる Azure リージョン間の通信は、帯域幅の GB あたりのより大きなデータ転送料金を発生させます。

    • 適用されるデータ転送速度は、考慮される Azure リージョンの大陸によって異なります。
    • 大陸を横断するデータに対する課金は、かなり高いレートで行われます。

  • Express Route と VPN の接続方法を使用することで、特定のシナリオで異なる Azure リージョン同士、あるいは異なるクラウド プラットフォーム同士を直接接続することもできます。

  • サービス間通信に関しては、Private Link を使用することでプライベート エンドポイントを使用する直接通信を実現できます。

  • 1 つの Azure リージョン内、および同じ地域内の異なる Azure リージョンにわたる仮想ネットワーク間のルーティングを実現するために、オンプレミス接続に使用される Express Route 回線を通してトラフィックをヘアピン留めすることができます。

    • Express Route を通したヘアピン留めトラフィックは、仮想ネットワーク ピアリングに関連するデータ転送コストがかからないため、コストを最適化する方法として使用できます。
    • このアプローチでは、Azure 内のアプリケーション統合のための追加のネットワーク ホップが必要になり、待機時間と信頼性のリスクが発生します。 Express Route と関連するゲートウェイ コンポーネントの役割を Azure/オンプレミスから Azure/Azure 接続も含むように拡張します。

  • サービス間の待機時間がミリ秒未満であることが必要な場合は、近接配置グループを使用することができます (使用サービスでサポートされている場合)。

設計の推奨事項

  • リージョン内および異なるリージョン間でネットワークを接続するには、仮想ネットワーク ピアリングを使用します。 Express Route 内でヘアピン NAT を行わないことを強くお勧めします。

  • Private Link を使用して、同じリージョン内または複数のリージョンにわたる (リージョン A 内のサービスがリージョン B 内のサービスと通信する) サービス間で直接通信を確立します。

  • コンポーネント間で非常にやり取りが多いアプリケーション ワークロードの場合は、デプロイ スタンプを 1 つのゾーンに制限し、異なるゾーン間で複数のスタンプをデプロイすることを検討してください。 これにより、単一のアプリケーション コンポーネントではなく、カプセル化されたデプロイ スタンプのレベルでゾーン冗長が維持されます。

  • 可能な場合は、各デプロイ スタンプを独立して、他のスタンプから切断されているものとして扱います。

    • 直接的なネットワーク パスを使用してアプリケーション レベルで一貫性を実現するのではなく、データ プラットフォーム テクノロジを使用して、リージョン間で状態を同期します。
    • 障害シナリオであったとしても、必要な場合を除き、異なるリージョン間の 'dog legging' トラフィックは避けます。 グローバル ルーティング サービスとエンド ツー エンドの正常性プローブを使用して、単一のクリティカル コンポーネント層で障害が発生した場合に、障害が発生したコンポーネント レベルでトラフィックを別のリージョンにルーティングするのではなく、スタンプ全体を循環から取り出します。

  • 待機時間に非常に敏感なアプリケーションのシナリオでは、イングレス パスのネットワーク待機時間を最適化するために、ゾーンとリージョン ネットワーク ゲートウェイの使用を優先します。

マイクロセグメント化と Kubernetes ネットワーク ポリシー

マイクロセグメンテーションは、個々のアプリケーション ワークロードを分離してセキュリティで保護するために使用されるネットワーク セキュリティ設計パターンであり、ゼロ トラスト モデルに基づいてワークロード間のネットワーク トラフィックを制限するポリシーが適用されます。 これは通常、ポリシー駆動型のアプリケーションレベルのネットワーク制御を通して、ネットワーク攻撃面を減らし、侵害の封じ込めを促進し、セキュリティを強化するために適用されます。

Azure Kubernetes Service (AKS) を使用する場合、ミッションクリティカルなアプリケーションでは、サブネットまたはネットワーク インターフェイス レベルでのネットワーク セキュリティ グループ (NSG)、サービス アクセス制御リスト (ACL)、ネットワーク ポリシーを使用して、アプリケーションレベルのネットワーク セキュリティを適用できます。

このセクションでは、これらの機能の最適な使用方法について調べ、アプリケーションレベルのマイクロセグメント化を実現するための重要な考慮事項と推奨事項を明らかにします。

デザインに関する考慮事項

  • AKS は、以下の 2 つの異なるネットワーク モデルでデプロイできます。

    • kubenet ネットワーク: AKS ノードは既存の仮想ネットワーク内に統合されますが、ポッドは各ノード上の仮想オーバーレイ ネットワーク内に存在します。 異なるノード上のポッド間のトラフィックは、kube-proxy 経由でルーティングされます。
    • Azure Container Networking Interface (CNI) ネットワーク: AKS クラスターは、既存の仮想ネットワーク内に統合され、そのノード、ポッド、およびサービスは、クラスター ノードがアタッチされているのと同じ仮想ネットワークから IP アドレスを受け取ります。 これは、ポッドとの間の直接接続を必要とするさまざまなネットワーク シナリオに適しています。 異なるノード プールは、異なるサブネット内にデプロイできます。

    Note

    Azure CNI は、kubenet よりも多くの IP アドレス空間を必要とします。 ネットワークの適切な事前計画とサイズ設定が必要です。 詳細については、「Azure CNI ドキュメント」を参照してください。

  • 既定では、ポッドは分離されず、任意のソースからのトラフィックを受け入れ、任意の宛先にトラフィックを送信できます。特定の Kubernetes クラスター内において、ポッドは他のすべてのポッドと通信できます。Kubernetes はネットワーク レベルの分離は何も保証せず、クラスター レベルで名前空間を分離しません。

  • ポッドと名前空間の間の通信は、ネットワーク ポリシーを使用して分離できます。 ネットワーク ポリシーは、ポッド間の通信のアクセス ポリシーを定義する Kubernetes の仕様です。 ネットワーク ポリシーを使用して、トラフィックの送受信方法を制御するためのルールの順序付きセットを定義して、1 つ以上のラベル セレクターにマッチするポッドのコレクションに適用することができます。

    • AKS は、Azure と Calico というネットワーク ポリシーを実装する 2 つのプラグインをサポートしています。 どちらのプラグインも Linux IPTables を使用して、指定されたポリシーを適用します。 詳細については、「Azure と Calico ポリシーおよびそれぞれの機能の違い」を参照してください。
    • ネットワーク ポリシーは加法的であるため、競合を起こしません。
    • 2 つのポッド間のネットワーク フローを許可するには、ソース ポッドのエグレス ポリシーと宛先ポッドのイングレス ポリシーの両方がトラフィックを許可する必要があります。
    • ネットワーク ポリシー機能を有効にできるのは、クラスターのインスタンス化時だけです。 既存の AKS クラスターでネットワーク ポリシーを有効にすることはできません。
    • ネットワーク ポリシーの配信は、Azure と Calico のどちらが使用されているかに関係なく一貫しています。
    • Calico は、Windows ノードのサポートを含むよりリッチな機能セットを提供し、kubenet だけでなく Azure CNI もサポートします。

  • AKS は、GPU 機能を持つノードと持たないノードのように、異なるハードウェアとソフトウェアの特性を持つノードを使用しているさまざまなワークロードを分離するために、さまざまなノード プールの作成をサポートしています。

    • ノード プールを使用しても、ネットワーク レベルの分離は何も提供されません。
    • ノード プールでは、同じ仮想ネットワーク内の異なるサブネットを使用できます。 NSG をサブネットレベルで適用することで、ノード プール間のマイクロセグメント化を実装できます。

設計の推奨事項

  • すべての検討対象サブネットで NSG を構成して、イングレス パスをセキュリティで保護し、ゼロ トラスト モデルに基づいてアプリケーション コンポーネントを分離する IP ACL を提供します。

    • Azure Front Door 内で定義されたアプリケーション バックエンドを含むすべてのサブネット上の NSG 内で Front Door サービス タグを使用します。これはトラフィックが正当な Azure Front Door バックエンド IP アドレス空間から送信されていることを検証するためです。 これにより、トラフィックはサービス レベルで Azure Front Door を通って流れることが保証されますが、ヘッダー ベースのフィルタリングは、特定の Front Door インスタンスの使用を確認するためと、'IP スプーフィング' のセキュリティ リスクを軽減するためにも必要となります。

    • パブリック インターネット トラフィックは、該当するすべての NSG の RDP と SSH のポートで無効にしてください。

    • Azure CNI ネットワーク プラグインの使用を優先し、制限されたアドレス空間内のアプリケーションに合わせて使用可能な IP アドレスの範囲が限られているシナリオでは Kubenet を検討してください。

      • AKS は、Azure CNI と kubenet の両方の使用をサポートしています。 このネットワークの選択はデプロイ時に行われます。
      • Azure CNI ネットワーク プラグインは、より堅牢でスケーラブルなネットワーク プラグインであり、ほとんどのシナリオで推奨されます。
      • kubenet は、より軽量なネットワーク プラグインであり、利用可能な IP アドレスの範囲が限られているシナリオで推奨されます。
      • 詳細については、「Azure CNI」を参照してください。

  • Kubernetes のネットワーク ポリシー機能は、クラスター内のポッド間のイングレスおよびエグレス トラフィックに関する規則を定義するために使用してください。 詳細なネットワーク ポリシーを定義して、ポッド間通信を制限します。

    • デプロイ時に Azure Kubernetes Service のネットワーク ポリシーを有効にします。
    • Calico は、よりリッチな機能セットと広範なコミュニティ導入とサポートを提供するため、こちらの使用を優先します。

次のステップ

アプリケーションの正常性を定量化して監視するための考慮事項を確認します。

正常性モデリングと監視