ホーム > タグ > google app engine

google app engine

Amazon EC2とGoogle App Engineのコスト比較

どうも、うしねずみです。

最近趣味で作ろうとしているWebサービスを、クラウド上に実装しようとしていて、AmazonのEC2を使うかGoogle App Engineを使うかを選ぶ必要がありました。そこで気になるのはやっぱり、実際どっちがどれぐらい得なんだろうねと。というわけで、自分が想定しているサービスで月毎にかかる料金を試算してみました。それが以下のグラフです。

Amazon EC2 v.s. Google App Engine

Amazon EC2 v.s. Google App Engine

横軸は自分の想定しているサービスの登録ユーザ数。縦軸はその時のコスト(米ドル)です。グラフをみると最初はGoogleが低いものの、途中から逆転しています。両方が交差している点は2400万ユーザの1万7000米ドルくらいです。(試算の細かい前提は後で書きます)

しかし、自分で出しといて言うのもなんですが、このグラフは眉唾ものです。何故かというと、この試算にはGAEの利用CPU時間に対する課金が一切含まれていません(実際どれぐらい消費するのか予想しづらい。「そこをベンチマークするのがお前の仕事だろ」って言われそうですが)。実際にはGAEではリクエストを受けた時やBigtable(GAEのデータベース)にアクセスした際に利用されたCPU時間に対して課金されるわけで、CPU時間に対して課金されないAmazon EC2と並べて比べるのは非常に不公平です。

しかしGoogleにばかり有利な試算ではありません。実際ユーザ数が増えてくると、Amazon EC2では1つのインスタンスではリクエストをさばけなくなってくるはずです。そうなったときサイトのパフォーマンスを維持するためにインスタンス数を増やせば、当然インスタンス利用時間にかかる課金がもっと増えてきます(GAEは「マシンと数」みたいな概念は無く、自動でスケールするので気にする必要が無い)。さらにインスタンスを2つ以上にした場合はロードバランサーをオプションとして付けなければならなくなるため、ロードバランサーの処理したトラフィックに対する課金も含まれてきて、EC2のコストはこの試算よりも膨れ上がるはずです。

結局今回の試算で効いているのは、EC2はデータ転送量が増えるほどデータ転送量に対する課金の単価が下がるのに対し、GAEではどれだけデータ転送量が増えても課金の単価が一定であるという点だけです。といっても全く意味がない試算をしたわけでは無くて、2400万ユーザという驚異的なユーザ数を獲得するまではGoogleの方が安いということはわかりました。そして、2400万ユーザも居たら、その時のコストである1万7000米ドル/月なんて余裕で回収できるんじゃないかっていうことも。
ま、CPU時間に対する課金とか、かなり効いてきそうなので、やっぱり意味の無い試算だったような気もします。

ちなみにこの試算ではEC2とGAEが逆転するのは2400万ユーザなんてかなり多い数になってますが、これは私が想定しているサービスの1リクエストあたりのデータ転送量が約4kBと少ないためで、画像なんかをたくさん置いている場合はもっともっと少ないユーザ数で逆転すると思います。

※今回の試算の前提
1ユーザ、1日あたりのリクエスト数 : 50
1リクエストあたりのデータ転送量(out) : 3.95kB
1リクエストあたりのデータ転送量(in) : サービスの特性上無視できる量なので無視
1アカウントあたりの情報量(ストレージの消費) : 0.2kB (←いや、今考えると少ないな)
サービスが履歴保存に使う最大容量(ストレージの消費) : 約5GB (←これを超えると古い情報から破棄していく)
その他 : EC2ではsmallインスタンスを24時間稼働しっぱなし。

GAEのBigtableへのデータのインポートとエクスポートをやってみた

どうも、うしねずみです。

Google App Engineで使えるデータベースはBigtableというのですが、このデータベースへのデータのインポートとエクスポートをやってみました。結論から言うと、日本語を含まないデータのインポートだけしかできませんでした。以下にまとめてみます。

基本的にはGoogleのスタートガイドのページのここに解説されています。だたし、気をつけなければいけないのは、データのインポートおよびエクスポートは英語版のSDKでしかできません(2009年8月3日現在)。どうやらSDKの1.2.1から加わった機能のようです。日本語のダウンロードページで公開されているのは1.2.0なので指示通りのコマンドを入れてもエラーを吐かれます。ですので英語のダウンロードページから最新版(2009年8月3日現在は1.2.3)をダウンロードしてインストールしてください。

これであとは解説ページ通りに行えば行けます。まだローカル環境でしか試してないのですが、1087件のレコードをインポートすることに成功しました。ただしこれは日本語を含まない場合のみで、日本語を含むデータでは

[ERROR   ] Error in worker [Thread-6]: ‘ascii’ codec can’t decode byte 0x82 in p
osition 0: ordinal not in range(128)

