Google App Engineは敷居が高いのがメリット？ セールスフォースは開発生産性が高いが制限にも苦しむ ～ クラウドごった煮パネルディスカッション（PaaS編 前編）

国内にあるクラウドのユーザーコミュニティに集まってもらい、ディスカッションを行う日本で初めてのイベント「クラウドごった煮」が、昨年末12月11日に開催されました。Windows Azureのユーザー会（Japan Windows Azure User Group、JAZ）の人たちが中心になり、つてをたどってほかのクラウドのユーザー会などに呼びかけて実現したものです。

前回のIaaS編に続き、この記事ではPaaS（Platform as a Service）の機能を提供する3つのクラウド、Google App Engine（GAE）、Heroku、Salesforce.com（SFDC）のコミュニティ代表3人のパネルディスカッションの内容を記事にして紹介しましょう。

Google App Engineのいいところは「敷居の高いところ」？

新野　PaaSのディスカッションでも、まずはなぜこのクラウドを選んだのか？ をみなさんに聞いていきましょう。ひがさん、いかがですか。

ひが（GAE）　Google App Engine（以下App Engine）のいいところは、素人お断りみたいな、そういうところがあるところが非常に気に入ってます。一般的には「とっつきやすいです」というのが売りになると思うのですが、App Engineは敷居が高いです。

ただし、これが重要なんですが、なぜ私がこれを「いいところ」にしたかというと、われわれがビジネスをやるうえにおいて大事なのは差別化なんです。ほかの人が「これはできない」ということをできる、その付加価値を提供できるときにお金がもらえる。

敷居が低いといろんな人が参入してきてマーケットが広がるという意味はありますが、差別化してお金を儲けるという意味では敷居が高いというのが大事だったりします。

新野　App Engineの敷居の高さというのは、どこにあるのでしょう？

ひが　単に敷居が高いだけではもちろんだめです。高いなりのメリットがちゃんと提供できないと意味がない。

App Engineはスケールアウトするようなアプリケーションに特化しているプラットフォームで、グーグルがサービスを提供するうえで使っているインフラ、彼らのスケールアウトする仕組みを使っています。

だから本当に世界規模、何億というユーザーにサービスを提供してもびくともしない、そういうアプリケーションが作れる。ただしデータベースとして使っているBigTableはRDBMSとまったく違うので、そこを分かっていないと使いこなせないし、プログラミングに制限があるんですが、その制限を理解したうえでどう回避するか理解しないと作れません。

新野　いまプログラミングの制限の話がでましたが、逆にここはなんとかしてほしい、ここは欠点だな、という点があれば教えてください。

ひが　いま私はソーシャル系のビジネスをやろうとしていて、そのプラットフォームとしてApp Engineを選んでます。そういうソーシャル系のプラットフォームとしてApp Engineは結構よくできている。

いろいろこう、SQLが使えないとか、レスポンスは30秒以内とか、一般には不便に感じるところはあるのだけれど、ソーシャル系のアプリケーションなら5秒以内とかにリクエストを処理しなければいけないから30秒は楽勝だし、リレーショナルデータベースではユーザーが増えていくと更新系が重くなって、たくさんデータベースを並べて解決するといったことをがんばらなくてはいけないのですが、App Engineはそういうのを自動化してくれるので、ソーシャル系ではそんなに不満に思ってはいません。

1つ不満に思うことをいえば年に4回くらい、データストアの調子が悪くなる。遅くなっちゃう。あと計画停止があって、それも3カ月に一回、1～2時間止まる。ただし計画停止は日本の早朝の5時とか、いい感じの時間帯に行われるので（笑） そんなに困ってはいません。

Herokuは開発も含めてスモールスタートに向いている

新野　では、同じ質問を小倉さんにも。クラウドとしてHerokuを気に入っている理由を教えてください。

小倉（Heroku）　Herokuは（Ruby on Railsをクラウドにのせたものなので）画期的なものではないんですね、パラダイムシフトがあるというものではないですし、アーキテクチャも言語もライブラリもHeroku独特のものがあるわけではないです。

でも使用料に応じたスモールスタートができますし、Ruby on Railsの経験者がいれば開発の部分も圧縮できるので、個人や数人のスタートアップでサービスを立ち上げたいときにすごく便利だなと感じています。

新野　一方で不満はありますか？

小倉　個人的にはそんなに欠点ではないと思うのですが、オートスケールがない、リレーショナルデータベースに限界がある、といったところです。

自分で開発するものが、例えば社内で使うイントラ向けのアプリケーションなどユーザーがどこまでも増えていくというものではないので、オートスケールがないのは気にならないところではあるのですが、そのあたりがセールスフォース・ドットコムに買われてどうなるのか期待しています（笑）

（注：このイベントの数日前に、セールスフォース・ドットコムがHerokuを買収するという発表が米国であったばかりでした）

開発生産性がセールスフォース・ドットコムのメリット

新野 ではそのSFDCについて、今岡さんに。ここは気に入っているというところから教えてください。

