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

今回取り扱う内容

前回：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(*)

wp-content/*

wp-includes/*

wp-admin/*

wp-login.php

各設定内容について

デフォルト"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の記事上の画像はキャッシュされても、記事ページ自体（テキスト内容）はキャッシュしてくれない恐れがあります。
もしサイトへのアクセスが急増した場合に備えてその部分も含めてキャッシュを働かせたい場合は

「デフォルトではキャッシュを働かせるようにしてキャッシュ効率を高める。ただし、動的な動作が必要なパスにはキャッシュを働かせないように設定を足してサイトの動作を担保する」

という構成をとる必要があります。
こうすることで設定するための手間はかかりますが、その一方でCloudFrontによるキャッシュ効率は非常に大きく高められる可能性があります。

このようにCloudFrontの設定を入れるにしても、トレードオフの関係にある

• キャッシュ効率
• 運用上の利点

を照らし合わせて、キャッシュ戦略を練る必要が有ります。

その戦略はどれが適切かは「ケースバイケース」、、、と言ってしまえば簡単なのですが、、、
“AWS for WordPress”のプラグインが設定するCloudFrontの設定がどのようになっているかを見ることで、キャッシュ戦略を練る上での参考となれば幸いです。

sho