というエラーが出てアップロードできませんでした。
また、エクスポート機能についてはGAEのサイトで以下のように言及されています。

2009 年 4 月: Python SDK リリース 1.2.1 には、データのアップロード機能と類似した、データのダウンロード機能の初期バージョンが含まれています。この機能はまだ appcfg.py では使用できませんが、試したい場合は、bulkloader.py をご覧ください。マニュアルを含めたこの機能の完全版を、今後の SDK バージョンでリリース予定です。

さっそくSDKの中からbulkloader.pyというファイルを探して覗いてみました。
【注意】:google_appengineの中には同じ名前のファイルが複数個所にあって分かりにくいですが、ここで言っているのは
\google_appengine\google\appengine\tools
にあるbulkloader.pyです。

この中で定義されているExporterというクラスがLoaderに対応するクラスのようです。さらに見ていくと、appcfg.py(これも上記のbulkloader.pyと同じフォルダ)の中のPerformUploadという関数の近くに(2038行付近)PerformDownloadという関数が定義されています。アップロードには’upload_data’というコマンドが紐付いていますが、ダウンロードには’download_data’が紐づけられているようです(2267行付近)。

つまり、データのアップロードの時に作ったローダクラス(Googleの説明だとalbum_loader.pyになっている)の中のLoaderをExporter、loadersをexportersに書きえてやれば動きそう。
アップロード時のコマンドは(ローカルでテストする場合は)以下でしたが

エクスポートの方では以下のようにすれば動くはず。

ちなみにローカルでテストするときはちゃんとGAEのローカルサーバ(dev_appserver.py)を動かしておいて下さいね。
いや、しかし動かないんだこれが。
 KeyError: ‘Album’
と言われてしまう。「Album」なんて種類のデータは無いんだと。いや、さっきアップロードしましたよっ!データベースから種類「Album」のデータの最初の100件を表示するテストページも問題なく動作してますよ!

なんでだろー。
知ってる方いましたら教えてくださいー。

結局、日本語を含まない場合のインポートだけしかできませんでした。
データのエクスポートができないままでは新規利用者にとって本格導入したい人も二の足を踏みます。もし他のプラットフォームに移行したくなっても、データが取り出せなきゃどうしようもないので。Googleさん、早く正式対応してください。それからドキュメントを…orz

Amazon EC2とGoogle App Engineの比較(それぞれの特徴をまとめてみる)

どうも、うしねずみです。

最近クラウドサービスをちょこちょこ触っています。Amazon EC2とGoogle App Engine(GAE)を両方触ってみたので、それぞれの特徴をまとめてみようかなと思います。

Amazon EC2

【長所】:自由度が高い

Amazon EC2の特長は何と言ってもその自由度の高さです。EC2ではユーザは「使いたいインスタンスのスペック」、「簡単なセキュリティポリシー」、「使いたいインスタンスの数」を選んで、インスタンスを起動します。例えば、OSがWindows Server 2003、CPUの性能はSmall(SmallとかHighとかで選ぶ)、HTTP(80番ポート)とリモートデスクトップ(3389番ポート)を使えるようにして、1インスタンスを起動、といった感じです。インスタンスというのは、PC1台だと思うとわかりやすいと思います。起動したインスタンスにはリモートデスクトップで接続できて(詳細は以前の日記を)、ソフトのインストールからセキュリティの設定までかなり自由にできます(Linux系OSならSSH接続)。

【短所】:面倒が多い

長所の裏返しですが、アプリケーションを実際に公開するまでの敷居が高いです。最初はWebサーバもメールサーバも何も入っておらず、すべて自分で設定しなくてはならないからです。私のように「Apachの設定はちょっとやりたくない。。。」と言う人にはかなり大変です。

また、負荷が増えた時にスケールすることがGAEに比べると以下の二つの点で面倒です。

  • スケールさせるべきかどうか自分で決めなくてはならない
  • スケールさせる際の追加の作業(とオプションの課金)がある

例えば1つのインスタスでサービスを始めたとします。だんだん人が増えてきて、「どの時点でインスタンスを2つに増やすか」は自分でサーバの負荷などを見ながら決めなくてはいけません。毎日ログを見るとはいえ「もう一台必要かなー?どうかなー?」みたいな判断を自分で行う必要があります(負荷に応じて自動的にインスタンスを追加起動する有料オプションがあったような・・・)。

また、もう1つインスタンスを増やすことにした場合「ロードバランサの設定」という追加作業が生じます。ロードバランサとは、一つのサービスを複数のサーバでこなすための「仕事振り分け」をする機器です。例えばusinezumi.comというドメイン(に紐付いているIPアドレス)でサービスを公開しているとします。2台目のPCにこれと違う新しいIPを割り当てるわけにはいかない(そしたらアドレスは違うけど全く同じ別サイトになる)ので、一つのIPに対して飛んできたリクエストを、それぞれのマシンの負荷を見ながら適当に振り分けていく必要があります。これをやってくれるのがロードバランサです。

