Microsoft Entra アプリケーション プロキシを使用してトラフィック フローを最適化する

この記事では、アプリケーションをリモートで発行およびアクセスするために Microsoft Entra アプリケーション プロキシを使用する場合のトラフィック フローを最適化する方法およびネットワーク トポロジに関する注意事項について説明しています。

トラフィック フロー

アプリケーションが Microsoft Entra アプリケーション プロキシを通じて発行される場合、ユーザーからアプリケーションへのトラフィックはすべて、次の 3 つの接続を経由して送信されます。

  1. ユーザーは、Azure 上の Microsoft Entra アプリケーション プロキシ サービスのパブリック エンドポイントに接続する
  2. アプリケーション プロキシ コネクタからアプリケーション プロキシ サービスへの接続 (アウトバウンド)
  3. アプリケーション プロキシ コネクタから対象アプリケーションへの接続

Diagram showing traffic flow from user to target application.

最も近いアプリケーション プロキシ クラウド サービスを使用するようにコネクタ グループを最適化する

Microsoft Entra テナントにサインアップするとき、指定した国/地域によってテナントのリージョンが決まります。 アプリケーション プロキシを有効にすると、テナント用のデフォルトのアプリケーション プロキシ クラウド サービス インスタンスが、Microsoft Entra テナントと同じリージョン、またはそこに最も近いリージョン内で選択されます。

たとえば、Microsoft Entra テナントの国またはリージョンが英国の場合、デフォルトのすべてのアプリケーション プロキシ コネクタは、ヨーロッパのデータ センターにあるサービス インスタンスを使用するように割り当てられます。 ユーザーが公開アプリケーションにアクセスする場合、トラフィックはこの場所のアプリケーション プロキシ クラウド サービス インスタンスを経由して送信されます。

既定のリージョンとは異なるリージョンにコネクタがインストールされている場合、これらのアプリケーションにアクセスするパフォーマンスを向上させるために、コネクタ グループが最適化されているリージョンを変更すると有益な場合があります。 コネクタ グループに対してリージョンを指定すると、指定したリージョンのアプリケーション プロキシ クラウド サービスに接続されます。

トラフィック フローを最適化し、コネクタ グループの待機時間を短縮するために、コネクタ グループを最も近いリージョンに割り当てます。 リージョンを割り当てるには、次の操作を行います。

重要

この機能を使用するには、バージョン 1.5.1975.0 以降のコネクタが使用されている必要があります。

  1. 少なくとも アプリケーション管理者 の権限で Microsoft Entra 管理センター にサインインします。

  2. 右上隅で自分のユーザー名を選択します。 アプリケーション プロキシを使用するディレクトリにサインインしていることを確認します。 ディレクトリを変更する必要がある場合は、 [ディレクトリの切り替え] を選択し、アプリケーション プロキシを使用するディレクトリを選択します。

  3. ID>アプリケーション>エンタープライズ アプリケーション>アプリケーション プロキシ を参照します。

  4. [新しいコネクタ グループ] を選択し、コネクタ グループの [名前] を指定します。

  5. 次に、[詳細設定] の下で、[特定のリージョン用に最適化] の下にあるドロップダウンを選択し、コネクタに最も近いリージョンを選択します。

  6. [作成] を選択します

    Configure a new connector group.

  7. 新しいコネクタ グループを作成したら、このコネクタ グループに割り当てるコネクタを選択できます。

    • コネクタ グループにコネクタを移動できるのは、既定のリージョンを使用するコネクタ グループにそれが属している場合のみです。 最適な方法は、最初は常に "既定のグループ" にコネクタを配置し、それを適切なコネクタ グループに移動することです。
    • コネクタ グループのリージョンを変更できるのは、コネクタ グループに割り当てられているコネクタおよびアプリがない場合のみです。
  8. 次に、コネクタ グループをアプリケーションに割り当てます。 これで、アプリにアクセスするときに、トラフィックはコネクタ グループが最適化されているリージョンのアプリケーション プロキシ クラウド サービスに送信されます。

待機時間を削減するための考慮事項

プロキシ ソリューションでは、ネットワーク接続に必ず待ち時間が発生します。 リモート アクセス ソリューションとして選択したプロキシまたは VPN ソリューションに関係なく、ソリューションには、企業ネットワーク内部に接続できるようにする一連のサーバーが必ず含まれます。

多くの組織では、サーバーのエンドポイントが境界ネットワーク内に含まれています。 しかし、Microsoft Entra アプリケーション プロキシでは、コネクタが企業ネットワーク上に配置されていてもトラフィックはクラウド内のプロキシ サービスを経由して送信されます。 このため、境界ネットワークは必要ありません。

次のセクションで、待機時間をさらに削減するための推奨事項を示します。

コネクタの配置

アプリケーション プロキシでは、テナントの場所に基づいてインスタンスの場所が自動的に選択されます。 ただし、コネクタのインストール場所は自分で決定できます。これにより、ネットワーク トラフィックの待機時間特性を定義できます。

