アプリケーション要求ルーティング処理を使用した HTTP 負荷分散

[アーティクル]
03/26/2024

作成者: IIS チーム

概要

このトピックでは、高可用性とスケーラビリティを実現するために、HTTP 要求を負荷分散するようにアプリケーション要求ルーティング処理を構成する手順について説明します。また、このチュートリアルでは、アプリケーション要求ルーティング処理がコンテンツサーバーの正常性を監視し、クライアントからコンテンツサーバーへの要求を関連付ける方法に関するいくつかの主要な機能についても説明します。

目的

アプリケーション要求ルーティング処理を使用して、複数のコンテンツサーバー間で HTTP 要求を負荷分散する方法を以下に示します。

前提条件

このチュートリアルでは、次の前提条件が必要です。

Windows 2008 (任意の SKU) 以降の IIS 7.0 以降のバージョン。
Microsoft アプリケーション要求ルーティング処理バージョン 1 と依存モジュール。
サイトとアプリケーションが正常に実行されているコンテンツサーバー (2 台以上)。

このドキュメントに記載されている手順に従って、アプリケーション要求ルーティング処理をインストールします。

もう 1 つの前提条件は、アプリケーション要求ルーティング処理 (ARR) サーバーグループの定義と構成に関する記事に記載されている手順を使用して、リーダーが 1 つのサーバーファームを定義および構成済みであることです。

手順 1: URL 書き換え規則を確認する

アプリケーション要求ルーティング処理 (ARR) サーバーグループの定義と構成に関するページで説明されている手順を使用してサーバーファームが作成されている場合は、単純な負荷分散シナリオ用の URL 書き換え規則が既に作成されています。

UI を使用して URL 書き換え規則を確認するには:

IIS マネージャーを起動します。
サーバーファーム myServerFarm を選択します。これは、アプリケーション要求ルーティング処理 (ARR) サーバーグループの定義と構成に関するページで作成したものです。
次のアイコンが表示されます。
[Routing Rules]\(ルーティング規則\) をダブルクリックします。
[Use URL Rewrite to inspect incoming requests]\(URL 書き換えを使用して着信要求を調べる\) チェックボックスがオンになっていることを確認します。
SSL オフロードは、既定で有効になっています。この機能を有効にすると、ARR サーバーとアプリケーションサーバー間のすべての通信がクリアテキストで行われます。これにはクライアントから ARR サーバーへの HTTPS 要求も含まれます。 ARR サーバーとアプリケーションサーバーの両方が、同じデータセンター内などの信頼されたネットワーク内に展開されている場合、SSL オフロードを有効にしてもセキュリティは犠牲になりません。また、この機能を有効にすると、要求と応答の暗号化と復号化にサイクルを費やす必要がないため、さらにアプリケーションサーバー上のサーバーリソースを最大化するのに役立ちます。
SSL オフロードを無効にするには、[Enable SSL offloading]\(SSL オフロードを有効にする\) チェックボックスをオフにして、[Apply]\(適用\) をクリックします。
ブラウザーを開き、ARR サーバーにいくつかの要求を送信します。
要求がアプリケーションサーバー間で均等に負荷分散されていることを確認するには、[myServerFarm] を選択します。 [Monitoring and Management]\(監視と管理\) をダブルクリックします。
ダッシュボードビューで、要求が均等に分散されていることを確認します。

コマンドラインを使用して URL 書き換え規則を確認するには:

管理者特権でコマンドプロンプトを開きます。
%windir%\system32\inetsrv に移動します。

URL 書き換え規則が正しく作成されたことを確認するには、「appcmd.exe list config -section:system.webServer/rewrite/globalRules」と入力します。次のような globalRules が返されます。

<system.webServer>
    <rewrite>
        <globalRules>
            <rule name="ARR_myServerFarm_loadbalance" patternSyntax="Wildcard"
            stopProcessing="true">
                <match url="*" />
                <conditions>
                </conditions>
                <action type="Rewrite" url="http://myServerFarm/{R:0}" />
            </rule>
        </globalRules>
    </rewrite>
