Java PaaS の比較

Google App Engine、Amazon Elastic Beanstalk、CloudBees RUN@Cloud の技術的比較

この記事では Java™ 開発者向けの 3 つの主要な PaaS (Platform as a Service) オファリングである Google App Engine for Java、Amazon Elastic Beanstalk、そして CloudBees RUN@Cloud を比較し、それぞれのサービスに特有の技術的な手法、長所、短所を分析するとともに、一般的な次善策について検討します。Java PaaS の基礎となる基本概念を学び、開発のニーズに最適なサービスを選択する方法を理解してください。

Michael J. Yuan, Chief Scientist, Ringful Health

Photo of Michael YuanMichael Yuan 博士は、エンタープライズ・コンピューティングおよび消費者向けモバイル技術の分野で有名な科学技術者です。ソフトウェア・エンジニアリングに関する著書は 5 冊、同じ分野の開発者向けジャーナルおよび業界ジャーナルでは 40 を超える記事を発表しています。彼は、消費者主導型医療という新しい分野の先駆者であり、Ringful Health での彼の業績はウォールストリート・ジャーナル、ニューヨーク・タイムス、ロサンゼルス・タイムスなどの国内メディアで広く取り上げられ、認められています。



2011年 4月 05日

今年は PaaS の年となるのか

2010年 12月、salesforce.com は Ruby ベースの PaaS プラットフォーム・ベンダーである Heroku を 2.12 億ドルで買収しました。これは、PaaS が急速に成長し、大きな注目を集めた 1 年の終わりにふさわしい結果でした。それ以来、PaaS を取り巻く活気は高まるばかりです。業界のリサーチを手掛ける Gartner 社は、2011年は「PaaS の年」であると発表しました。Gartner のアナリストである Yefim Natis 氏は、「2015年までには、IT ソフトウェア・プロジェクトによる採用条件のほとんどで、クラウド・プラットフォームの使用経験が必須スキルとして求められるか、望ましい条件の 1 つに挙げられることになるでしょう」と予測しています (「参考文献」を参照)。

PaaS は、プロバイダーがオンデマンドでハードウェアとオペレーティング・システムのサービスを提供するだけではなく、アプリケーション・プラットフォームおよびソリューション・スタックも提供するクラウド・サービスのタイプです。PaaS サービスは、リソースの割り当てからステージングとテスト、ロード・バランシング、データベース・アクセス、そしてプラットフォーム・ライブラリーへのアクセスまで、アプリケーションのデプロイメントに関連する IT 管理のほとんどの側面を自動化します。PaaS の重要な特徴は、マルチテナント型アーキテクチャーであることです。つまり、互いに関連付けられていない複数のアプリケーションを同じハードウェアおよびソフトウェアのインフラストラクチャー上で実行できるので、コンピューティング・リソースのコストを削減し、なおかつより効率的に使用できるというわけです。しかも、開発者はデプロイメントと IT の問題については気にせず、アプリケーションそのものに専念することができます。

Java 開発者には、PaaS 開発モデルを学んで利用するのに適した条件が揃っています。突き詰めるところ、PaaS の概念は初期の頃のサーバー・サイドの Java に深く根ざしているからです。その当時、IT 組織はアプリケーション・サーバーを「コンテナー」として使用し、そこにアプリケーションのアーカイブ・ファイルを投入して、共有リソース環境で実行するという構想に夢中でした (囲み記事「PaaS の先駆け」を参照)。その構想は、現在私たちが目にしている PaaS サービスと非常によく似ています。

しかし、Java エンタープライズ・アプケーションの初期の PaaS 構想は実現しませんでした。複数の関係のないアプリケーションを思いのままにデプロイ、アンデプロイできるようになるほどまで、Java アプリケーション・サーバーが安定することはなかったからです。結局は、アーカイブ構造が Java アプリケーションの開発サイクルにオーバーヘッドをもたらしました。PHP や Ruby on Rails の開発者はコードに手を加えた場合、ブラウザーをリロードすれば、その違いを確認できますが、Java 開発者はアプリケーションを再コンパイルし、再パッケージ化し、再デプロイしなければなりません。さらに、アプリケーション・サーバーを再起動しなければならないことも珍しくありませんでした。

PaaS の先駆け: 自己完結型の Java EE デプロイメント・ユニット

