Amazon EC2からしばらく離れてしまっていたので、少しでも最新の動向を把握できたらと思い、セミナーに参加してきました。

参加したセミナーは、イベント&セミナー情報｜パソナテック（PASONA TECH）です。
講師は、Amazon EC2の運営実績もあるサーバーワークスさんでした。

セミナーの中で説明されたポイントを、いくつかご紹介したいと思います。

パフォーマンスについて

Amazon EC2には「Region」という概念があります。
Regionを訳すと、地域とか地区などという意味ですが、インスタンスを実行する場所のことを示しています。EC2では、インスタンスを実行する際に、Amazonのデータセンターを間借りするようなイメージですが、要するにそのデータセンターがある場所だと捉えていいと思います。

2009年12月に「US West（N.California）」のRegionがリリースされました。
AWS Launches the Northern California Region

AWS Management Consoleでは、左ペインのNavigationより、選択することが出来ます。

2009/4/28時点では、3種類のRegionがあります。

• US East(Virginia)
• US West(N.California)
• EC West(Ireland)

サーバーワークスさんの説明では、US Westが一番パフォーマンスがよく、オススメのRegionだそうです。

簡単な比較結果が示されていました。

• US East
  pingコマンドの応答速度：200msec
• US West
  pingコマンドの応答速度：120msec

Amazon EC2でWebサービスを運営するにあたって、日本から利用する際のパフォーマンスがネックだと考える方も多いと思います。以前、私が「US East」を利用していた際は、SSHの操作でも若干ストレスを感じる程度でした。まだまだ早いとは言えませんが、すいぶん改善されたようなので、今度「US West」のRegionを使って体感してみたいと思います。

注意点は、Regionによって料金体系が異なることです。
Amazon Elastic Compute Cloud (Amazon EC2)

料金の違いは、時間単価で数セントのなので、パフォーマンス重視で迷わず「US West」を選択すると思います。

Cloudworks

次に、HOME – Cloudworksについてです。
講師でもある、サーバーワークスさんの提供されているサービスです。無料で使えるAWS Management Consoleの日本語版といった感じでしょうか。

その他にも独自の機能があるようです。

• インスタンス名に日本語で名前やタグ名を付けることができる。
  AWS Management Consoleでは、稼働中のインスタンスに英字で名前がつけられるため、パッと見、何の用途で稼動しているか、名前から判断するのは難しいです。
  
  こんなときに、日本語で名前を付けたり、タグを付けたりできると、複数のサービスを運営している際などには、一目で見分けられるので非常に便利です。
• インスタンスの起動／停止するようなジョブを設定でき、自動化することができる
  自前でバッチを作る必要も、そのバッチの配置場所を用意する必要もありませんので便利ですね。

Amazon EC2には興味があるが、英語サイトのAWS Management Consoleを使うのに抵抗を感じている方など、現時点では無料ですので、Amazon EC2を実際に使ってみて、理解を深めるいい機会だと思います。

Amazon EBS

EBSとはElastic Block Storeの略で、ストレージデバイスのオプションです。
ちょっと調べてみたのですが、以前は、まずはじめに仮想ディスクを作成してから、稼働中のインスタンスをアタッチするという手順だったようです。
※ この手順については、いつも参考にさせてもらっている、rx7さんのブログが非常に参考になります。
最近発表されたストレージサービスAmazon EBS(Elastic Block Store)をEC2から利用する – RX-7乗りの適当な日々

最近は、どうやら新しい機能がリリースされ、Amazon Machine Image（AMI）自体にEBSのオプションが付属しているようです。つまり、上記のような手順をとらず、AWS Management Consoleの「Root Device Type」が「ebs」になっているAmazon Machine Image（AMI）を選択し、起動するだけでこのオプションが利用できるようになったのです。
Boot from Elastic Block Store – Develop with pleasure!を参考にさせていただきました。

Root Device Typeには2つのオプションがあります。

• Instance Store（instance-store）
• Elastic Block Store（ebs）

一番の違いは「インスタンスダウン時にデータが消失しない」ことです。

EBSを使ってインスタンスを起動した場合、当然インスタンス上で変更した内容は永続化されるんだろうと思ったが、EBSから起動したインスタンスを停止する場合、以下の2パターンの停止方法があるみたい。