アプリケーション プロキシ サービスを設定する場合は、次の質問について考えてください。

  • アプリケーションの場所はどこか。
  • アプリケーションにアクセスする大半のユーザーの場所はどこか。
  • アプリケーション プロキシ インスタンスの場所はどこか。
  • Azure データセンターへの専用のネットワーク接続 (Azure ExpressRoute や類似の VPN など) が既に設定されているかどうか。

コネクタは Azure とアプリケーションの両方と通信する必要があるため (トラフィック フロー図の手順 2 と 3)、コネクタの配置場所はこれら 2 つの接続の待機時間に影響します。 コネクタの配置を評価する際は、次の点に留意してください。

  • シングル サインオンに Kerberos の制約付き委任 (KCD) を使用する場合、コネクタからデータセンターへの通信経路が必要になります。 さらに、コネクタ サーバーはドメインに参加している必要があります。
  • 使用するかどうかが不明な場合は、アプリケーションの近くにコネクタをインストールします。

待機時間を最小限に抑えるための一般的なアプローチ

各ネットワーク接続を最適化することによって、エンド ツー エンドのトラフィック待機時間を最小化することができます。 各接続は次の方法で最適化できます。

  • ホップの両端間の距離を短縮します。
  • 経由する適切なネットワークを選択します。 たとえば、パブリック インターネットではなく、プライベート ネットワークを経由した方が、専用リンクのため高速である可能性があります。

Azure と企業ネットワークの間に専用の VPN または ExpressRoute リンクがある場合は、これを利用することをお勧めします。

最適化戦略に焦点を合わせる

ユーザーとアプリケーション プロキシ サービス間の接続を制御するために実行できることはほとんどありません。 ユーザーは、ホーム ネットワーク、コーヒー ショップ、または別の国/地域からアプリにアクセスする可能性があります。 代わりに、アプリケーション プロキシ サービスからアプリケーション プロキシ コネクタへの接続とアプリケーション プロキシ コネクタからアプリへの接続を最適化できます。 環境内に次のパターンを組み込むことを検討してください。

パターン 1: アプリケーションの近くへのコネクタの配置

顧客のネットワーク内の対象アプリケーションの近くにコネクタを配置します。 この構成では、コネクタとアプリケーションが閉じているため、トポロジ図の手順 3 が最小限に抑えられます。

コネクタがドメイン コントローラーを見通す必要がある場合は、このパターンが得策です。 このパターンはほとんどのシナリオに適しているため、大半のユーザーが使用しています。 このパターンとパターン 2 を組み合わせて、サービスとコネクタ間のトラフィックを最適化することもできます。

パターン 2: Microsoft ピアリングを使用した ExpressRoute の活用

Microsoft ピアリングを使用して ExpressRoute が設定されている場合、アプリケーション プロキシとコネクタ間のトラフィック用により高速な ExpressRoute 接続を利用できます。 この場合でも、コネクタはネットワーク上のアプリケーションに近い場所に配置します。

パターン 3: プライベート ピアリングを使用した ExpressRoute の活用

Azure と企業ネットワークとの間に、プライベート ピアリングを使用して専用の VPN または ExpressRoute を設定済みの場合、別の選択肢があります。 この構成では、通常、Azure の仮想ネットワークは企業ネットワークの拡張機能と見なされます。 そのため、Azure データセンターにコネクタをインストールする一方で、コネクタからアプリへの接続について厳しい待ち時間の要件を満たすことができます。

専用接続を介して送信されるため、待機時間は損なわれません。 また、コネクタが Microsoft Entra テナントの場所に近い Azure データセンターでインストールされるため、アプリケーション プロキシ サービスからコネクタへの接続待ち時間も改善されます。

Diagram showing connector installed within an Azure datacenter

その他のアプローチ

この記事ではコネクタの配置を中心に取り上げていますが、アプリケーションの配置を変更して待ち時間特性を改善することもできます。

ホスト環境にネットワークを移動する組織が増えています。 これにより組織は、企業ネットワークの一部でもあり、ドメイン内のままであるホスト環境にアプリを配置できます。 この場合は、前のセクションで説明したパターンをアプリケーションの新しい場所に適用できます。 このオプションを検討している場合は、「Microsoft Entra Domain Services」を参照してください。

さらに、別々の場所やネットワーク内にある対象アプリケーションに接続するコネクタを、コネクタ グループを使用して整理することを検討してください。

一般的なユースケースの図

このセクションでは、いくつかの一般的なシナリオについて説明します。 Microsoft Entra テナント (およびそれに伴うプロキシ サービス エンドポイント) が米国 (US) 内にあると仮定します。 これらのユース ケースで説明されている考慮事項は、世界各地の他のリージョンにも当てはまります。

以下のシナリオでは、説明をわかりやすくするため、各接続に番号を付けて "ホップ" と呼びます。

  • ホップ 1: ユーザーからアプリケーション プロキシ サービスへ
  • ホップ 2: アプリケーション プロキシ サービスからアプリケーション プロキシ コネクタへ
  • ホップ 3: アプリケーション プロキシ コネクタからターゲット アプリケーションへ

