GAEでエッジキャッシュを利用してみる

当ブログの運用が落ち着いてきた事もあり、前々からやりたかったキャッシュサーバーを利用してサイトの高速化を図ります。

AWSで運用していた時はCloudFrontを使っていたので、GCPのCDNサービスであるCloudCDNを使うのかな？と思い調べていたらGAEは連携対象外で、代わりにGoogle本体が利用しているキャッシュサーバーをを利用するようです。

この機能をエッジキャッシュと呼ぶみたいです。

メリット

エッジキャッシュは

• フルマネージドサービス
• キャパシティが凄まじい
• とっても安価(らしい)

というメリットがあるようです。

Google本体がサービスで利用している機能でキャッシュサーバーの管理はGoogleがやってくれます。

(間借りする感じですね)

キャパシティについてもGoogleのサービスがダウンするくらいのトラフィックがこない限りは問題がないと言われているようです。

安価らしいですが、当記事を書いている最中に情報を探してみたのですが見つかりませんでした、、、(すいません)

見つかりましたらこちらは更新します。

デメリット

• アクセス制御は使えない
• キャッシュに乗っている時間はベストエフォート
• キャッシュを明示的に削除できない

エッジキャッシュは単純にキャッシュを返すだけなので、ロジックによるアクセス制御は出来ないようです。

キャッシュの有効期間の設定は可能ですがキャッシュの生存は保証はされない点ご注意下さい。

キャッシュを明示的に削除できないというのも厄介だと思います。

影響が少ないリソースを対象とすることと、キャッシュの有効期間の設定にも注意した方が良さそうです。

利用してみる

調べてみたところ、GAEではapp.yamlに記述し設定するようです。

17,22,27行目に「expiration: “4d 5h”」という記述がありますが、こちらが設定の記述になります。

• WordPressルート配下
• /wp-content配下
• /wp-includes/images/media配下

の画像ファイルのキャッシュ有効期間を4日と5時間にしました。

# App Engine runtime configuration
runtime: php72

# Defaults to "serve index.php" and "serve public/index.php". Can be used to
# serve a custom PHP front controller (e.g. "serve backend/index.php") or to
# run a long-running PHP script as a worker process (e.g. "php worker.php").
entrypoint: serve gae-app.php

# Defines static handlers to serve WordPress assets
handlers:
- url: /(.*.(htm|html|css|js))
  static_files: 1
  upload: .*.(htm|html|css|js)$

- url: /wp-content/(.*.(ico|jpg|jpeg|png|gif|woff|ttf|otf|eot|svg))
  static_files: wp-content/1
  expiration: "4d 5h"
  upload: wp-content/.*.(ico|jpg|jpeg|png|gif|woff|ttf|otf|eot|svg)$

- url: /(.*.(ico|jpg|jpeg|png|gif|woff|ttf|otf|eot|svg))
  static_files: 1
  expiration: "4d 5h"
  upload: .*.(ico|jpg|jpeg|png|gif|woff|ttf|otf|eot|svg)$

- url: /wp-includes/images/media/(.*.(ico|jpg|jpeg|png|gif|woff|ttf|otf|eot|svg))
  static_files: wp-includes/images/media/1
  expiration: "4d 5h"
  upload: wp-includes/images/media/.*.(ico|jpg|jpeg|png|gif|woff|ttf|otf|eot|svg)$

- url: /.*
  redirect_http_response_code: 301
  script: auto
  secure: always

instance_class: F1

automatic_scaling:
  target_cpu_utilization: 0.75
  target_throughput_utilization: 0.75
  max_concurrent_requests: 80

  min_instances: 0
  max_instances: 3

  min_idle_instances: 0
  max_idle_instances: 1

  min_pending_latency: automatic
  max_pending_latency: automatic

未設定の場合は、default_expirationのでデフォルト値:600秒(10分)がキャッシュの有効期間となるようです。

詳細はapp.yamlの公式Docをご確認下さい。

デプロイ後、当ブログの任意の記事を読み込ませキャッシュ対象となる画像ファイルがエッジキャッシュから拾ってきているか確認します。

curl --verbose --head --include --dump-header header.log https://yamavlog.com/wp-content/themes/simplicity2/images/line-btn-mini.png

出力されたレスポンスヘッダはこちら。

HTTP/2 200 
date: Sun, 10 May 2020 02:14:31 GMT
expires: Thu, 14 May 2020 07:14:31 GMT
cache-control: public, max-age=363600
etag: "-j6mCg"
x-cloud-trace-context: ce4b10108f325f24372766c14170edd9;o=1
content-type: image/png
server: Google Frontend
content-length: 531

• cache-control: public, max-age=363600
• content-length: 531

などで返ってきているので、エッジキャッシュの画像を拾ってきているようです。

余談ですが、ついでにGCSリソースのキャッシュ有効期間を調べてみましたが3600秒(1時間)で返ってきてました。

GCSもエッジキャッシュ使っているようです。

※GCSのエッジキャッシュ有効期間の変更方法については下記リンク記事をご覧下さい。

まとめ

いわゆるCDNサービス(CloudCDNやAWSのCloudFront)の方が使いやすいかなーと思いました。

コンテンツの差替え時に明示的にキャッシュクリア出来ない点がチト辛いかもです。