URI、リクエストパラメーター、HTTP ヘッダー、カスタム変数など、HTTP リクエストのさまざまな部分に基づいてキャッシュキーを生成するルールを作成することで、カスタムキャッシュキーを設定できます。この機能により、同じファイルに対するリクエストが単一のキャッシュキーに変換され、同じリクエストが異なるファイルとしてキャッシュされるのを防ぎます。その結果、キャッシュヒット率が向上し、オリジンフェッチが削減され、応答時間と帯域幅消費が減少します。
注意事項
カスタムキャッシュキー機能と無視パラメーター機能は相互排他です。無視パラメーターを設定している場合、CDN のポイントオブプレゼンス (POP) はリクエスト URL 内の疑問符 (
?) 以降のパラメーターを削除します。これにより、キャッシュキーに設定されたリクエストパラメーターが使用できなくなります。カスタムキャッシュキーを有効にする前に、無視パラメーター設定を一切行っていないことを確認してください。カスタムキャッシュキー機能は、リクエストのキャッシュ識別子のみを変更し、オリジンフェッチ URL は変更しません。オリジンフェッチリクエストの内容は、クライアントリクエストと同じままです。
カスタムキャッシュキーを設定した後、URL パージ機能ではキャッシュされたコンテンツをパージできません。
ユースケース
カスタムキャッシュキー機能は、リクエストのキャッシュ識別子のみを変更し、オリジンフェッチ URL は変更しません。オリジンフェッチリクエストの内容は、クライアントリクエストと同じままです。
キャッシュキーは、CDN ノードにキャッシュされるファイルの一意の識別子 (ID) です。デフォルトでは、ファイルのキャッシュキーは、そのパラメーターを含むリクエスト URL です。
ユースケース 1
リクエスト URL には複雑なパラメーターが含まれる場合があります。複数のリクエストが同じファイルに対するものであっても、URL パラメーターが異なる場合、POPs はそれらを異なるファイルに対するリクエストとして扱います。これにより、複数のキャッシュコピーが作成され、オリジンフェッチが増加します。
カスタムキャッシュキーのルールを作成して、これらのリクエストのキャッシュキーを統一し、オリジンフェッチを削減できます。
ユースケース 2
リクエストが同じ URL を持つ場合、CDN はそれらを同じファイルに対するリクエストと見なします。ただし、HTTP ヘッダーには異なるクライアントシステムを指定するクライアントフィールドが含まれている場合があり、これはリクエストが異なるファイルに対するものであることを意味します。
この場合、クライアントフィールドの値を含むカスタムキャッシュキーを作成できます。これにより、2 つのリクエストが 2 つの異なるキャッシュキーによって識別されます。
操作手順
「CDN コンソール」にログインします。
左側のナビゲーションウィンドウで、ドメイン名 をクリックします。
「ドメイン名」ページで、対象のドメイン名を見つけ、「操作」列の「管理」をクリックします。
ドメインのナビゲーションウィンドウで、キャッシュ設定 をクリックします。
カスタムキャッシュキー タブで、設定 をクリックしてキャッシュキーを設定します。
[パラメータータイプ]
手順
ルール条件
ルール条件は、ユーザーリクエスト内のさまざまなパラメーターを識別し、設定がリクエストに適用されるかどうかを判断します。
[使用しない]：ルール条件を使用しません。
ルール条件を追加または編集するには、[Rules Engine] で管理します。
URI
クライアントが要求したURIが設定済みのソース URIと一致すると、システムはソース URIを設定済みのターゲット URIに置き換えてキャッシュキーを構築します。
複数の URI 置き換えポリシーを設定できます。複数のポリシーが存在する場合、それらは上から下への順序で照合されます。ある ソース URI が照合されると、システムは対応する ターゲット URI を使用して置き換え操作を実行し、以降のポリシーの評価を停止します。
ソース URI：URI はスラッシュ (/) で開始し、http:// プレフィックスまたはドメイン名を含まないようにする必要があります。
PCRE正規表現がサポートされています。ターゲット URI: URI はスラッシュ (/) で始まります。`http://` プレフィックスやドメイン名は含みません。
リクエストパラメーター
操作の対象は、元のリクエスト URL のパラメーターです。追加、削除、変更、または予約パラメーターを選択できます。結果はキャッシュキーに追加されます。複数の操作を設定できます。複数の操作が設定されている場合、上から順に実行されます。
追加: キャッシュキーに新しいリクエストパラメーターを追加します。たとえば、元の URL が
http://image.example.com/cat.jpgで、リクエストパラメーターtype=jpgを追加すると、キャッシュキーはhttp://image.example.com/cat.jpg?type=jpgになります。削除: キャッシュキーを生成する際に、元のリクエスト URL から指定されたパラメーターを削除します。たとえば、元の URL が
http://image.example.com/cat.jpg?type=jpgで、パラメーターtypeを削除した場合、キャッシュキーはhttp://image.example.com/cat.jpgになります。変更: CacheKey を生成する際、元のリクエスト URL の指定されたパラメーターを変更します。例: 元の URL は
http://image.example.com/cat.jpg?type=jpgで、パラメーターtype=pngを変更すると、CacheKey は。予約: キャッシュキーを生成する際に、元のリクエスト URL から指定されたパラメーターのみを保持します。たとえば、元の URL が
http://image.example.com/cat.jpg?type=jpg&path=imageで、パラメーターtypeを保持する場合、キャッシュキーはhttp://image.example.com/cat.jpg?type=jpgになります。
HTTP ヘッダー
クライアントの元のリクエストから指定された HTTP ヘッダーの値をキャッシュキーに追加します。複数の HTTP ヘッダー名を設定します (スペースで区切ります)。各 HTTP ヘッダーの値は、順序どおりにキャッシュキーに追加されます。
たとえば、元の URL が
http://image.example.com/cat.jpgで、クライアントのリクエストにHTTP ヘッダー (path: image)が含まれている場合、HTTP ヘッダー にpathヘッダーが含まれていると、キャッシュキーはhttp://image.example.com/cat.jpgimageになります。カスタム変数
正規表現を使用して、指定されたリクエストパラメーター、HTTP ヘッダー、Cookie、または元のクライアントリクエスト内の指定された URI の値を照合できます。照合が見つかると、照合された値がキャッシュキーに追加されます。詳細については、「設定例」をご参照ください。
OK をクリックします。
設定例
URI
http://aliyundoc.com/a/b/image.jpg と http://aliyundoc.com/a/b/c/image.jpg へのリクエストは、同じファイルへのリクエストとして扱われます。そのファイルのキャッシュキーは http://aliyundoc.com/c/image.jpg です。
リクエストパラメーター
リクエスト先の http://aliyundoc.com/a/b/image.jpg?delete_par=1&modify_par=1 に対して、このルールは add_par=1 を追加し、delete_par を削除し、modify_par の値を 2 に変更します。最終的なキャッシュキーは、URL http://aliyundoc.com/a/b/image.jpg?modify_par=2&add_par=1 を基に生成されます。
同じ変数に対して複数の操作が実行される場合、優先順位は次のとおりです：追加 > 削除 > 保持 > 変更。
HTTP ヘッダー
User-Agent および Accept-Language HTTP ヘッダーの値は、キャッシュキーに追加されます。たとえば、http://aliyundoc.com/a/b/image.jpg へのリクエストに User-Agent=Mozilla/5.0 (Linux; X11) および Accept-Language=en が含まれている場合、このリクエストのキャッシュキーは http://aliyundoc.com/a/b/image.jpgMozilla/5.0(Linux;X11)en となります。
カスタム変数
例 1
変数名をlanguageに、ソースをRequest Headerに、ソースフィールドをAccept-Languageに、一致ルールを([%w]+),([%w]+)に、変数式を$1aaに設定します。
クライアントが http://aliyundoc.com/a/b/image.jpg をリクエストし、HTTP ヘッダー Accept-Language=en,ch を送信します。マッチルールは en を $1 としてキャプチャします。変数式ではこのキャプチャグループを使用し、aa を追加して値 enaa を生成します。この値はエイリアス language を使用し、URL に追加されて最終的なキャッシュキーを形成します：http://aliyundoc.com/a/b/image.jpgenaa。
変数式では、$n は、ルール内の n 番目のグループによってキャプチャされた内容を指します。 たとえば、文字列が Accept-Language=en,ch で、ルールが ([%w]+),([%w]+) の場合、$1 is en、$2 is ch となります。
例 2
変数名を expired に、ソースを Request Cookie に、ソースフィールドを a に、一致ルールを [%w]+:(.*) に、変数式を $1 に設定します。
クライアントがクッキー Cookie a=expired_time:12635187 を使用して http://aliyundoc.com/a/b/image.jpg をリクエストすると、一致ルールが値 12635187 を抽出し、変数式 $1 に割り当てます。この変数のエイリアスは expired です。この値は URL に追加され、最終的なキャッシュキー http://aliyundoc.com/a/b/image.jpg12635187 が作成されます。
例 3
URI ルールとカスタム変数を設定します。
URI：
URI が /abc/.*/abc と一致するすべてのリクエストを、/abc にマージします。
カスタム変数：
変数名を testname に、ソースを Path に、一致ルールを /abc/xyz/(.*) に、変数式を $1 に設定します。
クライアントが URL http://aliyundoc.com/abc/xyz/abc/image.jpg を要求します。URI 構成に基づき、この URL はマージされてキャッシュキー http://aliyundoc.com/abc/image.jpg が生成されます。次に、カスタム変数の構成に基づき、元の URL はパターン /abc/xyz/(.*) と一致します。この場合、変数 $1 に値 abc が割り当てられ、キャッシュキーに追加されます。最終的なキャッシュキーは http://aliyundoc.com/abc/image.jpgabc です。この 2 つのルールの組み合わせにより、より複雑なキャッシュ処理ロジックを実現できます。
リクエストがカスタム変数の一致ルールを満たさない場合、変数式 $1 はキャッシュキーに追加されません。
例 4
ルール条件とカスタム変数を設定して、モバイルクライアントと PC クライアントからのリクエストに対して異なるキャッシュキーを生成できます。
Mobile ルールの条件:
User-Agent に *Mobile*,*Android*,*iPhone*,*ipad* のいずれかが含まれています。
PC ルール条件:
User-Agent に *Mobile*,*Android*,*iPhone*,*ipad* のいずれも含まれません。
Mobile カスタムキャッシュキー：
「ルール条件」を Mobile に設定します。次に、「カスタム変数」で、「変数名」を Mobile に、「ソース」を Path に、「マッチングルール」を / に、および「変数式」を +mobile に設定します。
PC カスタムキャッシュキー：
ルール条件 を PC に設定します。カスタム変数 では、変数名 を PC に、ソース を Path に、マッチングルール を / に、変数式 を +pc に設定します。
クライアントが URL http://aliyundoc.com/image.jpg をリクエストします。 User-Agent の値に基づいて、リクエストは Mobile または PC のカスタムキャッシュキールールに一致します。 Mobile クライアントの場合、最終的なキャッシュキーは http://aliyundoc.com/image.jpg+mobile です。 PC クライアントの場合、最終的なキャッシュキーは http://aliyundoc.com/image.jpg+pc です。