</system.webServer>

SSL オフロードを無効にするには、最初にすべての URL 書き換え規則を削除します。

appcmd.exe clear config -section:system.webServer/rewrite/globalRules

次に、HTTPS トラフィックを転送する URL 書き換え規則を作成します。具体的には、この規則を使用すると、着信要求が HTTPS の場合、ARR は SSL を使用して要求を転送します。

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/+"[name='ARR_myServerFarm_loadbalance_SSL',patternSyntax='Wildcard',stopProcessing='True']"
/commit:apphost

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/[name='ARR_myServerFarm_loadbalance_SSL',patternSyntax='Wildcard',stopProcessing='True'].match.url:"*"
/commit:apphost

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/+"[name='ARR_myServerFarm_loadbalance_SSL',patternSyntax='Wildcard',stopProcessing='True'].conditions.[input='{HTTPS}',pattern='On']"
/commit:apphost

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/[name='ARR_myServerFarm_loadbalance_SSL',patternSyntax='Wildcard',stopProcessing='True'].action.type:"Rewrite"
/[name='ARR_myServerFarm_loadbalance_SSL',patternSyntax='Wildcard',stopProcessing='True'].action.url:"https://myServerFarm/{R:0}"
/commit:apphost

最後に、HTTP トラフィックをクリアテキストでアプリケーションサーバーに転送する URL 書き換え規則を作成します。

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/+"[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True']"
/commit:apphost

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True'].match.url:"*"
/commit:apphost

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True'].action.type:"Rewrite"
/[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True'].action.url:"http://myServerFarm/{R:0}"
/commit:apphost

SSL オフロードを無効にした状態で、URL 書き換え規則が正しく作成されたことを確認するには、「appcmd.exe list config -section:system.webServer/rewrite/globalRules」と入力します。次のような globalRules が返されます。

<system.webServer>
    <rewrite>
        <globalRules>
            <rule name="ARR_myServerFarm_loadbalance_SSL" patternSyntax="Wildcard"
            stopProcessing="true">
                <match url="*" />
                <conditions>
                <add input="{HTTPS}" pattern="On" />
                </conditions>
                <action type="Rewrite" url="https://myServerFarm/{R:0}" />
            </rule>
            <rule name="ARR_myServerFarm_loadbalance" patternSyntax="Wildcard"
            stopProcessing="true">
                <match url="*" />
                <conditions>
                </conditions>
                <action type="Rewrite" url="http://myServerFarm/{R:0}" />
            </rule>
        </globalRules>
    </rewrite>
</system.webServer>

手順 2: 正常性チェックの監視を構成する

アプリケーション要求ルーティング処理では、次の 2 つの方法でコンテンツサーバーの正常性を監視します。

ライブトラフィックを使用
明示的な URL テストを使用

ライブトラフィックのテストは、アプリケーション要求ルーティング処理への要求が行われると、既定で自動的に実行されます。明示的な URL テストは、ライブトラフィックのテストで使用できる追加のテストです。このセクションでは、明示的な URL テストを構成する手順について説明します。

UI を使用して正常性チェックの監視を構成するには:

URL テストには、テストする具体的な URL が必要です。この要件を満たすために、メモ帳を使用して、「healthCheck.txt」という名前のテキストファイルを作成し、「正常です。」という文を含めます。
healthCheck.txt ファイルをアプリケーションサーバーに配置します。
ブラウザーでページを開いて、healthCheck.txt が正しくレンダリングされていることを確認します。
IIS マネージャーで、サーバーファーム「myServerFarm」を選択します。次のアイコンが表示されます。
[Health Test]\(正常性テスト\) をダブルクリックします。
URL 値として「http://(server name or FQDN of ARR server)/healthCheck.txt」と入力します。
[Response match]\(応答の一致\) の値として「正常」と入力します。応答の一致は、応答の本文に想定される文字列が含まれていることを確認するオプションのテストです。この場合、healthCheck.txt には「正常です。」という分が含まれているので、応答の一致では「正常」という単語が検索されます。
[適用] をクリックして変更を保存します。
正常性チェックの監視の機能を検証するために、いずれかのアプリケーションサーバーで監視対象サイトを停止します。 [Interval (seconds)]\(間隔 \(秒\)\) の値は 30 秒に設定されているため、次の正常性チェックまで 30 秒間待機します。
30 秒間待機した後、複数の要求を ARR サーバーに送信します。
すべての要求が正常なサーバーに送信されることを確認するには、[Monitoring and Management]\(監視と管理\) をダブルクリックし、F5 キーを使用してダッシュボードを更新します。ランタイム統計がリセットされていることに注意してください。これは仕様です。必要に応じて追加の要求を送信し、ダッシュボードを更新できます。
正常性の監視は、異常のあったサーバーが正常になったことを検出するためにも使用されます。この機能を検証するには、手順 9 で停止したサイトを開始します。ここでも、[Interval (seconds)]\(間隔 \(秒\)\) の値は 30 秒に設定されているため、次の正常性チェックまで 30 秒間待機します。
30 秒間待機した後、複数の要求を ARR サーバーに送信します。
要求がサーバー間で均等に分散されていることを確認するには、IIS マネージャーでダッシュボードを更新します。ランタイム統計がリセットされていることに注意してください。これは仕様です。必要に応じて追加の要求を送信し、ダッシュボードを更新できます。

コマンドラインを使用して正常性チェックの監視を構成するには:

管理者特権でコマンドプロンプトを開きます。
%windir%\system32\inetsrv に移動します。

一致する文字列として「正常です。」が含まれる http://(server name or FQDN of ARR server)/healthCheck.txt を URL に設定するには、次のように入力します。

appcmd.exe set config -section:webFarms
/[name='myServerFarm1'].applicationRequestRouting.healthCheck.url:"http://(server
name or FQDN of ARR server)/healthCheck.txt "
/[name='myServerFarm1'].applicationRequestRouting.healthCheck.responseMatch:"I am
healthy." /commit:apphost

