CDN での Application Request Routing の展開

[アーティクル]
12/11/2009

公開日: 2009 年 7 月 16 日 (作業者: wonyoo (英語))

更新日: 2009 年 9 月 23 日 (作業者: wonyoo (英語))

目標

CDN/ECN 環境における 2 層キャッシュ階層展開で、子/エッジキャッシュノードおよび親キャッシュノードを正しく構成すること。このチュートリアルでは、子/エッジキャッシュノードおよび親キャッシュノードでの URL 書き換えルールについて理解することに焦点を当てています。最終的に、このチュートリアルでは、以下の図に示す構成をセットアップするための手順について順を追って説明します。

Ee886293.SANcachetopo(ja-jp,TechNet.10).jpg

この構成の特長を以下にいくつか紹介します。

元の参照は、子/エッジキャッシュノードによって行われます。
- カスタマーの一覧 (つまり、受け入れ可能な配信元サーバーの一覧) は、URL 書き換えの書き換えマップを使用して明示的に管理されます。
- 書き換えマップで見つからないホスト名はブロックされます。
ほとんどの場合、親キャッシュノードはフォワードプロキシとして構成されます。
SAN は、子/エッジキャッシュノードで共有されるように構成されます。
- 事実上、以下の 3 層のキャッシュが存在します。
  1. 子/エッジキャッシュノード。
  2. SAN。
  3. 親キャッシュノード。

必要条件

このチュートリアルの前提として、ARR Version 2 のディスクキャッシュおよびキャッシュ階層管理の構成に精通していることが必要です。そうでない場合は、構成を開始する前に以下のチュートリアルを参照しておくことを強くお勧めします。

Application Request Routing Version 2 RC をインストールしていない場合は、以下の場所からダウンロードできます。

Microsoft Application Request Routing Version 2 for IIS 7.0 RC (x86) をダウンロード(英語) 。
Microsoft Application Request Routing Version 2 for IIS 7.0 RC (x64) をダウンロード(英語)。

ARR Version 2 RC をインストールするには、このドキュメントに記載されている手順に従います。

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

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

この記事に従ってディスクキャッシュを構成および有効化します。この記事では、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 で展開するのに不十分です。

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

CDN/ECN のカスタマーは、サブドメインとして指定されます。この場合、子キャッシュノードの同じ IP アドレスに対するホスト名バインディングの数が多くなる可能性があります。
例: http://customer1.mycnd.net/、http://customer2.mycdn.net/ など。
CDN/ECN のカスタマーは、URL の最初のパスとして指定されます。
例: http://static.mycdn.net/customer1/、http://static.mycdn.net/customer2/ など。

このチュートリアルでは、1 番目の例を使用して説明します。2 番目のシナリオを有効にする場合も、同じようなルールを作成できます。