EC2でロードバランサの設定が大変かどうかは分かりませんが(おそらくそんなに大変ではない)、追加作業が発生しない方がいいのは明らかです(設定でトラぶったらサービス停止するし)。また、ロードバランサはオプションなのでそれに対して新たな課金が発生するのもあまり喜べません(課金体系は覚えていないのでAmazonのサイトで確認して下さい)。

GAE(Google App Engine)

【長所】:簡単!

GAEの特徴は、公開のまでの簡単さとスケールのしやすさです。GAEでは前回の投稿でも書いたとおりに、非常に公開までが簡単です。もちろんEC2のようにWebサーバの設定など必要ありません。コードをアップロードすればすぐにアプリが公開できます。Webアプリの開発者からすれば、Webアプリ以外のことを特に考えなくてよいのでとても楽だと思います。

また、自分のサービスの人気が出て負荷が増えた時に、自動的にスケールしてくれます。EC2で気にしたような「いつ?何台追加?」みたいなことは全く気にする必要はありません。というかそもそも「何台?」という概念自体がありません。

【短所】:自由度が低い

これも長所裏返しなのですが、自由度が低いです。といってもWebアプリを公開することに関して大概のことはできると思うのですが、「じゃあSubversionをインストールして、開発用のレポジトリサーバにできるの?」っていうとできません。新しいソフトをインストールするとか、どのポートを開放するとか言ったことはできません。できるのは、「コードをアップロードして公開する」だけです。あ、ちなみに静的なファイルのアップロードはできます。

【その他】:データベースの特殊性

これは長所でも短所でもあるのですが、GAEのデータベースはGoogleが使っているものと同じ「Bigtable」というものです。これはリレーショナルデータベースではないという点で、現在使われている多くのデータベースと異なります。これは他のプラットフォームからのGAEへの乗り換えの障害になりかねないのですが、このBigtableの特殊性がGoogleの強力な検索能力を実現していると思えば非常に魅力的に見えてきます。

この件について解説している記事もあると思いますのでここでは詳細は書きません。

まとめ

Amazon EC2とGAEはある程度は競合相手であり、ある程度は競合になりえないと思います。なぜなら「できること」の範囲が違うからです。Amazon EC2ではその自由度の高さゆえ、Webサーバ以外の用途にも使えます。例えばメールサーバや、シミュレーションなどの一時的な計算リソースとして使えたり、何か新しいことを試すためのテスト環境として使うようなこともできるでしょう。一方でGAEでは、アプリ開発以外のことができない代わりに、アプリ開発以外のことはほとんど気にしなくてよいという強みがあります。

同じクラウドというラベルを張られていてもかなり違ったサービスなので、自分が必要としているサービスはどちらなのかをしっかり見極めてから使う必要があるようです。

Google App Engineを使ってみた

どうも、うしねずみです。

以前まで「クラウド導入日記」という主題とともにクラウドを使ってみた情報を書いてましたが、やめました。

さて、今回はGoogle App Engineを使ってみたというお話です。
使ってみての感想ですが、何と簡単なことか!!! いや、ホントですよ。Googleの差し金じゃないですよ。

簡単な理由の一つに、スタートガイドの分かりやすさがあります。このスタートガイドを読みながら手順通りにやっていくと、簡単にアプリ公開までたどり着きます。そうですね、特に急いだわけでもなく、2時間くらいで済んだでしょうか(というか時間計ってなかったし覚えてないけど)。とくに深読みせず、テストコードをコピペでアップロードすれば30分で終わりそうです。

ということで今回私がここに手順をダラダラ書いてもGoogleのスタートガイドよりわかりやすくはならないと思いますので、使ってみたい人はぜひGoogleの方を訪れてください。

ちなみGAE(Google App Engine)では今JavaとPythonが使えますが、私はPythonを選びました(Javaの方が慣れているが)。理由はPythonの方が一年ほど(?)早くリリースしているので、Pythonの方が資料(手掛かり)が充実していると思ったからです。比べたわけではないですが「やっぱりPythonでよかった」と思うほど転がっている資料も多くなかったし、一番役に立ったGoogleのスタートガイドにはどちらも同じくらいのチュートリアルがあるので大差ないかと。私が気付いた限りでは、Bigtable(Googleのデータベース)へのデータのインポートの手順はPythonの方しかドキュメントおよびツールが準備されていないと思います(2009年8月2日現在)。

Amazonの時も思いましたが、クラウドサービスの導入って意外と簡単です。もちろんちゃんと使えるようなものを作るまでは大変ですが、それ以外の無駄な手間(クラウド自体の設定作業とか)は少ないにこしたことは無いので。

みなさんも、Let’s クラウドライフ!

Home > Tags > google app engine

Search
Feeds

Return to page top