手順 3: クライアントアフィニティを構成する

アプリケーション要求ルーティング処理には、クライアントセッションの間、アプリケーション要求ルーティング処理の背後にあるコンテンツサーバーにクライアントをマップするクライアントアフィニティ機能が用意されています。この機能を有効にすると、負荷分散アルゴリズムはクライアントからの最初の要求にのみ適用されます。その時点から、同じクライアントからの後続のすべての要求は、クライアントセッションの間、同じコンテンツサーバーにルーティングされます。この機能は、コンテンツサーバー上のアプリケーションがステートフルであり、セッション管理が一元化されていないために、クライアントの要求を同じコンテンツサーバーにルーティングする必要がある場合に便利です。

UI を使用してクライアントアフィニティを構成するには:

IIS マネージャーを起動します。
サーバーファーム myServerFarm を選択します。これは、アプリケーション要求ルーティング処理 (ARR) サーバーグループの定義と構成に関するページで作成したものです。
次のアイコンが表示されます。
[Server Affinity]\(サーバーアフィニティ\) をダブルクリックします。
クライアントアフィニティを有効にするには、[Client affinity]\(クライアントアフィニティ\) チェックボックスをオンにして、[Apply]\(適用\) をクリックします。

アプリケーション要求ルーティング処理では、Cookie を使用してクライアントアフィニティを有効にします。 [Cookie name]\(Cookie 名\) は、クライアントで Cookie を設定するために使用されます。つまり、クライアントアフィニティが正常に機能するためには、クライアントが Cookie を受け入れる必要があります。
クライアントアフィニティの機能を検証するために、ARR サーバーにいくつかの要求を送信します。 IIS マネージャー ([Monitoring and Management]\(監視と管理\)) でダッシュボードを更新します。クライアントが関連付けられているアプリケーションサーバーの 1 つのみに対して、ランタイム統計が変更されていることを確認します。必要に応じて追加の要求を送信し、ダッシュボードを更新できます。

