Amazon CloudFront キャッシュポリシーとオリジンリクエストポリシーを発表

Amazon CloudFront の新しいキャッシュポリシーとオリジンリクエストポリシーにより、CloudFront がリクエストデータを使用して、キャッシュキーとキャッシュミス時にオリジンに転送されるリクエストの両方に影響を与える方法をより詳細に制御できます。これにより CloudFront が実行するキャッシュの制御と効率を向上させながら、さらに柔軟性が高まります。これらの設定はすでに部分的には存在していましたが、キャッシュキーの設定はオリジン転送の設定から独立することになります。以前は転送されたデータのほとんどはキャッシュキーを自動的に変更していました。このポリシーにより、ほとんどのリクエスト要素をキャッシュキーに影響を与えることなくオリジンに転送できるようになります。ヘッダー、Cookie、およびクエリ文字列パラメータの任意の組み合わせを設定して、キャッシュキーとして考慮するよう含めたり、除外したり、必要に応じて転送したりできます。

基本的な設定の柔軟性の向上に加えて、これらのオプションは “ポリシー” を使用して設定されるようになりました。ポリシーでは、同様の設定の組み合わせを任意の数のディストリビューションに適用できます。これによりセットアップ時間が短縮され、複雑さが軽減されてチームは全体の設定にわたって一貫性を管理できます。

CloudFront には、事前設定されたシステムポリシーもいくつか用意されています。キャッシュ保持の最大化、動的トランザクションのプロキシ、一般的なユースケースと他の AWS サービスとの統合のために設定されたシステムポリシーがあります。たとえば、AWS Elemental MediaPackage を使用したパーソナライズされたビデオストリーミングのシステムポリシーがあります。異なるコンテンツやアプリケーションプロファイルに対して独自のポリシーを作成し、アカウント内の任意のディストリビューションやキャッシュ動作 (Behavior) に適用することができます。

キャッシュキーとは何ですか？なぜそれが重要ですか？

まず、キャッシュキーが何であるか、どのように構成されているかを理解しましょう。キャッシュキーは、CloudFront がキャッシュするすべてのリソースを一意に識別する方法です。デフォルトでは、CloudFront ディストリビューションのホスト名と、次の例のように、リクエスト URL のリソース部分（パス、ファイル名、拡張子）で構成されます。