配信元サーバーのホスト名の参照に使用できる URL 書き換えマップを定義します。IIS マネージャーを起動します。
サーバーのルートを選択して展開します。これが、子 (エッジ) キャッシュノードです。
[URL 書き換え] をダブルクリックします。
[操作] ウィンドウで、[書き換えマップの表示...] をクリックします。
[操作] ウィンドウで、[書き換えマップの追加...] をクリックします。
[書き換えマップの追加] ダイアログボックスで、書き換えマップの名前「OriginServers」を入力します。
この書き換えマップで、子キャッシュノードが受信するホスト名とこれに対応する配信元のホスト名とのマッピングを明示的に指定します。[操作] ウィンドウで、[マッピングエントリの追加...] をクリックします。
[マッピングエントリの追加] ダイアログボックスで、子キャッシュノードが受信するホスト名と配信元のホスト名を追加します。以下の例では、ARR の子キャッシュノードは、ホスト名ヘッダーとして customer1.mycdn.net を受信します。これに対応する配信元サーバーは images.customer1.com です。
CDN/ECN のサービス提供先に追加する必要があるすべてのカスタマーの数に応じて手順 8 を繰り返します。このようにして、サービス提供先が自分のカスタマーのみとなるようにカスタマーの明示的な一覧を管理できます。
書き換えマップの一覧にないカスタマーをブラックリストに追加するには、この書き換えマップの既定値を「#」に設定します。この値は、RFC に準拠した、ホスト名ヘッダーの一部として使用できない無効な文字です。[操作] ウィンドウで、[マップ設定の編集...] をクリックします。
[書き換えマップの編集] ダイアログボックスで、この書き換えマップの既定値に「#」と入力します。
OriginServers 書き換えマップで構成したルールでホスト名ヘッダーを書き換えます。キャッシュ失敗が発生し、要求が親キャッシュノードにルーティングされる場合、要求には配信元サーバーに一致するホスト名が含まれます。こうした理由から、ほとんどの場合、親キャッシュノードはフォワードプロキシとして構成されます。親キャッシュノードでキャッシュ失敗が発生すると、要求は単に、親キャッシュノードが受信するホスト名ヘッダーに基づいて配信元サーバーにルーティングされます。
URL 書き換えの UI で、ルールを見つけます。このチュートリアルでは、ルールの名前は、ARR_myParentCacheNodes_loadbalance となります。
ルールを選択し、[操作] ウィンドウで、[編集...] をクリックします。
[条件の追加] をクリックして、2 つのルールを追加します。
1 番目のルールでは、手順 6 で作成した OriginServers 書き換えマップを使用します。以下のルールにより、OriginServers のエントリに一致するキーとしてホストヘッダーが照合されます。
2 番目のルールでは、ホストヘッダーが OriginServers のエントリに一致しなかった場合に既定値を「#」として設定します。前述したように、# は有効な文字ではなく、ホスト名として使用できません。以下のルールは後で使用され、OriginServers のカスタマー (ホスト名で表される) のみが ARR によって処理されます。
[条件間でキャプチャグループを追跡] を選択します。
上記の条件に一致するように HTTP_HOST 値を設定するには、[サーバー変数...] をクリックします。
以下に示す値を入力して、HTTP_HOST をリセットします。
[OK] をクリックして、変更を保存します。
[操作] ウィンドウで、[適用] をクリックして、変更を保存します。
正しいルールが作成されていることを確認するには、メモ帳を使用し、applicationHost.config ファイルを開きます。構成ファイルは、%windir%\system32\inetsrv\config\ にあります。

サーバーファームの URL 書き換えルールである myParentCacheNodes を見つけます。ルールは次のようになります。

<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 書き換え] をダブルクリックします。
[操作] ウィンドウで、[規則の追加...] をクリックします。
[規則の追加] ダイアログボックスで、[空の規則] を選択します。
以下の値を入力し、ルールを保存します。
[名前:] 「顧客以外」
[使用:] 「ワイルドカード」
[パターン:] 「*」
[アクションの種類:] 「カスタム応答」
[ステータスコード:] 「400」
[サブステータスコード:] 「0」
ルールの順序は重要です。URL 書き換えルールは上から下に処理されます。この例では、受信ホスト名が上記の書き換えマップで指定されたホスト名のいずれかに一致する場合は、1 番目のルールである ARR_myParentCacheNodes_Loadbalance が実行されます。受信ホスト名が上記の書き換えマップで定義されたホスト名のどれにも一致しない場合は、2 番目の規則である Not my customer が実行されます。
子/エッジキャッシュノードの構成が完了しました。

追加の子キャッシュノードの構成を簡略化するために、子キャッシュノードの構成を 1 か所のみで管理するように共有構成を使用できます。それ以外の場合、上記の構成変更は CDN/ECN 環境の子キャッシュノードすべてに対して個別に行う必要があります。共有構成の詳細については、この記事を参照してください。

親キャッシュノードを構成する

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

ARR をフォワードプロキシとしてセットアップする。
書き換えマップを使用して、ARR を "リバース" プロキシとしてセットアップする。

上記の 2 番目のオプションを使用する場合も、書き換えマップは単に受信ホスト名を同じ値で書き換え、事実上のフォワードプロキシを実現します。書き換えマップは上記の子キャッシュノードの構成方法と同じように、親キャッシュが許可するホスト名の一覧を明示的に構成するために使用します。このチュートリアルの後半では、1 番目のオプションを簡単なフォワードプロキシとして使用して、親キャッシュノードを構成します。