* Terminate
こちらは通常のインスタンスの停止と同様、インスタンスを停止し、EBSボリュームも削除される。
* Stop
こちらはTerminateとは異なり、インスタンスは停止するが、EBSボリュームは削除されない。そのため、インスタンスの状態にStopという状態が追加されてる。このStop処理が可能なのはEBSからインスタンスを起動した場合のみ。Stopしている状態では当然インスタンスは稼働していないので、費用は発生しないがEBSのデータ量の課金は発生する。

環境を保持したり、永続化したいデータがあるのであれば、Stopを使うべし！と。うっかりTerminateしたらEBSが削除されるので冷や汗もんだけど。

Boot from Elastic Block Store – Develop with pleasure!より引用。

その他の特徴として、以下のような説明がありました。

• 利用可能なディスク容量は1GB～1TB
• 稼働中インスタンスのスナップショットを取得可能
• 別途利用料がかかる（Instance Storeは無料）
• AMIの起動時間は１分以内
• インスタンス終了時に、EBSボリュームを残すことが可能
• 停止時にカーネル、RAMディスクを変更可能

EBSとは、「外付け仮想ディスク」のようなものだ、とよく言われています。
セミナーの説明資料にも同様の説明がありました。

あと、補足としては、「Root Device Type」がElastic Block StoreのAMIは、まだまだ限られたものしかありません。

※ 比較的、Windows版は対応されているものが多いように、見受けられました。

その他には、、、
AWS Management Console上に表示されている、インスタンス一覧のコンテキストメニューから、「Create Image（EBS AMI）」を選択することで、インスタンスのバックアップができるようです。

AWS Management ConsoleとAmazon EC2 API Toolsを併用することで、使用不能になることは回避できるらしいです。

今度、実験してみたいと思います。

サインアップのステップが増えたようです

当初は、Amazon Web ServicesのWebサイトで、ウィザードに沿って進めていけば、サインアップが完了したのですが、どうやら、確認用の電話番号を登録するというステップが増えたようです。

1)アカウント取得
↓
2)EC2にサインアップ
↓
3)確認用の電話番号を登録
↓
4)電話がかかってきたら、確認用の4桁の数字をプッシュする。
↓
5)利用開始

詳細はよくわからないのですが、4)では自動音声で指示されるようなので、指示通り番号をプッシュすればよいのだと思いますが、このようなサインアップの形式を試したことがないので、なんとなく抵抗を感じます。すぐに電話がかかってこなかった場合などは、どうしたらよいのでしょう・・・

このステップが実施される以前に、アカウントをとっておいて良かったです。

ちなみに、確認用の電話番号は、国際電話になりますので、以下のような感じで入力します。

例）
03-1234-5678
↓
81-3-1234-5678

Amazon EC2のお役立ちツール

セミナーの最後にあった、Amazon EC2関連のツール郡について、いくつかご紹介したいと思います。

AWS Toolkit for Eclipse
EclipseからAmazon EC2を操作するプラグインです。使ったことはないのですが、Javaで作ったモジュールをすぐアップしたいときなど、非常に役に立つと思います。

Amazon Web Services Simple Monthly Calculator
Amazon EC2利用に発生するコストを簡易的に算出してくれるサイトです。月のランニングコストの目安になるかと思います。

また、稼働中のインスタンス等で障害が発生した場合にも、Amazonからの連絡は一切ないので、RSS等から情報をウォッチするするなど、自主的に情報収集しましょう。
AWS Service Health Dashboard – Apr 28, 2010

こんなときに役に立つのが、flashcast：フリーで働くITエンジニア集団のブログ: Nubium Sentinelを使ってみるで紹介したこともあるSentinelです！

Amazon EC2でサービスを運営する際には、積極的活用していきたいと思います。

久しぶりのAmazon EC2ということもあり、まったく知らなかった情報もいくつか入手できたので、非常にためになったのを感じるとともに、世間の技術の進歩の速さをあらためて痛感したものとなりました。

立ち上げたいサービスはあるけど潤沢な資金を用意できないような場合でも、EC2では初期投資がほとんどかかりませんし、急激にアクセスが増えてもスケーリングが容易ですので、フリーのエンジニアやベンチャー企業にも、チャンスを与えてくれる可能性を感じます。また、開発環境やテスト環境としての用途でも、十分に利用するメリットがあることを、今回のセミナーを通じて感じました。不要なときは停止しておけば、課金されませんから。
※ Amazon S3にイメージファイルを保存している場合には、別途料金がかかります。