GET /content/stories/example-story.html?ref=0123abc&split-pages=false HTTP/1.1
Host: d111111abcdef8.cloudfront.net
User-Agent: Mozilla/5.0 Gecko/20100101 Firefox/68.0
Accept: text/html,*/*
Accept-Language: en-US,en
Cookie: session_id=01234abcd
Referer: https://news.example.com/

上記のリクエストのデフォルトのキャッシュキーには、次のものが含まれます。

CloudFront ディストリビューション (d1111abcdef8.cloudfront.net) のドメイン名
要求されたオブジェクトの URL パスとファイル名 (/content/story/example-story.html)

デフォルトでは、ビューアリクエストのその他の値はキャッシュキーに含まれません。Webブラウザからの HTTP リクエストを考えてみましょう。デフォルトのキャッシュキーは上記の赤字の項目で構成され、存在する他の要素（ヘッダー、クエリ文字列パラメータ、Cookie）は、キャッシュポリシーを使用してキャッシュキーに追加することによってのみ含まれます。

キャッシュキー内のデータの組み合わせは、キャッシュフットプリント全体にわたって各リソースを一意に識別します。しかし、同じベース URL（パス、ファイル名、拡張子）を使用して、HTTP リクエストで提供できる他の“メタデータ“に基づいて変化するコンテンツを提供するアプリケーションがある場合はどうでしょうか？これには、ヘッダー、クエリ文字列、およびクッキーが該当します。

最新のアプリケーションの多くは、このような情報を使用して、結果のレスポンスをカスタマイズまたはパーソナライズします。これは、ユーザーまたはデバイスの特性に基づいてグラフィックやアイコンの代替バージョンを提供したり、クライアントの場所に基づいて異なる言語バージョンのテキストを提供したり、Cookie に基づいて Web ページに異なる出力をレンダリングすることができます。このデータの使用方法は無限ですが、重要な考慮事項は、同じベース URL を使用するオブジェクトをキャッシュするかどうかの要素とオリジンのアプリケーションサーバーに送信するデータとを区別する必要があることです。

これは、キャッシュキーの変更動作からオリジンへの転送動作を分離することが重要になります。キャッシュキーに適切な要素を含めない場合にCloudFront はコンテンツのレスポンスの違いを無視したり、または、同じファイルを異なる名前（キャッシュキー値）で別々にキャッシュしたりする場合があります。前者は、アプリケーションが期待どおりに動作しない可能性があります。また、後者は同じファイルを異なるキャッシュキーで別々にキャッシュする場合、CloudFront キャッシュのヒット率が低下し、パフォーマンスに影響を与える可能性があります。また、キャッシュキーに含まれるすべての要素のすべての値の一意の組み合わせは、キャッシュされる異なる一意のリソース（または同じリソースのコピー）の数になることに注意してください。実際にはオリジンによって異なるリソースが提供されてない場合、または数万以上の組み合わせにも関わらず、それぞれが少数の繰り返しのリクエストしか受けていない場合は、おそらく別の戦略を検討する必要があります。この状況では、いくつかのアプローチがあります。キャッシュポリシーを使用して、これらの種類が多くなる要素をキャッシュキーから除外できます。また、ポリシーの Default TTL = 0 または Max TTL = 0 の設定でキャッシュ不可にマークすることで、リクエストをプロキシすることもできます。または、cache-control =“ no-cache”や“ no-store”などのオリジンが提供するキャッシュ制御ヘッダーを使用してキャッシュを上書きすることもできます。（この方法の詳細については、CloudFront 開発者ガイドを参照してください）

キャッシュポリシーとオリジンリクエストポリシーとは何ですか？

ポリシーは CloudFront の新しい概念であり、アカウント内の任意の数のディストリビューションのキャッシュ動作 (Behavior) に適用できる設定情報のテンプレートと考えることができます。ポリシーを使用すると、CloudFront でリクエスト情報をキャッシュまたはオリジンに転送する方法の特性が同じようなコンテンツまたはアプリケーションのユースケースに適用できる標準を定義できます。これにより、繰り返しの作業を減らし、プロパティ、チーム、ワークフロー間で一貫性を保つことができます。キャッシュポリシーを使用すると、CloudFront がコンテンツをキャッシュする方法を制御できます。オリジンリクエストポリシーを使用すると、キャッシュミスの発生時にオリジンへのリクエストに含まれるデータのタイプを制御できます。

ポリシーは、新しい一連の設定画面を使用して CloudFront コンソールから作成および設定できます。これらは、左側のナビゲーションパネルのメニュー項目の“Policies” からアクセスするか、その後の Behavior へのポリシーの適用セクションで説明されているように、Behavior の作成/編集画面から “Create a new Policy” ボタンを選択します。各ポリシーの種類は異なっており、アカウント内の既存のポリシーをすべて表示できるリスト画面、ポリシーの詳細の表示のみで編集できないビュー画面、ポリシーの値を設定または変更できる編集/作成画面があります。

ポリシー一覧画面とナビゲーション

キャッシュポリシー

キャッシュポリシーは、CloudFront がコンテンツをキャッシュする方法を管理します。これには、オリジンで再検証する前にオブジェクトをキャッシュする時間の設定（TTL）、CloudFront が HTTP ヘッダー、クエリ文字列パラメータおよび Cookie のパラメータによって変わるコンテンツをキャッシュする方法、および CloudFront が圧縮されたコンテンツをキャッシュする方法を制御します。

キャッシュポリシーでは、次のオプションを使用できます。

Name – (入力必須) キャッシュポリシーの一意でわかりやすい名前を選択します。この値は、Behavior 画面のドロップダウン選択フィールドに表示されます
Comment – (オプション) ポリシーの整理に役立つ説明文を入力します。このフィールドは、選択中は表示されません

TTL 設定 – これらの値は、CloudFront が他の明示的なオリジン提供のキャッシュ制御ディレクティブと組み合わせてオブジェクトをキャッシュする時間を制御します。

Minimum TTL – オリジンへの再検証リクエスト（If-Modified-Since）なしで、オブジェクトをキャッシュに保持する最小時間
Maximum TTL – オリジンへの再検証リクエスト（If-Modified-Since）なしでオブジェクトをキャッシュに保持する最大時間
Default TTL – オリジンによって他のキャッシュ制御ディレクティブが指定されていない場合に、オブジェクトをキャッシュに保持するデフォルトの時間

最小値と最大値は、オリジンが提供するキャッシュコントロールヘッダー（max-age、s-maxage、expires など）と連携し、これらのディレクティブが CloudFront キャッシュで強制できる最小値と最大値を規制します。オリジン提供のキャッシュコントロールヘッダーに対する TTL 設定の動作の詳細については、CloudFront 開発者ガイドのこのセクションを参照してください。

キャッシュキーコンテンツ – 以下の値を使用して、CloudFront がヘッダー、クエリ文字列、Cookie などの追加リクエストメタデータを使用してコンテンツをキャッシュする方法を決定できます。オリジンまたはアプリケーションが、同じベース URL に対して応答する異なるコンテンツを決定するために使用したい要素を指定します。たとえば、Accept-Language ヘッダーに基づいて、HTML ページのコンテンツを変化させることができます。クライアントまたは CloudFront によって提供されるユーザーエージェントまたはデバイスタイプのヘッダーに基づいて、異なるイメージを提供できます。キャッシュキーで指定された値は、自動的にオリジンに転送されることに注意してください。キャッシュキーを変更している場合は、適切に変化するコンテンツを生成するために、オリジンが値を参照する必要があります。

Headers

None – キャッシュキーに追加のヘッダーを含めません
Whitelist – キャッシュキーに含めるヘッダーを指定します。定義済みの共通ヘッダーの一覧から選択するか、独自のカスタムヘッダーを入力します

Querystrings

All – すべてのクエリ文字列パラメーターの値をキャッシュキーに含めます
None – キャッシュキーにクエリ文字列パラメーター値を使用しません
Whitelist – 指定したクエリ文字列パラメータの値のみをキャッシュキーに含めます
All-Except – リストされたクエリ文字列パラメータを除くすべてのパラメータをキャッシュキーに含めます

Cookies

All – リクエストに存在するすべての Cookie をキャッシュキーに含めます
None – キャッシュキーに Cookie を使用しません
Whitelist – キャッシュキーに指定された Cookie のみを含めます
All-Except – リストされた Cookie の値を除くすべてをキャッシュキーに含めます

圧縮されたオブジェクトのキャッシュ

このチェックボックスは、オリジンまたは CloudFront が GZIP 圧縮されたコンテンツをキャッシュする方法を制御します。このチェックボックスをオンにすると、オブジェクトに GZIP 圧縮の有無の違いがある場合、それらがキャッシュされます。特定の圧縮タイプのチェックボックスの選択を解除すると、CloudFront はその違いをみてキャッシュしません。この設定は、CloudFront のBehavior 側で設定されたエッジ GZIP 圧縮を実行するための設定とは無関係ですが、エッジでの圧縮が有効になっていて、CloudFront で生成された圧縮バージョンをキャッシュする場合は、このチェックボックスがオンになっていることを確認してください。CloudFront で圧縮を実行する場合は、その操作の結果をキャッシュする必要があるため、推奨される動作です。オリジンで既にリソースを圧縮している場合は、CloudFront で圧縮バージョンと非圧縮バージョンの両方をキャッシュする場合は、このチェックボックスをオンにしてください。

オリジンリクエストポリシー

オリジンリクエストポリシーは、オリジンへのリクエストが行われたとき（キャッシュミスまたは再検証）に CloudFront がリクエストタイムメタデータをオリジンに送信する方法を管理します。これはCloudFront によって生成される特定のメタデータであり、クライアントから直接提供されるものではなく、厳密には転送オペレーションではないため、この機能はヘッダー転送からオリジンリクエストに名前が変更されました。その例として、CloudFront が IP アドレスやユーザーエージェントヘッダーなどのクライアント提供のデータから生成できる Geo ヘッダーとデバイスタイプヘッダーがあります。オリジンリクエストポリシーでは、CloudFront がオリジンに送信するヘッダー、クエリ文字列パラメータ、Cookie を設定できます。

次の表では、これらの各フィールドで受け入れられる値について説明します。

Headers

None – いずれのヘッダーもオリジンに転送しません
Whitelist – 特定のリストされたヘッダーをオリジンに転送します。定義済みの共通ヘッダーの一覧から選択するか、独自のカスタムヘッダーを入力します
All Viewer headers and whitelisted CloudFront-* Headers – クライアントによって指定されたすべてのヘッダーと、選択した CloudFront で生成されたヘッダーを転送します
All viewer headers – クライアントによって提示されたすべてのヘッダーを転送しますが、CloudFront で生成されたヘッダーは転送しません

Query strings

All – リクエスト URL に存在するすべてのクエリ文字列パラメータを転送します
None – クエリ文字列パラメータを転送しません
Whitelist – 指定したクエリ文字列パラメータのみを転送します

All – リクエスト内に存在するすべての Cookie を転送します
None – クッキーを転送しません
Whitelist – 指定した Cookie のみを転送します

キャッシュ動作 (Behavior) へのポリシーの適用

ポリシーを有効化するには、そのポリシーをディストリビューションのキャッシュ動作 (Behavior) に適用します。以下は、更新された Behavior の作成/編集画面のスクリーンショットで、有効化オプションが赤枠で強調表示されています。以前の機能は、“Use legacy cache settings” （レガシーキャッシュ設定を使用する）で有効にでき、新しい機能は “Use Cache Policy and Origin Request Policy”（キャッシュポリシーとオリジンリクエストポリシーを使用する）で有効にできます。この新機能はオプトインであることに注意してください。既存の CloudFront の設定は、お客様がこの新しいスタイルに変更しない限り、これまでと全く同じように機能し続けます。これは、ユーザーが明示的にアクションを実行しない限り、お客様のアプリケーションが妨げられることがなく、CloudFront がコンテンツをキャッシュする方法に突然の変更が発生しないようにするために行われました。新しいディストリビューションでは、起動後のコンソールワークフローでは、キャッシュポリシーとオリジンリクエストポリシーモードがデフォルトになります。コンソールと API が混在する環境の場合は、コンソールを使用して新しい機能を有効にする場合は、すべての API/SDK 実装を最新バージョンにアップグレードして、新しい機能と互換性を持たせるようにしてください。設定の柔軟性の向上により、お客様は積極的に新しい方法に移行することを強くお勧めします。

「キャッシュポリシーとオリジンリクエストポリシーを使用」モードを選択すると、ポリシー選択ドロップダウンリストが表示され、アカウントで設定されている既存のポリシーから選択できます。

キャッシュ動作 (Behavior) に適用するには、既存のポリシーが必要

ポリシーは、ディストリビューションのキャッシュ動作 (Behavior) にアタッチする前に存在する必要があります。コンソールベースの管理の場合、ポリシー作成画面を使用して必要なポリシーを作成してから、ポリシーを必要とするディストリビューションのキャッシュ動作 (Behavior) を作成する必要があることを意味します。API またはその他の自動化ワークフローを使用している場合は、キャッシュ動作 (Behavior) で使用するポリシーが既に存在することを確認する必要があります。次に、ListPolicies API のいずれかを使用して正しいポリシー ID を取得するか、任意の自動化ツールを使用して、使用可能なポリシーの別のリポジトリを維持することができます。ただし、CreateDistribution および UpdateDistribution API では、そのアクションを実行するときに特定のポリシー ID を指定する必要があります。

定義済みのマネージドポリシー

キャッシュ保持時間の最大化、動的プロキシのユースケースでのキャッシュの無効化など、一般的な用途用にデフォルトで定義済みのマネージドシステムポリシーが用意されています。また、Amazon S3 や AWS Elemental Media Services など、他の AWS サービスに共通のデフォルト値を実装するポリシーも作成しました。これは “Policy”ドロップダウンリストに表示され、通常、プレフィックス“Managed-”を使用してシステム提供のマネージドポリシーを示します。

その他の例

新しい機能がお客様にとって役立つ可能性のあるケースが、これまで数多く見られました。次のような例です：

ユーザーエージェントなどの情報を分析/ロギング用にオリジンに転送するが、デバイスタイプに基づいて異なるコンテンツを提供する必要がない（ユーザーエージェントヘッダーを転送してキャッシュキーから除外できるようになりました）
CloudFront のカスタムデバイスまたは Geo ヘッダーを転送するが、キャッシュキーに含めない
ヘッダーまたはクエリ文字列パラメータ内の認証情報を転送し、認証ロジックを使用してコンテンツを保護するが、そのデータに基づいて異なるバージョンのオブジェクトをキャッシュしない
URL に含まれるクエリストリングスのデータ、ヘッダに含まれるリダイレクト URL、短縮 URL、URL のリライト、その他のオリジンで利用されるデータ、または Lambda @ Edge 関数に含まれるデータをオリジンで利用するが、応答されるキャッシュコンテンツには影響を与えないようにする
クエリ文字列ベースのトークンが必要だが、キャッシュされる基になるコンテンツには影響しないカスタム認証ロジック
どちらがより管理しやすいパラメーターのリストを表すかに応じて、ポリシーを確立する際に包含または除外ロジックを使用します

まとめ

CloudFront は、キャッシュキーの構成方法と、キャッシュミス時にリクエストメタデータがオリジンに送信される方法に柔軟性を提供します。これらの新しいポリシーオプションを使用すると、オリジンのアプリケーションロジックで受信して処理するデータに高度な固有の構成を作成し、不要な重複するキャッシュオブジェクトを生成しないようにすることができます。また、ポリシーの導入はワークフローの変更となる一方で、複数の Web アプリケーションを維持する分散型のチームが構成の一貫性を強化し、CDN 構成の管理が開発チームによって直接実施されない場合に役立つというフィードバックも聞いています。このような場合、開発者はポリシー自体を管理する必要がなく、事前に設定された標準を適用できます。この機能の詳細については、CloudFront開発者ガイドを参照してください

著者について

Ted Middleton は、AWS の Edge スペシャリストソリューションアーキテクトチームのグローバルリーダーであり、CloudFront チームの元プリンシパルプロダクトマネージャーです。CDN および Edge サービスで 20 年以上の経験があります。

翻訳は Edge Services Solutions Architect 岡豊が担当しました。原文はこちらです。

Amazon Web Services ブログ