Google App Engine、Java対応についての賛否

作者 Scott Delap , 翻訳者 ガーナー 淳子 投稿日 2009年4月22日

セクション

運用/インフラ,

デベロップメント,

設計/アーキテクチャ

トピック

Java ,

クラウドコンピューティング ,

クラスタリング&キャッシング

原文(投稿日：2009/4/8)へのリンク

Googleは、Google App Engine（GAE）のサポートを拡大し、Pythonに加えJavaも含めることとした。この追加により、多数のJavaエコシステムに関連したツール、フレームワーク、言語（JRubyやClojureなど）が伴われることとなった。しかしこのことは、最小労力で調整と連結を行うGoogleの追加的な機能に対してGAE Javaアプリケーションにいくつかの制限を強いることとなっている。公式のGoogleブログ(リンク)では、Javaサポートについて次のように概要が述べられている。

我々はディベロッパに歓迎されるものを提供したいと考えたが、Google App EngineのシンプルさとJavaプラットフォームの性能および柔軟性を結合しなくてはならないことを認識していた。また既存のJava規格およびツールとの互換性を保ったまま、App Engineインフラストラクチャ（および拡張Googleインフラストラクチャ）を最大限に活用することを望んでいた。

そしてそれこそが我々が行ったことなのである。App EngineはJavaツールを優れたものにする規格をサポートしている（我々はGoogle Plugin for Eclipseによってツールに取り組んでいる）。これは現行のApp Engine APIを備え、Java Servlet API、JDOおよびJPA、javax.cache、そしてjavax.mailといった適切な標準規格でラップしている。またセキュアなサンドボックスも備えており、これは自在にアブストラクトを中断するのに十分な柔軟性を持ちつつも、Googleのサーバ上でディベロッパ自身のコードをセキュアに実行できる性能がある。

CNetは、GAEはJava 6を実行するとしている。しかし先に触れたように、JavaがGAEモデルに適合するよう強いるいくつかの制限が課せられている。GAE JavaはJava 2.4 Servlet APIをベースとしており、

• リクエストが一旦クライアントに送られると、それ以上の処理がなされない。これはデータ・ストリーミングも含んでいる。
• リクエストが30秒程度で完了しない場合は、中断される。現段階では例外処理される。キャッチされない場合は、ユーザに500エラーが返される。

スタックを上へ移動することは、いくつかあるサンドボックスの制限事項である。

• アプリケーションはファイル・システムに書き込むことができず、代わりにApp Engineデータストアを使用しなくてはいけない。
• アプリケーションはソケットを開くことができない。
• アプリケーションはそれ自身のスレッドを作成できないか、タイマといった関連ユーティリティを使用できない。

java.lang.Systemは以下のように制限される。

• exit()、gc()、runFinalization()、そしてrunFinalizersOnExit() は機能しない。
• JNI アクセスはできない。

これらのキー事項に加え、JREクラス・ローディング・ホワイトリストに代表される、その他の制限がある。説明資料では、GAEはカスタム・クラスローダを使用した多くのマジックを強いているように見受けられる。しかし、前述したような制限で稼動できる限りは、他のアプリケーション・レベル・クラスローダを許容すべきである。

2つ目の当然の疑問は、先に触れた制限が、GAEアプリケーションのメリットという観点からユーザに何を提供するかということだ。まずはスケーラビリティである。App Engineは複数のウェブ・サーバを用いてアプリケーションを実行し、リクエストを確実に処理するために使用するサーバの数を自動的に調整する。あるリクエストは任意のサーバに送られるが、それは同じユーザの以前のリクエストを処理したのと異なるサーバである可能性がある。説明文書には次のようにある。

…アプリケーションは約30のアクティブな動的リクエストを並行して処理できる。つまり、サーバ側のリクエスト処理時間が平均75ミリ秒であるアプリケーションは、(1000 ミリ秒/秒  /  75 ミリ秒/リクエスト)*30で1秒あたり400のリクエストまで待ち時間を招くことなく応えることができる。CPUバウンドの比率が高いアプリケーションは、他のアプリケーションが同一サーバをシェアする余地を設けるため、長期のリクエストにおいて多少の待ち時間を追加的に招く可能性がある。この制限は静的ファイルに対するリクエストには影響を与えない…

GoogleはJPOおよびJPAのBigTableサポート版やより容易なGAE開発を促進するGoogle Plugin for Eclipse(リンク)も提供する。

Googleは開発期間中にも多数のディベロッパ達にGAEを体験してもらっていた。Paul Hammant氏はその性能を試し、多くの見解を残した(リンク)。

…同一クライアントからの複数の同時リクエストは、バック・エンドで必ずしも同じサーブレット・コンテナに達するわけではないということに留意されたい。それは一見同じドメイン名からのように見えるが（リソースの転送は起こらない）、異なるサーブレット・コンテナ・インスタンスがそのリクエストに応答する可能性が極めて高い。これは適切に記述されたステートレス・アプリケーションにとって問題とはならないが、ストア属性のセッションを活用するアプリケーションは、そのマップ内で同一の論理リソースに2つ書き込むことによる並列処理の問題に遭遇する可能性がある…

…Googleは徹底したサンドボックスを実装した。それはおそらく悪意のあるコードから保護するためである。…XStreamはJavaコミュニティに特に好まれるものである。最新バージョンは1.3.1で、GAEが例外を投げる領域内であればどこでも初期化される。

Clojure(リンク)、JRuby(リンク)、そしてGroovy(リンク)で稼動させることができたエンジニアもいる。ThoughtWorks Ola Biniは、動的言語でのGAE運用について詳細をブログに投稿(リンク)した。

• 次へ >