つい先日、本ブログのサーバをAmazon Web Servicesに移行しましたので、構築方法をまとめます。

構成は下記のようになっています。

構成

独自ドメインを1.のCloudFrontに設定し、そのドメインにアクセスすることで、1.にまずユーザのリクエストが到達します。ここで、HTTPだった場合はHTTPSにリダイレクトするようになっています。

1.へのリクエストは、静的なファイルで且つ、以前のアクセスで結果がキャッシュされていれば、1.が直接返事をします。動的なファイル、もしくはキャッシュされていなければ、2.へとリクエストを一部加工して転送します。

2.はWordPressが動作するWebサーバです。適宜3のデータベースサーバにアクセスし、リクエストを返します。

大まかに、このような構成で動作しています。

落とし穴

単純にこの構成を組むのは簡単に思えますが、実は落とし穴があり、結構設定に手間取りました。

そして、CloudFrontの設定変更のデプロイ完了が非常に遅い！ 設定変更の際はテスト環境で実施しないと、ちょっとした設定ミスが結構な長さのサービス停止に繋がります。

設定方法

まず、2.のWebサーバにキャッシュの設定を行います。どうやらこの設定値を参考に、1.はキャッシュするようです。

Apacheの場合は、下記の設定を設定ファイルに記述します。

#
# mod_expires
#

<ifmodule expires_module="">
    ExpiresActive On
    ExpiresDefault "access plus 1 seconds"
    ExpiresByType text/css "access plus 1 weeks"
    ExpiresByType text/js "access plus 1 weeks"
    ExpiresByType text/javascript "access plus 1 weeks"
    ExpiresByType image/gif "access plus 1 weeks"
    ExpiresByType image/jpeg "access plus 1 weeks"
    ExpiresByType image/png "access plus 1 weeks"
    ExpiresByType image/svg+xml "access plus 1 year"
    ExpiresByType application/pdf "access plus 1 weeks"
    ExpiresByType application/javascript "access plus 1 weeks"
    ExpiresByType application/x-javascript "access plus 1 weeks"
    ExpiresByType application/x-shockwave-flash "access plus 1 weeks"
    ExpiresByType application/x-font-ttf "access plus 1 year"
    ExpiresByType application/x-font-woff "access plus 1 year"
    ExpiresByType application/x-font-opentype "access plus 1 year"
    ExpiresByType application/vnd.ms-fontobject "access plus 1 year"
</ifmodule>

Nginxの場合は、下記の設定を設定ファイルに記述します。

…
http {
    …
    server {
        …
        location / {
            …
            if (-f $request_filename) {
                expires 30d;
                break;
            }
            …
        }
        …
    }
    …
}
…

次に、CloudFront側の設定です。

ディストリビューションの設定は以下のように行います。

CNAMEsに独自ドメインを記述するのがミソです。今回のように、オリジンがHTTPSで通信する場合には必須です。

オリジンの設定は以下のように行います。

ビヘイビアの設定は以下のように行います。

デフォルト(*)でまとめて設定します。

ここでは、Hostヘッダを転送するのがミソです。デフォルトではHostヘッダは転送されず、CroudFrontのドメインでHTTPSアクセスするため、エラーになってしまいます。オリジンの設定でCNAMEを記述していれば、その値をHostヘッダとして転送してくれるため、HTTPSでも正常にアクセスすることができます。

また、Whitelist Cookiesで、転送するCookieをWordPressのログインで使うもののみにし、ヒット率向上を図っています。

設定は以上です。

設定確認時の留意事項

CloudFrontはコンテンツをキャッシュします。

当たり前のことですが、それは常に頭の片隅に置きながら設定をしていきましょう。キャッシュされている古いコンテンツを見て、設定が正しくできていると勘違いしたりしがちです。

最終確認時は、インバリデーションの設定画面でCloudFrontのキャッシュを一旦全て削除してから、確認するようにしましょう。

また、日々の運用も同様で、WordPressのプラグインの適用も、静的コンテンツに関連するものは全て、リアルタイムの適用ではなくなります。場合によっては表示のエラーを引き起こす可能性もあります。慎重に行いましょう。

まとめ

トラブル発生時はCloudFrontに関する正しい知識が要求されてしまうなどのデメリットはありますが、サーバのスペック（コスト）を上げることなく手軽に負荷分散できる仕組みなので、WordPressを運用されている方はぜひ利用してみてはいかがでしょうか。