Webサービスを公開するまでの流れを大まかに分けると、次のようなステップになるかと思います。

1. サーバを有料でレンタルする
2. 環境構築する
3. Webサービスを作成する
4. デプロイして公開する

今回は、MetaGatewayで採用しているGoogle App Engineの優位性を、このステップに沿って紹介していきたいと思います。

サーバを有料でレンタルする

まずサーバを有料で借りるという時点で敷居が高いわけですが、Google App Engineでは、月500万PV、ストレージも500Mまでは無料です。CPU、ネットワークリソースも十分な範囲が確保されており、スタートアップには最適です。

現在はプレビュー期間中ですが、ロードマップによれば、まもなく有料プランも開始されます。有料プランが開始されればリソースを追加購入することができます。つまり、無料で成長させ、制限を超えそうな、芽のでそうなサービスに対してのみリソースを追加購入すればいいのです。

環境構築する

簡単に環境構築と書きましたが、真面目に行うと、その範囲は多岐に渡ります。たとえば、Nagiosやcactiなどのツールを利用して、稼動状態を監視するとともに、サーバリソースなどの状態をきちんと把握する必要があります。

サービスが大きくなってくれば、当然フロントの負荷分散のために、ロードバランサーなども必要になります。memcache、データベース分散、レプリケーションなども利用する必要になってくるので、そのタイミングに応じてさまざまなチューニングや拡張を施していかなければいけないわけです。

はじめからそういう構成になると考えて構築しておけば、スムーズに展開できますが、個人で作るサービスでそこまで考えているケースなど皆無でしょうし、そういう構成にすることで、成功するかどうかもわからないサービスにさらにお金がかかってしまうのもナンセンスです。

Google App Engineではそういうことを一切考える必要がありません。スケールすることが前提で組まれているので、リソースを追加購入するだけで簡単にスケールさせることができます。当然環境構築など一切不要です。

ただ逆に言えば、環境をまったくさわることができないという意味でもあります。私自身はMetaGatewayを作るにあたって、直接さわることができないことから生まれる不安なポイントがたくさんありました。そこを不安に思っている開発者は結構いるのではないのでしょうか？

しかし、実際使ってみてわかったのは、なんの心配もらないということです。というか、あまりの楽さに一度この世界で開発してしまうと抜け出せなくなるのではないか？と思えるほど開発者サイドから考えられていました。

特に私が気にしたポイントは以下の点になります。

データの確認方法、または不整合が発生した場合の復旧方法（図1）

エンティティ単位でデータを確認することができます。またGQLというSQLと非常に似通った構文のクエリを発行することができ、それでデータを確認することができます。

絞りこんだデータに対して、updateすることもGUIからできますし、エンティティを作ることもできます。つまり、普通にRDBMSに対するクライアントのように操作することが可能で、不整合などが発生した場合には目視しながら直すことも容易にできます。

リソースの監視（図2）

リクエスト数などの情報がグラフによって簡単に把握することができます。

すべてのリソースに対して、どのくらい利用しているのかが一目瞭然なので、Quotaを超えた場合もなにを購入すればいいのかすぐにわかります。また、どのURIに対して何回リクエストされているのか、どのくらいCPUをつかったのかもチェックすることができます。

つまり、単純にリソースを購入すればいいとかいう話ではなく、常にどこにボトルネックがどこにあるのかを理解できるし、それらのチューニングをおこなうことによって、効率的に購入等を行っていくことが可能なのです。

ロギング

通常通りロギングすれば、管理画面ですべて確認することができます。MetaGatewayではexceptionが発生した場合など、一元的に処理してすべて同様にロギングしています。

つまり、ユーザの画面で発生したバグのほとんどのケースを私は把握しています。ユーザはfeedbackしてくれない人のほうが圧倒的に多いので、feedbackなしに進化できるシステムを構築しなければならないので、それがしやすいシステムであることが重要なのです。

インデックスの張り方（図3）

AppEngineではインデックスのはっていないクエリーは発行することができません。（⁠発行しようとするとNeedIndexErrorのexceptionが発生します。）

これ自体は賛否両論じゃないかと思いますが、私的にはわかりやすくていいかなと思っています。（⁠パフォーマンスもある意味バグと考えているので）

インデックスを張る方法は非常に簡単でindex.yamlというファイルにindexを記述するだけです。

開発環境ではindexが張られていなくても動作し、一度でもそのクエリーが流れればindex.yamlに自動的に記述されます。