機会がありましたら、また、参加したいと思います！

昨年、11月の初旬に、私もじゃもじゃ宛てに株式会社ハウインターナショナル様から1本のメールが届いておりました。

Amazon EC2を活用したSaaS型サーバ監視システム「Nubium Sentinel」というサービスを使ってみませんか？というものでした。

過去に、Amazon EC2に関する記事をいくつか書いていたことから、ご紹介いただけたのだと思います。

すいぶん経ってしまいましたが、最近ようやく、まとまった時間が取れましたので、Nubium Sentinelを試してみることができました。

Nubium Sentinelには、

1. サーバリソースの使用状況監視
2. サーバ死活監視（ping）
3. HTTP監視（BETA）

の大きく3つの機能があります。

メインは「サーバリソースの使用状況監視」で、CPU、Memory、Disk、Networkの状況を監視する機能です。
詳細はこちら

この機能は、サーバにモジュールをインストールする必要があります。EC2用とLinux用の2つの導入手順がありました。
詳しくはNubium Sentinelの「導入手順」をごらんください。

また、死活監視では閾値をこえると、アラートメールを送信する機能もついてました。

監視対象のサーバは、現状ではLinuxやUNIX系のOSが対象となるようです。また、Amazon EC2で運用中のサーバの監視もできるようで、Amazon EC2のようにクラウド上にサーバを配置するということに、不安を抱えるユーザに対してのNubium Sentinelの売りだと思います。

flashcastでは、Amazon EC2で運用しているサービスは現状ありませんので、当ブログサイトを運営しているサーバに対して、サーバ死活監視（ping）とHTTP監視（BETA）の2つを導入してみることにしました。

サーバ死活監視（ping）

まず、こちらから管理者機能にログインします。

次に、「設定」メニューから「サーバ設定」を選びます。

監視するサーバは5つまで登録できるようです。

PCマークのアイコンをクリックすると

登録画面が表示されます。

必要な情報を入力して、追加ボタンをクリックします。アラートメール設定は、とりあえず「パターン1」を選択してみました。

アラートメールのパターンの内容は、となりのヘルプマークをクリックすると意味が表示されます。

ちょっとわかりづらいかもしれませんので、機能説明の方にもあった方が良いような気がしました。

登録が完了すると、一覧に表示されるようになります。登録直後はPingが準備中マークになっていました。

サーバ死活監視（ping）の設定はこれで完了です。

HTTP監視（BETA）

HTTP監視（BETA）は、登録されたWebサイトをHTTPのHEADメソッドを使って監視する機能です。HEADメソッドを利用しているのでHTTPのレスポンスにメッセージボディが含まれません。なので、Google Analyticsなどのアクセスログ解析ツールを使用しても、ログがカウントされません。
詳しくはNubium Sentinelの「HTTP監視サービスBETA」をごらんください。

では、早速使ってみたいと思います。

「設定」メニューから「HTTP監視サービスBETA」を選びます。

監視対象サイトのURLを設定します。

HTTP監視対象一覧に表示されるようになります。

HTTP監視（BETA）の設定はこれで完了です。

監視間隔

5分毎に登録されているサイトの監視を行います。
サイトからのレスポンスが10秒以内に返って来ない場合は、再度サイトにリクエストを発行します。
3回続けて10秒以内にレスポンスが帰って来ない場合はタイムアウトと判断します。

アラートメール

監視対象のサイトのレスポンスのステータスコードが2xx以外の場合は、
登録されているメールアドレスにアラートメールを送信します。

異常があったときには、アラートメールが飛んでくるようです。メールが来ないことを祈ります。

サーバ死活監視（ping）の結果確認

サーバ死活監視（ping）の設定直後には準備中になっていましたが、HTTP監視（BETA）の設定が終わり、再度確認すると、監視中になっていました。

この設定をしたのが2010/2/27で2010/3/5に確認したところ、異常は発生していませんでした。

よかったよかった。

考察

24時間365日稼動するサービスの運営では、死活監視は重要な運用の1つです。その際には、当然監視する側の仕組みを作る必要がありますが、Nubium SentinelのようなSaaS型のサービスではその必要がありません。Nubium Sentinelの導入後、即、死活監視を開始することが出来るようになりますので、非常に便利なサービスです。

戦略的には、ユーザ数を増やすことを目的とするのなら、ping監視については無料で利用させ、サーバリソース監視の方をオプションでの有償提供するというのもありなのではないかと思いました。

