#概要
##CloudFrontとは
CloudFrontはAWSのCDN(Contents Delivery Network)サービスで、Webサイトの前段に入れるだけでサイトアクセスが爆速になります。爆速になる理由は主に下記2点。
- 初回リクエストはCloudFrontがオリジンにコンテンツを取りに行きますが、2回目以降は超高速でCloudFrontのキャッシュから返答します。ただし、TTL(有効期間)を過ぎたキャッシュは削除されます
- ユーザーがアクセスするCloudFrontのエッジロケーションは全世界に54ヶ所(2016年1月現在)あり、ユーザーはネットワーク的に最も近いエッジロケーションに誘導されます。それぞれのエッジロケーションは、超広帯域なネットワークと超大容量なキャッシュ処理機構に支えられており、ユーザーがサイジングに悩む必要はありません
メディア暴露によるスパイク、いわゆるxx砲は、従来であれば予告されていたとしてもその対処は非常に大変だったわけですが、CloudFrontを使えば突然xxロケットランチャーが来たとしてもへっちゃらです!
<公式ドキュメント>
http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/Introduction.html
<参考資料>
http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-2016-amazon-cloudfront
##何ができるのか
- WordPressサイトをCloudFrontで配信します
- WordPressサーバ(オリジン)はCloudFrontからのリクエストを処理するだけなので、サーバスペックは最低限でOKです
- WordPressサーバが落ちたとしても、エッジロケーションにキャッシュがある限り配信を継続できます(キャッシュ保持時間はTTL設定に依存)
- メールフォームなどのPOSTメソッドや検索クエリなどのGETにメソッドもOKです(全てオリジンで処理されます)
##前提条件
- AWSアカウントをもっていること
- DNSで名前解決できるWordPressサイトが立ち上がっていること。オリジンは必ずしもAWS上になくても構いませんが、本記事は下記手順で構築した環境が前提となっています
http://qiita.com/Ichiro_Tsuji/items/88f9009f80f3439ad9fa - レコードを編集可能な独自ドメインを保有していること
※ もっていない場合は無料で取ってしまおう!
http://qiita.com/Ichiro_Tsuji/items/8471fe0b3d4d17cde146
- 手順中に登場するFQDN(サイトのURL)は下記の通りです。ご自分の環境に合わせて読み替えて下さい
Wordpressサイト -> wp.jaws-ug.tk
CloudFront経由 -> wp-cf.jaws-ug.tk
- 独自ドメインをもっていない場合は下記の通り読み替えて下さい
Wordpressサイト -> WordPressサーバのPublic DNS
CloudFront経由 -> CloudFrontのDomain Name
##料金
https://aws.amazon.com/jp/cloudfront/pricing/
CloudFrontのオンデマンド料金は、EC2からインターネットへの転送料金とほとんど同額です。
他にオリジンからの転送量やHTTPリクエストに対する課金がありますが、トータルで見ればEC2単体の時とさほど変わらないはずです。
#プラグインの停止
#CloudFrontディストリビューションを作成する
今回は、POST/GETメソッドは有効(ともにオリジンにスルー)とし、TTLはCloudFront側で一律に制御する設定とします。なお、TTLはコンテンツのCache-Control
やExpires
ヘッダで個別に制御することも可能です。
TTLについての詳細説明
- AWSにサインインする
- CloudFrontコンソールを開く
- [Create Distribution]をクリックする
- Webの[Get Started]をクリックする
- Origin Domain NameにWordPressサイトのDNS名を入力してTabキーを押す
- Origin IDが自動的に生成されたことを確認する
- Allowed HTTP Methodsで[GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE]を選択する
- Object Cachingで[Customize]を選択し、希望のTTLを秒単位で入力する
- Forward Cookiesで[All]を選択する
- Query String Forwarding and Cachingで[Forward all, cache based on all]を選択する
- Alternate Domain Names(CNAMEs)にCloudFront経由でアクセスする場合のDNS名を入力する
- 2019年4月以降、代替ドメイン(CNAMEs)を設定する場合は、そのドメインの正当な所有者であることを証明することを目的に証明書の設定が必須化された。証明書はACMで簡単にを生成することができる
- [Create Distribution]をクリックする
- Distributionの作成完了までに15分程度かかる
※ 待っている間にDNSの登録やwp-adminをキャッシュさせないを先にやっておくとよい - IDをクリックする
- Domain Nameを確認する。これがCloudFront DistributionのEndpointとなるので、DNSにCNAMEレコードを登録(Route 53の場合は、AレコードAliasも可)することで独自ドメインでアクセスできるようになる(手順は次項で説明)
- Distributionの作成が完了すると[Deployed]に変わる
#独自ドメインでアクセスできるようにする
##独自ドメインをRoute 53でホストしている場合
Alternate Domain Names(CNAMEs)に入力したFQDNでAレコードAliasを登録する
http://qiita.com/Ichiro_Tsuji/items/8471fe0b3d4d17cde146#aレコードaliasの登録
##独自ドメインをRoute 53 以外のDNSでホストしている場合
Alternate Domain Names(CNAMEs)に入力したFQDNでDNSにCNAMEレコードを作成し、CloudFrontのEndpoint(Domain Name)を登録する
##CloudFront経由でアクセスしてみる
CloudFrontのデプロイ完了後にDNSに登録したURL(独自ドメインをもっていない場合は、CloudFrontのDomain Name)でアクセスするとトップページが表示されるはずです。ただしこのままでは、ページ中のリンクなどがオリジンを向いてしまうので、WordPressの設定を変更します。
#WordPressの設定を変更する
- WordPressの管理画面にログインする
- [設定]をクリックする
- WordPress アドレス (URL)とサイトアドレス (URL)を、先ほどDNSに登録したCloudFrontのURLに変更する。独自ドメインをもっていない場合は、代わりにCloudFrontのDomain Nameを入力する
**※ ここの設定を誤るとWordPress管理画面にアクセスできなくなるので慎重に!!**設定を誤って管理画面にアクセスできなくなった場合は次項参照 - [変更を保存する]をクリックする
- ログイン画面(CloudFrontのURL)に戻るので、ログインできることを確認する
##もし、管理画面にアクセスできなくなったら・・・
本来であればDBのレコードを直接修正して復旧する必要がありますが、暫定的にwp-config.phpを修正することで管理画面にアクセスできるようになります。
- WordPressサーバにSSHでアクセスし、下記コマンドを実行する
※http://wp-cf.jaws-ug.tk
は、CloudFrontのURL
※i-xxxxxxxx
は、AMIMOTO AMIインストール時に指定したインスタンスID。i-
まで入力してTabキーで補完してもよい
$ cd /var/www/vhosts/i-xxxxxxxx
$ sudo cp wp-config.php wp-config.php.org
$ sudo vim wp-config.php
/*53行目あたり、//define('WP_DEBUG_DISPLAY', false);の後に追記する*/
define('WP_HOME','http://wp-cf.jaws-ug.tk');
define('WP_SITEURL','http://wp-cf.jaws-ug.tk');
##ログイン時のCookieエラー
ブラウザの種類によってはログイン時に下記エラーが表示されることがあります(Chromeで確認)。その場合はオリジン(WordPressサイト)のログインURLでログインしてみましょう。ログインに成功すればCloudFrontのURLに飛ばされるはずです。
それでもダメな場合は、wp-adminをキャッシュさせないを試してみてください。
#POSTできるか確認してみよう
検索やコメント記入が機能するか確認してみましょう。
コメントは自動承認に設定している場合でも、最大でTTLの分だけ遅れて反映されます。
#WordPressサーバを停止してみよう
CloudFrontにキャッシュが存在するページであればサーバを停止しても表示されるはずです。当然ながらPOSTは処理できませんし、TTLを過ぎたキャッシュは削除されてしまいます。また、CloudFrontに切り替える前に投稿された画像はキャッシュされずオリジンを参照します。
可用性と利便性を天秤にかけてTTLの値を決めて下さい。
※ EC2でElasticIPをアサインしていない場合、サーバ停止 -> 起動でグローバルIPが変わりますので注意して下さい。IPが変わってしまった場合は、オリジン向きののDNSレコードを修正する必要があります
#wp-adminをキャッシュさせない
wp-admin(設定画面)はキャッシュされると正常に動作しない場合があるのでキャッシュ対象外にします。キャッシュ対象外の設定を行うには、下記画面で[Create Behavior]をクリックしてBehaviorを追加し、**/wp-admin/*
のTTLを0に設定します。その他の設定値は、先ほどディストリビューションを作成した時と同じでOKです。
併せて動的コンテンツである*.php
**もキャッシュ対象外としておきましょう。