2019.12.13

AWS製WordPressプラグインの「CloudFrontワークフロー」を検証・その2

sho

Contents

今回取り扱う内容
"Site Acceleration with Amazon CloudFront"機能によって生成されたCloudFrontディストリビューションのビヘイビア設定
まとめ

今回取り扱う内容

前回：AWS製WordPressプラグインの「CloudFrontワークフロー」を検証

前回の記事では、AWS製WordPressプラグイン“AWS for WordPress”の導入と、「CloudFrontワークフロー」の適用まで実施しました。

そのため、インストール手順をひたすらなぞるようなものとなってしまいましたが、今回は「CloudFrontワークフロー」によって構築されたCloudFrontのビヘイビアの設定内容を確認して、行こうと思います。

"Site Acceleration with Amazon CloudFront"機能によって生成されたCloudFrontディストリビューションのビヘイビア設定

設定対象となるパスパターン

まず、設定されたビヘイビアは全部で5つのPath Patternを対象に作られていました。

Default(*)
wp-content/*
wp-includes/*
wp-admin/*
wp-login.php

これらのパスを元にどのように設定されているのか見てみます。AWS CLIで取得した情報をかいつまんで列挙していきます。

パスパターンごとの設定内容

Default(*)

項目名	内容
許可するメソッド(Allowed HTTP Methods)	`["HEAD","DELETE","POST","GET","OPTIONS","PUT","PATCH"]`
ヘッダのホワイトリスト(Whitelist Headers)	`["CloudFront-Forwarded-Proto","CloudFront-Is-Desktop-Viewer","CloudFront-Is-Mobile-Viewer","CloudFront-Is-Tablet-Viewer","Host"]`
Cookieをフォワードするか？(Forward Cookies)	whitelist
Cookieのホワイトリスト内容(Whitelist Cookies)	`["comment_","wordpress_","wp-settings-*"]`
QueryStringをフォワードするか？(Query String Forwarding and Caching)	true
オブジェクトの自動圧縮する？(Compress Objects Automatically)	false

wp-content/*

項目名	内容
許可するメソッド	`["HEAD","GET"]`
ヘッダのホワイトリスト	[]
Cookieをフォワードするか？	none
Cookieのホワイトリスト内容
QueryStringをフォワードするか？	true
オブジェクトの自動圧縮する？	false

wp-includes/*

項目名	内容
許可するメソッド	`["HEAD","GET"]`
ヘッダのホワイトリスト	[]
Cookieをフォワードするか？	none
Cookieのホワイトリスト内容
QueryStringをフォワードするか？	true
オブジェクトの自動圧縮する？	false

wp-admin/*

項目名	内容
許可するメソッド	`["HEAD","DELETE","POST","GET","OPTIONS","PUT","PATCH"]`
ヘッダのホワイトリスト	`["*"]`
Cookieをフォワードするか？	all
Cookieのホワイトリスト内容
QueryStringをフォワードするか？	true
オブジェクトの自動圧縮する？	false

wp-login.php

項目名	内容
許可するメソッド	`["HEAD","DELETE","POST","GET","OPTIONS","PUT","PATCH"]`
ヘッダのホワイトリスト	`["*"]`
Cookieをフォワードするか？	all
Cookieのホワイトリスト内容
QueryStringをフォワードするか？	true
オブジェクトの自動圧縮する？	false

各設定内容について

デフォルト"Default(*)"の設定

まず、追加で設定されているいずれのパスパターンも合致しないパスの時に適用されるDefault(*)のパスについてですが、
許可するメソッド(Allowed HTTP Methods)においては全て許可。
ヘッダのホワイトリストでは、
["CloudFront-Forwarded-Proto","CloudFront-Is-Desktop-Viewer","CloudFront-Is-Mobile-Viewer","CloudFront-Is-Tablet-Viewer","Host"]　
のように設定されています。
これによりすべてのメソッドがデフォルトでは使えて、かつプロトコルやホスト名、Viewerの情報もCloudFrontのオリジンへ渡るようになっています。

そして、Cookieのホワイトリスト設定で、["comment_*","wordpress_*","wp-settings-*"]となっていますが、これはWordPressにおいて活用されるCookie群になっています。

画像類のパスでの設定

そして
wp-content/*
wp-includes/*
ですが、こちらは主にWordPressにおける画像類などが格納されるディレクトリ構成です。
メソッドの対象は狭く、クッキーも一切フォワードされない構成になっています。
これによりWordPress内の画像類でのキャッシュ効率を最大限高めようとしている意向が見えてきます。

管理画面での設定

そして最後に
wp-admin/*
wp-login.php
においてはメソッドは全許可。ヘッダーも全許可。クッキーも全部フォワードとなっています。
これらのパスはWordPressにおける管理画面・ログイン画面が位置するパスです。
これらのパス構成においてはキャッシュ機構が働いてしまうと、たとえば「設定をしたのに画面上にはキャッシュされた結果が出てしまい、今時点の最新の設定内容が反映されない」ということになってしまいますので、一切キャッシュは働かせないようにしていると思われます。

まとめ

このことから、

「デフォルトではヘッダー、クッキーを許可しつつ、画像類が格納されているパス構成を狙って最大限キャッシュ機構を働かせる。管理系の画面があるパスは非キャッシュにする」

というキャッシュ戦略が取られていることがわかります。

これはAWSが示しているAWS上でWordPressを運用する際のベストプラクティス・"Best Practices for WordPress on AWS"
https://d1.awsstatic.com/whitepapers/wordpress-best-practices-on-aws.pdf
におけるCloudFrontビヘイビアの設定内容とも一致しています。

このような構成にすることで、WordPressのプラグインの追加や、サイト上のWebフォーム追加などにおいても柔軟に、もしくは設定を加えることなくサイト動作を担保できる可能性があります。

しかし、「画像類を狙ってキャッシュを働かせる」という構成をとっているため、サイト訪問された際にCloudFrontが返してくれるキャッシュはページのコンテンツを完全にはカバーしてくれない可能性があります。
たとえば、WordPressの記事上の画像はキャッシュされても、記事ページ自体（テキスト内容）はキャッシュしてくれない恐れがあります。
もしサイトへのアクセスが急増した場合に備えてその部分も含めてキャッシュを働かせたい場合は