Cloud CDNのCache ModeとTTL overridesを試してみました

先日更新されたCloud CDNのリリースノートをうちの会社の人が情報共有してくれたのですが、内容をみて前のめりになりました。

当ブログのキャッシュミスが高い原因(Cloud CDNのキャッシュ要件を満たさないものはCloud CDNにキャッシュされない)について、以前記事を書きましたが、今回beta版リリースされた→GAとなった

• Cache Mode
• TTL overrides

を利用することで、厳しいCloud CDNのキャッシュ要件を大幅に緩和できるようです。

当ブログのCloud CDNのキャッシュ問題が解決出来そうなので早速試してみました。

当記事執筆時点では、Chace Mode,TTL overridesともにbeta版となっており、GCPのSLAは保証されません、ご利用される場合はご注意下さい。→GAになりました。

前提条件

• Cloud SDKが最新版となっていること

• Cloud CDNが有効になっている、バックエンドサービス、またはバックエンドバケットが設定済であること

設定

Cloud SDKのコマンドにて設定します。

gcloud compute backend-services update 【バックエンドサービス名】 \
--global \
--cache-mode=force-cache-all \
--default-ttl=31622400

default-ttl値は1年で指定しました。

コマンドの詳細については、下記公式Docをご確認下さい。

ページレベルでキャッシュするためにcache-mode=force-cache-allを指定しました。cache-mode=cache-all-staticだとページレベルでキャッシュはしませんでした。

キャッシュ対象システムがWordpressの場合、/wp-login.phpや/wp-admin/*などの管理系機能をキャッシュさせないよう、Cloud CDN側で設定を行って下さい。設定方法は下記記事をご覧下さい。

Curlコマンドでのレスポンス結果確認

Cache Mode設定前

$ curl -s -D - -o /dev/null https://yamavlog.com/
HTTP/2 200
content-type: text/html; charset=UTF-8
vary: Accept-Encoding
link: <https://yamavlog.com/wp-json/>;
link: <https://wp.me/bXhYl>; rel=shortlink
x-cloud-trace-context: 9f4b9d668f8e150bed6e615bed63a7ca;o=1
date: Wed, 16 Sep 2020 08:31:12 GMT
server: Google Frontend
content-length: 574316
via: 1.1 google
alt-svc: clear

Cache Mode設定後

$ curl -s -D - -o /dev/null https://yamavlog.com/                                                                                                                 138ms
HTTP/2 200
content-type: text/html; charset=UTF-8
vary: Accept-Encoding
link: <https://yamavlog.com/wp-json/>;
link: <https://wp.me/bXhYl>; rel=shortlink
x-cloud-trace-context: b30d150108ed5609f1c0f8c7d17221c5;o=1
date: Wed, 16 Sep 2020 10:13:01 GMT
server: Google Frontend
content-length: 572657
via: 1.1 google
alt-svc: clear
cache-control: public,max-age=3600

cache-controlヘッダが出力されるようになりました。

レスポンスヘッダの情報が変化したので、上手く行ったっぽいです。

ロードバランサのログもみてみます。

ロードバランサ ログの確認(Cache Mode設定変更後)

• cacheHit: true
• statusDetails: “response_from_cache”

とログに出力されているので、Cloud CDNのキャッシュコンテンツをGETしています。

上手く行きました。

まとめ

当ブログをGAEで構築してからずっと課題だった、CDNへのキャッシュ問題もほぼ解決です→解決しませんでした詳細は追記1をご覧ください。

ただ、cache-controlヘッダのmax-ageの値が3600となっている点については対応が必要です。

※原因が分かれば当記事に追記します。

追記1:chache-modeについて

• cache-mode=force-cache-allを指定すると、/wp-admin〜や/wp-login.phpなどブラックリスト(キャッシュしない)指定しているにも関わらず、キャッシュされる挙動をするのでやめました。

• この辺りはAWS CloudFrontのキャッシュブラックリスト機能の方が進んでいる印象です。(ブラックリスト指定かつ、生存期間0指定可能。URIに*つけて部分一致指定も可能です)

• 危険なので、cache-mode=cache-all-staticに切り替えて運用する事にしました。静的コンテンツは確かにCloud CDNから配信されるようにはなりましたが、レスポンスの体感値的にはうーんって感じです。劇的にレスポンス早く感じるようになるには動的コンテンツをキャッシュしないとダメですが、Cloud CDNで安全に使えるようになるにはまだ先になるみたいです、、、

追記2:cache-controlヘッダのmax-ageの値が3600となる問題について

default-ttl値を1年に指定しても、cache-controlヘッダのmax-ageの値が3600となってしまう問題ですが、chache-ttlがGAになったので画面で確認すると最大値に指定できる値は30日ということがわかりました。

beta版で1年を指定してコマンドが通っちゃったのは謎ですが、beta版あるある？ということで気にしない事にします。

30日で指定し静的コンテンツをcurlで確認したところ、最大有効期間が30日でちゃんと返ってきました。