クラウドの最近のブログ記事

この記事は「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ホスティング環境を手に入れよう

この記事は「Amazon Web Serviceを活用してきたSaaS事例からの学び」の続きです。（スライド：5〜8にあたります）

SonicGardenの元々のきっかけは、社内向けのSNSをオープンソース化したことから始まっています。2005年に自社用に開発した社内SNSを2008年に"SKIP"という名前でオープンソース化し、オープンソースにしたソフトウェアを使ってビジネスにするために、AWSを活用してSaaS化することにしました。そのSaaS事業をするのがSonicGardenの最初の事業であり、創業のきっかけでした。

SKIPをSaaS化したサービスということで、SKIPaaSと名付けたのですが、その特徴は「シングルテナント」と「月額定額」という点でした。オープンソースにしたSKIPのバージョン1系は、社内向けに作っていたということもあり、複数の会社で同時に使うようなアプリケーションのアーキテクチャーになっていませんでした。なので、必然的に、SKIPを利用する会社ごとにAWSのインスタンスを用意しないといけませんでした。しかし当時の私たちはその点を逆手にとって、メリットであると訴えることにしました。AWSのインスタンスが会社毎に分かれるシングルテナント方式であるため、きちんと他のお客様のデータとは分離して管理しているので安心だという風にマーケティングしました。しかも、会社毎にインスタンスを分けているので、大企業にとっては割高に感じてしまうユーザ課金ではなく、月額定額のビジネスモデルにすることが出来るというのもメリットとして打ち出しました。

そうした発想に行き着いたのは、元々私たちはSonicGardenを立ち上げる前の2004年頃からずっと「仮想化技術」に注目しており、ハードウェア構成を気にしないアーキテクチャを気に入っていて、さらに「ハードウェアそのもの」も自分たちで持たなくて済む方法を模索していた中で、「仮想マシン」のホスティングサービスとしてAWSに出会ったのです。なので、シングルテナントにすることは、アイデアとしては自然な成り行きだったし、当時、その「仮想マシン」のホスティングができるのは、AWSだけだったのが、AWSを選んだ理由です。

オープンソースで公開されているアプリケーションの多くは、自分でインストールすることを想定しているため、シングルテナントで動作することを前提としたものが多いと思います。オープンソースを活用してSaaSにする際の課題は、シングルテナントにせざるを得ない場合が多いということに尽きます。SKIPaaSも、シングルテナントにしたことでセキュリティ上の見かけは良かったのですが、やはり運用していくには、非常に非効率でした。まだAWSを活用していたので、事前にAMIを作っておいて、契約する会社毎にコピーをしていけば良いので、その点は効率的ではあったのですが、バージョンアップをしていく際の手間は相当大変でした。何十社と契約が進めば、それだけのインスタンスに配置されているアプリケーションに順次バージョンアップ作業をしていくというのは、いくらAPIで自動化しているからといって骨のおれる作業だったわけです。

そこで、私たちは大きなPivotの決断をしました。マルチテナントのSaaSにするために、SKIPのソースコードをゼロベースから作り直すというPivotです。SKIP2と名付けて、それにあわせてビジネスモデルもイチから考え直しました。SKIP2での開発上の重要なコンセプトの一つに、バージョンアップなどを含めた「運用のし易さ（Ease Of Operation）」を置きました。そして、それを実現するために、チームの構造も運用担当者とアプリ開発者という垣根をなくし、開発も運用も「プログラマ」が行うというスタイルに変更しました。一般的に言われるDevOpsという形に必然性から辿り着きました。

オープンソースを開発していたときからの大きなパラダイムシフトは、品質管理の考え方です。１度のリリースのタイミングを重視するという考え方（Point of Sales）は、製造業的にはよかったのですが、クラウドのような形で日々提供し続ける、しかも、バージョンアップし続けるという場合には、リリースそのものよりも日々の運用を重視するという考え方（Point of Use）に変えないといけなかったのです。私たちは身をもってその教訓を体験しました。おそらく、パッケージベンダーがクラウドに乗り出して最初にはまる落とし穴かもしれませんので、気をつけると良いと思います。