また、Amazon EC2ユーザをターゲットにするなら、サーバモジュール導入済のAMI（Amazon Machine Image）を公開されるのも良いかもしれません。

要望が1つあります。
アンインストールの手順が欲しいですね。

あ、あと、自前のサーバと違って、自由に設定を変更したり、モジュールを導入したりできないという制限の多いレンタルサーバなどでも、「サーバリソースの使用状況監視」ができるようになると素敵だと思います。

次は、Amazon EC2への導入にチャレンジしてみたいと思います！

Amazon Web Serviceより、AWS Management Console β版リリースの発表がありました！AWS Management Consoleは、AWSが提供する（Amazon EC2を中心とした）サービスの、Webベースの管理コンソールです。EC2に関しては、AMIを一度に複数インスタンス起動したり、起動しているインスタンスの状態を参照したりすることができます。早速ちょこっと使ってみました。

1.AWS Consoleポータルを開きます。

AWS Console

2.[Sign in to Amazon EC2 Console]ボタンをクリックしてSign inします。

Sign inするとAWS Management Consoleが開きます。

3.左ペインのAMIsを選択します。

4.Private AMIを選択し、[Launch]ボタンをクリックします。

ここでは、flashcast：フリーで働くITエンジニア集団のブログ: Amazon EC2でlighttpdとphpをセットアップしてみたで作成したAMIを選択しています。

[Launch Instances]画面が表示されますので、Number of Instances（起動するインスタンスの数）を入力して、[Launch]ボタンをクリックします。

起動中のメッセージが表示されます。

ん？なんかエラーが出ました。「リロードしなさい。解決しなければ連絡を。」みたいなことでした。エラーメッセージを一生懸命読んでるうちに、インスタンスが起動しました（Statusがrunningになりました）。

うん。大丈夫そうです。

5.[Connect]ボタンを押してみました。

sshで接続しなさいと言われてしまいました。[Connect]ボタンはいらないような気がします・・・

7.[Output]ボタンを押してみました。

サーバの情報が出力されています。

8.lighttpdが起動しているか確認します。

確かに起動しています。じっくりいじるのは今度にしよう。

9.AWS Consoleに戻って、[Terminate]ボタンをクリックし立ち上げたインスタンスを停止します。

確認メッセージが出ました。[Yes, Terminate]ボタンを押してしばらくするとStatusがterminatedになりインスタンスが停止しました。

これならElasticfoxやAmazon EC2 Command-Line Toolがない環境でも、ブラウザがあればEC2を立ち上げられます。機能もElasticfoxより充実しているように思いました。但し、サーバにリモート接続するためにはsshが必要になります。ありがたいのはflashcast：フリーで働くITエンジニア集団のブログ: Amazon Machine Image（AMI）を立ち上げる前にのような事前準備がほとんどいらなくなることです。必要な情報はサーバ側にあるのですから。

lighttpdって、日本語で呼ぶとき困りませんか？ライトエイチティーティーピーディーなのか、ライトティーピーディーなのか？正しくはlightTPDで後者のようです。
lighttpd – Wikipedia

lighttpdとは、軽量（light）で高速なWebサーバ（http）として動くデーモン（d）で、Apacheよりも高速だと言われており注目を集めていますが、phpとの連携をAmazon EC2で試してみました。

いつものようにFedora8のパブリックAMIを使用してインスタンスを立ち上げ、PuTTYにてログインします。後の手順でlighttpd-fastcgiパッケージをインストールするのですが、yumコマンドでlighttpd-fastcgiが見つからなかったため、まずyumのリポジトリを最新状態にしました。

lighttpdをインストールします。

サーバ起動時にlighttpdが自動的に立ち上がるように設定します。

lighttpdを起動します。

ブラウザからlighttpdが正常に起動されたか確認します。http://hostname/でlighttpdのデフォルトページが表示されるか確認します。

これでlighttpdの初期設定は完了です。

ここからはphpとlighttpdの連携のためのインストールと設定の説明になります。phpをlighttpd上で稼動させるためには、FastCGIが必要です。
FastCGI – Wikipedia

lighttpd-fastcgiパッケージをインストールします。

phpをインストールします。

php.iniを編集します。/etc/php.iniの任意の場所に以下の一行を追記します。

cgi.fix_pathinfo = 1

