スティルハウスの書庫の書庫

はてなダイアリーで書いてた「スティルハウスの書庫」を移転してきました。

From Spark Plug to Drive Train: Life of an App Engine Requestを見たメモ

From Spark Plug to Drive Train: Life of an App Engine Request


Google App Engine Stackの構成(引用元)>

Life of a request

  • リクエストの受信 0:15
    • リクエストはクライアントから最も近いGoogleデータセンターに到着
    • Google内部ネットワークを経由してFront Endに到着
  • Staticコンテンツへのリクエス
    • Staticコンテンツ:appengine-web.xmlでstatic要素に指定したコンテンツ
    • アプリケーションコード等とは物理的に分離され配置されている
    • Front Endが直接処理し、App Serverは関与しない
  • Dynamicコンテンツへのリクエスト 0:17
    • App Server
      • Dynamicリクエストを処理。アプリコードが動作する
      • 多数のアプリを同時に収容し、アプリ間の隔離性を確保
      • アプリはステートレス。アプリが異なるAppserverに移動する場合でも状態を引き継いだりしない。負荷分散とフェイルオーバーが簡単になる
      • 状態はAPI(datastoreなど)で保存する
      • (HttpSessionはDatastoreで管理?)
    • App Master
      • アプリを管理してスケジュール
      • Front Endにアプリの情報を伝える
    • 処理の流れ
      • Front EndがApp Serverにリクエストを転送
      • App Serverは
        • 初回アクセス時はランタイムのメモリ上にアプリのキャッシュがないため初期化が実行され、処理が遅い
        • 次回以降アクセス時はメモリ上のアプリによりすぐにリクエストを処理
  • リクエストによるAPIアクセス 0:21
    • APIアクセスの流れ
      • アプリがAPIを呼ぶ
      • App Serverはそれを受けてアプリの実行をブロック、APIを実行
      • API実行結果を返し、実行を再開
    • API
      • XMPP
      • Task Queue(オフライン処理)
      • Datastore
        • Entity Groupはデータをパーティショニングする手段
        • コミットされたデータは地理的に分散した3台以上のサーバーに書き込まれる
        • 個々のentityにはGUIDが割り振られる
  • Design Motivations 0:27
  • The Numbers 0:36
    • 現状
      • 8万以上のアプリを収容
      • 140M PV/day
      • 20万人以上の開発者が利用
    • GAEのスケール事例:ホワイトハウスの"Open For Questions"
      • 2日間だけ提供された投票サイト
      • 10万件の質問と360万件の投票を受け付けた
      • その結果を受けてオバマ大統領が記者会見を行った
      • ピーク時には毎秒700回のクエリを実行した
      • Google Moderatorのソースをベースに、ホワイトハウス側の開発者がチューンしてデプロイした
      • GAE上の他のアプリケーションには一切影響がなかった


<"Open For Questions"のトラフィック推移(引用元)>

  • Questions 0:39
    • Datastore上のデータの物理的(地理的)位置を制御できるか?
      • できない。
    • アプリが受けられる負荷に上限はあるか?
      • 現状、safety limitが設けられている。それを超える負荷を扱いたい場合は、app engineチームに連絡してほしい。案件ごとにsafety limitを解除できる。