WordPress + W3 Total Cache + CDN な話

今となってはさほどアクセスもないうちのブログなんですが、なんとなくCDN(Contents Delivery Network)を導入してみました。というのも、か細い回線&自宅サーバだったこの10年にお別れをし、自宅の引っ越しを機に海外のサーバに移転したからですが。

cdn-settings-001

日本語でしか書いてないこのブログ、普通に考えれば国内のサーバを借りて公開ってのが筋でしょうが、あいにくのひねくれ者なので「Media Temple」という海外のホスティング会社のDedicated Virtualのサービスを使っています(俗に言うVPSに似た感じのサービスで管理があまりいらない)。

サーバのスペック的には強力になったとはいえ、日本国内からではネットワーク的にはかなり遠い…。どれぐらい遠いかと言えば、日本とアメリカぐらい(そのまま 笑)。そういう背景もあって、このWordPressを使ったブログでもあれやこれやと実験しながら、せめてコンテンツ自体を最適化してロード時間を抑えようと努力してたわけですが、ネットワークが遠すぎたら限界も出てきます。

そこで、今回のこのCDN導入とあいなったわけです。

ところでCDNって何なのよ?

大規模なサイトを運用したりしてる方にはおなじみかもしれませんが、あまりそういう機会のない方のために簡単にCDNの話から始めてみましょう。

CDNっていうのは、直訳すれば「コンテンツ配信ネットワーク」のこと。この仕組み自体は古くからあって、ライブのストリーミングやら容量が大きくなる動画ファイルの配信によく用いられていました(有名なところでは、AppleやらAdobeなんかも使ってるAkamai、国内だとJストリームなどがありますね)。

CDNを使えば、一箇所のサーバにアクセスが集中して配信が止まらないよう、データそのものを世界中に分散されたサーバに配置して、閲覧側のネットワークから近いサーバからコンテンツを配信することが可能になります。期間限定のキャンペーンなどで一時的にアクセスが集中することが予想される場合も、落ちたりしないように前もって予防策が採れるわけです。

今回の震災絡みでは、計画停電の実施で東京電力のサイトが繫がらなくなりました。あれも結構日にちが経ってからAkamaiから配信されるようになってましたが、アクセスが集中するのはアホでもわかるわけだから前もってサイトが落ちないようにすべきとこですけどねぇ…、トップとその告知のページだけでも(契約さえすれば短時間ですぐ稼働させられるんだし)。

近年ではそのような大容量になる動画などのコンテンツ配信や一時的なアクセスの集中を分散化させる以外でも用いられています。最近のWebサイトは、サイト内で使用する画像やCSS、JSといった静的ファイルの数も容量も肥大化してるので、これらのファイルをCDNに置いて配信すればより高速なページ表示が可能になるわけです。

これが大規模なサービスや人気コンテンツを持ってアクセスの多いサイトだけに有益かというとそうでもない。限定的なリソースで運用することで負荷がかかってる部分を他にまわしてあげることは、中小規模のサイトでも導入してみる価値はあります(HTTPリクエストを分散させる意味でも)。

ただし、国内でCDNなどと名が付いてるサービスは、値段が書いてない(問い合わせしてね♥)とかそもそも高いとか、個人レベルだと導入までの敷居がなんとなく高いものです。そんな理由もあるのか既に多くの人が導入しているのが、従量制で課金される「Amazon S3(Amazon Simple Storage)」や「Amazon Cloud Front」だったり、無償のプランもあって最近話題の「CloudFlare」でしょうか。AmazonのサービスやCloudFlareの導入については、多くの方が書いてるので検索してみましょう。

Media TempleのProCDNを使ってみるのさ

ボクが契約しているMedia Templeには、世界的にも有名な「EdgeCast」のCDNが月額$20-(月間転送量200GBまで)で使える「ProCDN」っていうアドオンサービスがあります。EdgeCastの持つ世界4大大陸、東京をはじめとした19箇所の拠点があるので、静的なファイルだけでも閲覧側から近いトコから出してあげれば多少なりとも表示速度は改善されるだろう、と。

日本語での解説もあるAmazonなんかのサービスと違って、英語でしか使えないような海外のサーバを使ってる物好きには説明の必要もないですかね…、でも一応。Media Templeのアカウントでログインして、サービスをアクティベートすればすぐ使えます(笑)。サービスが有効になったら、アカウントセンターからProCDNの管理画面を開いて設定をおこないましょう。

cdn-settings-002

最初にやることは、Customer Originの追加

EdgeCastのCDNは、用意されたEdgeCastのサーバに手動でコンテンツをアップロードする方法と、特定のドメインをCustomer Originとして追加して自動的にコンテンツを追加する方法が採れます。自動で取得する場合は、「HTTP Large」と「HTTP Small」の区別がありますが、300kを超える.flvとか.wmvのようなコンテンツは「HTTP Large」、そうでない画像なんかは「HTTP Small」で扱えば良いようです。

cdn-settings-003

自動的にコンテンツを取得する場合は、EdgeCastでどのサーバのコンテンツを拾うかを決めなければなりません。

cdn-settings-004

配信の大元となるサーバとEdgeCast側の位置の紐付けは、「Customer Origin」メニューを選んでから「Directory Name」にCDN内の位置となるディレクトリ名を入力、「Hostname or IP Address」で配信元のオリジナルのサーバを追加します。で、最後に「Add」を押して終了。

