Google App Engineのアーキテクチャ
App Engineアーキテクチャ（写真中の人物は夷藤勇人氏）
HTTPリクエストが複数のApp Engine Front Endに割り振られ、さらにApp Engine Front Endがロードバランサとなる2段階の負荷分散が行われ、リクエストをApp Serverに割り当てるようになっているのが、スライドから見て取れます。
Google App Engineの用途
Google App Engineの使用
以上のように、Google App Engineのさまざまな制限が説明されましたが、その目的は「スケールをしやすくするための制限」のように見えます。
制限
| 制限内容 | 著者コメント |
| HTTPリクエストは30秒以内 | 暴走対策と考えられる。初期の頃は8秒に制限されていたので、それと比べるとかなりマシになりました。 |
| サーバからのプッシュはできない | 上記制限により、長時間のコネクション維持ができない。 |
| スレッドの作成はできない | HTTPリクエストの30秒制限を実質、回避できてしまうためスケールが難しくなるためと考えられる。 |
| ファイルシステムは読み取り専用 | デプロイ用のディレクトリに設置することで、静的ファイルを設置することはできるが、動的ファイルの設置はできない。動的ファイルが発生するとスケールしにくくなるため。 |
サーブレットの利用
サーブレット
現時点で、サーブレットコンテナとしてJettyを選択しているが、将来に渡ってJettyを採用しつづける訳ではないことを強調していました。
アプリケーション設定
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
<application>application-id</application>
<version>1</version>
<static-files>
<include path="/**.png"/>
<exclude path="/data/**.png"/>
</static-files>
<ssl-enabled>true</ssl-enabled>
<sessions-enabled>true</sessions-enabled>
</appengine-web-app>
このXMLでは、ssl-enabledやsessions-enabledがtrueになっているが、両方ともサーバに負荷のかかる設定なので、本当に必要なとき以外は設定しないで欲しいとのことです。
SSLが必要になる時と言えば、まず思い浮かぶのがログイン時のパスワード送信時だと思いますが、Google App Engineでは認証サービスにGoogle Accountsを利用できるので、SSL設定が必要なシーンというのは限られてくると思います。
また、利用する静的ファイルはstatic-filesを利用して、明示的に指定した方が良いとのことです。
各サービスの対応
ソフトウェア・サービス
| サービス | Java標準API | バックエンドGoogleインフラ |
| Authentication | Servlet API | Google Accounts |
| Datastore | JPA, JDO | Bigtable |
| Caching | javax.cache | memcacheg |
| javax.mail | Gmail gateway | |
| URL Fetch | URLConnection | Caching HTTP proxy |
サービスの階層構造
サービス・インフラストラクチャ（写真中の人物は夷藤勇人氏）
最下層のレイヤーにGoogleのインフラに直接アクセスする実装があり、その上に言語非依存インターフェースがあります。この言語非依存インターフェースレイヤーを用意することによって、Python版とJava版が動くようになっているのだとすると、他の言語への対応も期待できるかもしれません。
