第1回 Google App Engine上でLL＋RDBアプリを作ろう

これまでの手法が通用しないGAEの制限

　しかしながら、GAEがサポートする言語のWebアプリケーションであれば、いままで利用してきたものがそのまま動くのかというと、残念ながら答えはノーです。

　GAEを活用していく上で開発者が知っておくべき制限について説明します。

　GAEにおける主な制限には、以下のようなものがあります。

・応答時間の30秒制限

　リクエストからレスポンスまでの応答時間は30秒以内です。30秒以上を要するリクエストは、GAEによって強制的に切断されます。

・ファイルシステムへのアクセス制限

　ファイルシステムへのアクセス（アプリケーション内でのファイルの生成）は行えません。ストレージとして、BigTableというデータストアが用意されており、これを利用します。

・外部サーバとの接続不可

　GAEの外部との通信を、独自のソケットを開いて行えません。例えば、アプリケーション自体をGAE上に配置し、そこから自分たちが管理するデータベースサーバにアクセスさせるような構成を取れません。

・独自のデータストア、BigTable

　これは、制限とは少し意味合いが異なりますが、データの永続化に、いわゆるkey-value型データストアのBigTableを利用します。リレーショナルデータベースは提供されておらず、外部サーバとの通信にも制限があるため、原則としてGAE上でのデータの永続化はBigTableを前提として行います。

　これらはどれも、不特定多数のユーザーがインフラを共有することへの配慮（サンドボックスにすることで安全性を高める）、スケーラビリティの確保（BigTableはGoogleの各種サービスのスケーラビリティの要となる非常に優れたテクノロジです）を目的としたものです。GAEの性質を考えれば、妥当なものばかりであるともいえます。

　これまで長い間、データの永続化手段にはリレーショナルデータベースが利用されてきました。しかし、GAEでWebアプリケーションを開発するということは、アプローチを変えて、BigTableを前提とした設計・実装が必要になることを意味します。

　「GAEではリレーショナルデータベースが使えない」ことが大きなハードルになって、いままで利用してきたWebアプリケーションを、そのままでは動かせないのです。

　例えば、GAE上でJRubyを利用して、Ruby on Railsアプリケーションを稼働させるアプローチが、Rubyistの間で注目されています。しかし、GAEではRailsの大きな特徴の1つであり、フレームワークとしてのアドバンテージでもあるActiveRecordが、そのままでは使えません。

　同じくPHPの世界でも、GAEではPear::DBをはじめとする、リレーショナルデータベース接続ライブラリが使えません。

　これが原因で、GAE上のRails／PHPに興味・関心を持っていても、いまのところは様子見をしているという方も多いのではないでしょうか。リレーショナルデータベースの有無は、大きなインパクトなのです。

　もちろん、Webアプリケーションのフレームワークやアーキテクチャの設計において、永続化層の実装になるべく依存しないような設計を考えることは常識的なこととされてきました。

　しかしながら、つまるところ多くのデータ永続化アーキテクチャは、リレーショナルデータベースの存在を大前提としたものであり、永続化層そのものが変わってしまうことは、ほとんど考慮されていません。

　実際、永続化層の存在をあまり意識させずにアプリケーション上のエンティティとの変換をしてくれる仕組みのことを、一般にO/Rマッピングと呼びます（ActiveRecordもO/Rマッピングを実現するコンポーネントの1つです）。O/Rの「R」はRelational、つまりリレーショナルデータベースの「R」ですから、そもそもRDBMS以外の永続化手法は考慮していないのは当然といえます。

　BigTableを利用したアプリケーションの設計は、大きなパラダイムシフトでもあるのです。

それでも、GAE上でRDBを使いたい！

　もちろん、BigTableは優れた仕組みですし、スケーラビリティの面でも不可欠ともいえるものでしょう。

　しかし、旧来のWebアプリケーションをGAE上に移植するならば、BigTableに対応させなければなりません。また、最初から作るにしても、設計手法をBigTableにあったものに換えなくてはなりません。

