GAE/Jはサーバ構築いらず、簡単デプロイ
（この記事は、日経BP社「ITpro」向けに書いたものを再掲しています）
ご都合.comの開発を通じてもっとも感銘を受けた点は、「サーバ環境の構築とデプロイの簡単さ」です。ここでは細かな手順の説明は省略しますが、GAE/Jによるシステム開発は以下の流れとなります。
- GAE/Jにサインアップする
- GAE/JのEclipseプラグイン（Google Plugin for Eclipse for App Engine development）をインストールする
- Eclipse上でGAE/JのAPIに基づくJavaアプリケーションを開発、テストする
- EclipseからGAE/Jへデプロイする
GAE/Jは、他のクラウドサービスや通常のサーバホスティングサービスとは異なり、「サーバ環境」ではなく「Webアプリの実行環境」を提供するサービスです。例えばアマゾンのクラウドサービス「Amazon EC2」は、おおざっぱに言えば「VPS（Virtual Private Server）」であり、利用者はEC2が提供する仮想サーバ上にログインし、ミドルウェアやアプリケーションのデプロイや設定を自ら実施する必要があります。これに対しGAE/Jは、TomcatやJBossに相当するGoogle独自のアプリケーションサーバがすでに稼働している環境があり、そこに利用者のWebアプリをデプロイして利用します。
この形態には以下のような一長一短があります。
【メリット】
- サーバ構築（OS、ミドルウェア、APサーバ、データベース、ネットワーク等のインストールや設定）が一切不要
- 1クリックでデプロイできる
【デメリット】
- Webアプリが独自の「サンドボックス」内部で動作するため、そのさまざまな制約を受ける
これらのうち、とりわけ「サーバ構築が一切不要」というメリットは、大幅な開発コスト削減をもたらします。いまどきのOSSベースのシステム開発では、OSやミドルウェア、APサーバ、DBといった個別のソフトウェアのインテグレーション作業に時間がかかるうえに、システム障害の原因となる大きなリスクとなります。GAE/Jでは、そうしたコストやリスクを回避できます。例えば今回、筆者はご都合.comの構築をほぼ5日（開発とドキュメント作成）で実施しましたが、もしいつも通りのサーバ構築をゼロから始めたならば、面倒なインストール作業やメモ作成、微調整などで、あと2日は余計に時間がかかったはずです。
GAE/Jが提供する実行環境では、おもに以下のようなAPIを利用できます。
| 名称 | 内容 |
| Java Servlet / JSP | サーブレットとJSPの実行環境（GAE/J独自のサンドボックスによる制限を受ける） |
| Datastore Java API | Bigtableによるデータストア機能を提供するJDOベースのAPI |
| Logging API | java.util.loggingによるログ機能 |
| Memcache Java API | JCache APIベースの分散メモリキャッシュ機能 |
| URL Fetch Java API | 外部サーバへのhttp/httpsリクエスト送信機能 |
| Mail Java API | JavaMail APIベースのメール送信機能 |
| Images Java API | 独自APIによる画像処理機能 |
| Google Accounts Java API | 独自APIによるGoogleアカウントのシングルサインオン機能 |
GAE/Jが提供するおもなAPI
開発者は、GAE/JのEclipseプラグイン「Google Plugin for Eclipse for App Engine development」をインストールすることで、これらのAPIによるコーディングとビルド、テストをローカル環境で実施し、ボタンクリック1つでWebアプリをGAE/Jの実運用環境にデプロイできます。これはPHPやRuby on RailsといったLL系システムと同じ程度のお手軽さで、ここ3年はRails一辺倒であった筆者も「この手軽さならまたJavaに戻りたい」と思うほどです。
EclipseによるGAE/J対応Webアプリの開発
ちなみに、ローカル環境と実際のGAE/J環境には微妙な振る舞いの差があり、たとえば今回Flexとサーバ間の接続に使用したミドルウェア「Adobe BlazeDS」は実行環境でのみうまく動作せず、パッチ適用と再ビルドが必要でした。
また、GAE/Jには「独自のサンドボックスによる制限を受ける」というデメリットがあります。具体的には、以下のような制約が課せられます。
- サーブレットによる30秒以上を要するリクエスト処理
- サーブレットによるレスポンス送出時のデータストリーミング
- ファイルシステムへの書き込み
- 外部サーバへのソケット接続
- スレッド生成
- ガベージコレクション実行やシステム停止
- カスタムクラスローダの利用
例えば、サーブレットが個々のリクエスト受信からレスポンス送出までには30秒という時間制限があり、それを超えるリクエストはHTTPステータス500番のエラーが発生して中断されます。また、レスポンスデータを段階的にストリーミング送信することはできませんので、例えばCometサーバのような疑似プッシュは実装できません。もっとも、いわゆる普通のWebアプリであれば、これらはそれほど大きな制約にならないと思われます。
ご都合.comの事例では、上述したBlazeDSに備わるサーブレットがデフォルトではJMX API（Java EEの管理用API）を用いる設定になっており、サンドボックスによる例外が発生していました。そこでJMXを使わない設定に変更し、サンドボックス内で問題なく動作させることができました。そのほか、サーバ機能の実装に際して特に不都合を感じた点はなく、特別なことさえしなければ“ごく普通のWebアプリプログラミング”が可能という印象を受けました。
以上、本稿では「ご都合.com」の開発事例を通じて、GAE/JによるWebアプリ開発の実際とそのポテンシャルを解説しました。筆者はとりわけ「Bigtableがあまりにも簡単に使える」こと、そして「サーバ構築が不要、ワンクリックでデプロイできる」という点に驚嘆しました。「クラウドコンピューティング」が、単なるbuzzwordではなく本物の「進化」であると実感できたことが、この連休中に得られた大きな“収穫”でした。