Java サーブレット技術が登場した頃に、Java Web アプリケーションを CGI または PHP アプリケーションと区別していた主要な特徴の 1 つは、Java アプリケーションは必要なものをすべて完備した自己完結型のアプリケーションとして、「Write Once, Run Anywhere (一度書けば、どこでも実行できる)」WAR ファイル内に組み込まれることになっていたことです。実行時も、WAR アプリケーションは自己完結型であると考えられます。アプリケーションには、そのアプリケーションに固有の WAR ファイル内にあるクラスとリソースしか「見えません」。これは、他の WAR ファイルのクラスとファイルに干渉しないようにするためです。アプリケーションのアーカイブ形式は後になって、他のタイプの自己完結型のエンタープライズ・アプリケーション・モジュールを含めるように拡大されました。このような自己完結型アプリケーション・デプロイメント・ユニットは、PaaS にはぴったりです。

結局のところ、PaaS の構想は、JVM よりも遥かに高度な次世代の仮想化技術なしでは実現できません。Google App Engine によって開発された次世代の Java PaaS サービスは、かつての Java EE の約束を果たします。しかも、これらの Java PaaS サービスが提供している、必要な分だけ支払う方式の IT インフラストラクチャーは需要に応じて拡大するため、事前に高価なハードウェアへの投資やシステム管理を行うための投資をする必要はありません。

この記事では、3 つの主要な Java パブリック PaaS オファリング (Google App Engine for Java、Amazon Elastic Beanstalk、CloudBees RUN@Cloud) を検討し、それぞれの手法とその長所、短所を比較します。この 3 つのオファリングが提供する基本的な機能セットは同じです。具体的には、以下の共通機能があります。

  • アプリケーション WAR のアップロードおよびデプロイ
  • デプロイ済みアプリケーションのバージョン管理
  • 環境のテストおよびステージング
  • ログ・ファイルへのオンライン・アクセス
  • 自動監視および使用状況レポート

ただし、以上の共通機能とは別に、重要な違いがいくつかあります。この記事では、これらの新しい技術に取り組んだ私自身の経験から、PaaS を比較する際の枠組みを提示し、PaaS を使用する際の問題回避に役立つと考えられる次善策について検討します。

Google App Engine

GAE (Google App Engine) は、最初に普及した Java PaaS プラットフォームです (Java バージョンは、GAE の Python ベースの PaaS オファリングと区別するために GAE/J と呼ばれることもあります)。また、GAE は基礎となるインフラストラクチャーをほぼ完全に抽象化して開発者に見えないようにするという点で、おそらく市場で「最も純粋な」PaaS オファリングとも言えます。

Java とは言え、完全には Java ではありません

GAE は 2009年から Java プラットフォームを開発およびデプロイメント環境としてサポートしていますが、GAE の Java サポートは限られており、標準に準拠していません。GAE を利用するアプリケーションには多数の制約が課せられることから (その多くは、スケーラビリティーを確保するにはやむを得ないものです)、GAE がサポートしない Java プラットフォーム API もあります。その筆頭に挙げられるのは、ファイル書き込み I/O API (GAE はアプリケーションがアクセス可能なファイルシステムを提供しないため)、そしてネットワーク I/O API の多く (GAE はアプリケーションから開始されるネットワーク操作に厳しい制約を設けているため) です。GAE がサポートする Java プラットフォーム API をすべて網羅した「ホワイト・リスト」については、「参考文献」を参照してください。

GAE は独自の限られたネットワーク I/O API しかサポートしないため、GAE を利用するアプリケーションは自由に他のサービスに接続することが制限されます。また GAE は名目上、アプリケーションから他のサーバーへのアウトバウンド接続を許可しますが、システム内のスレッド数を規制する目的で、アプリケーションが開始した接続を 5 秒から 10 秒後に強制終了します。こうしたことは、サードパーティーの Web サービス API を利用するアプリケーションがますます増え続けるなかで、それらのアプリケーションが GAE を利用する上での大きな制約となっており、マッシュアップ・タイプのアプリケーションにとって、GAE が信頼できないプラットフォームとなる原因になっています。

さらに、これらの API の制約は、既存のアプリケーション・フレームワークを使用したり、既存のアプリケーションを GAE に移したりする必要がある場合に問題となります。現在、エンタープライズ Java 開発は、何年にもわたる進化の結果、フレームワークに大きく依存するようになっています。よく使用されているフレームワークのなかには、Spring や Struts などのように、GAE ですぐに使用できるものもありますが、それ以外の多くのフレームワークは GAE では機能しないか、ソース・コードにパッチが必要になります。GAE で実行できるようにするためにフレームワークのソース・コードに手を加えるのは賢明ではありません。それは実質的に、上方互換性を崩す分岐を作ることであり、デバッグするのが困難なバグをフレームワークに取り込む恐れがあります。その好例は、JSF (JavaServer Faces) Web フレームワークです。このフレームワークを GAE 環境で実行するにはソース・コード・レベルでの手直しが必要であり、GAE 環境で実行できるようになったとしても、JSF をベースとする多くの UI ライブラリーは GAE には対応していません (GAE がサポートする Java フレームワークのリストについては、「参考文献」を参照してください)。

