置いたら幸せになるCloudFrontから置かなくても幸せになるCloudFront

2012年12月8日2016年9月8日

CDP Advent Calenderに参加したいがために書いた記事^^;;

@asumaslv 8日米須さん、9日僕でいきましょ。 http://t.co/QkZcvxKj で参加表明と希望日をコメントすればオッケーです
— 西島幸一郎 (@k_nishijima) 2012年12月4日

二日間連続JAWS-UG沖縄!!!それがやりたかっただけともいう。
他に書いているメンバーみていると・・・見ないふり、見ないふり

1番好きなAWSサービスはCloudFront。
だって置けばあとは勝手にやってくれるんだもん。
ということでCloudFrontネタでいってみる。

SlideShareで荒木(@ar1)さんのプレゼンを眺めていたら

サイトまるごとCloudFront化なんていう文言を発見

サーバ台数削減、コスト削減
エンドユーザ体験向上
モデルのシンプル化

個人ユーザにとってコスト削減(EC2 Instanceを極力使わない)とエンドユーザ体験向上(CDNの利用)はアリでこのサイトでも一部使っていた。
.htaccessでがんばって

Redirect permanent /archives/ http://cdn.barasu.org/archives/

ディレクトリ単位で書いていく?

*.JSや*.CSSを置いてあるフォルダだけS3にCopyしてCDN(CloudFront)で配信する?
どちらにしても面倒なのは変わらない。
がんばらないといけないし

ということで目指すのは手軽に何も考えずにCloudFrontを利用して高速Webサイト
イメージはこんな感じにしたいなぁ〜と考えています。

詳しくは「【AWS発表】Amazon CloudFrontが動的コンテンツをサポート」を参考に

こんな感じで最初に入ってくる部分はCloudFrontにする。

でもこの構成図をみてすぐにやってみようと思えない・・・
だってどう考えたってめんどくささそうだよね?
「手軽に何も考えずにCloudFrontの利用」というのを目標にしている私には敷居は高い・・・

今のこのサイト構成は下記のようになっています。

同期はs3syncをcronで処理していました。
これをCloudFrontを頭にしてみます。

S3バケットの用意をする
s3syncで画像ファイルをS3にあげる
新規CloudFrontを追加
CloudFrontの設定を行う
DNSの設定変更

1. S3バケットの用意をする。

バケット作成はいろいろなツールがあるとは思いますが1番楽なAWS Management Consoleを利用しました。
今回のバケット名は「barasu-cf」で作りました。
CloudFrontのLogをはき出すバケットもついでに作ります。
Log用バケットは「barasu-cf-log」

2. s3syncで画像ファイルをS3にあげる(やらなくてもOK)

S3にあげる必要はないんですけどね^^;;とりあえずバックアップの意味で上げてあります。

s3sync.rb -rp ドキュメントルート/wp-content/uploads/ barasu-cf:wp-content/uploads/

私は定期的に上記スクリプトが動くようにcrontabに設定しました。

3. 新規CloudFrontを追加

AWS Management ConsoleでCloudFrontを選択して
「Create Distribution」を押下します。
Step1: Select delivery method は「Download」を選択
Step2: Create distributionは下記の通りにしました。
Origin Domain Name 現在利用しているコンテンツ配信先
Alternate Domain Names(CNAMEs) www.barasu.org(配信したいドメイン名)
Logging On
Backet for Logs Log用に作成したバケット
上記項目が設定終わったら「Create Distribution」を押下します。

数分待つとStatusがInProgressからDeployedになります。

今作ったDistributionを選択して「Distribution Settings」を押下
General、Origins、Behaviors、Invalidationsというタブが出てくるはずです。

Originsに追加するならS3バケットを追加してください。
私は追加をしました。
画像はそっちに置いた方がバックアップも兼ねて安心なので

今回はやらなくてもCloudFrontでの利用は可能です。

Behaviorsはこんな感じにしました

Path Pattern	Origin
archives	S3-barasu-cf
/wp-content/uploads/	S3-barasu-cf
Default(*)	コンテンツ配信先

archives配下と/wp-content/uploads/ 配下はS3バケットからの配信
それ以外はEC2のInstanceからの配信という設定になります。

ファイル名(*.jpgとか*.png)やディレクトリ毎にOriginsを設定することも可能です。今回は「手軽に何も考えずにCloudFrontの利用」というのを目標なのでこれ以上は触りません。

※OriginsやBehaviorsの設定をしたら反映までに少し時間がかかります。

DNSの設定変更

CNAMEで設定した名前をDomain Nameに設定します。
私はRoute53でDNSをもっているのでRoute53の設定変更を行います。

これでアクセスしたらCloudFront経由になっています。

AWSはエンタープライズ系にももちろん耐えうるから個人ユーザの敷居が高くなっているきがしていましたが今回やってみて考え変わりました。
複雑な事も出来るけど、単純な事ももちろん出来る。
ですね。

最後になりますが本当にCloudFront経由になっているか確認します。
テスト用の画像ファイルを用意して置きます。
それを表示させて1度そのファイルを消してみてください。
CloudFront側にキャッシュされていれば消したファイルももちろんキャッシュが消えるまでは閲覧可能。
キャッシュが残って困るかたはInvalidationsでがんばってください。
今回は触れません^^;;
だって手軽に何も考えずにCloudFrontの利用だもーん^^;;

速度よりもtracerouteの結果にびびりました。
当たり前なんだけどエッジロケーションまでなのでHOP数が恐ろしく小さい。
Singapore Regionから行うと日本国内に入ってこない。
Singapore Region内部で解決
Pingdom Toolsdでもtracerouteのチェックをすると7hopしかかっていない。
世界中にエッジが持てる強みは強烈。
1回目