次の方法で共有

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 アプリケーション ファイアウォールの機能に関する大幅な複雑さと、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 プレミアムではプライベート エンドポイントがサポートされており、インターネットから Azure 仮想ネットワークにトラフィックを直接フローできます。 これにより、Azure Front Door プレミアム経由でバックエンドにアクセスできるように、VNet でパブリック IP を使用する必要がなくなります。

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

  • 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 は、最適化されたトラフィック ルーティング、透過的なフェールオーバー、プライベート バックエンド エンドポイント (プレミアム SKU を使用)、エッジ キャッシュ、Web アプリケーション ファイアウォール (WAF) との統合を提供しているため、HTTP/S ワークロードを強く推奨しています。

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

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

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

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

重要

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

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

  • 推奨されませんが、Azure Front Door へのグローバル ルーティング冗長性のために Azure Traffic Manager を使用する HTTP ワークロードでは、Azure Front Door を通過する許容可能なトラフィックのために Web アプリケーション ファイアウォール (WAF) を Application Gateway にオフロードすることを検討してください。
    • これにより、標準のイングレス パスに障害ポイントが追加され、管理とスケーリングを行う追加のクリティカル パス コンポーネントが導入され、グローバルな高可用性を確保するための追加コストも発生します。 ただし、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 アプリlication 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 アプリlication Gateway、Azure API Management などの関連サービスを考慮して、主要なアプリケーション配信機能を確認することで、グローバル ルーティングの推奨事項に基づいています。

設計上の考慮事項

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

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

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

    • カスタム ルールを追加して、マネージド ルール セットを拡張することもできます。
    • Azure WAF は、Azure Front Door、Azure アプリlication Gateway、または Azure CDN (現在パブリック プレビュー段階) 内で有効にすることができます。
      • 各サービスで提供される機能は若干異なります。 たとえば、Azure Front Door WAF では、Application Gateway WAF 内ではまだ提供されていないレート制限、geo フィルタリング、ボット保護が提供されます。 ただし、これらはすべて組み込みルールとカスタム ルールの両方をサポートしており、検出モードまたは防止モードで動作するように設定できます。
      • 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 など) を使用します。 アプリケーション エンドポイントはエンド ユーザーには表示されないため、Azure で管理される doメイン (マネージドcloudapp.net証明書などazurewebsites.net) を使用できます。

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

  • Azure Front Door を使用してグローバルに、または Azure アプリlication 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 アプリケーション ファイアウォール (WAF) 機能は提供されません。 ただし、Akamai や Verizon などのサード パーティソリューションの同様のサービスと統合する柔軟性がさらに向上します。
    • Azure Front Door サービスと Azure CDN サービスを比較するときは、次の決定要因を調べる必要があります。
      • 必要なキャッシュ規則は、ルール エンジンを使用して実現できます。
      • 保存されているコンテンツのサイズと関連するコスト。
      • ルール エンジンの実行に対する 1 か月あたりの価格 (Azure Front Door での要求ごとに課金されます)。
      • 送信トラフィックの要件 (価格は宛先によって異なります)。

設計の推奨事項

  • イメージ ファイルのサイズが決して変更されない、またはほとんど変更されないサイズのコピーなどの静的コンテンツは、キャッシュのメリットも得られます。 キャッシュは、URL パラメーターに基づいて、さまざまなキャッシュ期間で構成できます。
  • ユーザーへのコンテンツの配信を静的と動的で区別し、関連するコンテンツをキャッシュから配信して、バックエンド サービスの負荷を軽減し、エンド ユーザーのパフォーマンスを最適化します。
  • グローバル ルーティングと Web アプリケーション ファイアウォール (WAF) の目的で Azure Front Door を使用するための強力な推奨事項 (ネットワークと接続 の設計領域) を考えると、ギャップが存在しない限り、Azure Front Door キャッシュ機能の使用に優先順位を付けることをお勧めします。

仮想ネットワークの統合

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

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

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

注意事項

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

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

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

仮想ネットワークなし

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

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

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

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

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

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

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

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

    • サポートされている場合は、プライベート エンドポイントを使用して 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 の合計帯域幅を提供できます。

Note

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

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

設計の推奨事項

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

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

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

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

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

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

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

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

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

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

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

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

    Note

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

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

インターネット エグレス

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

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

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

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

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

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

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

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

  • Azure アプリ Service などのマルチテナント環境では、各インスタンスで使用できる送信ポートの数が限られています。 これらのポートが不足した場合、新しい送信接続を開始することはできません。 この問題を軽減するには、プライベート/パブリック エッジ トラバーサルの数を減らすか、Azure NAT ゲートウェイなどのよりスケーラブルな 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 ゲートウェイを使用して送信トラフィック フローを抽象化することを検討してください。

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

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

Note

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

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

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

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

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

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

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

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

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

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

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

  • アプリケーション コンポーネント間で非常におしゃべりなアプリケーション シナリオでは、アプリケーション層をゾーン間に分散すると、大幅な待機時間とコストの増加が生じる可能性があります。 デプロイ スタンプを 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 ネットワーク ポリシー

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

ミッション クリティカルなアプリケーションでは、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 では、ネットワーク ポリシー を実装する 2 つのプラグイン (Azure と Calico) がサポートされています。 どちらのプラグインも Linux IPTable を使用して、指定されたポリシーを適用します。 詳細については、 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 の使用に優先順位を付けます。

次のステップ

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

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