この記事は「Amazon Web Serviceを活用してきたSaaS事例からの学び」の続きです。（スライド：9〜12にあたります）
youRoomは、SonicGardenとして創業した後に企画・開発したサービスです。かなり実験的な要素の濃い事業として開始したのを憶えています。元々はSonicGardenのプログラマたちとのフリーディスカッションの中で、こういうツールがあると良いよねという話をしていて、その話をしていたのが@mat_akiの夏休み前で、その休み明けには、なんとプロトタイプが出来ていたので、じゃぁそのままローンチしようといって始まったのでした。ただローンチするだけでは自分たちがやる意義がないので、幾つかの仮説をもって事業を始めています。このように事業の内容そのものを実験だと考えて、仮説と検証をやっていたのは、今でいえばリーンスタートアップでした。つまり、どんな新規事業も実験みたいなものなんです。
現在はそこそこ多くのユーザにも使って頂いているyouRoomですが、youRoomをローンチする際に立てたコンセプトは、いかにお金をかけずにマーケティングと運用を行うか、ということでした。お金をかけなくても広めて運用することができるのではないか、という仮説です。実際は、そこまでうまくいってる訳ではないですが、実際の現金という意味ではゼロ円で、口コミとフリーミアムで拡大することが出来ました。多少は広告宣伝費をかけてもよかったかな、とも思いますが、お金をかけずともこの程度までいけるという指標はとれました。
また、SKIPの経験から当初からマルチテナントで動かすことは当然でしたが、それに加え「セルフサービス」というのもポイントにしていました。というのは、アメリカ出張時にクラウドのことを話すと、向こうの人たちは「セルフサービスのことね」と言うんですね。つまり、営業が丁寧に売りに行くのではなくて、ユーザ自身によって選択して購入するのです。確かに、クラウドであれば可能だし、そうしなければクラウドである本当の価値は出せないように思います。youRoomでもフリーミアムなビジネスモデルにして「セルフサービスできる」ことを重視しました。
youRoomは運用のコストも殆どかけないようにするため、当初はHeroku（RubyのPaaS）のフリープランを使って運用を開始しました。そういえばHerokuもフリーミアムでセルフサービスでしたね。Herokuはオープンな技術を採用しており、便利なツールも沢山あり、プログラマが運用まで行うDevOpsスタイルの我々にとっては非常にマッチしていたプラットフォームでした。今でもそう思っています。しかし、youRoomは最初にローンチしてから半年ほどで、AWSへの移行を行うことになりました。
HerokuからAWSへの移行を行った理由は２つ。１つは、Herokuそのものは安価で、かつスケールに柔軟なため、コストパフォーマンスもすごく良いのですが、Railsのアプリを動かしているだけなら、の話で、実際に色々な要望に対応したりしていくと、本体のアプリだけではできないことが増えて関連サービスを使わなければいけなくなるのですが、Herokuの場合、それがオプションになっていて割と割高に感じました。もう１つの理由として、そうした関連サービスや運用の自動化なども含めたAWSの環境を我々が作るだけのAWSに関するノウハウをもっていたということです。自分たちで自分たちに必要なHeroku相当まではいかないまでも、それなりのプラットフォームを作れるようになったので、AWSに移行することにしたのです。
これまでAWSでyouRoomを運用してきて、もっとも大きかった障害が、先日（2011年4月21日）のAWSのus-east-1リージョンにおける障害の影響でした。この障害はニュースにもなり、西海岸に拠点をおくHerokuやFoursquareなどのウェブ企業に影響を与えることになりました。youRoomもその影響で使えないようになってしまったんですが、他社のサービスが復旧までに最大４日ほどもかかっている中、youRoomはなんと１時間程度で復旧まで行いました。その辺りの詳しい経緯と内容は以下のブログに詳しく書かれています。
- youRoomにおいて発生した 2011/4/21 のAWSの障害について技術的な観点から – mat_akiの日記
- AWS障害による影響を小さくするための設計(2011/4/21の障害を踏まえて) – よかろうもん！
SonicGardenでの運用の考え方の根底には、以下の２点があります。
- 障害は必ず発生するので、どれだけ速く復旧するかに注力する
- 運用にかかる人手は、人力を雇わずに自動化でカバーする
一つ目は、AWSを信用しすぎないということです。どんなハードウェアのサーバを買ったとしても必ず物理的に壊れることはあるのと同じで、AWSだからといって壊れることはない、ということはないのです。であれば、それを見越した上でどうやったら速く復旧できるかにポイントを置いたシステム構成にするのです。この辺りは、一般的なシステム構成の設計となんら変わらないと思います。ただ、いかに速く復旧するか、のためにはAMIの仕組みは必須であり、それができるAWSが優位であることは間違いないと思います。
二つ目は、運用のサービスレベルを確保したり、運用作業が発生しそうなときに、人手を用意するというのは最も短絡的で簡単な解決方法ですが、そうして人海戦術にはいってしまうと、大手との価格競争（という名の削り合い）には勝てなくなります。私たちは、足りない労働力は知恵でカバーすることをまず考えて、徹底的に自動化を行います。その際には、APIが充実したAWSに優位性があると言えます。
私たちは、ある意味どっぷりとAWSにすでに漬かっていたので、HerokuからAWSへ移行を行いましたが、これからどちらにしようかというので悩んでいて、かつ、使う言語がRubyであるなら、Herokuから始めた方がきっと学習コストも低く、運用の手間も少なくていいと思います。
あわせて読みたい：Amazon Web Serviceを活用してきたSaaS事例からの学び
あわせて読みたい：Ruby版PaaSの”Heroku”で無料Railsホスティング環境を手に入れよう
