GAEのサーバー構成とリクエストの流れ
＜Google App Engine Stackの構成（引用元）＞
GAE Stackの特徴
GAE Stackの構成要素
- App Master
- アプリのデプロイ管理やバージョン管理
- Front EndへのApp Server位置の通知
- 全体の統括
- Front End
- スタティックファイルサーバー
- スタティックコンテンツを提供するサーバー
- スタティックコンテンツとは
- appengine-web.xmlでstatic要素に指定した、静的コンテンツ
- HTMLファイルや画像ファイル、動画ファイルなど
- アプリコードとは別の専用サーバーに配置される
- Front Endが直接処理し、App Serverは関与しない
- App Server
- ダイナミックコンテンツのリクエストを処理。アプリコードが動作するアプリサーバー
- 多数のアプリを同時に収容し、アプリ間の隔離性を確保する
App Serverについて
- App Serverの構成
- App Serverによるアプリの扱い
- アプリはステートレスに設計する
- アプリにステート（フィールド内容など）は持たせない
- アプリが異なるApp Serverに移動する場合でも、ステートは引き継がれない
- 多数のApp Serverによる負荷分散とフェイルオーバーを簡素化するため
- ステートはDatastoreやmemcacheに保存する
- セッション情報はDatastoreに保存されるので、どのApp Serverからでも同じ内容を共有できる
- （セッションの掃除が必要？）
- アプリにステート（フィールド内容など）は持たせない
- アプリはステートレスに設計する
- アプリのデプロイ後の起動
- 初回アクセス時はランタイムのメモリ上にアプリのキャッシュがないため初期化が実行され、処理が遅い
- 次回以降アクセス時はメモリ上のアプリによりすぐにリクエストを処理
- App Engine APIクラスライブラリ
- App Server上ではパッチリリースのアップグレードが自動的に行われ、再デプロイの必要はない
- ApiProxyによるAPIコールの扱い
Dependency Injection Frameworks - Guice, Spring, etc. Aspect Oriented Programming - AspectJ, Spring AOP, etc. Web frameworks - Google Web Toolkit, Tapestry, BlazeDS (Flex), etc. - Grails (Just Announced!) Alternate JVM languages - Scala, Rhino, JRuby, Jython, Clojure, Groovy, PHP, etc.
＜GAE/Jで利用可能な既存資産：引用元＞
GAEのスケールアウト
- 高負荷時の自動デプロイ
- 高負荷状態が50分程度続くと新しいApp Serverが追加されデプロイされて負荷分散し、負荷が低くなるとアンデプロイされるようです
- （高負荷時などに）アプリが新しいApp Serverにデプロイされたときの遅延は？
- アプリが使うライブラリ規模にもよるが、数100ms〜数秒程度
- アプリが受けられる負荷に上限はあるか？
- 現状、safety limitが設けられている。それを超える負荷を扱いたい場合は、app engineチームに連絡してほしい。案件ごとにsafety limitを解除できる
- 単純な負荷テストではスケールしないらしい
GAEのスケールアウト事例
そのほか
- Java版とPython版の性能の違いは？
- きちんとした比較はしていない。使い方によって異なるが、あまり大きな違いはない。GAE以外の環境で両者を比べた場合と同じ程度。
- Cometサポートは？
- 現状ではレスポンスのストリーム送信に対応しないため、Cometは使えない。現状、Cometサポートはロードマップにはないが、XMPPはサポート予定なので、プッシュ通信は実装できるようになる
- googleスタッフがデータを閲覧しないためのセキュリティポリシーはあるか？
- 社内のポリシーがある
