最近わかってきたこと

Amazon CloudFrontを体験してみた

2008-12-15 01:30 | IT, エントリー | コメントをする »

遅くなりましたが、CloudFrontを体験してみました。

実験の前に参考サイト

CloudFrontの設定方法や、ダウンロードのベンチマークなどは以下のサイトを参考にしましょう。（と丸投げ）

• AmazonS3上のファイルを国内でも高速配信可能なAmazon CloudFrontリリース : Media Technology Labs (MTL) : メディアテクノロジーラボ　ブログ
• Amazonの従量課金制CDNサービス「Amazon CloudFront」を使う方法 – RX-7乗りの適当な日々

実験の方法

今回やりたかったことは、ブラウザーを使って普通にブラウジングをしてみて、体感を測ることです。

1. HTMLファイル    1
2. JSファイル    5
3. CSSファイル    2
4. 画像ファイル    25

合計33ファイル、163KBのページを表示して、ページがロードされる具合を体感してみました。

EC2単体で体感実験

まずは、全てをEC2のスモールインスタンス上にアップした状態で体感。
Apacheは2.2.9、設定はrpmのデフォルト。KeepAliveはOFF。

やはりもっさり感は否めません。（4.6秒）

CloudFrontで体感実験

では1のHTML以外をS3にアップロードして、CloudFront経由で体感してみます。

これは明らかに速い（1.16秒）。EC2の場合は「ただいま画像1つ1つをロードしてます」って感じで画像が描画されるまでもたもたしていましたが、CloudFront経由の場合はページのロードと同時に画像も描画されました。

Etagもきっちり返してくれるので2回目以降のアクセスには304が返ってきますし、gzipを利用したhttp圧縮も行われているので、cssやjsなどのテキストファイルは効率よく転送されるはずです。

ただし、最初のアクセス時はキャッシュサーバーにデータが届いていないため、キャッシュする為にS3サーバーからの転送時間が加わるので、もっさり感を感じます。2回目はX-Cacheヘッダーが上画像のように変わります。

まとめ

実に簡単な体感実験ですが、CloudFrontの実力は歴然でした。
イメージサーバなどの用途で静的なファイルを負荷分散をするサーバーを立てるケースを想定すると、アクセス急増時にロードバランサー配下のリアルサーバーを増やしたり、静的なファイルを共有する、もしくは分散する仕掛けを用意したり、トラッフィクに注意したり、メンテナンスと運用にかかる時間と人のリソースは、想像に難しくありません。

上記のような心配が必要なサービスを運用している会社さんの場合は、当然既にakamaiなどのCDNを利用していると思いますが、それでもファイル転送元のリアルサーバーは持っている必要があります。
CloudFrontの場合は、配信元サーバーがS3なので、そこのリソースも気にしなくて済みます。

社内でかかるメンテナンスコスト（ベンダー保守、社内保守・監視、対応）、電気代、帯域代、ラック代、サーバー代など様々なコストを考えると、すべて込み込みで1GB/30円っていうのはかなり魅力的ではないでしょうか。

EC2用にCentOS5.2のAMIを作ってみた

2008-12-01 01:33 | IT, エントリー | 3 コメント »

CloudFrontで生まれ変わるか

EC2は日本からだと相変わらず帯域がもっさりしているんですが、Amazon CloudFrontがリリースされて、利用方法を工夫すれば、まともに使えるのでは？と俄然注目です。
CloudFrontはS3上に配置したファイルを展開するCDNで、しかもキャッシュサーバーが日本国内にもあるので、静的なコンテンツはCloudFrontで配信、動的なコンテンツはEC2で配信と分散すれば体感はだいぶ速くなるんじゃないでしょうか。

Amazon Machine Image(AIM)を作る

