Amazon SNS自腹実験人柱サイト、AWSWatch をリリースしました。 Tweet

Amazon Web Serviceを監視して、異常があったらAmazon Simple Notification Serviceを通してメールで通知するサイト、AWSWatchを作ってみました。 ロゴがいかにもやっつけでダッサイですけど。

作った動機

あまり大きな声で言いたくないのですが（笑）、2010年5月、立て続けにUS-EASTで障害が発生しました。

• 5/4(米国時間）発生の、US-EASTでの電源供給不具合の影響について
• 5/8(米国時間) US-East でAZの一つに障害発生
• 5/11(米国時間) US-EASTで障害発生
• 日本時間5/20 US-EAST EC2での障害情報

一発目はゴールデンウィーク中の5月4日で、こちらのブログでも言及されている通り、一部のEC2インスタンスが結構長い間ストップしてしまいました。個人的にも仕事で使っているインスタンスのうち1台が、外部からの強制リブートがかかった形跡を確認しています。

通常サービスを立てる際は、サーバーの監視というのをやると思いますけど、仮にトラブルが発生した際、原因がアプリケーションなのか、OSなのか、それとももっと低レイヤーのハードウェアなのか？という切り分けをするかと思います。そう言った事をクラウドでやろうとすると、ハード的な部分はそもそも仮想化されているので、直接見る事が出来ません。見えたところで、どうしようもないのですけど、基本的にはクラウドベンダーが公開する障害情報を頼りにするしかありません。

AWSであれば、Service Health Dashboardで随時確認する事が出来ます。ですがこのサイト、ぱっと見キレイにまとまって見やすい感じがしますが、いざ問題があった時、時系列を追うのが結構厳しいです。基本的にはRSSフィードを見てね、という作りでちょっと不親切です。また、時間表記が太平洋時間だったりしますので、日本人的には結構つらいものがあります。だいたい、障害があった時は、基本的に「心の余裕」がありませんので、この作りはあまりいただけません・・。

というわけで、

• 障害があったらメールを受け取りたい
• 自分の好きなタイムゾーンで時刻を表示したい

という事がやりたくて、AWSWatchを作りました。

Heroku

開発は帰宅してから空いた時間でボチボチと作っておりました。Amazon SNSのRubyクライアントを作る所から始めたので、なんだかんだで二週間くらいかかりました。完全に個人で運用するサイトですので、最初はお金のかからないGoogle App Engineを使おうかと思いましたが、一番手になじんでいるのがRailsですし、以前から興味があったHerokuを使ってみようと思い、あまり深く考えずにチョイスしました。

このHerokuですが、RubyでWebアプリが書ける人であれば、即利用可能です。herokuのGemをインストールして、gitが使えれば、こんな感じでサービスを公開出来ます。

gem install heroku
rails awswatch
cd awswatch
git init
git add .
git commit -m "First Release!"
heroku create
git push heroku master

gitでpushした時点でdeployが完了した事になります。

マイグレーションは

heroku rake db:migrate

consoleは

heroku console

とやれば、

script/console production

をやっている事になります。スバラシイ！！

Herokuに関しては、この辺を参考にさせていただきました。

• Ruby版PaaSの"Heroku"で無料Railsホスティング環境を手に入れよう - Social Change!
• [Ruby on Rails][heroku] heroku が今、最高にアツい！ - mat_akiの日記

個人的にここが素晴らしい！と思った点は、

• 基本的に無料
• Gemを入れるだけという気軽さ
• Deployが簡単
• SSLが無料で使える
• 独自ドメイン使用可能
• Add-onが充実している

特にAdd-onに関しては、

• New Relicというアプリケーションモニターが利用可能
• Exceptionalという例外を通知してくれるサービスが利用可能
• Amazon RDSも利用可能！（RDSの利用料はかかります）

あたりが個人的にポイント高いです。

ただし、無料の範疇だとスレッドは1つですので、トラフィックが多いサイトになると厳しいです。その辺りが気になる方は、今のところGoogle App Engineが最強か？と思います。（Rubyだと厳しそうですが・・）

Amazon Simple Notification Service（Amazon SNS）

2010年4月5日に、Amazon Simple Notification Service（Amazon SNS）というサービスがリリースされました。（参考：アマゾン、クラウドサービスにメッセージ送信機能「Amazon SNS」を追加 - CNET Japan）

Amazon SNS・・・実に誤解をはらみそうなネーミング（笑）ですが、SQS同様メッセージングサービスという事で、かゆいところに手が届く的なサービスになっています。

SNSとSQSの違いは、プッシュとプルの違いでしょうか。SNSはメッセージをEMail、HTTPなどに配信します（プッシュ）。SQSは、メッセージをQueueに取りに行く必要があります（プル）。SNSで真っ先に思いつくところとしては、メールの一斉配信です。これを自前でやろうとしたら大変な事は容易に想像出来ますが、その大変な部分をAmazonが肩代わりしてくれるという、非常にAmazonらしいサービスになっています。しかも、例によって激安です。メールは10万通送信しても、たった2ドルです。

この部分だけを見ると、スパマーにもってこいのサービスじゃね？と一瞬思ってしまいますが、そこはちゃんとしています。ユーザーがメールの配信を希望する（Subscribe）と、SNSは、ユーザーに確認メールを自動送信します。そのメールの中に書いてある確認用のリンクをクリック（Confirm）すると、はじめてメールが送信されるようになります。

まだ出たばかりのサービスですので、API的にもちょっとこれは・・という点がなきにしもあらずですが、それは今後の充実に期待！という事で。SNSに関しては、また追って記事を書きたいと思います。

突っ込み所が満載な件

という訳で、サービスはHerokuに置いています。識者の方はここで「？」となるはずです。
公開前日に発覚した、驚愕の事実がございます（笑）

Herokuが完璧なまでにEC2に乗っかっておりました！知りませんでした !(^^)! 事前に調べておけよ、って感じですが、HerokuにAmazon RDSのAdd-onがある時点で「？」と思うべきでしたね。監視のサービスが落っこちたら監視になりませんので、別のインフラに載せるのがエンジニアの嗜みですけど、最初から躓いてますね・・まぁ、そのうち気が向いたらGoogle App Engineにでも移行して、反省の意を表明したいと思います（笑）。でも、そもそもメール通知にSNSを使っている時点で企画倒れな様な気もしますね・・。