　大規模なサービスを想定しているならば、BigTableを見据えた設計を考えるべきでしょう。一方で、GAE上で稼働するすべてのサービスが必ずスケールアウトするとも限りません。

　Googleは、GAE上にどういうサービスを置くべきかを規定していませんから、サービスの種類は多岐に渡ります。

　余談として挙げた草野球チームの試合日程、出欠管理アプリケーションなどは、せいぜいチームのメンバー十数人がアクセスするだけで、もし自分のチームの部員が増えるといっても、せいぜいが数十人レベルでしょう。同様に、ある企業の部門レベルのサービスで、ユーザー数も限定されているというケースであれば、スケールアウトは求められない可能性もあります。

　スケーラビリティよりも、むしろGAEのインフラ構築・維持コストの低さに大きな魅力を感じる人ならば、スケーラビリティには多少目をつぶるとしても、旧来どおりのアプローチで素早くサービスを構築したいと思うのではないでしょうか。

　そこで本連載では、解決策の1つとして「SQL4G」というライブラリを利用する方法を紹介します。SQL4Gは、リトルソフトが開発・提供するオープンソースのライブラリで、GAEベースのアプリケーションにリレーショナルデータベースを組み込む手段を提供します。

　SQL4Gのデータベースエンジンは、H2というPure Javaのリレーショナルデータベースのエンジンを拡張したものです。H2は、組み込み型およびサーバプロセス型をサポートしていますが、SQL4Gではデータベース上のデータをBigTableに直接保存します。

　インターフェイスは、基本的にJDBC互換（H2のそれに準じる）のため、開発者はSQL4G特有のコーディングがほとんど必要なく、H2へJDBC経由でアクセスするのと何ら変わらない実装方法でデータベースを操作できます。つまり、従来のJavaによるWebアプリケーションをほぼそのままの形でGAEに載せられます。

　また、H2には主要なデータベース（Oracle、PostgreSQL、MySQLなど）とのSQL互換モードが用意され、H2以外のリレーショナルデータベースからのマイグレーションも行いやすくなっています。

　スケーラビリティも、GAEの自動スケールアウト（分散JVM）に対応しています。

　といったところで、今回はここまでです。次回から、SQL4GとPHP／Railsを組み合わせて、リレーショナルデータベースを使ったWebアプリケーションをGAE上で稼働させる方法を紹介します。ご期待ください。

　なお、次回まで待てない！という方は、SQL4Gを http://www.littlesoft.jp/sql4g からダウンロードしてお試しください。

2/2

Index
Google App Engine上でLL＋RDBアプリを作ろう
	Page1 GAE上でリレーショナルデータベース！？ Google App Engineがすごい3つの理由
	Page2 これまでの手法が通用しないGAEの制限 それでも、GAE上でRDBを使いたい！

GAE＋PHP／Rubyで拓く新世界

---

Coding Edgeお勧め記事

	いまさらアルゴリズムを学ぶ意味 コーディングに役立つ！ アルゴリズムの基本（1）　コンピュータに「3の倍数と3の付く数字」を判断させるにはどうしたらいいか。発想力を鍛えよう
	Zope 3の魅力に迫る Zope 3とは何ぞや？（1）　Pythonで書かれたWebアプリケーションフレームワーク「Zope 3」。ほかのソフトウェアとは一体何が違っているのか？
	貧弱環境プログラミングのススメ 柴田 淳のコーディング天国　高性能なIT機器に囲まれた環境でコンピュータの動作原理に触れることは可能だろうか。貧弱なPC上にビットマップの直線をどうやって引く？
	Haskellプログラミングの楽しみ方 のんびりHaskell（1）　関数型言語に分類されるHaskell。C言語などの手続き型言語とまったく異なるプログラミングの世界に踏み出してみよう
	ちょっと変わったLisp入門 Gaucheでメタプログラミング（1）　Lispの一種であるScheme。いくつかある処理系の中でも気軽にスクリプトを書けるGaucheでLispの世界を体験してみよう
	more

　　Coding Edgeフォーラムフィード　 2.0／1.0／0.91