同様に、すでに開発されている大規模なエンタープライズ・アプリケーションは、GAE では禁止されている API を使用している可能性があります。これらのアプリケーションを GAE にマイグレーションするとなると、かなりのコストがかかることになるでしょう。それは、問題を特定して次善策を作成しなければならないだけでなく、アプリケーション全体の品質保証が白紙に戻ってしまうからです。

Java プラットフォーム API の一部をサポートしない GAE は、その点で「一度書けば、どこでも実行できる」という Java の約束を破っています。これが、多くの人々にとって GAE を選択しない主な要因になることはありませんが、これから GAE を使おうと思っている場合には認識しておかなければならないことです。

クラウド・コンピューティングと IBM の PaaS

IBM WebSphere の CTO である Jerry Cuomo 氏へのインタビューを聞いて、クラウドにおける IBM の取り組みを理解してください。Cuomo 氏はこのインタビューでパブリック・クラウド・コンピューティング、プライベート・クラウド・コンピューティング、およびハイブリッド・クラウド・コンピューティングに対する IBM の構想を語り、WebSphere、DB2、MQ を中心とした IBM の PaaS オファリングの計画、そしてクラウドでの標準化の必要性について詳しく説明しています。

スケーラビリティーとパフォーマンス

GAE はスケーラビリティーを約束し、それを実現しますが、それは必ずしも本来のパフォーマンスというわけではありません。Web アプリケーションの場合、本来のパフォーマンスの測定基準は Web リクエストに対する応答時間です。スケーラビリティーとは、システムにアクセスしているユーザー数に関わらず、プラットフォームが一定の応答時間を維持する能力を指します。つまり、スケーラビリティーのあるシステムであれば、例えば 100 人の同時ユーザーに対して 3 秒で応答するとしたら、100 万人の同時ユーザーに対しても 3 秒で応答するということです。

GAE は一定の応答時間という基準では、優れたスケーラビリティーを実現します。しかし、GAE 本来のパフォーマンスとなると、それほど優れていないことは珍しくありません。私自身の経験で言うと、GAE がデータベース関連のリクエストに応答するまでに、大抵は 1 秒から 3 秒かかります。

アプリケーション開発者にとって、この特性によってもたらされる結果は明らかです。それは、実行時間の大部分がアイドル状態の Web アプリケーション (つまり、ほとんどの小規模な Web アプリケーション) を GAE インフラストラクチャーにデプロイしても、ローエンドの仮想プライベート・サーバーに対してすら、パフォーマンス面でのメリットがもたらされないということです。パフォーマンス面で真のメリットがもたらされるのは、ローエンドのサーバー・ハードウェアの容量を遥かに超えてアプリケーションをスケーリングしなければならないような場合においてです。

トラフィック量の少ない Web サイトでのもう 1 つのパフォーマンス面での問題は、GAE はシステム上の高トラフィックの Web アプリケーションのために、非アクティブな JVM をメモリーからスワップアウトすることで最適化を行うことです。JVM がメモリーからスワップアウトされると、GAE は次にリクエストが到達した際に、アプリケーション全体を起動するのに余分に時間をかけなければなりません。低トラフィックの Web アプリケーションの場合、これが低パフォーマンス (最初のリクエストに対する応答を待機する時間が 5 秒を超えること) を招く結果となります。GAE では、より安定したパフォーマンスを実現するために、非アクティブな JVM をメモリーに保持する有料のオプションを開発者に用意しています。ヒント: 2 分から 3 分間隔で Web サイトをロードするクーロン・ジョブを GAE 内にセットアップすると、JVM をアクティブな状態に維持することができます。

BigTable の利点と欠点

GAE の鍵となっている革新は、極めてスケーラブルなデータ・ストアである Google BigTable を使用していることです。大抵の Web アプリケーションはリレーショナル・データベースをデータ・バックエンドとして使用しますが、リレーショナル・データベースはスケーリングするのが困難なことで知られています。この問題を解決するため、Google の研究者たちはリレーショナル・データベースに代わるデータ・ストレージ・ソリューションを開発しました。それが、BigTable です。BigTable は、NoSQL データベース分野でのデータ・ストレージ・ソリューションの 1 つに数えられています。

