オリジンオフロードを増やす
概要
CloudFront でキャッシュヒット率 (CHR) を増やすと、ウェブアプリケーションのパフォーマンスが向上し、オリジンの負荷が軽減されます。CHR は、リクエストの総数に対する CloudFront キャッシュから処理された HTTP リクエストの比率です。CloudFront キャッシュから処理されるリクエストは、レイテンシー (最終バイトまでの時間など) が向上するというメリットがあり、CHR はオリジンオフロードとアプリケーションパフォーマンスの良い指標となります。CloudFront ディストリビューションの CHR は、キャッシュヒット率 CloudWatch メトリックスを使用してモニタリングできます。CHR を高めるには、CloudFront のキャッシュ設定を最適化し、Origin Shield を有効にして、アプリケーションの動作を最適化できます。
キャッシュの有効期間 (TTL) を増やす
オリジンから送信される Cache-Control ヘッダーを使用して、オブジェクトが CloudFront にキャッシュされる期間を制御できます。このヘッダーは、キャッシュポリシーで設定された Time To Live 設定によって制限されます。TTL を増やすと CHR にプラスの影響が及ぶため、以下のことが推奨されます。
- CloudFront の TTL をより適切に制御し、ブラウザキャッシュを活用するために、オリジンでキャッシュ制御ヘッダーを設定します。
- 静的アセットを不変オブジェクト (例:キャッシュコントロール:max-age=31536000、不変) としてキャッシュし、その URL パス (例:/static/app.1be87a.js) をバージョン管理します。
- オブジェクトに ETag を実装すると、オリジンへの条件付き HTTP リクエストを活用できます。
- HTML などのより動的なコンテンツについては、キャッシュ (高い TTL) と、アプリケーションが古いコンテンツを許容する量 (低い TTL) との間で適切なバランスを取ってください。
キャッシュキーの設定を最適化
キャッシュポリシーを使用するキャッシュキー設定は、CloudFront が HTTP リクエストにキャッシュされたオブジェクトを再使用するかどうかを決定します。キャッシュキーの設定を最適化すると、一意のキャッシュキーと固有のオブジェクトが 1 対 1 の関係になります。追加されたクエリパラメータに関係なく、同じ /about.html を提供するウェブアプリケーションを考えてみましょう (例:/about.html?utm_medium=social) 。キャッシュキーが utm_medium クエリパラメータを含むように設定されている場合、CloudFront は異なる URL をキャッシュします (例:/about.html?utm_medium=Social & /about.html?utm_medium=email) は 2 つの異なるキャッシュキーを使っています。これにより、両方のリクエストがオリジン上のまったく同じファイルに対するものであるにもかかわらず、オリジンへのキャッシュミスが 2 回発生し、これは最適とは言えません。
キャッシュキー設定を最適化する最初のベストプラクティスは、オリジンレスポンスが異なるリクエスト属性だけをキャッシュキーに含めることです。これを実現するには、次のことをおすすめします。
- 異なるキャッシュキー設定を必要とするオブジェクトには、個別のキャッシュビヘイビアを設定します。
- クエリパラメータ、ヘッダー、またはクッキーがオリジンで応答が異なる場合は、実際に反応するものだけを含めてください（例：すべてのクッキーではなく、cookie user_id）。
- CORS ヘッダーを追加する代わりに、CloudFront のレスポンスヘッダーポリシーを使用して CORS を管理します (例: オリジン、アクセス制御リクエストメソッド、アクセス制御リクエストヘッダー）をキャッシュキーに、オリジンレベルでCORSを管理します。
- キャッシュキーに認証ヘッダーを追加する代わりに、署名付き URL、CloudFront 関数、または Lambda @Edge を使用してアクセス制御を CloudFront にオフロードし、オリジンレベルで管理します。
- CloudFront のオリジンリクエストポリシーを使用して、HTTP 属性をキャッシュキーに追加する代わりにオリジンに転送します。
2 つ目のベストプラクティスは、リクエスト属性をキャッシュキーに追加する前に正規化して、設定可能な値のカーディナリティを減らすことです。その結果、それぞれが固有のキャッシュキーになります。これを実現するには、次のことをおすすめします。
- クエリパラメータを使用する場合、同じ順序で、同じ大文字と小文字で送信する
- キャッシュキーにユーザーエージェントヘッダーを追加する代わりに、 CloudFront-IS-Mobile-Viewer などの CloudFront で生成されたヘッダーを使用してデバイスタイプを識別します。
- CloudFront Functions を使用して高度な正規化を適用する (クエリパラメータの順序変更や大文字と小文字小文字の削減)、Cookie をキャッシュキーに追加する代わりに、Cookie の存在に基づいて異なるバージョンのウェブページを提供する、複数の国のグループに対して同じ応答を送信できる場合に、国によって異なる応答のばらつきを減らす、圧縮が必要な場合の Accept-Encoding のカーディナリティやクラウドのカーディナリティをさらに低減する複数のデバイス検出ヘッダーが使用されている場合のフロントデバイス検出ヘッダー。
オリジンシールドを有効にする
デフォルトでは、CloudFront は 2 つの高レベルのキャッシュレイヤー (PoP レベルのレイヤー、もう 1 つはリージョナルエッジキャッシュ (REC) レベルのレイヤー) を使用することで、オリジンへのキャッシュミスの数を減らします。CloudFront PoPは、名目上は世界中の10を超えるRECのうちの1つに関連付けられています。リクエストの結果 PoP レベルでキャッシュミスが発生した場合、CloudFront は関連する REC のキャッシュをチェックしてリクエストを処理し、その REC にキャッシュされていない場合にのみ、CloudFront はリクエストをオリジンに転送します。REC は高可用性を維持するために互いに分離されているため、キャッシュは共有されません。その結果、世界中のさまざまな場所から人気のあるオブジェクトがリクエストされると、CloudFront は同じオブジェクトに対する複数のリクエストを複数の REC からオリジンに送信します。
オリジンに転送されるリクエストの数を減らすには、CloudFront で Origin Shield を有効にします。これは、REC とオリジンの間の 3 番目の高レベルのキャッシュレイヤーです。RECは、オリジンから直接オブジェクトをリクエストする代わりに、まずOrigin Shieldキャッシュからのリクエストを処理しようとします。
アプリケーションの動作を最適化
キャッシュヒット率にプラスの影響を与える可能性のあるアプリケーションレベルの変更を検討してください。以下に例を示します。
- アプリケーションが提供するカーディナリティオブジェクトを減らします。アプリケーションが同じアセットの複数のレンディションを生成する場合、たとえば、異なる画面に合わせて異なるサイズの画像を作成する場合は、幅と高さに使用できる値の数を制限することを検討してください。
- ブラウザキャッシュの活用。これは、オリジンから送信された Cache-Control ヘッダーを使用して行うことができます。CloudFront とブラウザの TTL を区別するには、Cache-Control ヘッダーで max-age と s-maxage ディレクティブを使用するか、ブラウザの Cache-Control ヘッダーを使用してキャッシュポリシーを使用して CloudFront TTL を制御します。
- クライアントでバイト範囲リクエストを使用して、必要なものだけをダウンロードします。