運用中のアプリケーションのバージョニングもGoogle App Engineがやってくれる。Google App Engineでは、管理コンソールでアプリケーションのバージョンを管理していて、バージョンを指定してデプロイすることで、アプリケーションの履歴を保存できる。
「バージョンを指定したURLにアクセスすれば、それぞれのバージョンの動作をいつでも確認できるし、ユーザーに見せるバージョンのデフォルトも指定できるので、アプリケーションに何か問題があったときは、すぐに以前のバージョンに切り替えられます」(本多さん)
「これを利用すれば、限定されたユーザーのみに新バージョンを公開できますし、管理コンソールから設定を変更するだけなので、新バージョンローンチ時のトラブルはグッと減るでしょう。また、動作状態のモニタやアプリケーションのログも管理コンソールから見られます」(本多さん)
2008年のサービス開始当初は、トライアル版ということで「フリークオーター」と呼ばれる制限されたリソースの範囲内のみでのサービスだったが、2009年に入ってから課金サービスも開始された。フリークオーターの範囲を超えてもっとサービスを提供したいという開発者に、有料でもっと多くのリソースを開放する。
「アプリケーションの使うリソースに応じて課金するという形なので、始めのユーザーがあまり使っていない状態ではフリークオーターで、ユーザーが増えて処理量が増えればそれに応じて課金していくというシステムになっています。あらかじめ上限を決めておき、どこまでなら払うかということを自分で設定できます」(鵜飼さん)
Google App Engineでは、アプリケーションが実際に何台のどういうマシンで動いているか、開発者は気にする必要がない。多くのアクセスを集めるアプリケーションならば、たくさんのマシンでデプロイされるし、小規模であれば、なるべくリソースを使わない形でデプロイされる。事前にサーバをセットアップする必要もないし、そのスペックに悩まされることもない。
処理すべきデータの量が増大しても、グーグルのいろいろなWebプロダクトの中で使われているスケーラブルなインフラストラクチャを基にして処理できる。アクセス数が増えたことでサーバがダウンする心配をする必要はないという。
なぜなら、データストアにはグーグルが開発した非常にスケーラブルで分散したデータストレージであるBigtableが使われているからだ。
Bigtableは、基本的にはスプレッドシートのように、行と列、つまり行に対していろいろなカラムがついている形の2次元で構成されている。データは行のキー(任意)で並べ替えられた状態になっていて、行をいくつかずつに分割して「タブレット」と呼ばれる固まりにし、さらにそのタブレットをまとめて1つの固まりとして管理して、巨大な1つのテーブルを構成している。
そして、タブレットサーバというものがいくつかのタブレットの管理をしており、実際にそのタブレットに対する読み書きなどの処理をしている。
さらに、Bigtableのマスタがテーブルを管理していて、「どのタブレットを、どのタブレットサーバが管理しているか」といった情報を見ている。タブレットサーバは自分の管理するタブレットだけを見ている、そういったタブレットサーバがたくさん存在して、クライアントからは非常に大きなテーブルも1つのテーブルとして見られるようになっている。
「Bigtableに限らずデータストア一般的な話になるかと思いますが、普通のRDBMSと違ってデータ自体がいろいろなサーバに分散して保存されているので、大量のデータを一気に処理したいと思ったときには、全部のサーバに同じ処理を投げて返ってきた結果を集めるられるので、『大量のデータに対して簡単な操作をする』という点においては、とても高速に実行されます。ある行を指定してその内容を取得する、特定の値をスキャンするなどの処理は、データが大量でも非常に高速に実行できます」(鵜飼さん)
ただし、普通のRDBMSにあるJOINのように、複雑な複数のテーブルにまたがって操作をするような場合には、プログラム側で工夫が必要。「複雑なリレーションはデータストアをスケールしにくくするため」だという。
「Google App EngineのデータストアはBigtableの特徴を生かしつつ、できるだけユーザーに分かりやすいような形でアクセスができます。GQLというSQLライクなクエリ言語を使って、WHERE句で条件を指定してデータを取ってきたりすることもできます。ただし、そういった場合は、エンティティとは別のインデックステーブルを用意しておく必要があります。
インデックステーブルのWHERE条件からインデックスのキーになるようにうまく構成してLookupして、実際のエンティティのテーブルにアクセスして取ってくるという作りになっています。実際にはLookupすればさっとアクセスできるようになっています。
GQLにはORDER句もあるので、ORDERが逆順の場合には、条件に応じてスキャンできるように、始めから逆順になっているインデックステーブルが作ってあります。実際のエンティティはオープンソースのProtocol Buffersで書かれています」(鵜飼さん)
確かに、これまでのRDBMSを使ったアプリケーションでは、「単純な構造で何度もアクセスする方が速いか」「JOINやビューテーブルを利用した複雑なリレーションでデータ取得を一度に済ませた方が速いか…」というのは、データベース・サーバのスペックやデータ量などによってその場その場で判断せざるを得ないことも多かった。
しかし、このGoogle App Engineのデータストアが利用できるのであれば、「構造を単純に作っておけば、レスポンスはグーグルに保証されているというわけです」(鵜飼さん)
PythonRuntimeのAPIリファレンスドキュメント日本語版が公開された。JavaRutime版はまだ日本語化されていないが、予定はあるとのことだった。
活発な議論が交わされているコミュニティ。各APIに詳しいGoogle APIエキスパートがリードしているという。
Google App Engineのアプリケーションギャラリー。実験的なものから、実際に使えそうなものまでさまざまなアプリケーションが登録されている。また、このギャラリー自体もGoogle App Engineで作成されているという。
6月9日に開催されるGoogle Developer Dayでも、Google App Engineについてのセッションが予定されている。ハッカソンのテーマにも取り上げられており、Google App Engineで面白いアプリケーションがその日中に生まれるかもしれない。
「小規模なサービスにとって、インフラの準備やセットアップに掛かるコストは、アプリケーション本体の開発コストと同等か、それ以上のものだった。サービスが急激に成長してうれしい悲鳴を上げているうちに、レスポンスの悪さからユーザーに愛想を尽かされてしまうのではないかとヒヤヒヤしながら増設サーバの予算稟議を待った経験がある人もいるかもしれません。しかし、データストアやAPI、さらにはインフラなど、グーグルの技術を利用することで開発者はアプリケーションの開発につきまとう、そういった『心配事』を一気に解決できるようになります。Google App Engineによってアプリケーション開発の障壁が低くなり、ここからさまざまなサービスが生まれてくることを期待しています」(鵜飼さん)
立薗理彦(たちぞの まさひこ・左)
1972年東京生まれ。1996年、慶應大学 環境情報学部卒。シャープで組み込み系のソフトウェアエンジニア、ノキアで日本向け端末のリリースに携わる。週末プロジェクトとしてiTunesでの再生履歴をネットで公開するサービス「音ログ」を開発。現在は、音楽ニュースサイト「ナタリー」の技術担当取締役
佐藤真琴(さとう まこと・右)
1980年生まれ。日本工学院八王子専門学校卒。
20歳の時、時代の流れでWEB系エンジニアとして就職。2008年、ナターシャに入社。現在は「ナタリー」の開発者で、趣味と実益を兼ねる日々
Copyright © ITmedia, Inc. All Rights Reserved.