コマンドラインを使用してクライアントアフィニティを構成するには:

管理者特権でコマンドプロンプトを開きます。
%windir%\system32\inetsrv に移動します。

クライアントアフィニティを有効にするには、次のように入力します。

appcmd.exe set config -section:webFarms
/[name='myServerFarm1'].applicationRequestRouting.affinity.useCookie:"True"
/commit:apphost

手順 4: 新しい接続を許可しない

サーバーで新しい接続を許可しないことで、サーバーファーム環境からサーバーを適切に取り出すことができます。アプリケーション要求ルーティング処理では、新しい接続を許可しない場合、既存のセッションが優先されるため、この設定はクライアントアフィニティ機能が使用されているときにとくに有効です。つまり、クライアントが新しい接続を許可しないサーバーに関連付けられていると、クライアントは引き続き同じサーバーにルーティングされるため、クライアントへの影響はありません。ただし、新しい接続を許可しないサーバーに、新しいクライアントはルーティングされません。

UI を使用して、新しい接続を許可しないようにするには:

上記の手順 3 のセットアップを使用して、クライアントが関連付けられているサーバーを特定します。
サーバーファーム myServerFarm を選択します。これは、アプリケーション要求ルーティング処理 (ARR) サーバーグループの定義と構成に関するページで作成したものです。
次のアイコンが表示されます。
[Monitoring and Management]\(監視と管理\) をダブルクリックします。
クライアントが関連付けられているサーバーを選択します。 [操作] ウィンドウで、[Disallow New Connections]\(新しい接続を許可しない\) をクリックします。
確認のダイアログボックスで [はい] をクリックします。
クライアントからの要求が関連付けられているサーバーにルーティングされ続け、新しい接続が許可されていないことを確認するために、ARR サーバーに複数の要求を送信します。 IIS マネージャーでダッシュボードを更新します。クライアントが関連付けられているアプリケーションサーバーのみに対して、ランタイム統計が変更されていることを確認します。必要に応じて追加の要求を送信し、ダッシュボードを更新できます。
新しい接続が許可されていないサーバーに、新しいクライアントがルーティングされていないことを確認するには、ブラウザーを閉じて再起動し、アプリケーション要求ルーティング処理で設定された Cookie を削除します。
ARR サーバーにいくつかの要求を送信します。 IIS マネージャーでダッシュボードを更新します。 [Available]\(使用可能\) のサーバーのみに対して、ランタイム統計が変更されていることを確認します。具体的には、新しい接続を許可していないサーバーのランタイム統計が変更されていないことを確認します。必要に応じて追加の要求を送信し、ダッシュボードを更新できます。

まとめ

これで、スケールアウトして負荷を均等に分散するように、アプリケーション要求ルーティング処理の複数の設定が正常に構成されました。アプリケーション要求ルーティング処理を使用したより高度なルーティング機能については、「アプリケーション要求ルーティング処理モジュールの使用」を参照してください。

次の方法で共有

アプリケーション要求ルーティング処理を使用した HTTP 負荷分散

概要

目的

前提条件

手順 1: URL 書き換え規則を確認する

手順 2: 正常性チェックの監視を構成する

手順 3: クライアントアフィニティを構成する

手順 4: 新しい接続を許可しない

まとめ

フィードバック

その他のリソース

次の方法で共有

アプリケーション要求ルーティング処理を使用した HTTP 負荷分散

概要

目的

前提条件

手順 1: URL 書き換え規則を確認する

手順 2: 正常性チェックの監視を構成する

手順 3: クライアント アフィニティを構成する

手順 4: 新しい接続を許可しない

まとめ

フィードバック

その他のリソース

手順 3: クライアントアフィニティを構成する