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 DNS や Microsoft Entra ID などの共有基本サービスによってのみ実現可能であり、ほぼすべての Azure サービスのグローバル プラットフォームの依存関係として機能します。 冗長な Azure テクノロジが適用されている場合、セカンダリ サービスでも使用できないか、サービスが低下している可能性があります。
      • グローバル ルーティング サービスの障害シナリオは、サービス間の依存関係を通じて、主要なアプリケーション コンポーネントに使用される他の多くのサービスに大きな影響を与える可能性が高くなります。 サードパーティのテクノロジが使用されている場合でも、基になる問題の影響が大きいため、アプリケーションは異常な状態になる可能性があります。つまり、Azure 上のアプリケーション エンドポイントへのルーティングは、とにかくほとんど価値を提供しないということです。

  • グローバル ルーティング サービスの冗長性は、グローバルな停止の影響がルーティング サービス自体に制約される、非常に少数の架空の障害シナリオに対する軽減策を提供します。

    グローバルな停止シナリオに対してより広範な冗長性を提供するために、マルチクラウドのアクティブ/アクティブ デプロイ アプローチを検討できます。 マルチクラウドのアクティブ/アクティブ デプロイ アプローチでは、運用が著しく複雑になり、回復性のリスクが高くなり、グローバルな停止で仮定されるリスクをはるかに上回る可能性があります。

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

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

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

  • 一部のサードパーティグローバル ルーティング サービスでは、100% SLA が提供されます。 ただし、これらのサービスによって提供される歴史的で達成可能な SLA は、通常 100% 未満です。

    • これらのサービスは利用不可に対する財政的な補償を提供しますが、人間の生命が最終的に危険にさらされる安全に不可欠なシナリオなど、利用不能の影響が大きい場合には、ほとんど意味がありません。 そのため、アドバタイズされた法的 SLA が 100% の場合でも、テクノロジの冗長性または十分な運用上の軽減策を考慮する必要があります。

Azure Front Door

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

    • バックエンド エンドポイントごとに多数の接続が維持されます。
    • 受信クライアント要求は、最初に、送信元クライアントに最も近いエッジ ノードで終了します。
    • 必要なトラフィック検査の後、要求は既存の接続を使用して Microsoft バックボーン経由で適切なバックエンドに転送されるか、エッジ ノードの内部キャッシュから提供されます。
    • この方法は、大量のトラフィックをバックエンド接続に分散させる場合に非常に効率的です。

  • エッジ ノードからの静的コンテンツを提供する組み込みキャッシュを提供します。 多くのユース ケースでは、専用のコンテンツ配信ネットワーク (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 も正常性プローブに依存して、バックエンドが正常で正常に動作しているかどうかを把握します。 別の値が返されるか、何も返されない場合、ルーティング サービスは進行中の問題を認識し、その特定のバックエンドへの要求のルーティングを停止します。

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

Azure Standard Load Balancer

重要

リージョン間Standard Load Balancerは、技術的な制限付きでプレビュー段階で利用できます。 このオプションは、ミッション クリティカルなワークロードには推奨されません。

設計の推奨事項

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

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

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

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

Mission-Critical Global Load Balancer Configuration

重要

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

Azure は、他のクラウド プラットフォームと効果的に統合できます。 ただし、複数のクラウド アプローチを適用しないことを強くお勧めします。これは、さまざまなデプロイ スタンプ定義と、異なるクラウド プラットフォーム間での運用正常性の表現によって、運用上の複雑さが大幅に発生するためです。 この複雑さは、アプリケーションの通常の操作内で多くの回復性リスクを引き起こすので、グローバル プラットフォームの停止の仮定のリスクをはるかに上回ります。

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

    • ほとんどの場合、これは専用のコンテンツ配信ネットワーク (CDN) の必要もなくなります。

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

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

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

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

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

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

Azure の Traffic Manager

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

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

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

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

    ただし、Traffic Manager の場合は、サービス レベルのリージョンフェールオーバーに関する追加の考慮事項を考慮する必要があります。 特に 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 では、レート制限、geo フィルタリング、ボット保護が提供されます。これは、Application Gateway WAF 内ではまだ提供されていません。 ただし、これらはすべて組み込みルールとカスタム ルールの両方をサポートしており、検出モードまたは防止モードで動作するように設定できます。
      • Azure WAF のロードマップにより、すべてのサービス統合で一貫した WAF 機能セットが提供されるようになります。

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

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

    Azure Front Door

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

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

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

  • Azure Front Door では、クライアントに接続する SSL 証明書に対して、フル マネージド証明書サービスと証明書持ち込み方法の両方が提供されます。 フル マネージド証明書サービスは、簡素化された運用アプローチを提供し、ソリューションの 1 つの領域内で証明書管理を実行することで、全体的な設計の複雑さを軽減するのに役立ちます。

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

  • 証明書の更新は、Azure Front Door が "マネージド" と "Use Your Own Certificate" の間で切り替えた場合にのみダウンタイムが発生します。

  • 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 など) を使用します。 アプリケーション エンドポイントはエンド ユーザーには表示されないため、 や cloudapp.netなどの azurewebsites.net Azure マネージド ドメインは、マネージド証明書で使用できます。

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

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

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

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

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

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

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

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

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

