Google APP Engineでできることできないこと

Google App Egine

　実際にエントリーを書いてみて解ったのですが、Google　APP　Engineはかなり巨大になっていて、すべてを網羅しつつ技術的に詳細を解説しようとすると相当な分量になります。逆に言うと、やりたいことができるかどうかを調べるだけで相当な手間がかかるでしょう。
　なので、そのあたりを簡単に纏めてみました。

Google　APP　Engineのメリット

　メリットをざっと並べると次のようになります。

  1. サーバーの設定・運用・構築の手間がかからないこと
  2. データベースの分割、レプリケーションに相当するオペレーションが不要。Googleの技術・ノウハウで運用できる
  3. メールの送受信が容易
  4. 全体的に安価であること

　運用の手間がかからないというよりはほぼ手出しができないというのが正しいのですが、安定しており、一番大変なデータベースの分割、レプリケーションといったオペレーションが不要なサーバーを安価に借りられる、というのは大きいと思います。

Google　APP　Engineの制約

　反対にデメリットとなる制約をあげると次のようになります。

  1. 処理時間に制限がある
  2. 自由にプロダクトをインストールできない
  3. 複雑なJOINを使ったクエリーが使えない
  4. 外部サーバーとの通信でポートは固定
  5. ソケットを使えない
  6. ネイティブドメイン(example.comのようなもの)を使えない

　プロセスが30秒間動くと強制的に停止させられてしまいます。このため、CommetやWebSocketといったリアルタイムな通信を行うもののサーバーとしては使えません。
　外部サーバーとの通信はプロトコル及びポートが固定されていて、httpまたはhttpsのみでしかできません。
　特定の処理をするプロダクトをインストールしたりすることもできないので、もしどうしても使いたければ別サーバーで処理だけを行って保存だけを行う、といった工夫が必要になります。これは外部サーバーとの通信や前述のリアルタイム通信についても同じことが言えます。
　

　ただ、JOINについては複雑なものが必要な場合はエンタープライズ向けのある程度タイムラグがあってもいい分析系のケースがほとんどと思われますので、そのあたりは定期実行などの工夫で対処ができるかもしれません。
　

Google　APP　Engineに向いているもの

　やはり一番向いているのは、処理負荷が見積もりにくくそれでいて高負荷だったり大容量を必要としたり負荷変動が激しくなるようなケースです。つまり、新規、あるいは実験的なサービスにはぴったりだといえるでしょう。
　また、単純に大容量・高負荷を要するようなケースにおいてもmixiアプリなどで実績があがりつつあり、こういった方面にも適用できると思われます。