AWSのt2.microで月間100万PVに耐えるアダルトサイトを制作した話

AWSのt2.microと言えば、月間1,500円程度のEC2でも極小のインスタンスです。
初回利用の方は無料枠で利用できてしまいます。

そんな貧弱なスペックのサーバーでも大量のアクセスを裁くインフラ作りがAWSなら簡単に出来るので紹介します。
ワードプレスが重いという場合も、同じ手法でサクサクに出来ます。

AWS Cloud Front によるリバースプロキシ構成

AWSに詳しい方なら「閃いた！」となる方もいるかもしれませんが、
CloudFrontにキャッシュさせてしまい、CloudFrontから応答してもらう方法を取る事です。

コンテンツ配信ネットワーク、いわゆるCDNと呼ばれているサービスの商品名です。
主な用途は、大容量な画像や動画、音声等をAWSのインフラを間借りして、代わりに高速配信してくれるサービスです。

一昔前まで、動画配信サービスを運営するには、
「強固なサーバー環境を用意して」
「占有の太い回線を要して」
と、インフラの初期投資が莫大に必要でした。

CDNの登場によって、インフラはAmazonが用意してくれるので
配信に使用した分だけ、Amazonに支払えば良いという初期投資ゼロが可能に成りました。
参考：CloudFrontとEC2の転送料金比較

CloudFrontは、世界中にエッジロケーション（配信を担当するサーバー）を配置しており、
消費者の最寄りのエッジサーバーからコンテンツを配信してくれます。

cloudfrontの仕組み

エッジサーバーは、コンテンツのオリジナル（配信元）からファイルを受け取ると、それ以降はキャッシュします。
配信元には問い合わせず、キャッシュからコンテンツを配信してくれる為、高速配信が可能です。
（※分かりやすくする為、超訳してます）

CDNリクエスト構造

通常はEC2などのインスタンスに対してDNSレコードを割り当てますが、
CloudFrontのディストリビューション自体にアクセスさせたいDNSレコードを割り当てます。

例えば、作品の検索やフォーム送信処理等、
キャッシュされると困る内容についてはCloudFrontからのキャッシュさせない設定が必要です。

新しい記事の追加や、記事変更のタイミングでCloudFrontにキャッシュを削除する様に
Invalidationリクエストを送信すれば、新しいコンテンツを返させる事が可能です。
但し、数分時間を要します。

CloudFrontに負荷のかかる仕事を押し付けるから、EC2は貧弱でも大丈夫という構成です。
欠点としては、キャッシュされている間は新たしいコンテンツに差し変わらないという事です。

然し、1時間に1記事アップするなら、3,600秒キャッシュしたら良いよね？という話です。

リアルタイムなユーザーコメント等が必要であれば、そこだけJSを使って、
クライアントサイド主体に仕事をさせれば、それだけでも大分負荷が変わってきます。

CloudFrontと同等のサービスがSAKURAインターネットから出されており、
料金的にはさらにお得な設定でした。
EC2+ SAKURAのウェブアクセラレータ構成の方がオススメです。
詳しくは：SAKURAのCDNウェブアクセラレータが安くて快適だったので乗り換えた