うちの場合は、以前から別ドメイン(gaspanik.com)から配信していたテンプレート(テーマ)に含まれる画像やCSSは「static.gaspanik.com」、WordPressのディレクトリの「wp-includes」や「wp-content」以下にあるアップロード済みの画像やJSといった静的なファイルは「content.gaspanik.com」から配信するように設定しました。本当は一個あればいいんですけどね(笑)。

cdn-settings-006

EdgeCastは、CDN側のコンテンツのGzip圧縮なんかも設定できます。

箱の用意が終わったら、DNSにCNAMEを登録する

EdgeCast側のデータの場所を決めたら、CDNとして稼働するドメインのCNAME(カノニカルネーム。言ってしまえば、エイリアスというか別名)を決めて、EdgeCast側に登録しドメイン側のDNSにもそれを反映させます。

cdn-settings-005

まずは、EdgeCast側の「Edge Cnames」で別名を設定します。「cdn.〜」みたいなサブドメインを入れて、EdgeCastのサーバ内でポイントされる場所(先に設定したディレクトリ以下など)を指定します。

cdn-settings-007

次に自分のドメインのDNSにCNAMEレコードを追加して、HTTP Smallなら「wac.〜.edgecast.net」みたいな指定されたEdgeCastのドメインを指定します。これでEdgeCastのCDNに関するもろもろの設定は終わり。

W3 Total CacheのCDNオプションを有効に

いよいよ本題です(笑)。WordPressで構築されたサイトの高速化するプラグインとして有名な「W3 Total Cache」には、CDNオプションが用意されています。ブログにアップロードする画像やテーマなどに含まれるJSなどはそこそこデータサイズも大きいので、更新の必要のない静的なファイルをCDN側から配信すれば更なる高速化が見込めるわけです。

W3 Total CacheでCDNのオプションを有効にするには、「General Setting」で「Content Delivery Network」を「Enable」にして、自分の使うCDNの種類を選択します。今回のうちの環境はコンテンツをミラーするだけなので、ここでは「Mirror」を選びましたが、Amazon S3やCloudFrontも選択可能です。

cdn-settings-008

次に「Content Delivery Network Settings」に移動して、CDN経由で配信するコンテンツを選択します。

cdn-settings-009

ミラーするだけの場合は、CDN経由で配信されるコンテンツをCNAMEに指定したドメインに置き換えることになります。W3 Total Cacheは、Configurationのところに追加すれば自動的にソースが書き換えられます。

利用するCDNのサービスによっては、FTPなどのログイン情報を指定してライブラリ内のファイルをアップロードすることになるかもしれません、はい。

cdn-settings-010

今回のEdgeCastの設定はCustomer Originにしてるので、ブラウザからコンテンツがリクエストされると配信元のドメインにあるデータが自動的に保存され、その後はCDN側のサーバから配信されるようになるんですね。

あー楽ちん楽ちん。

traceroute で経路を確認してみる

CDN経由でコンテンツの一部を配信するようにしたのでどれぐらい速いかを検証したいものです。Webコンテンツのロード時間を計測するサイトは数多く存在しています。実際に世界各国からいろいろ試してた結果、ロード時間は圧倒的に速くなっていました(世界各国から見られることはないけどもw)。

ホストまでの経路は接続先の環境によって異なるわけですが、自分のところからの経路の比較ならターミナルから「traceroute」というコマンドを使うと手っ取り早いです。

traceroute 調べたいホスト名

と入力すればオッケイ。

cdn-settings-012

うちの回線からもともとのサーバまで約20ホップあったのですが、CDNに振ったサーバだと12ホップになってるので経路自体は短くなっています。EdgeCastは東京にも拠点があるようですが、うちからだとカリフォルニアから配信されてるのはまぁご愛敬ということで(笑)。

これで少しでも国内からのアクセスが速くなればいいな、と。

単なる負荷分散で終わらすか、それとも…

一箇所に集中するコンテンツへのアクセスの負荷を分散させる目的でCDNを使うのはもちろんありですが、それと同時にサイトの高速化を目論んでいる場合は、単純にファイルをCDNから配信すればいいってわけでもありません。

CDN側におく静的なCSSやJSファイルは、Minify化やGzip圧縮することでもっと速くロードされるでしょう。画像に関しても同様で、単にPhotoshopやFireworksから書き出しただけのファイルは別の方法で最適化すればさらに小さくなります。

更新頻度の少ない静的なファイルは、ブラウザのキャッシュを有効に効かせるようにしておけばなお効果的かな、と。最近話題のCloudFlareのことを書いてるサイトは、分散させてお終いだけだったりしますからね(謎)。

負荷分散と一緒にその辺もやってあげると、転送量で課金されるCDNは安くなるだろうし、見る側のストレスもさらに軽減されるんじゃないでしょうか。自サイトで何をすべきかは、GoogleさんのPageSpeedとかGTmetrixや、下の書籍で確認してみましょうか(笑)。

HTML+CSSコーディング ベストプラクティス(Amazon.co.jp)

Tags: , , , , ,

   

Comments are closed.


Performance Optimization WordPress Plugins by W3 EDGE