リレーショナル・データベースと同じく、BigTable ではデータを行と列からなるテーブルに分けることができます。各行には一意のインデックス ID が付けられます。けれどもリレーショナル・データベースとは異なり、BigTable の場合、それぞれのテーブルに固有のスキーマはなく、通常は非正規化されます。したがって、テーブルには行によって異なる列が含まれる場合もあります。そこでベスト・プラクティスとされるのが、さまざまなテーブル間で各行をキー列によって関連付けるのではなく、1 つの行に含める列の数を多くすることです。これは、データ・モデルの設計に大きな影響を及ぼすこととなります。アプリケーション開発者には、正規化されたリレーショナル・モデルを設計するのではなく、検索を容易にするためにそれぞれの行内に重複した情報を格納することが推奨されるようになります。例えば Web サーバーのアクセス・ログを考えてみてください。すべての行に IP アドレスとブラウザー・エージェントが繰り返されているとしたら、場所は取るものの、一括処理が単純化されることになります。

BigTable の利点はスケーラビリティーです。Google のエンジニアたちは、BigTable でのデータ・クエリーに対する応答時間を決定する唯一の要因は、結果として返されるデータ・セットのサイズだけであると断言しています。つまり、クエリーの対象が 1000 行のテーブルであろうと、1000 万行のテーブルであろうと、結果が 1000 行に制限される限り、同じパフォーマンスが維持されるということです。GAE としては、各クエリーで返されるデータ・セットを 1000 行に制限しています。

SQL のバックグラウンドを持つ開発者にとって、NoSQL のパラダイムに適応するのは難しいかもしれません。けれども、Big data の問題に直面する IT 組織がますます増えている今、NoSQL のパラダイムに適応するスキルを身に付けることは非常に重要です。私は Java 開発者が NoSQL を学ぶには、GAE が絶好の近道になると思います。

その一方、BigTable は GAE が極めて高いスケーラビリティーを実現する上で重要な役割を果たしているものの、Java 開発者がその現行の実装に足りないと感じるところはたくさんあります。具体的に言うと、BigTable の欠点 (そして考えられる次善策) としては以下の 2 点が挙げられます。

  • データ・クエリーのサポートが十分でないこと: BigTable からデータを取得するには、GQL (Google Query Language) で記述したクエリーを使用します。GAE では、クエリーに関連するすべてのデータ列にインデックスを付けなければなりません。しかも、インデックスには BLOB やテキスト列を含めることができません。それはそれで問題ありませんが、GAE でテーブルごとに付けられるインデックスは最大 100 に制限される点が問題です。この数は、標準的な SQL データベースには十分かもしれませんが、BigTable のような非正規化された NoSQL データベースには数千もの列が含まれることもあるため、多くのアプリケーションでインデックスが足りなくなる可能性があります。さらに悪いことに、GAE には使用されなくなったインデックスを簡単に削除する方法がありません。

    GAE 開発者にとって、どの列にインデックスを付けるべきかを決めるのは大きな負担です。インデックスが付けられていない列の組み合わせがクエリーで使用されていても、GAE は実際にクエリーを実行する時まで例外をスローしません。SDK には、アプリケーションをローカル・コンピューターでテストするときに自動的にインデックス構成ファイルを生成するツールが用意されていますが、それでも、ありとあらゆる実行パスを手動でテストしなければ、必要なインデックスを付け損なう可能性があります。自動生成されたインデックスをデプロイ済みのアプリケーションにマージする作業も、インデックスを誤って構成しがちなプロセスです。しかも、誤って構成されたインデックスに Web アプリケーションのユーザーがアクセスするまでは、そのことに気付くことはありません。

    最後に、これが Google の製品であることを考えると多少衝撃的なことですが、BigTable はデータベースのフリー・テキスト検索をサポートしていません。Apache Lucene などの検索エンジン実装をアプリケーションに組み込めば、テキスト列にインデックスを付けて検索することができます (「参考文献」を参照)。けれどもそれでは、単純なテキスト検索には標準的な SQL の LIKE 文で事足りるような小規模の Web サイトには面倒過ぎます。

  • データのインポート、エクスポートが難しいこと: BigTable に伴うもう 1 つの大きな問題は、データをインポート/エクスポートする機能が用意されていないことです。BigTable に直接アクセスするための標準 API がないことから、データをインポートまたはエクスポートするには、データ・インポート・ロジックとデータ・エクスポート・ロジックをアプリケーション内部のサーブレットに書き込み、その上で独自の Web インターフェースを使用しなければなりません。

    GAE はあらゆる Web リクエスト・スレッドを 30 秒後に強制終了します。したがって、大きなデータ・セットを永続的な接続でアップロードすることはできません。一般的な次善策は、インポートするデータを分割して、それぞれのチャンクを 30 秒以内にアップロードして処理できるようにすることです。そうすれば、JMeter や Grinder などの自動 HTTP ドライバーを使用して、すべてのデータがインポートされるまでチャンクを 1 つひとつインポートすることができます。しかし言うまでもなく、これは面倒なプロセスです。

    BigTable からデータをエクスポートするとなると、さらに問題は深刻になります。API は各データ・クエリーの結果を 1000 件に制限するため、エクスポート・データは、30 秒の処理タイムアウト制約で許容されるサイズよりも小さなチャンクで管理しなければならないからです。

