フレクトのクラウドblog(New)

セールスフォース、Google、AmazonのPaaSの比較とSIer視点からの印象

最近、Amazon Beanstalkが発表されて、PaaS領域が一段と盛り上がってきました。

業務系に強いForce.com、ソーシャルアプリなどコンシューマ系サービスに強いGoogle App Engineあたりが有名でしたが、最近は選択肢がかなり増えました。
この記事を書いている最中にもちょうど以下のような記事がでていて、PaaSに対する注目度が高いことがうかがえます。

http://www.publickey1.jp/blog/11/google_app_engine_paas.html

http://www.publickey1.jp/blog/11/_java_paas.html

上記の記事でだいたいよいところ、難しいところがまとまっているのですが、今日はGoogle App Engine、Force.com、AWSのサービス、それぞれ実サービスの運用や受託開発で使った経験や、SIerでマネージャをする立場から、自分なりの比較と印象を書いてみようと思います。まず、セールスフォース、Google、Amazonが提供、あるいは関連が強いPaaSについて言語、利用するDB、インフラ運営元、そしてサービス提供会社を一覧にしてみました。

◆ 各プラットフォームと言語、DBなどの比較

名前	言語	DB	インフラ環境	サービス提供会社
Google App Engine(GAE)	Python, Java	BigTable	Google	Google
Force.com	Apex, VisualForce	Force.comのDB(Database.com)	Force.com(セールスフォース)	セールスフォース
VMForce	Java(Spring Framework)	Force.comのDB(Database.com)	Force.com(セールスフォース)	セールスフォース
Heroku	Ruby(Ruby on Railsなど)	PostgreSQL(標準)など	Amazon	セールスフォース
Amazon Beanstalk	Java	Amazon RDS(MySQL), Amazon SimpleDBなど	Amazon	Amazon
Engine Yard	Ruby(Ruby on Railsなど)	MySQL(標準)など	Amazon	Engine Yard(いずれAmazon?)

注目すべきはGAEはDBが独自であること、Force.comはApex、VisualForceという独自の言語でアプリケーション構築をする必要があることでしょう。(Force.comのDBは独自といえば独自ですが、RDBの考え方でだいたい操作できます)

それに対して、Amazon上で動くPaaSは言語、DBともに、オンプレミス環境からの差分はかなり少ないと思ってよさそうです。こういった特徴を踏まえたうえで、「よいところ」と「気をつけるべきところ、気になるところ」を私の所感でまとめてみました。

◆ 特徴まとめ

PaaS分類	よいところ	気になるところ
Google App Engine(GAE)	・アプリケーションサーバだけでなく、データベースまで自動スケールするところ。 ・Java/Pythonといった汎用性の高い言語で開発できること ・非常に安い。1日あたりのQuota制限があるが、ある程度のボリュームまでは無料と考えてもよい。範囲を超えても安い。 ・個人で勉強しやすい。情報も多いし、安い。	・物理的にどこにデータが置かれているかなどブラックボックス(悪いこととは限らない)で、どう動いているか見通しがきかないことがあること ・BigTableという、RDBとは違う考え方が求められるデータベースを使うため、使いこなすにはかなりの学習コストが発生すること。開発者の確保もやや難しいこと
Amazon系(Heroku、Engine Yard、Beanstalk)	・Java(Tomcat)やRuby on Railsなど、オンプレミスの環境で培われた技術を用いてアプリケーションが構築できること。 ・開発者が確保しやすい。 ・Amazon EC2、RDS、S3、CloudFrontなどPaaSの構成要素となるコンポーネントが独立したサービスとなっており、自由自在に組み合わせられる。	・GAE、Force.comと比べるとRDBやストレージなどのバックアップ等、ミドル、インフラの運用面的なことを多少意識しないといけないこと ・アプリケーション部分についてはForce.comのように何かベースとなる強力な機能があるわけではないので、その開発コストはオンプレミスに近い感じになること
Force.com系	・GUI操作(Point&Click)だけで、かなりのカスタム機能が作成でき、型にはまると生産性がかなり高いこと。 ・認証系の機能、ユーザの権限制御、ワークフローなどスクラッチ実装をするとけっこう面倒な機能が既に存在すること。 ・国内、海外問わずたくさんの大手企業が業務システムに使っており、セキュリティ含め、実績面では信頼しやすい	・Apexなど独自技術の学習コストがかかる ・ストレージ容量やレコード件数、外部からのAPI呼び出しの最大数の制限など、「容量の大きいデータ」、「件数の多いデータ」への制限は強いこと ・ライセンス費用がユーザ単位であり、GAEやAmazon系の課金と違うのは注意が必要なこと

上の色をつけているところが、もっともメリットとして特色があるところです。

◆ 用途に合うと高い効果を出すGAEとForce.com

GAEとForce.comは「制約は強いが、型にはまると高い効果を出す」と考えるとよいと思います。

GAEはデータベースが独自なので「Joinをさける」「集合関数は使わないで、レコードに持つ」などRDBとは違う考え方で開発が必要です。しかし、アプリケーションサーバだけでなく、データベースまでもが自動スケールするので、アクセス量が読めないアプリケーション(ソーシャルアプリなど) では、独自技術を習得するコストを払ってもメリットを得られる可能性があります。

