Google AppEngineについて思うところ

早すぎる最適化オジサン @makotokuwata

Google AppEngineについて思うところを書いてみる。うざいかもしれんがご了承ください。

早すぎる最適化オジサン @makotokuwata

まずAppEngineがいまいちブレークしないのは、お金を集める仕組みが用意されていないことと、Datastore (Bigtable) の使い方が難しいことの2点だと思う。

早すぎる最適化オジサン @makotokuwata

1点目の、集金システムについて。AppEngineと比べて、たとえばiPhoneアプリは十分ブレークしているといえるけど、これはやはりiPhoneアプリは販売して収益を出せる可能性があることが大きい。

早すぎる最適化オジサン @makotokuwata

それに比べて、GAEはインフラと開発環境は提供するけど、集金の仕組みは提供できてない。言い方を変えると、無料で使える環境は提供しているけど、収益を上げるための環境は提供できてない。そこがiPhoneアプリと違うところ。

早すぎる最適化オジサン @makotokuwata

それに比べて、SalesForceはサブスクリプション制で集金する仕組みを提供している。どう考えても、クラウドでビジネスするならSalesforceのほうだと思う。GAEは別途収益を上げる方法を持ってる人じゃないと、お金にしにくい。

早すぎる最適化オジサン @makotokuwata

まあ別に収益を*あげなければいけない*なんてことはなく、無料で使えればそれでいいという人も多いだろうから(自分もそう)、それはそれでいいのかもしれない。

早すぎる最適化オジサン @makotokuwata

でもやっぱりGAEが今の微妙な不人気を解消しようとしたら、やっぱり何らかの課金の仕組みが必要だと思う。だからこそ、GoogleにはPaypalを買収してほしいと思う。

早すぎる最適化オジサン @makotokuwata

で、2点目の「Datastore (Bigtable) が使いにくい」という点だけど、これはもうどうしようもない用に思う。つまり解決のめどが思いつかない。

早すぎる最適化オジサン @makotokuwata

通常のRDBMSは、まず「データベースに必要な要件は何か？」ということから始まって、それを満たしたうえで性能を向上させてきた。しかしBigtableは逆で、性能を最優先し、性能を落とす機能はことごとく省略されている。

早すぎる最適化オジサン @makotokuwata

これはどちらが正しいかという話ではなくて、どちらにも利点と欠点はあるのだから、単に開発者がどちらを選ぶかという話に過ぎない。ただGAEでの問題点は、開発者には選ぶ自由がないことだ。つまり「性能はそこそこでいいから使いやすい方を選ぶ」ことができない。

kotobuki万寿斎 @ktbk0227

@makotokuwata まずフリーワードでの検索諦めないとだから辛いっすよねー。アイディア次第なんでしょうけど…

早すぎる最適化オジサン @makotokuwata

GAEマンセーな人の意見はいつも、「高い性能を出すためには機能が犠牲になるのはやむを得ない」というものだけど、性能と機能のどちらを優先するかは開発者が決めることであって、プラットフォームで強制されることは、*本来は*おかしな話である。

早すぎる最適化オジサン @makotokuwata

あとアプリの性能は、なにもデータベースの性能だけに依存するものではない。どちらかというと、「いかにキャッシュをうまく効かせられるか」「いかにデータを分散できるか」のほうが重要であって、それだとBigtableである必要性は薄い。

早すぎる最適化オジサン @makotokuwata

GAEを使えば無条件に高性能なアプリが作れる、あるいはGAEだと高性能なアプリが簡単に作れるというのなら、GAEはもっと人気が出ただろう。しかし実際には、中身を良く理解してかなり工夫を凝らさないと高い性能は出せない。

早すぎる最適化オジサン @makotokuwata

いくらBigtableが高性能だといっても、RDBMSと比べるとずいぶん使い勝手が落ちるので、正直言ってプラスよりマイナスのほうが大きいんじゃないかと思う。

早すぎる最適化オジサン @makotokuwata

「高性能」と「高機能」はなかなか両立しない。そして歴史を振り返ってみると、「高性能(速いこと)」よりも「高機能(使いやすくて便利)」であるほうが好まれる傾向にあると思う。端的な例がプログラミング言語で、高性能なC++やJavaよりスクリプト言語のほうが今は人気だ。

早すぎる最適化オジサン @makotokuwata

データベースも、高性能だけど扱いにくいBigtabeよりも、性能は若干落ちるかもしれないけどずっと扱いやすいRDBMSのほうが、主流のままだと思う。

早すぎる最適化オジサン @makotokuwata

GAEでも、BigtableにアクセスするよりもMemcacheにアクセスしたほうが高速なので、結局キャッシュしなきゃいけないなら、DBは多少遅いRDBMSでもいいと思う。

早すぎる最適化オジサン @makotokuwata

あとGAEのBigtableは、現状ではどう考えてもRDBMSより信頼性が劣るので（マジでデータが消えることがある）、お金を扱うようなアプリをGAEで開発するのはおすすめしない。ブログとか掲示板とかにとどめておいたほうがいい。

早すぎる最適化オジサン @makotokuwata

長くなったね。要点は、GAEのDBであるBigtableは高性能だけど扱いづらいので主流にはならないだろう、それよりRDBMSの使いやすさを享受したまま、性能はキャッシュとデータ分散化で稼ぐほうが楽、ということ。もちろんこれは私見であることに注意。

早すぎる最適化オジサン @makotokuwata

Googleは、GAEではRDBMSをサポートしないと過去に明言したことがあるけど、RDBMSをサポートしない限りGAEがブレークすることはないだろう。ただビジネス向けに一部RDBMSをサポートする計画もあるらしいが、ブラフの可能性もあるので鵜呑みにはできない。

早すぎる最適化オジサン @makotokuwata

じゃあGAEは使い物にならないかというと、もちろんそんなことはなく、(A)収益は特に考えない(無料で使えればそれでいい)、(B)信頼性もそこそこでいい、(C)複雑なデータモデルは扱わない、という条件を満たすならGAEはお勧め。具体的にはブログとか掲示板ね。

早すぎる最適化オジサン @makotokuwata

こういう条件を満たすアプリはけっこう多いはず。BTSとかグループウェアとか写真管理とか。反対に、在庫管理とか受注管理とか会計のシステムは、データモデルや検索条件も複雑だし、無理にBigtableやKVSを使うよりRDBMSを使ったほうがいいと思う。

早すぎる最適化オジサン @makotokuwata

給与計算とかは、、、うーんどうだろう、データモデルはそこまで複雑じゃないと思うけど、集約関数があるRDBMSのほうがやっぱり楽だろうなあ。

早すぎる最適化オジサン @makotokuwata

あーそうだ、RDBMSってテーブルが基本だから、ツリー構造を扱うのがあんまり得意じゃないんだった。会計システムだと二次元のテーブルで間に合うけど、部品構成表とかMRPだとツリー構造扱うからRDBMSは使いづらいよね。だからといってBigtableで扱いやすくなるわけじゃないけど。