lighttpd.confを編集します。/etc/lighttpd/lighttpd.confを編集しmod_fastcgiを有効にするためにコメントアウトをはずします。

server.modules　　　= (
#　　　　　　　　　”mod_rewrite”,
#　　　　　　　　　”mod_redirect”,
#　　　　　　　　　”mod_alias”,
　　　　　　　　　”mod_access”,
#　　　　　　　　　”mod_cml”,
#　　　　　　　　　”mod_trigger_b4_dl”,
#　　　　　　　　　”mod_auth”,
#　　　　　　　　　”mod_status”,
#　　　　　　　　　”mod_setenv”,
　　　　　　　　　”mod_fastcgi”,　　　　　　　　　< - ここ！
#　　　　　　　　　”mod_proxy”,
#　　　　　　　　　”mod_simple_vhost”,
#　　　　　　　　　”mod_evhost”,
#　　　　　　　　　”mod_userdir”,
#　　　　　　　　　”mod_cgi”,
#　　　　　　　　　”mod_compress”,
#　　　　　　　　　”mod_ssi”,
#　　　　　　　　　”mod_usertrack”,
#　　　　　　　　　”mod_expire”,
#　　　　　　　　　”mod_secdownload”,
#　　　　　　　　　”mod_rrdtool”,
　　　　　　　　　”mod_accesslog” )

.phpファイルをfastcgiで処理できるように、以下の部分のコメントアウトをはずします。

fastcgi.server　　　= ( “.php” =>
　　　　　　　　　　　( “localhost” =>
　　　　　　　　　　　　(
　　　　　　　　　　　　　”socket” => “/var/run/lighttpd/php-fastcgi.socket”,
　　　　　　　　　　　　　”bin-path” => “/usr/bin/php-cgi”
　　　　　　　　　　　　)
　　　　　　　　　　　)
　　　　　　　　　　)

テストphpページを作成します。

<?php phpinfo(); ?>

phpinfo.phpとして保存。lighttpdのコンテキストルートはデフォルトで/var/www/lighttpdなので、ここに移動。

lighttpdを再起動します。

phpinfo.phpにアクセスします。

ちゃんと表示されました。

こんな感じで試しに何かしてみようというときにも、Amazon EC2だとサクッと出来ちゃいますね。物理的にサーバ用意して、ネットワークつなげて・・・なんてことも要りません。使いたいときに使いたい時間だけ、立ち上げる。実運用に入っても、本番サーバ、テストサーバなんて筐体をそれぞれ用意しておく必要もないし。それぞれイメージを用意しておけばいいのですから。なんて便利な時代になったことか。カスタムAMIとして保存したければ、いつものようにS3にアップロードして完了です！

※　カスタムAMIの保存はこちらを参考に。
flashcast：フリーで働くITエンジニア集団のブログ: Amazon EC2 AMI起動

稼働率99.95%以上というSLAを引っさげて10/23に正式版になったAmazon EC2、久しぶりにいじってみました。β版から使っていたカスタムAMIも問題なく動きました。

EC2を使っていると、ローカルで作成したものを起動中のサーバにアップしてブラウザから確認、というようなことをしたいときがありますが、こんなときに便利なのがs3sync.rb。

1.起動中のサーバにインストール

2.解凍

3.環境変数の設定

• AWS_ACCESS_KEY_ID：
• AWS_SECRET_ACCESS_KEY：

flashcast：フリーで働くITエンジニア集団のブログ: Amazon Machine Image（AMI）を立ち上げる前にでご紹介した、3.のAccess Key IDと4.のSecret Access Keyです。私の場合、.bash_profileで設定しています。

AWS_ACCESS_KEY_ID=XXXXXXXXXXXXXXXXXXXX
AWS_SECRET_ACCESS_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

export AWS_ACCESS_KEY_ID
export AWS_SECRET_ACCESS_KEY

4.EC2からS3へアップロード
コマンドラインからカレント配下のファイルをS3のflashcastバケットのtempにコピーする場合。

※　rubyがインストールされていること！

5.S3からEC2へダウンロード
コマンドラインからflashcastバケットのtemp内のファイルをカレントにコピーする場合。

※　-vオプションは詳細を表示する。Create node uploadtest1.txt・・・が出力されています。

運用中のインスタンスの場合などには、スクリプトを組んで定期的にS3にバックアップするようなことにも利用できるかと思います。