Force.comについては、GAEに比べると書籍等少なく、個人で勉強する人も少なそうなので、知らない人も多そうですが、GAEと同じく型にはまると強いPaaSと考えています。
GAEやAmazon系のPaaSが提供している機能はデータストアやストレージのAPIなど、どんなアプリケーションでも共通で使いそうなものが中心です。それに対して、Force.comは会社などの組織で使うアプリケーション構築に必要な機能が最初から揃っています。たとえば、ユーザの発行、権限管理、ワークフローなど。認証処理とか権限制御など、受託案件では「毎度おなじみ」の機能ですが、けっこう作るのは毎度面倒、な機能です。そういったものが最初からそろっていて、しかも簡単にカスタマイズできるというのは、はまるとすごい生産性です。

実際、フレクトでも案件管理や勤怠管理、経費申請などいくつかの業務アプリをバンバン作っていった実績があります。セールスフォースが得意とするCRMだけでなく、多くの業務系アプリの開発が高い生産性でできる実感を持っています。

一方でForce.comはユーザごとにライセンス費用がかかったり、CPUやストレージをちょっと使うと意外と早く制限がくるなど、特有の制約事項があり、注意しながらの開発が必要です。

両方とも制約が強く、はまると効果テキメンっといった感じですが、学習コストがかかるので開発者のアサインが意外と難しい、といったデメリットがあります。

◆ 既存のオープンな技術をベースにスピーディに作れるAmazon系

HerokuやBeanstalkなどのPaaSはRuby on Rails、Java(Tomcat)、PostgreSQL、MySQLなどのオンプレミス環境でも存在しているオープンな技術をベースとしていて、それらを使ったシステムをすばやく作れるというメリットがあります。アプリケーションサーバ、RDB、ストレージなどはAWSや各PaaSが提供してくれているサービスをそのまま使えばいいので、インフラ、ミドルの心配をせずに、Web開発のスタンダードな技術であるJava、Ruby、MySQLなどを使って開発できるというのがGoodです。オンプレミス環境と同じで、なおかつオープンな技術をベースにしているものが多いので学習コストも低く、開発者のアサインも容易です。

コンシューマが使うWeb系のシステム構築で、とにかく早くリリースしたい、早く作りたい、という場合には、Amazon系のPaaSが有力な選択肢になります。