これらの BigTable の欠点がほとんどの開発者にとって制約となることを認識している GAE では、有料のビジネス・オファリングにより、ホストされた MySQL サービスを利用できるようにしています。

他のサービスとの統合

GAE と Google の他のサービスとの相性は抜群です。特に、GAE アプリケーションでは Google アカウントを利用できるようになっており、ユーザーが Google に登録したユーザー名とパスワードを使ってアプリケーションにログインできるようになっています。ユーザー管理システムの構築は、あらゆる Web サイトが行わなければならない重複する作業であることを考えると、Google アカウントを利用できることは大幅な時間の節約となります。その一方で欠点もあります。それは、すべてのユーザーが Google アカウントを持っているわけではないこと、そして Web サイトを Google アカウントに結び付けると、後で別の PaaS プロバイダーに移行するのが難しくなることです。

GAE アプリケーションはまた、単純な API を使って GMail サーバー経由で E メール・メッセージを送信することもできます。セキュアではない SMTP サーバーと比べ、GMail サーバーが受信側 ISP によってブロックされる可能性は大幅に低くなります。

ドメインを Google Apps にホストする場合、Google Apps アカウントを GAE アカウントに結びつけることで、管理下にある任意のサブドメインからアプリケーションにアクセスできるように構成することも可能です。例えば、mydomain.com というドメインが Google Apps でホストされているとすると、mydomain.appspot.com ではなく、www.mydomain.com からアプリケーションにアクセスできるようにすることができます。

判定

全体的に見て、GAE は適切に設計されたスケーラブルな PaaS となっています。また、小規模な Web サイトに提供されている寛大な無料枠も魅力です。その一方、完全な Java プラットフォームとしてのサポートが不十分であることが、GAE を選択する妨げとなる可能性があります。さらに GAE の一部のコンポーネントは本番レベルというよりも、まだ実験的な段階であるという感があります。


Amazon Elastic Beanstalk

Amazon Elastic Beanstalk は Amazon Web サービスによる比較的新しいオファリングです。Beanstalk は Amazon EC2 (Elastic Computing Cloud) インフラストラクチャーをベースとして、管理された Apache Tomcat ランタイム環境を提供します。EC2 は IaaS (Infrastructure-as-a-Service) オファリングであるため、Beanstalk の柔軟性は GAE よりも遥かに優れています。ただしそのトレードオフとして、Beanstalk では、アプリケーションを管理およびスケーリングする際の開発者側の作業が増えることになります。

Pure Java 環境である Tomcat

Beanstalk 環境は、EC2 仮想サーバー上で稼働する Tomcat サーバーを完全にサポートします。Tomcat はそのベースにあるファイルシステムにアクセスできる Pure Java 環境です。Tomcat は広く普及していることから、ほとんどすべてのエンタープライズ Java フレームワークは、Tomcat のデプロイメントをサポートしています。Tomcat のデプロイメントをサポートするフレームワークは Tomcat の WAR ファイルから起動またはブートストラップすることができるため、フレームワークおよびライブラリーの選択肢が大きく広がります。

Tomcat ランタイムそのものには、スレッド化とファイル I/O またはネットワーク I/Oに関する制限がありません。ネットワーク I/O スレッドは、必要とされる限りオープン状態を維持することができます。そこに制限を課すのは、そのベースにある仮想マシンの容量だけです。

スケーリングするには犠牲を伴います

Beanstalk はアプリケーションをスケーリングするために、自動的に新しい EC2 インスタンスを起動して、そのインスタンスに WAR ファイルをデプロイします。Beanstalk のすべての EC2 インスタンスは、ロード・バランサーの背後で実行されます。各 EC2 インスタンスで使用可能なリソースを監視して、既存のサーバーの負荷が事前に設定された限度を超えた時点で自動的にロード・バランサーの背後に新しいサーバー・インスタンスを起動するルールをセットアップするには、Web ベースの管理コンソールを使用することができます。

