PaaSの動向(前編):初期のPaaSは完成度が高いがロックインされやすい
先週10月13日にクラウド利用促進機構(CUPA)というNPOが主体となって「オープンクラウドキャンパス」というイベントが開催されました。今回のテーマはPaaSです。
そのイベントの冒頭で「PaaSの動向」についてプレゼンテーションをしてもらえないか、と依頼をいただきまして、お話をしてきました。このプレゼンテーションのあと、各PaaSベンダからそれぞれのPaaSの紹介が行われる予定だったため、主眼はPaaSの歴史的な流れと、その背景にある技術を概観することにフォーカスしました。
この記事は、そのプレゼンテーションの内容を紹介したものです。本番では時間があまりなくて省略した部分もあったので、記事化にあたってはそうした点の補足もしました。
初期のPaaSは完成度が高い
新野と申します。Publickeyというブログをやってます。それから先月くらいに「クラウド利用促進機構 総合アドバイザー」という肩書きをいただきまして、今日はその肩書きとしての初仕事、ということになります。よろしくおねがいします!(会場から拍手)
さて。PaaSとは何か、といったことはここにお集まりの皆さんはすでにご存じだと思いますのでそうした基本的なことは飛ばして、まずはPaaSの歴史を簡単に振り返ってみます。
最初に登場したPaaSはセールスフォース・ドットコムのForce.com。2007年です。ちなみにここで示す登場年はβ版やプレビュー版など何らかの形でサービスが公開された年を示しています。
Force.comはApexと呼ばれる専用言語と、今ではDatabase.comと呼ばれているリレーショナルなデータベースをバックエンドに備えています。
翌年2008年にはグーグルのGoogle App Engineが登場します。プログラミング言語としてPythonが使え、データベースとしてNoSQLのBigTableが使えます。その後Javaも使えるようになっています。
2009年にはマイクロソフトからWindows Azureが登場します。.NETでプログラミングができ、当初はNoSQLデータベースが提供されていましたが、途中からSQL Azureがメインのデータベースとなりました。
これら初期に登場したPaaSの特徴は、生まれながらにPaaSとして設計され登場したという点です。インフラの部分のIaaSレイヤは公開されず、インフラのレベルからPaaSに最適化されています。
例えばGoogle App EngineやForce.comはリソースの有効活用のために仮想化を用いていないと言われていますし、Windows AzureではWeb RoleやWorker Roleのようなクラウドに特化したアーキテクチャを持っていたり、SQL Azureが最初から3ノード連係で障害に強い構成になっている、といったことがあります。
そしてミドルウェアとデータベースがセットで提供されており、ベンダによってしっかり垂直統合されている点も挙げられます。これによって非常に完成度の高いPaaSになっている半面、独自性が高く、顧客から見ればロックインされやすい性格だともいえます。
今後は、この次に紹介するOpen PaaSの流れもあり、これらもオープンな環境を提供するPaaSになっていくと予想しています。
その後、続々と登場してきたのが、IaaS上に構築されたPaaSです。ここに挙げたHerokuは2007年に登場していますが、今年2011年になるまでRuby on Railsの一種類のみのPaaSでした。今のような多言語対応になったのは2011年からです。
2011年にはAmazonクラウドのElastic Beanstalkが登場。Javaに対応しています。
Cloud Foundry、OpenShiftも相次いで今年登場しており、JavaやRuby、PHP、Pythonなど非常に多くの言語に対応しています。
これらの特徴はAmazon EC2のようなIaaSの上に構築されたPaaSであること、IaaSに対してインストーラブルであること、そして言語やデータベースの選択肢が広いということです。「Open PaaS」というキャッチフレーズで呼ばれることもあります。
ただしどれも最近登場したものばかりなので、実績や完成度の面ではこれから、というところです。
フルスタックのPaaS以外にも、データベースサービスなど、PaaSを構成するためのサービスが登場してきています。Amazonクラウドなどではこうしたサービスがエコシステムを作り上げようとしており、IaaSのOS化のような現象にも見えます。
今後はエディタ、デバッガなど統合開発環境も含めてPaaSで提供されるようなことになるだろうと予想しています。
PaaSの品質に対するハードルが上がった
さて、これらを踏まえて最近のPaaSの動向から、特に興味深い項目を挙げてみました。
1つ目はNoSQLからRDBへの揺り戻しです。2~3年前はクラウドでのデータベースはスケーラビリティが重要ということでNoSQLに注目が集まっていました。しかしこのところリレーショナルデータベースでもスケーラビリティを実現しようとしていたり、また業務アプリケーションをクラウドに乗せるのであれば、利用者は社員に限定されるのでそれほど大規模なスケーラビリティは不要である、といった状況もあって、クラウド上のリレーショナルデータベースの重要性が語られるようになってきました。
業務アプリケーションでよく使われるOracle DatabaseがAmazonクラウドやNiftyクラウドで提供されたり、またNoSQLの主要なデータベースの1つであるBigTableを提供していたGoogle App EngineでもGoogle SQL Cloudの提供を開始するなども、こうしたトレンドの表れのように思います。
2つ目は1つのPaaSで複数のプログラミング言語対応が普通になってきていることです。特に昨年くらいまではJavaをサポートするクラウドはあまりなかったのですが、このところ急に増えてきています。またJava VM上では複数のプログラミング言語が実装されているため、複数のプログラミング言語をサポートする意味でJava VMの重要性が高まってきているように思います。
今年の5月にAmazonクラウドで大規模な障害があり、FourSquareやHerokuが止まるなどPaaSにも大きな影響を及ぼしたのですが、そのときにHerokuはこう発表しました。「IaaSが原因の障害であっても、PaaSが止まった責任は私たちがとる」と。これはPaaSの品質に対して1つハードルを上げる出来事だったと思います。
つまりこれからのPaaSは単にIaaSの上にPaaSレイヤを持つのではだめで、複数のデータセンターやクラウドに展開し、特定のデータセンターやクラウドに障害があった場合でも問題なく動き続けるような品質をPaaSレベルで構築できるようにならないといけないのだろう、ということです。
そしてつい先週、オラクルがクラウド参入を発表しました。Java EE 6とOracle DatabaseのPaaSです。実はこれまでどのPaaSでもJavaではSpringフレームワークを採用していました(OpenShiftのみJava EE対応)。
業務アプリケーションのプラットフォームとしてJava EEのクラウドは注目に値しますし、今後Java EEのクラウドでの存在感が高まるかもしれません。
また同じく先週、JavaOneでJava EE 7がクラウド対応になると発表されています。
長くなったので後編「PaaSの動向(後編):PaaSのスケーラビリティとマルチテナント方式の違い」に続きます。