浜田山にあるブルー・グラス・アーツさんの吹きガラス体験でグラスを作ってきました。こんな道具を使います。色ガラスの粒を並べて、模様をデザインします。この炉にドロドロなガラスが入っています。ガラスを巻き付けた管を冷やします。十分空気を入れたら、真っ赤に燃えたガラスに用意した色ガラスの粒を巻き付けていきます。管を底に付け替えて、口を作ります。温度を徐々に下げないと割れてしまうので、専用の保存庫で12時間かけて常温に冷ましていきます。・・・いろいろありますが、すっとばして完成!このグラスで初めてやることと言えばやっぱこれでしょ!美味い!番外編。見えても人間だと50歳のおじさんだそうです。エサをあげたら懐かれた。遅くなりましたが、CloudFrontを体験してみました。実験の前に参考サイトCloudFrontの設定方法や、ダウンロードのベンチマークなどは以下のサイトを参考にしましょう。今回やりたかったことは、ブラウザーを使って普通にブラウジングをしてみて、体感を測ることです。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円っていうのはかなり魅力的ではないでしょうか。CloudFrontがリリースされて、利用方法を工夫すれば、まともに使えるのでは?と俄然注目です。CloudFrontはS3上に配置したファイルを展開するCDNで、しかもキャッシュサーバーが日本国内にもあるので、静的なコンテンツはCloudFrontで配信、動的なコンテンツはEC2で配信と分散すれば体感はだいぶ速くなるんじゃないでしょうか。Image(AIM)を作るその実験に先立って、いざという時に安心して使えるEC2用のイメージを持っておこうと思い、使い慣れているCentOSのオリジナルイメージを作ってみました。作成したイメージファイルを圧縮・分割してS3上に置いた上で、EC2にAIMとして登録を行うと、いつでもそのイメージファイルからインスタンス(サーバー)が起動できるようになります。S3に保管しておくのに料金がかかりますが、月$0.15/GBなので、圧縮したイメージファイルが一つ500Mくらいですから、毎月$0.05(5円)程度ととても経済的です。(実際、毎月のクレジットの明細にきっちり$0.05が請求されています。請求の手間の方がかかるような気が)【参考】RightScaleがCentOSのイメージを公開しているので、それでも問題ない場合はそれを利用した方が楽です。イメージを用意するとてもよくまとまっています。ここを参考に作業を進めていけば、かなりスムーズにいきます。ここでは環境の問題などで詰まった部分や補足を説明します。必要EC2用のコマンドツール群はEC2のインスタンスを立ち上げたり、情報を取得したり、操作をしたりするec2-api-toolsと今回利用するAMIを作成したり、アップロードしたりするec2-ami-toolsがあります。インストールするここでyumのgroupinstallオプションでインストールをするわけですが、最初CentOS4.6上で作業した時にはここで躓きました。yumのバージョンが全然違うので、当たり前っていえば当たり前です。ものを利用しましょう。(CentOS4系にyum3系インストールするのは依存関係が半端無く、萎えますのであきらめましょう。)アップロードec2-upload-bundleコマンドでアップロードします。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への登録まで、全く同じ手順で行います。Blog(ブログ)こちらを参考に、EC2カーネル用モジュールをコピーして、依存を修正します。これでようやく汎用的なマイイメージが出来上がりです。今後はこれにhttpdを入れればWebサーバに、PerlやPHPを入れてAPサーバーに、MySQLやPostgreSQLを入れてDBサーバーにと、ベースのインスタンスを拡張していろいろな用途のサーバーを自由に、いつでも用意できるようになります。次回はこのインスタンスを使って、Webサーバーを立てて、CloudFrontの実用性を検証してみたいと思います。