画像、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 パラメーターに基づいて、さまざまなキャッシュ期間で構成できます。
  • ユーザーへのコンテンツの配信を静的と動的で区別し、関連するコンテンツをキャッシュから配信して、バックエンド サービスの負荷を軽減し、エンド ユーザーのパフォーマンスを最適化します。
  • グローバル ルーティングとWeb Application Firewall (WAF) の目的で Azure Front Door を使用するための強力な推奨事項 (ネットワークと接続の設計領域) を考えると、ギャップが存在しない限り、Azure Front Door キャッシュ機能の使用に優先順位を付けすることをお勧めします。

仮想ネットワークの統合

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

ミッション クリティカルなアプリケーションは、3 つの包括的なネットワーク構成の 1 つ内にデプロイできます。これにより、アプリケーション統合をネットワーク レベルで行う方法が決まります。

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

注意事項

Azure ランディング ゾーン内にデプロイする場合は、構成 1。 はオンライン ランディング ゾーン内にデプロイする必要があります。また、ネットワーク レベルの統合を容易にするために、Corp. Connected Landing Zone 内に 2) と 3) をデプロイする必要があります。

このセクションでは、これらのネットワーク統合シナリオについて説明し、Azure Virtual Networks とその周辺の Azure ネットワーク サービスを適切に使用して階層化し、統合要件が最適に満たされるようにします。

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

仮想ネットワークなし

  • 最も簡単な設計方法は、仮想ネットワーク内にアプリケーションをデプロイしないことです。

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

  • この設計アプローチでは、さまざまなサービス コンポーネントと依存ソリューション間のアクセス制御を提供するために、"セキュリティ境界としての ID" が採用されています。 これは、セキュリティの影響を受けにくいシナリオに適したソリューションである可能性があります。 パブリック エンドポイントを介してすべてのアプリケーション サービスと依存関係にアクセスでき、不正アクセスの取得に向けた追加の攻撃ベクトルに対して脆弱になります。

  • AKS などの多くのサービスには、基になる仮想ネットワークに対するハード要件があるため、この設計アプローチはすべての Azure サービスにも適用できません。

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

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

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

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

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

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

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

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

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

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

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

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

  • Azure リージョンまたはオンプレミス ネットワーク間で IP アドレス空間が重複すると、ネットワーク統合が考慮されると大きな競合が発生します。

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

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

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

注意

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

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

