スキップしてコンテンツを表示

カスタムオブジェクトキャッシュを設定しても、CloudFront ディストリビューションがオリジンのキャッシュ設定を使用する原因を教えてください。

所要時間2分
0

カスタムオブジェクトキャッシュを設定したものの、Amazon CloudFront ディストリビューションはオリジンのキャッシュ設定を使用するため、その原因をトラブルシューティングしたいです。

簡単な説明

オブジェクトキャッシュをカスタマイズする際、デフォルトの有効期間 (デフォルト TTL)、最小 TTL、および最大 TTL を設定します。

CloudFront は、次のように動作します。

  • オリジンがキャッシュヘッダーを返さない場合、CloudFront ディストリビューションはデフォルト TTL を使用します。
  • オリジンが返すキャッシュヘッダーの値が最小 TTL よりも低い場合、ディストリビューションは最小 TTL を使用します。
  • オリジンが返すキャッシュヘッダーの値が最大 TTL よりも高い場合、ディストリビューションは最大 TTL を使用します。

注: CloudFront が最小 TTL または最大 TTL に基づいて応答をキャッシュする場合も、クライアントへの応答にはオリジンのキャッシュヘッダーが含まれます。ブラウザ、プロキシなどのすべてのプライベートキャッシュは、オリジンのキャッシュヘッダーを使用する可能性があります。

ディストリビューションがデフォルトの TTL 値に基づいてキャッシュを行わない場合は、オリジンのキャッシュヘッダーが競合していないかを確認してください。

解決策

競合するキャッシュヘッダーを特定する

オリジンのキャッシュヘッダーがディストリビューションのカスタムオブジェクトキャッシュと競合していないかを確認します。

最小 TTL とデフォルト TTL は 0 に設定されているにもかかわらず、CloudFront からの結果はキャッシュされる場合

CloudFront からの応答を参照し、X-Cache の値が Hit from cloudfront または RefreshHit from cloudfront であるかどうかを確認します。

< HTTP/1.1 200 OK
< Content-Type: text/html
< Content-Length: 437
< Connection: keep-alive
< Date: Sat, 03 Feb 2018 19:26:45 GMT
< Last-Modified: Sat, 03 Feb 2018 19:25:24 GMT
< ETag: "example12345abcdefghijklmno54321"
< Cache-Control: max-age=300, Public
< Accept-Ranges: bytes
< Server: AmazonS3
< Age: 14
< X-Cache: Hit from cloudfront

X-CacheHit from cloudfront または RefreshHit from cloudfront の場合は、リクエストの送信元はエッジロケーションのキャッシュです。更新ヒットでは、CloudFront は期限切れのオブジェクトが変更されていないことをオリジンで再検証し、オブジェクトが古くなっている場合は更新します。

応答内の Cache-ControlExpiresAge 値を確認します。Cache-Controlmax-age 値が Age 値より高い場合、キャッシュされた応答の送信元は CloudFront のキャッシュです。Expires の日付が未来のものである場合は、キャッシュされた応答も古くなっていません。キャッシュ動作のパスで 最小 TTL および デフォルト TTL が 0 に設定されている場合も、これは想定動作です。

注: 上記の例では、最大 TTL は 0 より高い値です。すべての TTL 値を 0 に設定すると、キャッシュは無効になります。

最大 TTL とデフォルト TTL が 0 より高く設定されていても、CloudFront でキャッシュヒットしない場合

CloudFront からの応答を参照し、X-Cache の値が Miss from cloudfront であるかどうかを確認します。

< HTTP/1.1 200 OK
< Content-Type: text/html
< Content-Length: 437
< Connection: keep-alive
< Date: Sat, 03 Feb 2018 19:26:45 GMT
< Last-Modified: Sat, 03 Feb 2018 19:25:24 GMT
< ETag: "example12345abcdefghijklmno54321"
< Cache-Control: no-cache, no-store
< Accept-Ranges: bytes
< Server: AmazonS3
< X-Cache: Miss from cloudfront

X-CacheMiss from cloudfront の場合、リクエストはキャッシュではなくオリジンから送信されたことを示しています。

Cache-Control の値が no-store の場合、このヘッダーは、CloudFront が応答をキャッシュしないよう指示します。Cache-Controlno-cache の場合、このヘッダーは、CloudFront がキャッシュされた応答を返す前に、オリジンで検証を行うよう指示します。Cache-Controlprivate の場合、CloudFront は、応答をプライベートキャッシュ (例: ブラウザのローカルキャッシュ) のみに格納するよう求められます。

これらの動作は、最大 TTLデフォルト TTL の設定よりも優先されます。

注: キャッシュ以外からの応答には、Age ヘッダーは含まれません。

上記の例では、最小 TTL は 0 に設定されています。最小 TTL が 0 より大きい場合、応答のディレクティブが no-cacheno-storeprivate である場合も、CloudFront はオブジェクトをキャッシュします。詳細については、「CloudFront がオブジェクトをキャッシュする期間を指定する」を参照してください。

CloudFront がエラー応答をキャッシュする場合

CloudFront はオリジンからのエラー応答をクライアントに転送し、オリジンのエラー応答をデフォルトでは 10 秒間キャッシュします。

オリジンのエラー応答に Cache-Control ヘッダーが含まれている場合、CloudFront はデフォルトの 10 秒ではなく、関連する TTL を使用してエラーをキャッシュします。

エラー応答がオリジンからのものか CloudFront からのものかを確認するには、Server 値を確認します。エラーがキャッシュされた応答であるかどうかを確認するには、その応答に Age ヘッダーが含まれているかどうかを確認します。

Amazon Simple Storage Service (Amazon S3) オリジンが返す、キャッシュされた応答のエラー例を次に示します。

< HTTP/1.1 403 Forbidden
< Content-Type: application/xml
< Transfer-Encoding: chunked
< Connection: keep-alive
< Date: Sat, 03 Feb 2018 21:07:51 GMT
< Server: AmazonS3
< Age: 12
< X-Cache: Error from cloudfront

CloudFront が返す、キャッシュされた応答ではないエラー例を次に示します。

< HTTP/1.1 403 Forbidden
< Server: CloudFront
< Date: Sat, 03 Feb 2018 21:14:53 GMT
< Content-Type: text/xml
< Content-Length: 146
< Connection: keep-alive
< X-Cache: Error from cloudfront

オリジンを更新する

ディストリビューションのカスタムオブジェクトキャッシュよりも優先されるキャッシュヘッダーを特定した後、オリジンを更新します。

次の手順を実行します。

  1. ウェブサーバー設定内で、そのヘッダーの場所を特定します。
  2. 問題のヘッダーが適用されている行を削除します。
  3. サーバーを再起動します。
  4. オリジンをテストし、キャッシュヘッダーが応答に返されなくなったことを確認します。
  5. CloudFront ディストリビューション全体で無効化を行い、変更を適用します。

関連情報

リクエストヘッダーに基づきコンテンツをキャッシュする

コンテンツがキャッシュに保持される期間 (有効期限) を管理する

AWS公式更新しました 4ヶ月前
コメントはありません

関連するコンテンツ