+86 13541016684Mon. - Fri. 10:00-22:00

WordPress 结合CloudFront 配置加速教程

WordPress 结合CloudFront 配置加速教程

WordPress 结合CloudFront 配置加速教程

概要

CloudFrontとは

e9f4c7b4-e5ec-4ac5-8402-4706b14ab6fb
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単体の時とさほど変わらないはずです。

プラグインの停止

  • WordPressの管理画面にログインする
  • [プラグイン]をクリックする
  • Nginx Cache Controllerが有効化されている場合は[停止]をクリックする 3ec5df29-0783-f373-92b8-34d7208b4dfd

CloudFrontディストリビューションを作成する

今回は、POST/GETメソッドは有効(ともにオリジンにスルー)とし、TTLはCloudFront側で一律に制御する設定とします。なお、TTLはコンテンツのCache-ControlExpiresヘッダで個別に制御することも可能です。
TTLについての詳細説明

  • AWSにサインインする
  • CloudFrontコンソールを開く 69cedf9b-4721-9ce4-1939-abdde349b040
  • [Create Distribution]をクリックする
    b96226c2-ed14-7254-b464-fabfab89017f
  • Webの[Get Started]をクリックする
    c8610270-7cb8-158d-f7c3-450e2b7bc6f2
  • Origin Domain NameにWordPressサイトのURL(FQDN)を入力してTabキーを押す
  • Origin IDが自動的に生成されたことを確認する 2d2c8ff9-99c1-ef62-2793-8780b1a88e0a
  • 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]を選択する
    2ab1c103-e3d4-a72e-7536-f128e35555e8
  • Alternate Domain Names(CNAMEs)にCloudFront経由でアクセスする場合のURL(FQDN)を入力する。独自ドメインをもっていない場合は、ダミーのFQDN(例:hoge.com)を入力する。ただし、すでに他のユーザーに使われているFQDNを入力するとエラーになるので、hogeの部分には自分の名前などを使うと良い
  • [Create Distribution]をクリックする
    89ac6450-5c79-7fa5-4fe2-0a97bcdbf59d
  • Distributionの作成完了までに15分程度かかる
    ※ 待っている間にDNSの登録wp-adminをキャッシュさせないを先にやっておくとよい
  • IDをクリックする 4209d024-090d-af05-b916-6c0b8d4402d2
  • Domain Nameを確認する。これがCloudFront DistributionのEndpointとなるので、DNSにCNAMEレコードを登録(Route 53の場合は、AレコードAliasも可)することで独自ドメインでアクセスできるようになる(手順は次項で説明) 51e0a070-433e-6bc6-5a40-790e0baf2f78
  • Distributionの作成が完了すると[Deployed]に変わる 6343df21-0fe9-f1fb-7e27-e8411827f5cf

独自ドメインでアクセスできるようにする

独自ドメインを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の設定を変更します。
0d377b82-24dc-524e-5e6c-c064a10c43f8

WordPressの設定を変更する

  • WordPressの管理画面にログインする
  • [設定]をクリックする
  • WordPress アドレス (URL)とサイトアドレス (URL)を、先ほどDNSに登録したCloudFrontのURLに変更する。独自ドメインをもっていない場合は、代わりにCloudFrontのDomain Nameを入力する
    ※ ここの設定を誤るとWordPress管理画面にアクセスできなくなるので慎重に!!設定を誤って管理画面にアクセスできなくなった場合は次項参照
  • [変更を保存する]をクリックする 084d4e9c-1f0b-562b-a812-e76c4f5b2579
  • ログイン画面(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
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をキャッシュさせないを試してみてください。
e2b1c178-33df-0238-f2f6-5f5443cb4c6b

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もキャッシュ対象外としておきましょう。
96f46c34-2ca4-1ead-7c9f-9c257874063a
e0d85c3d-e88f-0c73-ab94-4f4a800b10d6