ロード・バランシングされた Web クラスターに共通の問題は、HTTP セッションをどう処理するかです。各 Tomcat サーバー・ノードは、それぞれのクライアントのためにセッション・オブジェクトを作成して管理します。そのため、Web リクエストの負荷が複数のサーバー・ノードに分散される場合には、リクエストに対処するサーバー・ノードに、適切なセッション・オブジェクトが必ずあるようにしなければなりません。その最も簡単な方法は、「スティッキー・セッション」をロード・バランサーで有効にして、ロード・バランサーにその背後にある各サーバーが維持するセッション cookie を記憶させ、着信 cookie に応じて適切なサーバーにリクエストを転送させるようにすることです。「スティッキー・セッション」は、Beanstalk のロード・バランサー管理コンソールで有効にすることができます。さらに効率的で確実なソリューションには、サーバー・ノード間で共有するメモリーをセットアップする方法、あるいは単純にセッション・オブジェクトを中央データベースに保存する方法もあります。これらの方法を使用すれば、すべてのサーバー・ノードが同じセッション状態情報を持つことになるため、ロード・バランサーがランダムなサーバー・ノード、または最もビジーでないサーバー・ノードにリクエストを転送することができます。けれども、いずれのオプションにしても、アプリケーション開発者側での作業が必要となります。セッション・データを自動的に BigTable に保存する GAE とは異なり、Beanstalk では開発者がセッション・データを保存するすべての作業を行わなければなりません。

Beanstalk の最大の欠点の 1 つとしては、その価格が挙げられるでしょう。これは、他で無料のホスティング・サービスを受けられる小規模な Web サイトにとっては、とりわけ大きな欠点です。Amazon EC2 では、新規のサインアップに対して「一年間無料」のプログラムを提供しているものの、Beanstalk の標準料金設定は単一ノードのセットアップでさえも月々 40 ドル近くに上ります。この価格は、必要に応じて短時間で自動的にスケールアウトできるクラスター対応のインフラストラクチャーとしては手頃ですが、時折トラフィックが急増するだけで、ほとんどアイドル状態のアプリケーションには、GAE のオファリングと比べると高額です。

柔軟なデータベースの選択肢

Elastic Beanstalk プラットフォームの長所の 1 つは、データベース技術を柔軟に選べることです。選択肢には以下に挙げるものがあります。

  • リレーショナル・データベース: Amazon 独自の RDS (Relational Database Service) では、多種多様なリレーショナル・データベースをデプロイすることができます。これらのデータベース・サーバーは、Amazon によって管理および監視されており、データのインポートおよびエクスポートを簡単に行えます。アプリケーション内で必要な作業は、データ・ソースを RDS サーバーに配置することだけです。ただし、それぞれの RDS インスタンスは、皆さんのデータベースを実行するための専用サーバー・インスタンスであることに注意してください。このため、データベース・インスタンスの料金は、同等の EC2 インスタンスの 30 パーセント増です。これだけのコストをかけるのが妥当な場合もありますが、専用データベース・サーバーが必要なアプリケーションは多くありません。
  • NoSQL: RDS サーバーに伴う問題の 1 つは、これがスケーリングの困難なリレーショナル・データベースであることです。Google BigTable と同様の NoSQL 手法をお望みの場合には、Amazon SimpleDB を使用することもできます。SimpleDB の Java API では、アプリケーションが容易にデータにアクセスできるようになっています。
  • 独自のデータベース・サーバー: EC2 では仮想サーバーをそのまま利用できることから、必要なのは独自のデータベースまたは NoSQL データ・ソース (Apache Cassandra など) を別個の EC2 インスタンスにセットアップし、Beanstalk アプリケーションがその独自のデータベース・サーバーを使用するように設定することだけです。

データベースを選択する際の柔軟性は、特に Amazon が管理するリレーショナル・データベースも使用できるという点で、エンタープライズ開発者の興味を引くはずです。

他のサービスとの統合

Amazon RDS と SimpleDB に加え、Beanstalk サーバーは他の Amazon サービス (Simple Queue Service、S3 Storage、SES (Simple Email Service)、決済 API など) も利用することができます。なかでもとりわけ興味深いサービスは SES です。これは、GAE の GMail API と比較するにはもってこいです。

SES に用意されている単純な API を使用すると、Amazon の SMTP サーバーを使用して E メール・メッセージを送信することができます。独自の EC2 インスタンスにセキュアでない SMTP サーバーをセットアップする代わりに、Amazon SMTP サーバーを使用する利点は、Amazon サーバーは主要な ISP のスパム・フィルターによってブロックされる可能性が低いことです。この目的のために SES が提供している豊富なツールでは、E メールのボリューム増加を制御したり、ISP スパム・フィルターからのフィードバックを受信したりすることができます。これらの機能はすべて、Beanstalk アプリケーションから使用可能になります。そのため、E メールを使った一連の活動を監視して、E メールの内容を最適化することで、より効率的な E メールを配信することができるようになります。

判定