実際、フレクトでもPaaSではありませんが、Amazon EC2、S3などを使ってモバイルサイト(http://bhmb.jp/)を開発、運用しており、開発時のプラットフォーム選択の決め手はクラウドの恩恵をうけつつ、既存技術をベースにすばやく開発したい、というものでした。

◆ SIer視点からの認知度、信頼度の印象

SIerである私たちにとって、多く接するお客様はユーザ企業の情報システム部門の方々です。そういった企業の方々からも選択肢として認知されているのはセールスフォースがやはり一番という印象です。多くの企業で導入されたということはコンプライアンス観点などからもクリアした案件が多いということで、この辺はお客様に提案するプラットフォームとしてはSIer的にはGoodです。

Amazon系のサービスやGoogle App Engineもまったく認知されていないというわけではないのですが、積極的に選択肢にあがってくるケースが多いかというと必ずしもそうではなさそうな気もします。Amazon系やGAEの事例もサービス企業が内製でそのメリットを活かして作っているケースが多く見受けられます。企業の情報システム部門からの認知度、信頼度という点は、今後の向上に期待というところです。

もちろん、私が知る範囲でもお客様によってはAmazon系やGAEなどの技術に長けていて、すごく活用されているというケースもあります。ただ、全体で見るとまだ低い割合なのかな、と思います。

◆ 今後の気になるところはPHPのPaaS

SI案件というとJava系が多いと思いますが、Web絡みになるとPHPの比重が高くなります。そういう点ではPHP系のPaaSは有名なものは見当たらないですね。注目としてはPHP Fog(http://www.phpfog.com/)が、Heroku的立ち位置を目指しているようなので今後どうなるか気になるところです。

※ 【追記】 AzureでPHPできるとご指摘いただきました。ちょっと調べてみます。

◆ まとめと中途採用募集のお知らせ

VMForceなどリストアップしていながら、あまり言及していないものがあり、すみません。また今度調査してみます。

最後に、フレクトはセールスフォースのプラットフォームやAWSを使ったインテグレーション事業を拡大中です。最新のPaaSを使った開発に興味のある人はぜひご連絡いただければと思います。採用エントリーは以下からです。お待ちしております。

http://www.flect.co.jp/recruit/

Herokuについて調べたことのまとめ

遅くなりましたが、あけましておめでとうございます。
フレクトの大橋です。

フレクトはセールスフォースを使ったシステムインテグレーション事業が
中心事業の1つだったりします。なので、年末年始はセールスフォースが買収した
Heroku(ヘロク)やRubyについて急に勉強を始めました。

忘れないように、年末に年始に勉強したことを備忘録的にまとめておきます。

＜1. どんなものか＞

乱暴な言い方をすれば、Google App EngineのRuby版です。（乱暴すぎる？）

もっとも違うのは、Ruby, Rails, PostgreSQL、memcachedなどオープンな技術の上に作られており、自分たちのLinuxサーバで動かしたアプリケーションをそのまま動かしやすい環境であることです。

Dynoと呼ばれるWebサーバプロセス数や、データベースの使用する容量などにより課金され、無料の範囲もありますが、Goolge App Engineよりは無料範囲が小さいと思っておいてよいと思います。

＜2. Hello, World的なものを動かすには＞

とりあえず、Hello, World的なものを動かしたくなります。動かすだけならば以下のすばらしい記事を見ればOKでした。

http://kuranuki.sonicgarden.jp/2009/05/rubypaasherokurails.html

デプロイなどはgitに連動していて、コマンドラインから簡単にできることが体感できると思います。

＜3. 構成コンポーネントとリクエストの流れ＞

以下の図にあるようなコンポーネントが基本コンポーネントで、
リクエストを順次処理していきます。

(※ http://heroku.com/how/architecture から図は引用しています)

まず、リクエストはnginxでできているリバースプロキシ(HTTP Reverse Proxy)に到達します。そこから、varnishでできているHTTP Cache層に来ます。

HTTP Cache層ではCache-Controlヘッダなどの内容によりコンテンツキャッシュを
返す機能があり、キャッシュヒットするコンテンツはここでレスポンスとしてユーザに戻します。

HTTP Cache層の次は、Routing Meshです。ここでリクエストを各Dynoにバランシングします。ここはHerokuがErlangで独自実装したミドルウェアのようです。

次にDyno Grid上での各Dynoで動くアプリケーションにリクエストが来ます。マルチテナントなので、Dyno Grid上にはいろいろな人、組織のアプリケーションが動いていますが、適切なDynoにリクエストが送られるよう、Routing Meshでルーティングされています。

なお、Dynoはアプリケーションサーバの1プロセスで、アプリケーションサーバThin(http://code.macournoyer.com/thin/)をベースにしているもののようです。Dynoは追加購入すれば、ユーザは柔軟に増やすことができ、2秒で起動するとのことです。

Dyno上のアプリケーションがリクエストを処理し、必要に応じてDatabaseやMemory Cacheにアクセスします。

Databaseは標準はPostgreSQLで、Memory Cacheはmemcachedが動いています。それぞれ、Dyno上で動くアプリケーションからアクセスできます。

＜4. 動かせるアプリケーション＞

Rackに対応したアプリケーションであれば動かせます。
RackというのはRubyにおけるWebサーバとフレームワーク(RailsやSinatraなど)との
インタフェースの役割を果たすライブラリです。詳しくは以下で。

http://gihyo.jp/dev/serial/01/ruby/0023

Rackに対応したフレームワークであれば、Heroku上で動くことになります。なので、Railsだけでなく、Sinatraなど他のフレームワークでも動くそうです。

＜5. 無料で使える範囲＞

1つのアプリケーション、1つのDyno、5MBのデータベース領域であれば無料で使うことができます。個人で勉強する分には十分かと思いますので、いろいろ試してみたいところです。

＜6. 魅力的なアドオンがたくさん＞

標準では、Dyno(アプリケーションサーバ)、Databaes(PostgreSQL)、Memory Cache(memcached)を使うくらいかもしれませんが、よく見てみるアドオンがたくさんあり、使いたくなるものもいろいろありました。個人的に使いたいと思ったものをいくつか列挙しておきます。

◆ Amazon RDS連携

　　EC2上で動いているので当たり前っぽいサービスですが、これは必要ですね。

　　　　http://addons.heroku.com/amazon_rds

 

 

◆ Exceptionトラッキング（通知）

　　エラー発生時にメールやTwitterで通知してくれるサービス。運用上こういう
　　仕組みを作るのは以外と面倒なので助かります。

　　　　http://addons.heroku.com/exceptional

 

 

◆ Solr

　　フレクトでは全文検索などやるときSolrを使っていたりするので、これは
　　魅力的です。外部のSolrサービスをWeb経由で提供している会社に
　　つながるみたいですが。
　　日本語辞書で形態素解析できるのか、など追加の調査は必要ですね。

　　　　http://addons.heroku.com/websolr

 

＜まとめと今後＞

Rails(Rack)アプリのためのPaaS、"Heroku"について勉強したことを備忘録的にメモにしました。

US-EAST以外にいつ展開されるのか、といったことや、セールスフォースが買収したことにより、どんなサービスが追加されるのか、など今後の動きが気になります。

一部、実験的にnode.jsに対応など始まっており、多言語展開するのかも気になるところです。

実戦投入まではもう少し勉強、検証が必要ですが、海外を中心に実戦投入された事例も多いので、フレクトでも経験積んで実戦で活かす機会が作っていきたいと思います。

しばらく研究してみて、今後、Herokuの記事もたくさん書けるようにしていきたいです。

では、本年もよろしくお願いします。