カスタムキャッシュキーのルールは、URI、リクエストパラメーター、HTTP ヘッダー、カスタム変数など、HTTP リクエストの特定の部分からキャッシュキーを生成します。この機能は、同じリソースへのリクエストのキャッシュキーを統一することで、キャッシュヒット率を向上させ、オリジンフェッチを削減し、レスポンス時間を短縮して帯域幅の消費を削減します。
機能の比較と選択
カスタムキャッシュキーと パラメーターの無視 との競合：パラメーターフィルタリングとカスタムキャッシュキーの両方を同時に設定すると、パラメーターフィルタリングは無効になります。
カスタムキャッシュキー機能はより細かい制御を提供するため、パラメーターフィルタリングよりも推奨されます。次の表は、2つの機能を比較したものです。
ユースケース
パラメーターフィルタリング
カスタムキャッシュキー
キャッシュキー内のすべてのリクエストパラメーターを無視する
[パラメーターを無視] を [はい] に設定し、[指定したパラメーターを保持] フィールドを空白のままにします。
リクエストパラメーターのルールを追加します。[アクション] を [リザーブ] に設定し、[パラメーター名] を
example-argumentのような存在しないパラメーター名に設定します。キャッシュキーにリクエストパラメーター
key1のみ保持する[パラメーターを無視] を [はい] に設定し、[指定したパラメーターを保持] を
key1に設定します。リクエストパラメーターのルールを追加します。[アクション] を [リザーブ] に設定し、[パラメーター名] を
key1に設定します。キャッシュキーからリクエストパラメーター
key1のみ削除する[指定したパラメーターを削除] を
key1に設定します。リクエストパラメーターのルールを追加します。[アクション] を [削除] に設定し、[パラメーター名] を
key1に設定します。オリジンパラメーターの書き換え：カスタムキャッシュキー機能はキャッシュキーを変更するだけで、オリジンフェッチリクエストの URL は変更しません。オリジンフェッチリクエストは、クライアントリクエストと同じままです。オリジンに送信されるリクエストパラメーターを変更するには、オリジンパラメーターの書き換え を使用します。
キャッシュのパージ：カスタムキャッシュキーを設定した後、URLによるパージタスクがキャッシュされたコンテンツと一致しない場合があります。パージを正常に完了させるには、ルールによって生成された最終的なキャッシュキーをパージターゲットとして使用します。
ユースケース
キャッシュキーは、CDN の POP (Point of Presence) にキャッシュされたファイルを一意に識別するものです。キャッシュされた各ファイルには、対応するキャッシュキーがあります。デフォルトでは、キャッシュキーはパラメーターを含むクライアントのリクエスト URL です。カスタムキャッシュキー機能は、オリジンフェッチの URL を変更しません。キャッシュキーのみを変更します。オリジンフェッチリクエストは、クライアントの元のリクエストと同じままです。
CDN は静的リソースを高速化するように設計されており、動的 API の高速化はサポートしていません。カスタムキャッシュキー機能は、URL パラメーターの標準化やクライアント間の区別など、静的リソースのキャッシュ戦略を最適化するものであり、動的 API のキャッシュシナリオには適していません。動的コンテンツの高速化には、Edge Security Acceleration (ESA) の使用をご検討ください。
ユースケース1：リクエストの統合
クライアントからのリクエストが異なると、URL に含まれるパラメーターも異なることがよくあります。複数のリクエストが同じファイルを対象としている場合でも、CDN の POP は、URL パラメーターが異なるリクエストを別々のファイルとして扱います。これにより、複数のキャッシュコピーが作成され、追加のオリジンフェッチが発生します。
カスタムキャッシュキーのルールを使用すると、これらのリクエストのキャッシュキーを統一でき、オリジンフェッチ率を削減できます。
ユースケース2：リクエストの区別
クライアントリクエストの URL が同じである場合、CDN はそれらを同じファイルへのリクエストとして扱います。ただし、異なるクライアントシステムを識別する HTTP ヘッダーの client フィールドに基づいて、異なるコンテンツを配信する必要がある場合があります。
この場合、カスタムキャッシュキーのルールを使用して、client ヘッダーの値をキャッシュキーに追加します。これにより、クライアントタイプごとに個別のキャッシュキーが作成されます。
操作手順
Alibaba Cloud CDN コンソールにログインします。
[ドメイン名] ページで、管理対象のドメイン名を見つけ、[アクション] 列の [管理] をクリックします。
左側のナビゲーションペインで、[キャッシュ] を選択します。
カスタムキャッシュキー タブで、ルールの追加 をクリックして、次のパラメーターを設定します。
[ルール条件]
ルール条件は、リクエストに設定を適用するかどうかを判断するために、様々なパラメーターに基づいてそのリクエストを識別します。ルールがルール条件を使用する場合、実行順序は機能の優先度設定ではなく、ルール条件の優先度によって決まります。
使用しない：カスタムキャッシュキーは、ルール条件なしですべてのリクエストに適用されます。
ルール条件の追加または編集：ルールエンジンで管理します。詳細については、「ルール条件」および「ルールエンジン」をご参照ください。
[URI]
クライアントリクエストの URI が設定の ソース URI と一致すると、システムはそれを設定済みの ターゲット URI に置き換えてキャッシュキーを生成します。複数の URI 置換ポリシーを設定できます。ポリシーは上から下に順次照合されます。ソース URI が一致すると、システムは対応する ターゲット URI を適用し、後続のポリシーの照合を停止します。
[ソース URI]: スラッシュ (
/) で始まり、http://プレフィックスまたはドメイン名を含まない URI です。PCRE 正規表現に対応しています。[ターゲット URI]：スラッシュ (
/) で始まり、http://プレフィックスまたはドメイン名を含まない URI です。
[リクエストパラメーター]
元のリクエスト 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になります。[変更]: キャッシュキーを生成する際に、元のリクエスト URL にある指定されたパラメーターの値を変更します。たとえば、元の URL が
http://image.example.com/cat.jpg?type=jpgで、パラメーターをtype=pngに変更した場合、キャッシュキーはhttp://image.example.com/cat.jpg?type=pngになります。[予約]: キャッシュキーの生成時に、元のリクエスト URL から指定されたパラメーターのみを保持します。それ以外のパラメーターはすべて削除されます。たとえば、元の URL が
http://image.example.com/cat.jpg?type=jpg&path=imageで、typeパラメーターを保持する場合、キャッシュキーはhttp://image.example.com/cat.jpg?type=jpgになります。
[HTTP ヘッダー]
クライアントの元のリクエストから指定された HTTP ヘッダーの値をキャッシュキーに追加します。複数のヘッダー名をスペースで区切って指定できます。値は、ヘッダーが指定された順序で追加されます。たとえば、元の URL が
http://image.example.com/cat.jpgで、クライアントリクエストに HTTP ヘッダーpath:imageが含まれている場合、HTTP ヘッダー フィールドでpathを設定すると、キャッシュキーhttp://image.example.com/cat.jpgimageが生成されます。[カスタム変数]
生成されたキャッシュキーにカスタム変数の値を追加して、キャッシュの柔軟性を向上させます。カスタム変数は、次のパラメーターで構成されます。
変数名：変数のカスタム名です。
ソース：クライアントリクエストに含まれるフィールド値です。次のソースタイプが利用可能です。
クエリ文字列パラメーター：リクエスト URL のクエリ文字列。
リクエストヘッダー：クライアントリクエストに含まれるリクエストヘッダー。
パス：リクエスト URL のリソースパス。
スキーム：リクエスト URL で使用されるプロトコル。HTTP と HTTPS をサポートします。
ソースフィールド：クエリ文字列パラメーター、リクエストヘッダー、およびリクエスト Cookie のソースタイプにのみ必要です。次のいずれかを指定します。
クエリ文字列内の指定されたパラメーターの名前。
指定されたリクエストヘッダーの名前。
一致ルール：ソースフィールド値内の特定の文字列に一致する正規表現です。
変数式: 最終的な変数値が生成されます。固定文字列、および最初の括弧で囲まれたグループによってキャプチャされたコンテンツを参照する
$1などのキャプチャグループ参照をサポートします。
OK をクリックします。
設定例
[URI]
http://aliyundoc.com/a/b/image.jpg および http://aliyundoc.com/a/b/c/image.jpg へのリクエストは、同じファイルへのリクエストとして扱われます。このファイルのキャッシュキーは http://aliyundoc.com/c/image.jpg です。ソース URI /a/b をターゲット URI /c に、ソース URI /a/b/c をターゲット URI /c に書き換えるように、URI 書き換えルールを設定します。[+ ソース URI を追加] をクリックして書き換えルールを追加するか、[削除] をクリックして既存のルールを削除します。
[リクエストパラメーター]
http://aliyundoc.com/a/b/image.jpg?delete_par=1&modify_par=1 に対するクライアントリクエストは、add_par=1 が追加され、delete_par が削除され、modify_par の値が 2 に変更されます。その結果、キャッシュキーは http://aliyundoc.com/a/b/image.jpg?modify_par=2&add_par=1 になります。
複数の操作が同じリクエストパラメーターを対象とする場合、優先順位は次のようになります：追加 > 削除 > リザーブ > 変更。
削除操作は単一のパラメーター名のみをサポートします。複数のパラメーターを削除するには、[+ パラメーター操作を追加] をクリックして、パラメーターごとに個別の削除ルールを追加します。
[HTTP ヘッダー]
クライアントリクエストの User-Agent ヘッダーと Accept-Language ヘッダーの値が、キャッシュキーに追加されます。 たとえば、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 になります。 [HTTP ヘッダー] テキストボックスに、User-Agent や Accept-Language など、含めたいリクエストヘッダーフィールドを入力します。
[カスタム変数]
例1
変数名は language、ソースは Request Header、ソースフィールドは Accept-Language、一致ルールは ([%w]+),([%w]+)、変数式は $1aa です。 カスタム変数を次のように設定します: [変数名] を language に設定し、[ソース] として [リクエストヘッダー] を選択し、[ソースフィールド] に Accept-Language を入力し、[一致ルール] に ([%w]+),([%w]+) を入力し、[変数式] に $1aa を入力します。
クライアントは、HTTP ヘッダー Accept-Language=en,ch を付けて http://aliyundoc.com/a/b/image.jpg をリクエストします。一致ルールが en をキャプチャし、変数式の $1 に割り当てます。変数式はさらに aa を追加します。その結果、変数値は enaa となり、language というエイリアスが付けられます。この値が URL に追加され、最終的なキャッシュキーとして http://aliyundoc.com/a/b/image.jpgenaa が生成されます。
変数式内の $n は、一致ルール内の n 番目のキャプチャグループによってキャプチャされた内容を指します。 たとえば、Accept-Language=en,ch と一致ルール ([%w]+),([%w]+) を使用すると、$1=en、$2=ch となります。
例2
変数名が expired、ソースが Request Cookie、ソースフィールドが a、マッチルールが [%w]+:(.*)、変数式が $1 の場合、カスタム変数を次のように設定します。
変数名:
expiredソース：[リクエストクッキー]
ソースフィールド：
a一致ルール：
[%w]+:(.*)変数式：
$1
クライアントが Cookie Cookie a=expired_time:12635187 を使用して http://aliyundoc.com/a/b/image.jpg をリクエストします。一致ルールは 12635187 をキャプチャし、変数式でエイリアス expired を持つ $1 に割り当てます。この値が URL に追加され、最終的なキャッシュキーは http://aliyundoc.com/a/b/image.jpg12635187 となります。
例3
この例では、URI ルールとカスタム変数を組み合わせています。
URI：
URI が /abc/.*/abc に一致するすべてのリクエストを /abc にマージします。ソース URI は /abc/.*/abc で、最終 URI は /abc です。
カスタム変数：
変数名は testname、ソースは Path、一致ルールは /abc/xyz/(.*)、変数式は $1 です。 次のように設定します。[変数名]を testname に設定し、[ソース]をパスに設定し、[一致ルール]を /abc/xyz/(.*) に設定し、[変数式]を $1 に設定します。
クライアントが http://aliyundoc.com/abc/xyz/abc/image.jpg をリクエストします。 URI 設定に従って、キャッシュキーは http://aliyundoc.com/abc/image.jpg に書き換えられます。 次に、カスタム変数設定に基づいて、元のリクエストパスが /abc/xyz/(.*) と一致します。 この時点で、$1 には abc/image.jpg という値が割り当てられ、キャッシュキーに追加されることで、最終的なキャッシュキーは http://aliyundoc.com/abc/image.jpgabc/image.jpg になります。 これは、ルールを組み合わせてより複雑なキャッシュロジックを実装する方法を示しています。
キャッシュキーのカスタム変数が一致しない場合、変数式 $1 はキャッシュキーに追加されません。
例4
この例では、ルール条件とカスタム変数を組み合わせて、モバイルクライアントと PC クライアントからのリクエストに対して異なるキャッシュキーを生成します。
Mobile ルール条件:
User-Agent ヘッダーに、次のいずれかの文字列が含まれています： *Mobile*,*Android*,*iPhone*,*ipad*。
PC ルール条件:
User-Agent ヘッダーには、以下のいずれかの文字列が含まれていません: *Mobile*,*Android*,*iPhone*,*ipad*。
モバイル カスタムキャッシュキー：
ルール条件 で Mobile を選択します。カスタム変数 では、変数名 を Mobile に、ソース を Path に、マッチングルール を / に、変数式 を +mobile に設定します。
PC カスタムキャッシュキー:
ルール条件 には PC を選択します。カスタム変数 については、変数名 を PC に、ソース を Path に、マッチングルール を / に、変数式 を +pc に設定します。
クライアントから http://aliyundoc.com/image.jpg へのリクエストは、User-Agent の値に基づいて Mobile または PC のカスタムキャッシュキールールに一致し、モバイルクライアントの最終的なキャッシュキーは http://aliyundoc.com/image.jpg+mobile、PC クライアントの最終的なキャッシュキーは http://aliyundoc.com/image.jpg+pc になります。