ユース ケース 1

シナリオ: アプリは米国内の組織のネットワークにあり、ユーザーは同じリージョン内に存在している。 Azure データセンターと企業ネットワークの間に ExpressRoute または VPN は存在しません。

推奨事項: 前のセクションで説明したパターン 1 に従います。 待ち時間を改善するには、必要に応じて ExpressRoute の使用を検討してください。

これは、単純なパターンです。 アプリの近くにコネクタを配置することによって、ホップ 3 を最適化します。 コネクタは、KCD 操作を実行するために、通常、アプリとデータセンターとの通信経路にインストールされるため、これは自然な選択でもあります。

Diagram that shows users, proxy, connector, and app are all in the US.

ユース ケース 2

シナリオ: アプリは米国内の組織のネットワークにあり、ユーザーは世界中に分散している。 Azure データセンターと企業ネットワークの間に ExpressRoute または VPN は存在しません。

推奨事項: 前のセクションで説明したパターン 1 に従います。

繰り返しますが、一般的なパターンはホップ 3 の最適化です。これにより、コネクタはアプリの近くに配置されます。 ホップ 3 は、すべて同じリージョン内にある場合、通常、コストは高くありません。 ただし、世界各地のユーザーが米国内のアプリケーション プロキシ インスタンスにアクセスするため、ユーザーの場所によってはホップ 1 のコストが高くなる可能性があります。 どのプロキシ ソリューションも、グローバルに分散しているユーザーに関して類似した特性を持つことは注目に値します。

Users are spread globally, but everything else is in the US

ユース ケース 3

シナリオ: アプリは米国内の組織のネットワークにある。 Microsoft ピアリングを使用した ExpressRoute が、Azure と企業ネットワークの間に存在します。

推奨事項:: 前のセクションで説明したパターン 1 とパターン 2 に従います。

最初に、コネクタを可能な限りアプリケーションの近くに配置します。 これで、ホップ 2 には ExpressRoute が自動的に使用されます。

ExpressRoute リンクで Microsoft ピアリングを使用している場合、プロキシとコネクタの間のトラフィックはそのリンク経由で送信されます。 ホップ 2 の待ち時間が最適化されます。

Diagram showing ExpressRoute between the proxy and connector

ユース ケース 4

シナリオ: アプリは米国内の組織のネットワークにある。 プライベート ピアリングを使用した ExpressRoute が、Azure と企業ネットワークの間に存在します。

推奨事項:: 前のセクションで説明したパターン 3 に従います。

ExpressRoute プライベート ピアリング経由で企業ネットワークに接続されている Azure データセンターにコネクタを配置します。

コネクタは、Azure データセンターに配置できます。 プライベート ネットワークを経由しても、コネクタからアプリケーションとデータセンターへの通信経路は保たれるため、ホップ 3 は最適化されたままになります。 加えて、ホップ 2 はさらに最適化されます。

Connector in Azure datacenter, ExpressRoute between connector and app

ユース ケース 5

シナリオ: このアプリはヨーロッパの組織のネットワークにあり、既定のテナント リージョンは米国で、ほとんどのユーザーはヨーロッパにいます。

推奨事項: コネクタをアプリケーションの近くに配置します。 コネクタ グループを更新して、ヨーロッパのアプリケーション プロキシ サービス インスタンスを使用するように最適化します。 手順については、「最も近いアプリケーション プロキシ クラウド サービスを使用するようにコネクタ グループを最適化する」を参照してください。

ヨーロッパのユーザーは、同じリージョンのアプリケーション プロキシ インスタンスにアクセスしているため、ホップ 1 のコストは高くありません。 ホップ 3 は最適化されています。 ExpressRoute を使用して ホップ 2 を最適化することを検討してください。

ユース ケース 6

シナリオ: このアプリはヨーロッパの組織のネットワークにあり、既定のテナント リージョンは米国で、ほとんどのユーザーは米国にいます。

推奨事項: コネクタをアプリケーションの近くに配置します。 コネクタ グループを更新して、ヨーロッパのアプリケーション プロキシ サービス インスタンスを使用するように最適化します。 手順については、「最も近いアプリケーション プロキシ クラウド サービスを使用するようにコネクタ グループを最適化する」を参照してください。 米国のすべてのユーザーがヨーロッパのアプリケーション プロキシ インスタンスにアクセスする必要があるため、ホップ 1 はコストが高くなる可能性があります。

このような状況では、もう 1 つのバリエーションを使用することも検討できます。 組織内のほとんどのユーザーが米国内に存在する場合、ネットワークが米国まで拡張される可能性があります。 コネクタを米国内に配置し、コネクタ グループについては既定の米国リージョンをそのまま使用し、ヨーロッパ内のアプリケーションには専用の社内ネットワーク回線を使用します。 これにより、ホップ 2 と 3 が最適化されます。

Diagram shows users, proxy, and connector in the US, app in Europe.

次のステップ