大阪Pythonユーザの集まり 2014/03 のLTの発表スライド スライド中のリンクが切れているので原本にもリンク貼っておきます。 https://docs.google.com/presentation/d/1NngYBtxr0yB3ykh5nrP-uS1dJFBy2vqhsSeo_LkmIsc/edit?usp=sharing

1. GAEで
スパイクを捌く
osakapy 5/29

2. アジェンダ
● 自己紹介
● スパイクについて
● スパイク対策
● 宣伝
● おまけ

3. おまえ、だれよ？
会津 剛（@Ido）
● 株式会社バスキュール/MJ-12在籍
● 主にPythonを使ったサーバーシステム開発に
従事
● 元々はFlash開発者でAS書いてた
● Especia推し

4. スパイクについて
スパイクとは
瞬間的に発生する大量トラフィックのこと
バースト（トラフィック）とも呼ばれている

5. スパイクが発生する要因
● Yahooトップにバナー出稿される
● 大量のフォロアーがいるSNSアカウントが誘導
をかける（特にLINEがYAVAY）
● 時刻指定でユーザー操作を求めるコンテンツ。
例えば視聴者参加型TV番組（例 : 曲に合わせ
てクリック、30秒以内に合計1万クリックでス
テージクリアなど）

6. スパイクの問題点
オートスケールが間に合わない
↓
雪ダルマ方式に処理待ちリクエストが積み上がっていく
↓
リクエストは30秒でエラー処理に入る
↓
エラーが大量発生

7. K.U.F.U.
対策は大きく分けて2種類
● 運用的対策
● システム的対策

8. 運用的K.U.F.U.
● スパイクの最大瞬間リクエスト数とタイミングを
予想しておき、インスタンス数を起動しておく
（app.yaml で warmup を設定し、
automatic_scalingのmin_idle_instancesを設
定する）
● スパイクが発生しないようにCDNなどに配置し
ている静的ページを経由させる

9. システム的K.U.F.U.
待ちリクエストを発生させないか
1秒ルールを見据えているか
↓
処理を軽くする
処理を後回しにする
↓
データの性質に合わせてに処理を分別する

10. 反映が遅延してもよいデータ
基本的にタスクキューを使って遅延処理を行うが、
タスクキューが積み上がりすぎてパンクする可能
性がある（今はしないかもしれない）
↓
プルキュー形式でタスクキューを積んでおき、
cronやバックエンドインスタンスなどで粛々とタスク
を消化していく

11. 即反映して欲しいデータ
性質上、大体数字の加算 / 減算なので memcache の incr() /
decr() を使用してメモリ上にデータを保持し、cronなどで定期的
にデータストアに保存して永続化する。
ただし、cronの最短間隔が1分毎と遅いため秒単位で処理を行
いたい場合、バックエンドインスタンスの起動処理をループに入
れて一定間隔で処理を行う

12. 起動インスタンス数の見積
対策を行ったシステムが稼働するインスタンス
（F1<600MHz,128MB>）1台が秒間で処理できる
リクエストは2〜3リクエストなので、予想される瞬
間最大リクエスト数を2〜3で割ると起動インスタン
ス数の大体の目安

13. 宣伝
バスキュールでは一緒にスパイクを捌くシステムや
対スパイクコンポーネント「M.I.E.S.」を共に開発し
てくれる仲間を募集しています。
ご興味あればお声がけください。

14. GAEの本当に怖い話
● システム障害報告が遅い、ぬるい
● admin console の数字がリアルではない
● デプロイが詰まる
● サポートは飾り（ではなかったかも）