Ad Network

あわせて読みたい

  • あわせて読みたい

« 「RESTful MVC」なアーキテクチャの話 | Main | ブラウザー上で動く iPhone-style トグルスイッチ »

Cloud Computing考:Amazon ec2とGoogle App Engineの違いを私なりにまとめてみた

 Cloud Computing の話が注目されるようになってしばらく経つが、商用での本格応用という意味ではまだまだ未熟な市場である。PhotoShareは去年の7月サービス開始時から Amazon の ec2+S3 という組み合わせで運営しており、私から見れば当然の選択だったわけだが、あのタイミングで商用サービスへの採用に踏み切った会社も少なかったのか、何件かインタビューの申し込みが来たりして少し驚いている(参照)。

 すぐに陳腐化するハードウェアの資産はできるだけ持ちたくないし、自分でデータセンターにラックを借りるなんてことはコスト的に見合わない。かといって、通常のレンタルサーバーは初期費用がばかにならない(今は少しは改善されているのかも知れないが、去年の段階では「それじゃあハードが自分で買えるじゃん」と言わせるぐらいの初期費用を請求する企業がほとんどであった)。それに加えて、どのくらいのトラフィックが来るのかを予測するのが不可能な場合(一般ユーザー向けのネットサービスのほとんどがそう)、「需要を予測した上で、それに見合うだけの初期投資が必要」なモデルはどう考えてもありえなかった。

 そんな理由で Amazon のウェブサービスを選択したわけだが、結果から見れば正しい判断だったと言える。特にサービス開始時のトラフィックが予想しにくい時期に、モバイルビジネスに良くある「はやって地獄(予想以上にユーザーが集まったためにサーバーが足らなくて四苦八苦すること)、はやらないで地獄(多大なトラフィックを想定してそれなりの初期投資をしたにもかかわらず、実際にはトラフィックが予想を遥かに下回り、初期投資の回収がままならなくなること)」というジレンマに陥らずに済んだことは大きい。

 しかし、実際に1年以上PhotoShareを運営して来て、Amazon のウェブサービスに足らない部分もいくつか見えては来ているので、ここに書いてみる。

 まず一つ目は、ec2はバーチャル・サーバーと呼ばれてはいるが、私が期待していたレベルのバーチャル・サーバーではないこと。Amazonはバーチャル・サーバーの仕組みを、「一つのパワフルなサーバーを複数のバーチャル・サーバーとして小分けしてレンタルする」ことに使ってはいるものの、「サーバーを完全にバーチャルにしてハードウェアと切り離し、ハードウェアに問題があってもサービスには一切支障をきたさない」というレベルまでは使っていない。バーチャル・サーバーと呼ぶのであれば、「ハードの問題」とか「特定のCPUから別のCPUへの引っ越し」とかを見えなくしてほしい。

 二つ目はAmazonの問題ではないのだが、ec2を使っても「データベースのお守り」は自分でしなければならないこと。PhotoShareはMySQLを使っているので、Oracleほどのチューニングは必要ないとは言え、バックアップとか修復とか、それなりの手間はかかる。そして当然だが、データベースのスケーラビリティの問題を解決するのもサーバーの借り手の責任である。一つのデータベースで足りているうちは良いが、ユーザーが増えて複数のデータベースに分けなければならない段階になると、パーティショニングやリプリケーションやらといろいろと複雑な問題を解決しなければならない。

 つまり簡単にまとめると、Amazon のウェブサービス(ec2)は、自分のサーバーを持つことや通常のレンタルサーバーを借りることと比べると、(1)初期投資が少なくかつ安い、(2)トラフィックの量が急激に変動したときに柔軟に対応できる、という利点があるが、(3)ハードの故障からは完全にはプロテクトされない、(4)データベースのスケーラビリティの問題は自分で解決しなければならない、という点は十分認識しておく必要がある。

 そんなことを頭に置いた上で、先週少し Google の App Engine について調べてみた。私がもっとも気に入ったのは、Amazonが解決してくれなかった、(3)ハードの故障問題から解放、と(4)データベースのスケーラビリティ問題からの解放、という部分。

 クラウドコンピューティングを「サーバー運営のアウトソース」という意味で見た時に、Amazon と Google では、セルフサービスの学食とフルサービスのレストランの違いぐらいがある。「ハードウェアの故障にどう対応しよう」「ユーザーが増えた時にデータベースをどう分けよう」などのことは心配せずに、サービス作り・ソフトウェア作りに100%集中したいのであれば、Google App Engineの方が格段の「おもてなし」である。

 とは言え、Google App Engineにまったくマイナス面がないわけではない。自分でOSのインストールまでできるAmazonと比べると以下のような制限がある:

1. Goolgle App Engine上のアプリケーションはサンドボックスの中で走る。OSのインストールはもちろんだめだが、それだけでなく、さまざまなリソースへのアクセスはかなり制限される(例:「ファイル」を作ることができない、デーモン・プロセスを起動したり、TCP/IPソケットを開きっぱなしにすることもできない)。基本的に、「入って来たHTTPリクエストを高速にステートレスに処理する」ことしか出来ないと思って間違いない。

2. データベースはGoogleのDatastore(Big Table)を使わなければならない。MySQLやOracleのようなリレーショナル・データベースとは違い、スキーマレスのオブジェクト・データベースなので、リレーショナル・データベースに関するノウハウはほとんど使えない。作ったアプリケーションを他の環境(例えばAmazon ec2)に大きな変更を加えずに持って行くことは不可能。

3. 公式にサポートされている言語は、PythonとJava(Javaの上でRubyやPHPなどの他の言語を動かすことは可能)。

 以上が、私から見たAmazon・Google二社のクラウドコンピューティング・サービスの違いである。App Engineに関しては、実際に商用サービスを運用した経験があるわけでもないので、どこかに見えない落とし穴があるかも知れないが、私から見れば「商用サービスを試してみる価値のある」レベルには十分に達していると思う。ちょうど一つ(ひょっとすると二つ)、新しいサービスで良い候補があるので、試してみようと考えている。

 ちなみに、私はPythonは初めてだったが、とても簡単な言語なのでそれほど悩まずに1日ぐらいでそれなりに書けるようになったので、皆さんにもおすすめする(特にJavaScript使いにはおすすめ)。Datastoreも初めはとっつきにくいかも知れないが、一度その中身がどうなっているかを理解すれば(つまり、慣れ親しんだリレーショナルデータベースとの違いをはっきりと認識できれば)それほど難しいものではない。

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341c4f9853ef0120a61e69b9970b

Listed below are links to weblogs that reference Cloud Computing考:Amazon ec2とGoogle App Engineの違いを私なりにまとめてみた:

Comments

ku-suke

 自分にとってはタイムリーな話題でした。新しいサービスを立ち上げようとAmazonEC2とGAE/Jを交互に試しているんですが、両方で試してみた感想とEC2での補足を少し。

GAE/Jは予想よりも制限が引っかかる場合があるように感じています。たとえばDataStoreは1エンティティ1MB制限があるので、メタデータ用のテーブルと、生データを分割格納するテーブルに分けないといけなかったり、エントリであげられている他にも画像処理に使うImageIOが使えなかったりと、制限による苦労が(サーバ管理の「慣れた」苦労に比べ)大きいように思います。また、制限を回避する策も状況によっては見つからないため、ある程度プロジェクトが進行してから方針転換や別サーバとの併用を検討する状況に僕はなってしまったため、十分な検証を行ってからでないと厳しいように感じました。

そして、Amazonのほうですが、DataStoreのかわりにSimpleDBがありますので、こちらを使えばDBのチューニングからは解放され、Web側のインスタンスを増やせばリニアにスケールするシステムがEC2でも利用出来るかと思います。EC2以外からも接続可能なので、開発時にもローカルから直接接続可能な様です。

きみき

突然の訪問、失礼いたします。
私はこちら⇒http://www.ouji.info/hako
で無料オンラインゲームサイトをやっているきみきといいます。
色々なサイトをみて勉強させていただいています。
もしよろしかったらご参加をお願いできないでしょうか?
よろしくお願いします^^

Post a comment

This weblog only allows comments from registered users. To comment, please Sign In.