設計の推奨事項

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

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

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

  • 他の Azure またはオンプレミス ネットワークに接続する場合、アプリケーション仮想ネットワークは、仮想ネットワーク ピアリングと仮想ネットワーク ゲートウェイ リソースが関係する重大な複雑さを生み出すので、エフェメラルとして扱うべきではありません。 仮想ネットワーク内のすべての関連アプリケーション リソースは、更新されたリージョンデプロイ スタンプのブルーグリーンデプロイを容易にするために使用される並列サブネットを使用して、一時的な状態を維持する必要があります。

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

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

  • AKS ネットワーク統合には Azure CNI を使用する優先順位を付 けます。これは、より豊富な機能セットをサポートするためです。

    • 制限付きアドレス空間内のアプリケーションに合わせて使用可能な IP アドレスが限られているシナリオでは、Kubenet を検討してください。

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

  • オンプレミスのネットワーク統合を必要とするシナリオでは、Express Route を使用してセキュリティで保護されたスケーラブルな接続を確保する優先順位を付けます。

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

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

    注意

    Azure ランディング ゾーン内にデプロイし、より広範な組織ネットワーク トポロジと統合する場合は、ネットワーク ガイダンス を検討して、基本ネットワークが Microsoft のベスト プラクティスと一致していることを確認してください。

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

インターネット エグレス

インターネット エグレスは、次のコンテキストで外部通信を容易にするミッション クリティカルなアプリケーションの基本的なネットワーク要件です。

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

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

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

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

  • Azure では、仮想ネットワーク上の仮想マシンまたはコンピューティング インスタンスに対して、Azure NAT ゲートウェイや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 サービス間のトラフィックを検査するために使用されていないことを確認します。

注意

Azure ランディング ゾーン内にデプロイする場合は、基本プラットフォーム Azure Firewall リソース (または同等の NVA) の使用を検討してください。 インターネット エグレス用の中央プラットフォーム リソースに依存関係がある場合、そのリソースの信頼性レベルと関連するネットワーク パスは、アプリケーションの要件と密接に一致している必要があります。 障害シナリオで潜在的な運用アクションを通知するために、リソースからの運用データもアプリケーションで使用できるようにする必要があります。

送信トラフィックに関連する大規模な要件がある場合は、ノイズの多い近隣シナリオなど、一元的に共有されたリソースの使用に関連するリスクを軽減するために、ミッション クリティカルなアプリケーションの専用のAzure Firewall リソースを考慮する必要があります。

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

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

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

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

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

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

    ゾーン間通信では、2 ミリ秒未満のラウンドトリップ待機時間が保証されます。 ゾーン間の距離とファイバー パスが異なる場合、ゾーンの待機時間の差異は小さくなります。

  • 可用性ゾーンの接続はリージョンの特性によって異なるため、エッジの場所を介してリージョンに入るトラフィックは、その宛先に到達するためにゾーン間でルーティングする必要がある場合があります。 これにより、ゾーン間ルーティングと "光の速度" の制約を指定すると、最大 1 ミリ秒から 2 ミリ秒の待機時間が追加されますが、ハイパーセンシティブなワークロードにのみ影響を与える必要があります。

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

  • リージョン内のゾーン間の通信では、帯域幅の GB あたりの データ転送料金 が発生します。

  • アプリケーション コンポーネント間で非常におしゃべりなアプリケーション シナリオでは、アプリケーション層を複数のゾーンに分散すると、大幅な待機時間が発生し、コストが増加する可能性があります。 デプロイ スタンプを 1 つのゾーンに制限し、複数のスタンプを異なるゾーンにデプロイすることで、設計内でこれを軽減できます。

  • 異なる Azure リージョン間の通信では、GB あたりの 帯域幅あたりのデータ転送料金 が大きくなります。

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

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

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

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

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

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

設計の推奨事項

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

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

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

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

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

  • 待機時間が長いアプリケーション シナリオの場合は、リージョン ネットワーク ゲートウェイを使用したゾーンの使用に優先順位を付けて、イングレス パスのネットワーク待機時間を最適化します。

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

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

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

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

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

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

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

    注意

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

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

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

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

  • AKS では、ハードウェアとソフトウェアの特性が異なるノード (GPU 機能の有無にかかわらずノードなど) を使用して異なるワークロードを分離するために、異なるノード プールの作成がサポートされています。

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

設計の推奨事項

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

    • 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 は、より広範なコミュニティ導入とサポートを備えた豊富な機能セットを提供するため、 Calico の使用に優先順位を付けます。

次のステップ

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

正常性モデリングと可観測性