次のエントリでは、youRoomを題材にしたHerokuからAWSへの移行について書きます。

あわせて読みたい：Amazon Web Serviceを活用してきたSaaS事例からの学び

SonicGardenでは、Amazon Web Service（AWS）を色々な形で活用してきました。オープンソースソフトウェアをAWSでクラウドのSaaSにしてみたり、HerokuというRubyのPaaSからAWSに移行してみたり。これまでSonicGardenで得てきたAWSのノウハウについて、社団法人コンピュータソフトウェア協会（CSAJ）のAWSセミナーで話してきました。

発表スライドはこちらです。

今回お話ししたのは以下の３つのケースです。次からのエントリーで、内容について補足していきたいと思います。

1. オープンソースをAWSでクラウド化
2. 自社クラウドサービスのAWSへ移行
3. サービス型の受託開発でAWS活用

ここ数年で、クラウドのプラットフォームが広まることで、従来のSIビジネスの市場が影響を受けるということが起きてます。そこで多くの大手SIerが採った戦略は、自社でIaaSのようなクラウド環境を作るといったものです。自社が持つデータセンターに仮想化のエッセンスを加えて「クラウド」の冠を付けて売るというもので、あまり目新しさはありません。

今、それでは付加価値が薄いということで、PaaSに手を出そうとしているところもあるかと思います。ゼロから作って徐々に上にのせていくという戦略です。こういう戦略は、非常にお金を持った大手企業で、かつエンジニアが採りたい戦略に感じます。

なぜならば、これはGAEやAWSなどのプラットフォームが日本上陸したときに、その中で使われている技術を勉強して、自分たちでゼロから同じレイヤのプラットフォームを作ろうという発想ですよね。おそらく技術的には可能だし、技術者としてのプライドもあるのかもしれませんが、正直、その領域でこれから戦おうとしても追いつきこそすれ、追い抜かすことは難しいのではないでしょうか。WindowsやMacOSXを見たからといって、各社が自社製のOSを作ろうなんて思わないはずです。ここは思い切って、すでにあるプラットフォームの上でどう戦うかを考えた方が良いように思います。黒船を作るのではなく、操船技術をまずは磨くのです。

お金や資産を持たないスタートアップにとっては、そもそも、そんなゼロから作る戦略はとれるはずもなく、すでにあるプラットフォームにうまく乗れるように考えます。そして、その土壌をベースに、さらなるプラットフォームを作ろうとする訳で、そうするからこそベンチャーが大きくなれるチャンスがある訳です。ゼロから作って同じレイヤのものを作ろうとしても、先行者には勝てないですし、品質で戦おうとしてもユーザの多い大手には体力勝負で勝てません。

しかし、既にプラットフォームがあるのであれば、その上にプラットフォームを作ろうと狙えば、勝ち目は産まれます。大手になった企業は「イノベーションのジレンマ」に囚われがちですし、「破壊的イノベーション」というのは最初は品質が低くても市場には受け入れられます。米国で起きてる企業の世代交替はこうして起きているように思いますし、あちらの人たちは乗っかるのが上手な気がします。

まじめで優秀なエンジニアほど勉強家だったりするので、新しい技術などがあれば、自分のものにしようと勉強します。そして、最近の新しい技術はクラウドの企業から産まれていることが多いです。勉強すること、それ自体はとても大事なことなのですが、中の技術を知れば知るほど、自分たちで同じようなものを作ってみたくなってしまう症候群にかかってしまうのかもしれません。私もエンジニアだったので、その気持ちはとてもわかります。

そういえば、Javaでサーバサイドを作り始めた頃に、SIerが各社でオレオレフレームワークを作っていましたよね。デジャブを感じます。

【告知】
弊社SonicGardenでは、AWSと対抗するのではなく、なるべくAWSに乗っかって、その上でのビジネスを考えて実践してきました。その経験をふまえて、ビジネス視点で事例紹介をさせて頂くイベントがあります。よかったらご参加ください。
ソフトベンダのためのクラウド活用ビジネス事例紹介～事例から学ぶクラウド活用事業構築のポイント～