今岡（SFDC）　開発生産性の高さはメリットとして感じています。ただ単純に生産性が高いだけではなく、業務系のアプリケーションを作るときにデータのアクセスコントロール、誰がどのデータにアクセスできるか、などの機能も標準で提供されています。

ですので、われわれはお客様の要件がSFDCの標準機能で実現できるかどうかに注力して、機能の品質に関してはSFDCが保証しているので安心感がある。そういうところ、機能群が揃っているところが開発するうえでのメリットかなと思います。

新野　逆に、ここは不満に思う点があれば教えてください。

今岡　開発環境でいえば、標準の機能でできないところはコーディングを行います。そのときにローカル環境でのデバッグができない。ステップ実行とかできません。将来的にはできるようになるらしいのですが。

ですので現状では、コードの中にはデバッグするときのシステムデバッグだらけです。変数の状態は分かるようになったのですが、スーパークラスのメンバーが分からないとか、もうひとつなんですね。

あと「ガバナ制限」というのがあって、これに開発者は苦しめられます。マルチテナントで動いているので、実行中にCPUの負荷が高くなるような処理は実行時にシステムエラーを起こす。

例えば、トランザクションの中で発行していいクエリは何回までとか、いちどに取得可能な最大レコード件数は何件までとか。そういう制限が今後緩和されていくことを望みますね。

新野　ありがとうございます。では会場のみなさんからの質問はありますか？

それぞれのPaaSを使いこなすまでにどれくらいかかる？

会場から　それぞれのクラウドは、使い始めてから思い通り使えるようになるまでにどれくらいの時間がかかりましたでしょうか？

ひが（GAE）　App Engineの使い方を覚えるだけなら、JavaでもPythonでもそれほど時間はかからないと思います。

ただ先ほども言ったように、スケールアウトするアプリケーションをどう開発するか、ということを理解するには3カ月くらいかかるのではないですかね。

新野　会場から、「（それぐらいの期間でできるのは）ひがさんだから」という声が……

新野　Herokuはいかがですか？ 小倉さん。

小倉　HerokuはそのまんまRailsなので、単にアプリケーションを走らせるだけなら半日とかでしょう。ただ、ひがさんがおっしゃられたように、スケールアウトするためにどうするか。単にサーバを増やすと課金が増えていくので、それを圧縮するための効率のいいやり方を理解するという意味では、アーキテクチャをいじらなければならないので、マスターするのに数週間くらいはかかる、という気がします。

新野　SFDCではいかがでしょう？

今岡　ApexコードとかVisualForceといった開発言語を使うレベルでは、Javaとかの経験があればそれほど違和感がないかなと思います。

アプリケーションを作るという観点では、チュートリアルがありまして、それをひととおりやると40時間とかかな。ですから（データベースの）Accessとかでアプリケーションを作った経験がある人なら、だいたいそれくらいの時間で簡単なアプリケーションを試してみることができると思います。

クラウドの動向をどれくらい気にしている？

新野　まだ会場から質問がありますね。どうぞ。

会場から　いま自分が使っている以外のクラウドの動向をどれくらい気にしていますか？

今岡（SFDC）　そうですね、1つはSFDCがVMforceという形でJavaに取り組むと、その競合といえばWindows Azureになるのかなと思うので、自社で（SFDCとAzureの）生産性などの比較はしてみました。

あとSFDCはストレージの料金が比較的高いと思っていまして、大事な情報以外は別のクラウドにのせるのはどうか、といった意味でAmazonクラウドをちょっと気にしています。

小倉（Heroku）　Rubyが好きでHerokuを選んだので、自分で選ぶとすればRuby以外はないかなと思います。技術的な面白さで言えばApp Engineのスケールするところで、案件によってはApp Engineのことも見ておかなければなと。

ただIaaSと違って、PaaSだとアプリケーションのコードごとPaaSベンダと運命を共にすることになりがちで、だからといってほいほい乗り換えるわけにもいかないので、惚れ込んだところに絞った方がいいのかなと思います。

ひが　私は、App Engineに惚れ込んだわけではないんですね（笑）

ビジネスとして、いちばん成功しやすいプラットフォームとして選んだだけなので、Azureでもなんでもいろんな情報はいつもおさえていて、ほかのプラットフォームも同じように気にしています。

（さらに本音が炸裂する後編「どのクラウドが受託に向いているか？ Javaに未来はない、インフラ担当にも未来はないのか ～ クラウドごった煮パネルディスカッション（PaaS編 後編）」に続きます）

クラウドごった煮パネルディスカッション

• Amazon、Azure、Niftyクラウドのいいところ、悪いところを本音で語り合う ～ クラウドごった煮パネルディスカッション（IaaS編 前編）
• Amazonクラウド互換APIがデファクトになりつつある状況をどう思う？ ～ クラウドごった煮パネルディスカッション（IaaS編 後編）
• Google App Engineは敷居が高いのがメリット？ セールスフォースは開発生産性が高いが制限にも苦しむ ～ クラウドごった煮パネルディスカッション（PaaS編 前編）
• どのクラウドが受託に向いているか？ Javaに未来はない、インフラ担当にも未来はないのか ～ クラウドごった煮パネルディスカッション（PaaS編 後編）