プライベート ネットワーク コネクタとアプリケーションの高可用性と負荷分散
この記事では、アプリケーション プロキシの展開でのトラフィック分散のしくみについて説明します。 ユーザー間およびコネクタ間にトラフィックが分散される方法と、コネクタのパフォーマンスを最適化するためのヒントについて説明します。 コネクタとバックエンド アプリ サーバーの間をトラフィックが流れるしくみと、複数のバックエンド サーバー間での負荷分散に関する推奨事項について説明します。
コネクタ間のトラフィック分散
コネクタでは、高可用性の原則に基づいて接続が確立されます。 トラフィックがコネクタ間に均等に分散される保証はなく、セッション アフィニティはありません。 そうではなく、使用状況は変化し、要求はアプリケーション プロキシ サービス インスタンスにランダムに送信されます。 結果として、トラフィックは通常、コネクタ全体に均等に分散されます。 次の図と手順では、ユーザーとコネクタの間の接続がどのように確立されるかを示します。
- クライアント デバイスのユーザーが、アプリケーション プロキシ経由で公開されているオンプレミスのアプリケーションにアクセスを試みます。
- 要求は Azure Load Balancer を経由し、要求を受け取る必要があるアプリケーション プロキシ サービス インスタンスが決定されます。 リージョン内のすべてのトラフィックに対する要求を受け入れるために使用できるインスタンスが数十あります。 この方法により、トラフィックをサービス インスタンス間に均等に分散させることができます。
- 要求は Service Bus に送信されます。
- Service Bus により、使用可能なコネクタにシグナルされます。 その後、コネクタによって Service Bus から要求が取得されます。
- ステップ 2 で、要求は異なるアプリケーション プロキシ サービス インスタンスに送られるため、接続が異なるコネクタで処理される可能性がいっそう高くなります。 その結果、グループ内のコネクタはほぼ均等に使用されます。
- コネクタによって、アプリケーションのバックエンド サーバーに要求が渡されます。 その後、アプリケーションにより応答がコネクタに返送されます。
- コネクタでは、要求元のサービス インスタンスへの送信接続を開くことで、応答が完了されます。 その後、この接続はすぐに閉じられます。 既定では、各コネクタの同時送信接続の数は 200 に制限されています。
- その後、応答がサービス インスタンスからクライアントに返されます。
- 同じ接続からの後続の要求では、この手順が繰り返されます。
多くの場合、負荷がかかっているときは、アプリケーションに多くのリソースがあり、複数の接続が開かれています。 接続ごとに、サービス インスタンスへの割り当て手順が実行されます。 接続がコネクタとペアになっていない場合は、使用可能な新しいコネクタが選ばれます。
コネクタの高可用性のベスト プラクティス
高可用性のためにコネクタ間にトラフィックが分散される方法により、コネクタ グループには常に少なくとも 2 つのコネクタが必要です。 コネクタ間に追加のバッファーを提供するため、3 つのコネクタが推奨されます。 必要なコネクタの適切な数を決定するには、容量計画に関するドキュメントを参照してください。
単一障害点を回避するには、異なる送信接続にコネクタを配置します。 複数のコネクタで同じ送信接続を使った場合、接続に関するネットワークの問題により、それを使うすべてのコネクタが影響を受けます。
運用アプリケーションに接続されているときは、コネクタを強制的に再起動しないようにします。 そのようにすると、コネクタ間のトラフィックの分散に悪影響が及ぶ可能性があります。 コネクタを再起動すると、いっそう多くのコネクタが使用できなくなり、使用可能な残りのコネクタへの接続が強制されます。 結果として、最初のコネクタの使用が不均一になります。
コネクタと Azure の間の送信トランスポート層セキュリティ (TLS) 通信では、すべての形式のインライン検査を行わないようにします。 この種のインライン検査では、通信フローが低下します。
コネクタで自動更新が実行されていることを確認します。 プライベート ネットワーク コネクタ アップデーター サービスを実行している場合、コネクタは自動的に更新され、最新のアップグレードを受け取ります。 サーバーにコネクタ アップデーター サービスが見つからない場合は、コネクタを再インストールして更新プログラムを取得する必要があります。
コネクタとバックエンド アプリケーション サーバーの間のトラフィック フロー
高可用性が要因であるもう 1 つの重要な部分は、コネクタとバックエンド サーバーの間の接続です。 アプリケーションが Microsoft Entra アプリケーション プロキシを通じて発行される場合、ユーザーからアプリケーションへのトラフィックはすべて、次の 3 つのホップを経由して送信されます。
- ユーザーは、Azure 上の Microsoft Entra アプリケーション プロキシ サービスのパブリック エンドポイントに接続します。 クライアントの発信元クライアント IP アドレス (パブリック) と、アプリケーション プロキシ エンドポイントの IP アドレスとの間で、接続が確立されます。
- プライベート ネットワーク コネクタによって、アプリケーション プロキシ サービスからクライアントの HTTP 要求がプルされます。
- プライベート ネットワーク コネクタがターゲット アプリケーションに接続されます。 コネクタでは、接続を確立するために独自の IP アドレスが使われます。
X-Forwarded-For ヘッダー フィールドに関する考慮事項
状況によっては (監査、負荷分散など)、外部クライアントの発信元 IP アドレスを、オンプレミス環境と共有する必要があります。 その要件に対応するため、Microsoft Entra プライベート ネットワーク コネクタでは、送信元クライアント IP アドレス (パブリック) を含む X-Forwarded-For ヘッダー フィールドが HTTP 要求に追加されます。 適切なネットワーク デバイス (ロード バランサー、ファイアウォール)、Web サーバー、またはバックエンド アプリケーションでは、その情報を読み取って使用できます。
複数のアプリケーション サーバー間での負荷分散のベスト プラクティス
アプリケーション プロキシ アプリケーションに割り当てられているコネクタ グループに 2 つ以上のコネクタがある場合は、負荷分散が重要です。 負荷分散は、複数のサーバーでバックエンド Web アプリケーションを実行する場合にも重要です。
シナリオ 1: バックエンド アプリケーションでセッション永続化が必要ない
最も簡単なシナリオでは、バックエンド Web アプリケーションにおいてセッション持続性 (セッション永続化) が必要ありません。 バックエンド アプリケーション インスタンスは、サーバー ファーム内のユーザー要求を処理します。 レイヤー 4 のロード バランサーを使用し、アフィニティなしで構成することができます。 一部のオプションには、Microsoft ネットワーク負荷分散と Azure Load Balancer または別のベンダーのロード バランサーが含まれます。 または、ラウンドロビン ドメイン ネーム システム (DNS) 戦略を構成します。
シナリオ 2: バックエンド アプリケーションでセッション永続化が必要である
このシナリオでは、認証されたセッションの間にバックエンド Web アプリケーションでセッション持続性 (セッション永続化) が必要です。 バックエンド アプリケーション インスタンスは、ユーザー要求を処理します。 要求は、サーバー ファーム内の同じサーバーで実行されます。 クライアントは普通、アプリケーション プロキシ サービスに複数の接続を確立するため、このシナリオはいっそう複雑になる可能性があります。 異なる接続での要求は、ファーム内の異なるコネクタおよびサーバーに到着する場合があります。 各コネクタではこの通信に対して独自の IP アドレスが使われるため、ロード バランサーではコネクタの IP アドレスに基づくセッションの持続性を保証できません。 ソース IP アフィニティも使用できません。 シナリオ 2 のいくつかのオプションを次に示します。
オプション 1: ロードバランサーによって設定されたセッション Cookie を基にして、セッションの永続化を実現します。 このオプションは、バックエンド サーバー間に負荷をいっそう均等に分散できるため推奨されます。 この機能を備えたレイヤー 7 ロード バランサーが必要であり、HTTP トラフィックを処理して、TLS 接続を終了することができます。 Azure Application Gateway (セッション アフィニティ) または別のベンダーのロード バランサーを使用できます。
オプション 2:セッションの永続化のベースとして、X-Forwarded-For ヘッダー フィールドを使用します。 このオプションでは、この機能を備えたレイヤー 7 ロード バランサーが必要であり、HTTP トラフィックを処理して、TLS 接続を終了することができます。
オプション 3:セッションの永続化が必要ないようにバックエンド アプリケーションを構成します。
バックエンド アプリケーションの負荷分散の要件については、お使いのソフトウェア ベンダーのドキュメントをご覧ください。