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）

図1

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

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

リソースの監視（図2）

図2

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

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

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

ロギング

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

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