その実験に先立って、いざという時に安心して使えるEC2用のイメージを持っておこうと思い、使い慣れているCentOSのオリジナルイメージを作ってみました。
作成したイメージファイルを圧縮・分割してS3上に置いた上で、EC2にAIMとして登録を行うと、いつでもそのイメージファイルからインスタンス（サーバー）が起動できるようになります。
当然S3に保管しておくのに料金がかかりますが、月$0.15/GBなので、圧縮したイメージファイルが一つ500Mくらいですから、毎月$0.05（5円）程度ととても経済的です。
（実際、毎月のクレジットの明細にきっちり$0.05が請求されています。請求の手間の方がかかるような気が）

【参考】
RightScaleがCentOSのイメージを公開しているので、それでも問題ない場合はそれを利用した方が楽です。
ami-1363877a    rightscale_images/CentOS5_2V4_0_2_Beta.manifest.xml

大まかな流れは

1. 空のimgファイルにyumを使ってOSをインストールし、AMI用に各種設定を行う
2. S3にアップロードする前にimgファイルを分割してマニフェスト（xmlの設定ファイル）を作る
3. 分割したimgファイルとマニフェストをS3にアップロードする
4. アップロードしたimgを自分のAMIとしてEC2に登録する

参考にしたサイト

• [僕] Amazon EC2 用に自分で CentOS 5 のイメージを用意する

とてもよくまとまっています。
ここを参考に作業を進めていけば、かなりスムーズにいきます。
なので、ここでは環境の問題などで詰まった部分や補足を説明します。

AMI tools は ruby が必要

EC2用のコマンドツール群はEC2のインスタンスを立ち上げたり、情報を取得したり、操作をしたりするec2-api-toolsと今回利用するAMIを作成したり、アップロードしたりするec2-ami-toolsがあります。
後者はrubyが必須で、前者はJava VMが必須です。

yum で 作ったイメージに CentOS 5 をインストールする

ここでyumのgroupinstallオプションでインストールをするわけですが、最初CentOS4.6上で作業した時にはここで躓きました。yumのバージョンが全然違うので、当たり前っていえば当たり前です。
CentOS5のイメージを作成する際に利用する作業マシンのOSはyum > 3 のものを利用しましょう。
（CentOS4系にyum3系インストールするのは依存関係が半端無く、萎えますのであきらめましょう。）

アップロード

ec2-upload-bundleコマンドでアップロードします。
今回はWindows Vista上のVMWareのゲストOS（CentOS5）で作成、そのままアップロードを行いました。
が、VMWare上ではゲストOSの時刻が狂うという問題がありまして、アップロード中にサーバー（S3）の時刻とクライアントの時刻が狂っているとエラーが発生し、正常にアップロードできません。
最終的には、S3Foxを使って手作業でアップロードして、該当するbucketのACLを修正して対応しました。
ACLの設定は「za-team」ユーザーにRead権限を与えます。

以降はスムーズに行くと思います。

インスタンスを立ち上げた後

無事立ち上がった後、このイメージをベースにするため、自分で利用しやすいように環境を整えます。
いきなりhttpdやpostfixなどミドルウェアを入れにいってもいいのですが、どんなサーバーに利用しても必要となる最低限の環境を整えることが今回の目的なので、
ユーザーの作成や、sysstatのインストール、yumレポジトリの追加を行いました。

ベース環境の設定が終わったら、今度はこのインスタンスをイメージ化するため、インスタンス上にprivatekeyファイルとcertificateファイルをコピーして、
ruby、ec2-ami-toolsのインストールからS3へのアップロード、EC2への登録まで、全く同じ手順で行います。
作業の途中、「ec2-bundle-vol」コマンドがエラーで止まってしまうはずなので、

• 一人前のプログラマを目指す日記:[AWS] EC2の仮想マシンイメージを作った – livedoor Blog（ブログ）

こちらを参考に、EC2カーネル用モジュールをコピーして、依存を修正します。

これでようやく汎用的なマイイメージが出来上がりです。

今後はこれにhttpdを入れればWebサーバに、PerlやPHPを入れてAPサーバーに、MySQLやPostgreSQLを入れてDBサーバーにと、ベースのインスタンスを拡張していろいろな用途のサーバーを自由に、いつでも用意できるようになります。

次回はこのインスタンスを使って、Webサーバーを立てて、CloudFrontの実用性を検証してみたいと思います。