次の方法で共有


CDN でのアプリケーション要求ルーティング処理の展開

作成者: Won Yoo

このドキュメント セクションは、IIS 7 以降向けの Microsoft アプリケーション要求ルーティング処理バージョン 2 を対象としています。

目的

コンテンツ配信ネットワーク/エッジ キャッシュ ネットワーク (CDN/ECN) 環境への 2 層キャッシュ階層展開で子/エッジ キャッシュ ノードと親キャッシュ ノードを正しく構成する。 このチュートリアルのねらいは、子/エッジ キャッシュ ノードと親キャッシュ ノードにおける URL 書き換えルールについて理解することです。 最終的には、次の構成をセットアップするステップ バイ ステップの手順をひととおり体験します。

Diagram showing an overview of the connection between the origin server, parent nodes, child nodes, and S A N.

以下に、この構成の要となる部分を示します。

  • 配信元の参照は、子/エッジ キャッシュ ノードによって実行されます。

    • 利用者の一覧 (特定の条件を満たした配信元サーバーの一覧) は、URL 書き換えで書き換えマップを使用して明示的に管理されます。
    • 書き換えマップに見つからないホスト名はブロックされます。
  • 親キャッシュ ノードは、ほとんどの場合、転送プロキシとして構成されます。

  • SAN は、子/エッジ キャッシュ ノードによって共有されるように構成されています。

    • 実際には、キャッシュには 3 つの層があります。

      1. 子/エッジ キャッシュ ノード。
      2. SAN。
      3. 親キャッシュ ノード。

前提条件

このチュートリアルは、読者が ARR バージョン 2 のディスク キャッシュとキャッシュ階層管理の構成について理解していることを前提としています。 次のチュートリアルをまだ読んでいない場合は、先に目を通しておくことを強くお勧めします。

