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

2012-12-03-15-37-2.png

置いたら幸せになるCloudFrontから置かなくても幸せになるCloudFrontCDP Advent Calenderに参加したいがために書いた記事^^;;

[blackbirdpie url=”https://twitter.com/k_nishijima/status/275751687275298816″]

二日間連続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サイト
イメージはこんな感じにしたいなぁ〜と考えています。

2012 12 03 15 37 2

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

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

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

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

20121208CDP01

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

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

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

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

20121208CDP02

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になります。
20121208CDP03

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

20121208CDP04

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の設定変更を行います。
20121208CDP05

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

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

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

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

2回目
20121208CDP07

2回目のアクセスが早いのはCloudFrontの恩恵じゃないかなぁ〜
サーバ側のキャッシュだったらよ^^;;

ということでCloudFrontで配信する場合の構成は下記の通り

20121208CDP08

「キャッシュできるものは全部キャッシュすると理解している。」で当たっているのかが微妙ではありますが

この手法を使うと個人ユーザでも中小企業でも爆速ではないにせよ楽に高速化できます。
CSSセレクタやら画像圧縮よりも今の環境にほぼ手を入れなくても高速化が可能というメリットがあります。

ここまで来てあれですが・・・これってCDPのなににあたるんでしょうか?^^;;
偉い人教えてください。CDP:Cache Distributionパターンでいいのかな?

勉強会の資料もあげますぅ〜

“置いたら幸せになるCloudFrontから置かなくても幸せになるCloudFront” への 1 件のフィードバック

コメントは受け付けていません。