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

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

作成者: Won Yoo

ドキュメントのこのセクションは、IIS 7 以降向けの Microsoft アプリケーション要求ルーティング処理バージョン 2 に適用されます。

目的

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

配信元サーバー、親ノード、子ノード、および 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 つあります。

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

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

配信元サーバーのホスト名を検索する際に使用できる URL 書き換えマップを定義します。 IIS マネージャーを起動します。
サーバーのルートを選択して展開します。これは、子 (エッジ) キャッシュノードです。
[URL 書き換え] をダブルクリックします。
[操作] ウィンドウで、[書き換えマップの表示] をクリックします。
[操作] ウィンドウで、[書き換えマップの追加] をクリックします。
[書き換えマップの追加] ダイアログボックスで、書き換えマップに「OriginServers」という名前を付けます。
子キャッシュノードに送信されるホスト名とそれに対応する配信元ホスト名との間のマッピングを、書き換えマップで明示的に指定します。 [操作] ウィンドウで、[マッピングエントリの追加] をクリックします。
[マッピングエントリの追加] ダイアログボックスに、子キャッシュノードで受信するホスト名と配信元ホスト名を追加します。以下の例では、ARR の子キャッシュノードが、ホスト名ヘッダーとして customer1.mycdn.net を受信します。対応する配信元サーバーは images.customer1.com です。
手順 8. を繰り返して、CDN/ECN のサービスを受けるすべての利用者を追加します。このように利用者のリストを明示的に管理して、特定の利用者にのみサービスを提供することができます。
書き換えマップのリストに含まれていない利用者をブロックするには、RFC に従って、この書き換えマップの既定値を # (ホスト名ヘッダーの中で使用できない無効な文字) に設定します。 [操作] ウィンドウで、[マップ設定の編集] をクリックします。
[Edit Rewrite Map](書き換えマップの編集) ダイアログボックスで、この書き換えマップの既定値として「#」と入力します。
OriginServers 書き換えマップに構成されているルールでホスト名ヘッダーを書き換えます。キャッシュミスがあり、要求が親キャッシュノードにルーティングされると、その要求には、配信元サーバーと一致するホスト名が割り当てられます。このため、ほとんどの場合、親キャッシュノードは転送プロキシとして構成されます。親キャッシュノードでキャッシュミスが発生した場合、要求は、親キャッシュノードに送信されたホスト名ヘッダーに基づいて配信元サーバーにルーティングされます。
URL 書き換え UI で、該当するルールを見つけます。このチュートリアルでは、ルールの名前が ARR_myParentCacheNodes_loadbalance となっているはずです。
ルールを選択し、[操作] ウィンドウで [編集] をクリックします。
[条件の追加] をクリックして 2 つのルールを追加します。
1 つ目のルールでは、手順 6. で作成した OriginServers 書き換えマップを使用します。次のルールでは、OriginServers 内のエントリに対応付けるためのキーとしてホストヘッダーを使用します。
2 つ目のルールでは、ホストヘッダーが OriginServers 内のエントリと一致しない場合の既定値として # を設定します。前述のように、# は有効な文字ではないため、ホスト名として使用することはできません。次のルールは、後で ARR のサービスを OriginServers 内の (ホスト名で表される) 利用者に限定する目的で使用されます。
[Track capture groups across conditions](条件全体でキャプチャグループを追跡する) をオンにします。
上記の条件に一致するように HTTP_HOST 値を設定するために、[サーバー変数] をクリックします。
HTTP_HOST をリセットするために次の値を入力します。
[OK] をクリックして変更を保存します。
[操作] ペインで [適用] をクリックし、変更内容を保存します。
ルールが正しく書き込まれたことを確認するために、メモ帳を使用して applicationHost.config ファイルを開きます。構成ファイルは %windir%\system32\inetsrv\config\ にあります。

サーバーファーム (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>

(強く推奨) 上記の書き換えマップで定義されているホスト名と一致しない要求をブロックするには、そのような要求に対して 400 応答を送信する既定の URL 書き換えルールを作成します。

IIS マネージャーを起動します。
サーバーのルートを選択して展開します。これは、子 (エッジ) キャッシュノードです。
[URL 書き換え] をダブルクリックします。
[操作] ウィンドウで [ルールの追加] をクリックします。
[ルールの追加] ダイアログボックスで、[空のルール] を選択します。
次の値を入力してルールを保存します。
名前: Not my customer
使用する: ワイルドカード
パターン: *
アクションの種類: Custom Response
状態コード: 400
サブ状態コード: 0
ルールの順序は重要です。 URL 書き換えルールは上から下に処理されます。この例では、受信ホストの名前が、上記の書き換えマップに指定されたいずれかのホスト名と一致する場合に、最初のルール ARR_myParentCacheNodes_Loadbalance が実行されます。受信ホストの名前が、上記の書き換えマップに定義されているどのホスト名とも一致しない場合、2 つ目のルール (Not my customer) が実行されます。
子/エッジキャッシュノードの構成は、これで完了です。

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

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

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

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

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