アプリケーション要求ルーティング処理バージョン 2 がインストールされていない場合は、次のページからダウンロードできます。

  • IIS 7 (x86) 用 Microsoft アプリケーション要求ルーティング処理バージョン 2 (https://download.microsoft.com/download/4/D/F/4DFDA851-515F-474E-BA7A-5802B3C95101/ARRv2_setup_x86.EXE)。
  • IIS 7 (x64) 用 Microsoft アプリケーション要求ルーティング処理バージョン 2 (https://download.microsoft.com/download/3/4/1/3415F3F9-5698-44FE-A072-D4AF09728390/ARRv2_setup_x64.EXE)。

ARR バージョン 2 をインストールするには、「アプリケーション要求ルーティング処理バージョン 2 をインストールする」で説明されている手順に従います。

子/エッジ キャッシュ ノードを構成する

手順 1 - ディスク キャッシュを構成する

アプリケーション要求ルーティング処理バージョン 2 をインストールする」の記事に従って、ディスク キャッシュを構成して有効にします。 この記事では、セカンダリ キャッシュ ドライブの場所として使用するように SAN を構成する方法についても説明します。

手順 2 - 親キャッシュ ノードのサーバー ファームを定義する

アプリケーション要求ルーティング処理を使用したキャッシュ階層管理」の記事に従ってサーバー ファームを定義し、親キャッシュ ノードを追加します。

手順 3 - 子/エッジ キャッシュ ノードの URL 書き換えルールを追加作成する

この時点で、myParentCacheNodes をサーバー ファームの名前として、次の URL 書き換えルールが %windir%\system32\inetsrv\config\ の applicationHost.config ファイルに書き込まれています。

<rewrite>
   <globalRules>
      <rule name="ARR_myParentCacheNodes_loadbalance" patternSyntax="Wildcard" stopProcessing="true">
         <match url="*" />
         <action type="Rewrite" url="http://myParentCacheNodes/{R:0}" />
      </rule>
   </globalRules>
</rewrite>

上記のルールは CDN/ECN の展開において十分ではありません。キャッシュ ノードは階層化されており、次のキャッシュ ノード層 (すなわち、親キャッシュ ノード) には、親キャッシュ層でキャッシュ ミスがあった場合に配信元サーバーを見つける術がないためです。

このチュートリアルでは、要求が親キャッシュ ノードにルーティングされる前に、子キャッシュ ノードで配信元サーバーをマップすることで、この問題に対処します。 子キャッシュ ノードに送信された URL に基づいて配信元サーバーをマップする最も一般的な方法は 2 つあります。

  1. CDN/ECN の利用者をサブドメインとして指定します。 この場合、同じ IP アドレスの子キャッシュ ノードに対するホスト名のバインドが複数存在する可能性があります。
    たとえば、http://customer1.mycnd.net/http://customer2.mycdn.net/ などです。
  2. CDN/ECN の利用者を、URL の最初のパスとして指定します。
    たとえば、http://static.mycdn.net/customer1/http://static.mycdn.net/customer2/ などです。

このチュートリアルでは、最初の例を使ってデモンストレーションを行います。 2 番目のシナリオも同様のルールを記述して実現できます。

  1. 配信元サーバーのホスト名を検索する際に使用できる URL 書き換えマップを定義します。 IIS マネージャーを起動します。

  2. サーバーのルートを選択して展開します。 これは、子 (エッジ) キャッシュ ノードです。

    Screenshot showing the child cache node expanded.

  3. [URL 書き換え] をダブルクリックします。

  4. [操作] ウィンドウで、[書き換えマップの表示] をクリックします。

    Screenshot of the Actions pane showing the View Rewrite Maps option.

  5. [操作] ウィンドウで、[書き換えマップの追加] をクリックします。

    Screenshot of the Actions pane showing the Add Rewrite Map option.

  6. [書き換えマップの追加] ダイアログ ボックスで、書き換えマップに「OriginServers」という名前を付けます。

    Screenshot of the Add rewrite map dialog showing OriginServers in the input box.

  7. 子キャッシュ ノードに送信されるホスト名とそれに対応する配信元ホスト名との間のマッピングを、書き換えマップで明示的に指定します。 [操作] ウィンドウで、[マッピング エントリの追加] をクリックします。

    Screenshot of the Actions menu showing the Add Mapping Entry option.

  8. [マッピング エントリの追加] ダイアログ ボックスに、子キャッシュ ノードで受信するホスト名と配信元ホスト名を追加します。 以下の例では、ARR の子キャッシュ ノードが、ホスト名ヘッダーとして customer1.mycdn.net を受信します。 対応する配信元サーバーは images.customer1.com です。

    Screenshot of the Add Mapping Entry dialog with the example information entered.

  9. 手順 8. を繰り返して、CDN/ECN のサービスを受けるすべての利用者を追加します。 このように利用者のリストを明示的に管理して、特定の利用者にのみサービスを提供することができます。

  10. 書き換えマップのリストに含まれていない利用者をブロックするには、RFC に従って、この書き換えマップの既定値を # (ホスト名ヘッダーの中で使用できない無効な文字) に設定します。 [操作] ウィンドウで、[マップ設定の編集] をクリックします。

    Screenshot of the Actions menu.

  11. [Edit Rewrite Map](書き換えマップの編集) ダイアログ ボックスで、この書き換えマップの既定値として「#」と入力します。

    Screenshot of the Edit Rewrite Map dialog. The character # is in the Default value to use when key is not found in the map input box. OK is selected.

  12. OriginServers 書き換えマップに構成されているルールでホスト名ヘッダーを書き換えます。 キャッシュ ミスがあり、要求が親キャッシュ ノードにルーティングされると、その要求には、配信元サーバーと一致するホスト名が割り当てられます。 このため、ほとんどの場合、親キャッシュ ノードは転送プロキシとして構成されます。 親キャッシュ ノードでキャッシュ ミスが発生した場合、要求は、親キャッシュ ノードに送信されたホスト名ヘッダーに基づいて配信元サーバーにルーティングされます。

  13. URL 書き換え UI で、該当するルールを見つけます。 このチュートリアルでは、ルールの名前が ARR_myParentCacheNodes_loadbalance となっているはずです。

    Screenshot showing the example rule settings.

  14. ルールを選択し、[操作] ウィンドウで [編集] をクリックします。

  15. [条件の追加] をクリックして 2 つのルールを追加します。

  16. 1 つ目のルールでは、手順 6. で作成した OriginServers 書き換えマップを使用します。 次のルールでは、OriginServers 内のエントリに対応付けるためのキーとしてホスト ヘッダーを使用します。

    Screenshot of the Add Condition dialog showing origin server data with Pattern is set to *.

  17. 2 つ目のルールでは、ホスト ヘッダーが OriginServers 内のエントリと一致しない場合の既定値として # を設定します。 前述のように、# は有効な文字ではないため、ホスト名として使用することはできません。 次のルールは、後で ARR のサービスを OriginServers 内の (ホスト名で表される) 利用者に限定する目的で使用されます。

    Screenshot of the Add Condition dialog with Pattern set to the default.

  18. [Track capture groups across conditions](条件全体でキャプチャ グループを追跡する) をオンにします。

  19. 上記の条件に一致するように HTTP_HOST 値を設定するために、[サーバー変数] をクリックします。

  20. HTTP_HOST をリセットするために次の値を入力します。

    Screenshot of the Server Variables dialog.

  21. [OK] をクリックして変更を保存します。

  22. [操作] ペインで [適用] をクリックし、変更内容を保存します。

  23. ルールが正しく書き込まれたことを確認するために、メモ帳を使用して applicationHost.config ファイルを開きます。 構成ファイルは %windir%\system32\inetsrv\config\ にあります。

  24. サーバー ファーム (myParentCacheNodes) の URL 書き換えルールを見つけます。 つまり、次のようになります。

    <rewrite>
       <globalRules>
          <rule name="ARR_myParentCacheNodes_loadbalance" patternSyntax="Wildcard" stopProcessing="true">
             <match url="*" />
             <conditions trackAllCaptures="true">
                <add input="{OrigServers:{HTTP_HOST}}" pattern="*" />
                <add input="{C:1}" negate="true"  pattern="#" />
             </conditions>
             <serverVariables>
                <set name="HTTP_HOST" value="{C:1}" replace="true" />
             </serverVariables>
             <action type="Rewrite" url="http://myParentCacheNodes/{R:0}" />
          </rule>
       </globalRules>
    </rewrite>
    
  25. (強く推奨) 上記の書き換えマップで定義されているホスト名と一致しない要求をブロックするには、そのような要求に対して 400 応答を送信する既定の URL 書き換えルールを作成します。

    IIS マネージャーを起動します。

  26. サーバーのルートを選択して展開します。 これは、子 (エッジ) キャッシュ ノードです。

    Screenshot showing a server expanded.

  27. [URL 書き換え] をダブルクリックします。

  28. [操作] ウィンドウで [ルールの追加] をクリックします。

    Screenshot of the Actions menu showing the Add Rules option.

  29. [ルールの追加] ダイアログ ボックスで、[空のルール] を選択します。

    Screenshot of the Add rules dialog with Blank rule selected.

  30. 次の値を入力してルールを保存します。
    名前: Not my customer
    使用する: ワイルドカード
    パターン: *
    アクションの種類: Custom Response
    状態コード: 400
    サブ状態コード: 0

    Screenshot showing the rules variable dialog.

  31. ルールの順序は重要です。 URL 書き換えルールは上から下に処理されます。 この例では、受信ホストの名前が、上記の書き換えマップに指定されたいずれかのホスト名と一致する場合に、最初のルール ARR_myParentCacheNodes_Loadbalance が実行されます。 受信ホストの名前が、上記の書き換えマップに定義されているどのホスト名とも一致しない場合、2 つ目のルール (Not my customer) が実行されます。

    Screenshot showing 2 rules.

  32. 子/エッジ キャッシュ ノードの構成は、これで完了です。

構成する子キャッシュ ノードが他にもある場合、共有構成を利用できます。共有構成を使用した場合、子キャッシュ ノードの構成を 1 か所で管理できて効率的です。 それ以外の場合、CDN/ECN 環境内のすべての子キャッシュ ノードに対し、上記の構成変更を個別に行う必要があります。 共有構成の詳細については、「共有構成」の記事を参照してください。

親キャッシュ ノードの構成

ARR を親キャッシュ ノードとして構成するには、次の 2 つの方法があります。

  1. ARR を転送プロキシとして設定する。
  2. 書き換えマップを使用して、ARR を "リバース" プロキシとして設定する。

上記の 2 つ目の方法でも、書き換えマップは単に受信ホストの名前を同じ値で書き換えるだけで、実質的に転送プロキシになります。 先ほどの子キャッシュ ノードの構成と同様、書き換えマップは、親キャッシュが受け入れるホスト名の一覧を明示的に構成する目的で使用されます。 このチュートリアルの第 2 部では、1 つ目の方法を使用して、親キャッシュ ノードを単純な転送プロキシとして構成します。

手順 1 - ディスク キャッシュを構成する

アプリケーション要求ルーティング処理でディスク キャッシュを構成して有効にする」の記事に従って、ディスク キャッシュを構成して有効にします。

手順 2 - ARR を転送プロキシとして構成する

  1. ARR をプロキシとして有効にします。 IIS マネージャーを起動します。

  2. この構成には、サーバー ファームは含まれません。 すべての設定はサーバー レベルで行われます。

    Screenshot showing the server with expanded selections. The server name is highlighted.

  3. [アプリケーション要求ルーティング処理キャッシュ] をダブルクリックします。

    Screenshot showing the connections and main panes. The main pane shows the server function icons.

  4. [操作] ウィンドウで、[サーバー プロキシの設定] をクリックします。

    Screenshot of the Actions pane showing the Server Proxy Settings option.

  5. [プロキシの有効化] チェック ボックスをオンにし、[適用] をクリックします。 これで ARR が、サーバー レベルのプロキシとして有効になりました。

  6. ARR を転送プロキシにする場合は、ナビゲーション ウィンドウでサーバー ノードをクリックします。

    Screenshot showing navigation options.

  7. [URL 書き換え] をダブルクリックします。

  8. [操作] ウィンドウで [ルールの追加] をクリックします。

    Screenshot of the Actions pane showing the Add Rules option.

  9. [ルールの追加] ダイアログ ボックスで、[空のルール] を選択します。

    Screenshot showing the Add rules dialog. The Blank rule icon is highlighted.

  10. 次の値を入力してルールを保存します。
    名前: 転送プロキシ
    使用する: ワイルドカード
    パターン: *
    条件:
    入力: {HTTP_HOST}
    種類: 次のパターンと一致する
    パターン: *
    アクションの種類: 書き換え
    書き換え URL: http://{C:1}/{R:0}

    Screenshot showing the dialog with the example values.

  11. 親キャッシュ ノードの構成は、これで完了です。

    構成する親キャッシュ ノードが他にもある場合、共有構成を利用できます。共有構成を使用した場合、親キャッシュ ノードの構成を 1 か所で管理できて効率的です。 それ以外の場合、CDN/ECN 環境内のすべての親キャッシュ ノードに対し、上記の構成変更を個別に行う必要があります。 共有構成の詳細については、次の記事を参照してください。

まとめ

高度な URL 書き換えルールを使用して、2 層キャッシュ階層 CDN/ECN 環境の子キャッシュ ノードと親キャッシュ ノードを正しく構成しました。 「アプリケーション要求ルーティング処理でディスク キャッシュを構成して有効にする」の記事の手順 4. と手順 5. に従って機能を確認できます。 エラーが発生した場合は、「失敗した要求トレースの規則を使用したアプリケーション要求ルーティング処理のトラブルシューティング」の記事の手順に従って、失敗した要求トレースの規則を有効にしてください。

その他の ARR バージョン 2 のチュートリアルについては、「アプリケーション要求ルーティング処理バージョン 2 の概要」にあるドキュメントを参照してください。