CloudFrontにwordpressの記事をキャッシュする

(2018/11/22 Behiviorsパラメータを更新しました)
バックアップ、リストアの話から始まり、最終的にはCloudFrontでサイトをキャッシュしておけば、本番サーバがダウンしてもある程度キャッシュから応答を返せるのではないかという考えに至りました。
今回はCloudFrontでキャッシュサーバを構築していきます。

構成としては、本番サーバの前段にCloudFrontを設置するようにします。これまでwordpressをインストールしたサーバで全てのリクエストを受けていたのを、全てCloudFrontで受けてもらうようにし、キャッシュに載っていないデータだけを本番サーバ(以降originと表記)に取りに来てもらいます。

以降の作業は、前提としてDNSサービスでCNAMEを設定可能でなくてはいけません。独自ドメインサービスでドメイン名を取得している人はまず問題ないと思いますが、確認の上読み進めて下さい。

httpsでサーバーエイリアスを設定する

これまでのURLで継続してアクセス可能にするために、これまでのURLはCloudFrontのAlternate Domain Names(CNAME)に設定する必要があります。
必然的にこれまで使用してきたURLはCloudFrontに向く事になるので、今後はoriginへは別のURLでアクセスさせる必ことになります。
各種ドメインネームサービス等でホスト名を取得して、httpd.confでServerAliasを追加しましょう。以下は私の環境の例です。これにより二つのURLで同サイトにアクセスさせられます。

設定したらhttpdを再起動して追加したURLでアクセスできるか確認しましょう。

CloudFrontでディストリビューションを追加する

ここからがAWSでの作業になります。サービスからCloudFrontに進み、CreateDistrobution→Webと押して進みます。

Alternate Domain Namesにアクセスさせたいホスト名を設定します。(現状のwordpressのホスト名を入れれば、wordpress側の変更は不要です)
SSL Certificateは一旦デフォルトのままで良いです。後ほどインポートしてから設定します。
後はデフォルトで一旦Creat Distoributionを押して決定します。

Behaviorでパス毎の振る舞いを設定する

作成したDistoributionが一覧で表示されるので、IDをクリックして詳細に進みます。
Behiviorタブをクリックして、パスやgetパラメータによる振る舞いを定義します。
全てのアクセスがCloudFrontを経由するので、記事の投稿のような更新系のアクセスはoriginサーバへスルーしてもらわなくては、正しく更新ができません。
また、デフォルト動作ではurlのgetパラメータもoriginサーバに転送してくれず、getパラメータにより記事の内容が変わるような場合には対処できません。そういった問題を解決するためにこのBehaviorを設定します。

ここでは、以下のようなポリシーで設定していきます。

    1. wp-login.php→キャッシュせずにoriginへ転送
    2. wp-admin/*→キャッシュせずにoriginへ転送
    3. *(全てのアクセス)でpreviewのパラメータが含まれる場合はキャッシュせずにoriginへ転送←全くキャッシュしなくなったので対応調査中
    4. それ以外全て→キャッシュする。その際、getパラメータによる違いを全てキャッシュする。

Create Behaviorをクリックし、値を入力していきます。

キャッシュさせないページの設定

  • PathPatternは振る舞いの定義対象です。ここにwp-login.phpと入れます。
  • Allowed HTTP Methodsは全部入りを指定します。
  • Cache Based on Selected Request HeadersをwhitelistにしてHostを追加。
    これをやらないとcloudfrontに設定したURLとoriginのURLで食い違いのためうまく処理できないようです。
  • TTLは全て0にします。
  • Forward CookiesとQuery String Forwarding and Cachingは全て転送させます。
    これでwp-login.phpはキャッシュされなくなりました。

wp-admin配下も同様に設定しましょう。


previewの設定もほぼ同様ですが、Query StringをWhitelistにして”preview”を指定します。

キャッシュさせるページの設定

いずれにも当てはまらないパターンですが、こちらはキャッシュさせるように設定します。

    • Allowed HTTP MethodsはGET,HEADのみ
    • Whitelist headersには以下を以下を追加します
      • CloudFront-Is-Desktop-Viewer
      • CloudFront-Is-Mobile-Viewer
      • CloudFront-Is-SmartTV-Viewer
      • CloudFront-Is-Tablet-Viewer
      • Host
    • TTLはデフォルト値
    • Query Stringも全て転送させます。
    • Forward CookiesはWhite listにして、以下をwhilte listに追記します。
      • wordpress_logged_in*
      • wp-settings*

これでデフォルトはGETパラメータによる違いも含めキャッシュさせるようになりました。

CloudFront-Isシリーズはモバイルのテンプレートを使用するかどうかを判断するためにCloudFrontが付与してくれます。UserAgentを転送することでorigin側でも判断できますが、キャッシュ効率が悪くなるようです。


モバイルかデスクトップかの判断を入れる

cloudfrontはUser-Agentヘッダを転送してくれないので、wordpress側でモバイルかデスクトップかの判断を変更する必要があります。これは色々調べても正解が見つけられませんでした。とりあえずwp-includes/vars.phpでwp_is_mobile関数を定義していたので、それを修正してUser-AgentではなくCloudFront-Is-MOBILE(またはTABLET)ヘッダで判断するようにしました。しばらくこれで様子を見ます。
使用しているテンプレートによっても異なるかもしれません。この部分は真似される方がいましたら慎重にお願いします。

Distoributionの起動確認

Distributionsの一覧でstatusがDeployedに変わったら、IDから詳細に進んで、GeneralタブにあるDomain Nameをコピーして、ブラウザに貼り付けてアクセスできるか確認してみましょう。

あとはこのDNS名をこれまでのURLのCNAMEとして設定すれば、cloudfront経由でアクセスされるようになります。
(私の例でいくと、fujitea.no-ip.infoをCNAMEににて、IPアドレスでなくて新しいDNSを設定するようにします)

しかし、このままではhttpsでアクセスすると証明書エラーになります。長くなったので、次回証明書を設定していきます。

参考

CloudFront 配下での User-Agent の判定
WordPress + CloudFrontでPC版・SP版切り分け

シェアする

  • このエントリーをはてなブックマークに追加

フォローする