つまり、一度でも動作させてからアップすればindexの漏れは発生しないことになります。

もちろん、バージョンアップの際もindex.yamlに追加されていれば差分だけをきちんとindexを張ってくれます。いきなりはservingになりませんがほっておけば張られるのであまり心配はいりません。

バージョンアップ方法

私が、バージョンアップにおいて重要と考えていることは、既存のシステムを停止しない、また問題があった場合にすぐに前にシステムにロールバック可能だということです。

完全にメンテナンス状態にして終了後にはずすという方法では、システムが停止します。また、ステージングサーバにアップして確認、本番へシンクなどの方法では非常にロールバックが非常に大変です。その点、Google App Engineではすさまじく簡単です。app.yamlのversionを1つあげてアップするだけです。すると、新しいバージョンの完全なコピーが生成されます。

完全にユニークなURLが生成されるので、そこで動作確認し、問題なかったら、それを現在のバージョンに設定するだけです。もし問題があれば前のバージョンを現在のバージョンに戻すだけです。きわめて理想的なバージョンアップ方法になります。コマンド一発でアップしたあとは、GUIですべて操作可能です。

そのほかにもいろいろありますが、一度さわってみれば、Google App Engineのすさまじく洗練されたバックエンドを理解していただけるのではないかなと思います。

Webサービスを作成する

Google App Engineを使っている方は、下回りを気にしなくていいのでここから入ることになります。

Google App Engineを利用するということは、当然ながらGoogleのルールにしたがってアプリケーションを作成する必要があります。ロードマップでは別の言語も使用できる予定にありますが、今のところPythonしか利用できません。つまり、GoogleAppEngieを利用するにはPythonを覚える必要があるのです。Google App Engineという開発環境には興味をもちつつも、あえて新しい言語を覚えることに違和感を感じる人は多いのではないかと思います。

私自身はC/C++、 Javaを使うことが多いのですが、実は軽量言語の領域ではあまりしっくりとくるものがありませんでした。今回、私ははじめてpythonに触れたのですが、その哲学なども含めて非常に魅了された一人です。さらにフレームワークで利用したDjangoとあわせて覚えておいて決して損にはならないものだと思います。

特に私が気に入った点は、Pythonはユーザが必要とする最小限の機能のみを提供するように作られているため、誰が書いても同じようなコードに収束すること（複数のやりかたを提供しません⁠）⁠。また、インデントによってブロック構造が決まるので、常に読みやすいコードになること。これらの特性はチーム開発やメンテナンス性重視の私には非常に合っていました。また歴史の長い言語でもあるので、ライブラリなども非常に沢山あり、洗練されています。

私はC/C++、 Javaと並んで今後よく使うことになるのは間違いないと思います。

なお、Google App Engineではファイルシステムを使用したり、socketを直接開いたりと制限にかかるようなことはできませんが、そのような使い方でなければ、ほとんどのPythonのライブラリはそのまま使用することができます。直接利用できないとしても、ほとんどのライブラリはロジックは利用できますので、問題となる部分だけをさしかえて利用したりもできます。

たとえばMetaGatewayでは、xmlrpcのライブラリなどはトランスポート部分だけをurlfetchに差し替えて利用していたりします。

Google App EngineはWebサービスを作る上でも、面倒な処理を行うAPIが多数用意されているので是非確認してみてください。

たとえば、ユーザのログイン処理があります。Google App Engineを使えば、Googleのユーザ管理の仕組みをそのまま利用できるので、なにも作りこむ必要がありません。実際数行記述するだけです。ログイン後に自分らのサービスへコールバックされ、get_current_userをコールするだけでログインユーザが取得できます。

MetaGatewayではopenIDなども含めてgoogle以外の認証方法にも対応したいと考えているので、それへの布石が行えるような構造としてユーザ管理を行っていますが、おおむねやっていることは同じです。

デプロイして公開する

Google App Engineでは、コマンド1回でアプリケーションのアップロードが終了します。

python appcfg.py update metagateway

上記のようにコールするだけで終了です。後はアップロードしたバージョンの動作確認をして、現在のバージョンにGUIから設定するだけです（図4⁠）⁠。問題があれば再度同じコマンドを打てば、差分だけがアップされます。アップした後に、問題が起きた場合は、1つ前のバージョンに戻せばいいだけです。

すべてが一瞬で終了するこのプロセスに慣れてしまうと、今までの公開作業の煩雑さに面食らうかもしれません。まずは一度触れてみることをお勧めします。

次回はMetaGatewayの中身について説明していきます。