概して、Amazon Elastic Beanstalk は Tomcat アプリケーションのデプロイメントとスケーリングを大幅に単純化します。それと同時に、ベースとなる EC2 インフラストラクチャーの柔軟性を損なうこともないため、エンタープライズ・アプケーションには最適です。ただし、トラフィック量の少ない Web サイトや趣味で開発を行っている人にとってはコストは高くつきます。


CloudBees RUN@Cloud

Java PaaS の世界に新たに参入した CloudBees という会社は、誕生したばかりかもしれませんが、会社を支える人々はエンタープライズ Java のベテラン揃いです (会社を設立した JBoss の元 CTO、Sacha Labourey 氏に加え、オープンソース Java の 2 人の大物 (JBoss で有名な Adrian Brock 氏と Hudson で有名な川口耕介氏) が所属しています)。CloudBees の PaaS 技術は、ホストされた Java アプリケーション・サービスを 10 年以上にわたって企業の顧客に提供してきた Stax Networks から買収されました。堅牢な Stax プラットフォームをベースとする CloudBees RUN@Cloud サービスは、セルフサービス Web ポータルから個人の開発者が利用することができます。

主流のサービスと比べると、RUN@Cloud は (GAE での) 管理しやすいスケーラビリティーと (Amazon の PaaS サービスでの) 柔軟性の間で適度なバランスを見出しています。またその一方で、プラットフォームを通じて、開発ライフサイクル全体にわたって独自の工夫を凝らしたサポートを加えています。

堅牢な Java ランタイム

現在、EC2 インフラストラクチャーをベースとしている RUN@Cloud サービスは、Beanstalk と RDS を組み合わせて自動化を一層進めたサービスと見なすことができます。Beanstalk と同じく、RUN@Cloud も、Web アプリケーションごとに EC2 仮想サーバー上で稼働する専用 Tomcat インスタンスを提供します。また、ファイルシステムへのアクセス、ネットワーク I/O、スレッド化に関する人為的制約が一切ない、Pure Java 環境となります。

RUN@Cloud が持つ、独立した小さな企業としての強みの 1 つは、Amazon に束縛されていないことです。RUN@Cloud には、近い将来、他のインフラストラクチャー・プロバイダーで EC2 を補う計画があります。

無料のスケーラブルなインフラストラクチャー

同じく Beanstalk との共通点として、RUN@Cloud はロード・バランサーを使用し、サーバー・インスタンスをオンデマンドで起動してトラフィックの急増に対応するスケーラブルなインフラストラクチャーを提供します。ただし、RUN@Cloud は Beanstalk よりも自動化されています。例えば、「スティッキー・セッション」を使用する代わりに、RUN@Cloud での Tomcat サーバーはすでに、その管理下にあるデータベースにセッションを保存するように構成されています。この管理されたセッション・オブジェクト・データベースは、開発者には見えないようになっています。この点は、GAE とよく似ています。

RUN@Cloud は、単一の EC2 インスタンス上で稼働する複数の Tomcat サーバーを、共有ロード・バランサーを使って管理できるため、Tomcat インスタンスごとに 1 つの EC2 インスタンスを用意する必要がありません。したがって、低トラフィックの Web サイトを Beanstalk よりも遥かに低いコストで実行することができます。実際、RUN@Cloud には、低トラフィックのアプリケーションや、趣味で開発を行っている人、学生などに最適な無料の使用枠があります。

その一方、RUN@Cloud も GAE のように、アプリケーションが長時間非アクティブの状態になっていると、リソースを確保するために JVM をメモリーからスワップアウトします。これにより、最初のリクエストに対してはアプリケーションが「ウォームアップ」するため、レスポンスが遅くなることがあります。

ホストされた MySQL リレーショナル・データベース

RUN@Cloud サービスは Tomcat サービスと併せ、管理された MySQL サービスもネイティブにサポートします。データベースを作成および管理するには、Web ベースの管理コンソールを使用することができます。さらに、MySQL クライアントからデータベース・サーバーに直接接続してデータを管理することができます。

Amazon RDS とは異なり、RUN@Cloud サービスは複数のアプリケーションで共有するデータベース・サーバーをデプロイします。アプリケーションはそれぞれに独自のデータベースを使用することができますが、必ずしも専用サーバーが必要というわけではありません。PaaS プラットフォームは、データベース・サーバーのプールを最大限活用するようにデータベースを自動的にデプロイします。RDS とは対照的に、共有データベース・サーバーを使用することで仮想サーバーの使用効率が上がり、したがってコストも低くなります。

他のサービスとの統合

