AWS

WordPressにCloudFrontを導入する

更新日:

WordPressで作成したサイトにCloudFrontを導入しようとしたところ、思っていたよりも大変でした。
設定する必要があるものがいくつかあったのでそれを紹介します。

CloudFrontの導入時の設定

WordPressのサイトにCloudFrontを導入するとWordpressがうまく動作しない、認証が通らない、ヒット率が上がらないなどの問題がおきます。
それらの問題を解決する為に以下の設定を行いました。

  1. 管理画面とPHPファイルはキャッシュしない
  2. User-agentの転送
  3. 「Authorization」を転送する(Basic認証を設定している場合)
  4. デバイス判定処理の修正
  5. GoogleアナリティクスのCookieはキャッシュしない(アナリティクスを使用している場合)

それぞれについて、状況と設定方法について書いていきます。

管理画面とPHPファイルへのアクセスはキャッシュしない

CloudFrontを導入したところまず発生したのが、管理画面にうまくログインできないという問題でした。
対処方法としては、管理画面とPHPファイルへのアクセスでキャッシュを使用しないような設定をしました。

導入しているCloudFrontで「Behaviors」→「Create Behavior」

aws-cloudfront-wordpress-create-behavior

設定項目を以下のようにします。

aws-cloudfront-wordpress-create-wp-admin-1
aws-cloudfront-wordpress-create-wp-admin-2
aws-cloudfront-wordpress-create-wp-admin-3

「*.php」へのアクセスの設定も同様に「Create Behavior」で設定します。
この設定でとりあえずWordpressにログインできない問題は解消しました。

User-agentの転送

WordPressは動くようになったのですが、管理画面に入ってもなぜかビジュアルエディタが表示されませんでした。。
また、スマホやPCで表示を分けているものもうまく表示されませんでした。

原因としては、User-agentをCloudFrontが「Amazon CloudFront」に書き換えてしまうので、User-agentを使用しているところはうまく処理できません。
問題なく動作するようにUser-agentを転送しましょう。

導入しているCloudFrontで「Behaviors」→「Edit」で「/wp-admin/*」を選択します。
その中の「Cache Based on Selected Request Headers」を「whitelist」に変更して、直接「User-agent」と入力して「Add Custom >>」ボタンで追加します。

aws-cloudfront-wordpress-add-user-agent

同様に「*.php」と「Default (*)」にも設定します。
※「Default (*)」は、この設定してしまうとCloudFrontのヒット率が下がってしまうので、下記にあるデバイス判定処理の修正で再設定します。

「Authorization」ヘッダーを転送する

WordPress自体は問題なく動作するようになったので、Basic認証を設定しました。
しかし、Basic認証に正しいパスワードを入力しても認証することができません。
そのため、CloudFrontで「Authorization」も転送するように修正します。

導入しているCloudFrontで「Behaviors」→「Edit」で「/wp-admin/*」を選択します。
その中の「Cache Based on Selected Request Headers」の「whitelist」に、リストの中から「Authorization」を選択して「Add >>」ボタンで追加します。

aws-cloudfront-wordpress-add-auth

同様に「*.php」と「Default (*)」にも設定します。

デバイス判定処理の修正

ここまでの設定でWordpress自体は問題なく動作しているのですが、CloudFrontのヒット率が全く上がりませんでした。
原因としては、CloudFrontはヘッダーの内容を元にキャッシュを使うかオリジンへ転送するかを決定するためです。

まずは問題となる「User-agent」ではなく、CloudFrontから渡すことのできるヘッダーでデバイス判定を行うように修正します。
「Default(*)」を選択して編集します。
「Cache Based on Selected Request Headers」の「whitelist」に、リストの中から「CloudFront-Is-Desktop-Viewer」と「CloudFront-Is-Mobile-Viewer」と「CloudFront-Is-Tablet-Viewer」を選択して「Add >>」ボタンで追加します。
※必要なもののみをいれてください。

aws-cloudfront-wordpress-add-device

次にデバイスの判定箇所をテーマから探します。
テーマで「HTTP_USER_AGENT」をGrep検索して使用箇所を探します。
私がやったときは、Stinger系を使用しているので「st_is_mobile」というコードが見つかりました。
テーマ(子テーマ)のfunction.phpで「st_is_mobile」の処理を記述して、そちらを使うようにしていきます。
処理内容としては、「HTTP_CLOUDFRONT_IS_MOBILE_VIEWER」が存在した場合はそれを使ってモバイル判定、存在しない場合は既存コードを使用するように追記します。
また、「add_filter」を使用して「wp_is_mobile」が動いた際には「st_is_mobile」が動くように追記します。
function.phpに以下のコードを追加します。

if ( !function_exists( 'st_is_mobile' ) ) {
  function st_is_mobile() {
    if (isset($_SERVER['HTTP_CLOUDFRONT_IS_MOBILE_VIEWER'])) {
      if($_SERVER['HTTP_CLOUDFRONT_IS_MOBILE_VIEWER'] == 'true'){
				return true;
      } else {
        return false;
      }
    } else {
      /* 見つけたコードの中身を記述 */
    }
  }
}

add_filter( 'wp_is_mobile', function( $is_mobile ) {
  return st_is_mobile();
});

使っているテーマではそのほかに使用している箇所は見つかりませんでしたが、見つかっている場合は、その処理もCloudFrontから渡ってきている値を使用するように追記します。

GoogleアナリティクスのCookieはキャッシュしない

次は、GoogleアナリティクスによるCookie以外をキャッシュするように設定します。
GoogleアナリティクスのCookieは内容がアクセする度に値が変わってしまうので、そのCookieをキャッシュ対象に含めてしまうとキャッシュされているものを使用しなくなってしまいます。
そのため、Googleアナリティクスが含まれているCookieをキャッシュ対象から除きます。
Googleアナリティクスが含まれているCookieは別の記事を参考にさせていただきました。

「Forward Cookies」を「witelist」に変更して、「wordpress_logged_in*」と「wp-settings*」を追加します。

aws-cloudfront-wordpress-add-whitelist-cookie

以上で終了です。
プラグインに関しても使用していてうまく動作しない場合は、さらに見直す必要があるかもしれないです。

-AWS

Copyright© freamap ブログ , 2020 All Rights Reserved.