敢えてサイト丸ごとCDNにしない
can.ne.jpではサイトを丸ごとCDN(配信サービス)で配信しないようにしています。CloudFrontなどのCDNはそれなりにお高い上に、フォームを置いたインタラクティブなサイトでトラブルが生じる可能性を否定出来ないからです。
動画や画像だけCDNに置く
can.ne.jpが使っているWordPressというCMSは基本的にはローカルでファイルを管理します。ただし、『HTMLブロック』機能でリンクを手書きすれば外部の画像を表示出来ます。
また、WordPressプラグインの動画プレイヤー『FV Flowplayer Video Player』や音声プレイヤー『MP3 Music Player by Sonaar』はURL指定で外部ファイルを再生できます。
これらを使うことで、ファイルサイズが大きい動画や画像だけをCDNに置くことが出来ます。
2サーバー＋CloudFront構成で大きなファイルだけCDN配信する
これらを念頭に置いて構築したcan.ne.jpの構成図は下記となります。
まず、WordPress MultiSiteを設置したブログサーバー(can.ne.jp)とは別に配信サーバー(cloudfront.can.ne.jp)をLightSailで作ります。ただのファイル置き場なのでCMSなどは動かさず、Webサーバーも高速と言われるNginxを選びました。このようなサーバーを『オリジンサーバー』と呼びます。オリジンサーバーは外部からのアクセスを想定しないため、SSL証明書は不要です。
次に、CloudFrontのインスタンス(cf.can.ne.jp)を作成してSSL証明書を取得します。can.ne.jpのドメインはAWSのDNSサーバー『Route 53』に置いているので、cf.can.ne.jpへのアクセスをCloudFrontに流し込む設定を簡単に行えます。
なお、CloudFrontのようにサイト訪問者に最寄りから高速にデータを配信するサーバーを『エッジサーバー』と呼びます。各種設定の際は、オリジンサーバーとエッジサーバーが別のサーバー名(FQDN)になる点に気を付けて下さい。
Amazonの回し者のような図をついに描いてしまいましたが
AWSがAmazonの利益率が高い事業であることは知っているので、AWSが決して『最安』ではないとの認識です(Amazonの商品が必ずしも最安ではないように)。
CDNの導入にあたっては、無料枠があるCloudflareも検討しました。しかしDNSをRoute 53からCloudflareに移さなければならないことが分かったため断念しました。とにかく安くサイトを運営したいなら、DNSを設置する段階からCloudflareを選んでおくのが良いと思います。
また、CDNを選ぶ際はエッジサーバーが日本国内でどの程度配備されているかが重要なポイントとなります。個人サイトなら落ちさえしなければ遅くても構いません(笑)。しかしビジネス目的なら国内に多数のエッジロケーションがあるかどうかが配信速度を左右しますので、無難にCloudFrontや、お高いことで有名なAxxxxxなど有名なサービスを選ぶことになると思います。
CDNは「逃げられるようにしておく」のが大事
ロートルWeb担当者なら身に覚えがあるかも知れませんが、昔はCDNと言えばAxxxxx社だったので、CDNを入れるイコール「青天井の予算を組む」という恐ろしいタスクでした。
特に企業サイトでは新製品発表など訪問者がスパイクするタイミングで波の大きさがどれくらいになるか、なかなか読めないものです。発表日にはCDNのコンソール画面に貼りついて、アクセスが殺到して予算超過にならないか見張らなければなりません。
「いよいよ予算的にヤバイ」となれば、泣きながら手動でリンクをオリジンサーバーに付け替えるわけです。これでサーバーが重くなったり最悪落ちるかも知れませんが、CDNの青天井課金から逃げることだけは出来ます。
「そもそもアクセスが殺到しても耐えられるくらい予算を確保(できる会社に就職)しておけよ」という正論が聞こえてきますが、悲しきかな日本の社畜はそうも行かないのが常です。保身の手段として覚えておくと良い、かも知れません。