RUN@Cloud では、ベースにあるインフラストラクチャー・プロバイダーがサポートするプラットフォーム API およびサービスにアクセスすることができます。つまり、Amazon EC2 にデプロイされた RUN@Cloud アプリケーションの場合には、アプリケーション内部から S3、SQS、SES などの Amazon Web サービス API のすべてをフルに利用できるということです。

しかし、RUN@Cloud が本領を発揮するのは、クラウド・ベースの継続的インテグレーション・プラットフォームである DEV@Cloud との密な統合においてです。DEV@Cloud はソース・コードのバージョン管理システム (Subversion および GIT)、ビルド・リポジトリー (Apache Maven)、そしてビルド・サーバー (以前は Hudson と名付けられていた jenkins) を提供し、開発者のコンピューター上ではなく、クラウドでアプリケーションを自動ビルドおよびテストすることを可能にします。このような中央ビルド・システムは、リポジトリー内のソース・コードが常にテストされてリリース可能な状態であることを確実にするために、アジャイルなソフトウェア・チームの間で広く採用されています。

RUN@Cloud と DEV@Cloud を統合することにより、エンタープライズ Java Web アプリケーションの開発、テスト、デプロイメントのサイクル全体を管理できる、強力な PaaS サービス一式が揃います。自分のコンピューターでソース・コードを編集すれば、後のことはすべて、クラウド内にある自動システムに任せておけるので、IT のオーバーヘッドが最小限になります。

判定

CloudBees RUN@Cloud は、Amazon Elastic Beanstalk と RDS に代わる低コストの (場合によっては無料の) 手段です。さらに、RUN@Cloud と継続的ビルド・システムとの統合は、開発プロセスにおける IT の役割をすべて自動化したいと望んでいるアジャイルなソフトウェア開発チームにとって強力な魅力となります。


まとめ

失意の年を繰り返した末、Java PaaS サービスはついに全盛期を迎えました。この記事で比較検討した 3 つのサービスにはそれぞれに独特の手法があり、それ故に、独特の長所と短所があります。

新しいアプリケーションを開発していて、GAE の制約を受け入れられるとしたら、無料の GAE は絶好の選択肢となります。RUN@Cloud と Elastic Beanstalk はアプリケーション・レベルで交換可能なランタイムです。つまり、標準 Java EE アプリケーションはどちらのプラットフォームでも変更なしで実行することができます。導入するには RUN@Cloud のほうが安上がりで、構成するのも簡単です。また、RUN@Cloud の場合、継続的インテグレーション式の開発プロセスに対するサポートは抜群です。まずは、RUN@Cloud を無料で使用するところから始めることをお勧めします。CloudBees のサービスに満足できなければ、簡単に Elastic Beanstalk に移行することができます。

参考文献

学ぶために

  • Gartner Says 2011 Will Be the Year of Platform as a Service」: この Gartner のプレス・リリースからも明らかなように、PaaS を取り巻く活気は高まり続けています。
  • Consider PaaS in Your Cloud Strategy」: Gartner のアナリスト、Yefim Natis 氏が PaaS を支持するプレゼンテーションを行っています。
  • Google App Engine for Java: GAE for Java は、最初の Java PaaS オファリングの 1 つです。
  • Amazon Web サービス: Amazon Web サービスは、Elastic Beanstalk、Elastic Compute Cloud、Relational Database Service、SimpleDB、Simple Email Service を含め、一連の相互に関連したサービスを提供しています。
  • CloudBees: CloudBees の DEV@CloudRUN@Cloud には、どちらも小規模な Web サイト用に無料枠が用意されています。
  • 連載「Java 開発 2.0」: Andrew Glover が developerWorks に連載している記事で、Google App Engine、BigTable、および Amazon Elastic Beanstalk の導入方法を説明しています。
  • Google App Engine for Java」: Richard Hightower の 3 部からなる記事で、GAE 対応の Java アプリケーションを構築する方法を調べてください。
  • JRE クラスのホワイト・リスト: Google による、GAE でサポートされている Java プラットフォーム API の公式リストです。
  • WillItPlayInJava: よく使われているフレームワークのそれぞれに対する GAE のサポート状況を調べてください。
  • Technology bookstore で、この記事で取り上げた技術やその他の技術に関する本を探してください。
  • developerWorks Java technology: Java プログラミングのあらゆる側面を網羅した記事が豊富に用意されています。

製品や技術を入手するために

  • Apache Lucene: BigTable で Lucene を使用すると、独自のテキスト検索エンジンを作成して、GAE アプリケーション内で検索クエリーを実行できるようになります。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。プロフィールで選択した情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Java technology, Cloud computing, Open source
ArticleID=650785
ArticleTitle=Java PaaS の比較
publish-date=04052011