GAEで
スパイクを捌く
osakapy 5/29
アジェンダ
● 自己紹介
● スパイクについて
● スパイク対策
● 宣伝
● おまけ
おまえ、だれよ?
会津 剛(@Ido)
● 株式会社バスキュール/MJ-12在籍
● 主にPythonを使ったサーバーシステム開発に
従事
● 元々はFlash開発者でAS書いてた
● Especia推し
スパイクについて
スパイクとは
瞬間的に発生する大量トラフィックのこと
バースト(トラフィック)とも呼ばれている
スパイクが発生する要因
● Yahooトップにバナー出稿される
● 大量のフォロアーがいるSNSアカウントが誘導
をかける(特にLINEがYAVAY)
● 時刻指定でユーザー操作を求めるコンテンツ。
例えば視聴者参加型TV番組(例 : 曲に合わせ
てクリック、30秒以内に合計1万クリックでス
テージクリアなど)
スパイクの問題点
オートスケールが間に合わない
↓
雪ダルマ方式に処理待ちリクエストが積み上がっていく
↓
リクエストは30秒でエラー処理に入る
↓
エラーが大量発生
K.U.F.U.
対策は大きく分けて2種類
● 運用的対策
● システム的対策
運用的K.U.F.U.
● スパイクの最大瞬間リクエスト数とタイミングを
予想しておき、インスタンス数を起動しておく
(app.yaml で warmup を設定し、
automatic_scalingのmin_idle_instancesを設
定する)
● スパイクが発生しないようにCDNなどに配置し
ている静的ページを経由させる
システム的K.U.F.U.
待ちリクエストを発生させないか
1秒ルールを見据えているか
↓
処理を軽くする
処理を後回しにする
↓
データの性質に合わせてに処理を分別する
反映が遅延してもよいデータ
基本的にタスクキューを使って遅延処理を行うが、
タスクキューが積み上がりすぎてパンクする可能
性がある(今はしないかもしれない)
↓
プルキュー形式でタスクキューを積んでおき、
cronやバックエンドインスタンスなどで粛々とタスク
を消化していく
即反映して欲しいデータ
性質上、大体数字の加算 / 減算なので memcache の incr() /
decr() を使用してメモリ上にデータを保持し、cronなどで定期的
にデータストアに保存して永続化する。
ただし、cronの最短間隔が1分毎と遅いため秒単位で処理を行
いたい場合、バックエンドインスタンスの起動処理をループに入
れて一定間隔で処理を行う
起動インスタンス数の見積
対策を行ったシステムが稼働するインスタンス
(F1<600MHz,128MB>)1台が秒間で処理できる
リクエストは2〜3リクエストなので、予想される瞬
間最大リクエスト数を2〜3で割ると起動インスタン
ス数の大体の目安
宣伝
バスキュールでは一緒にスパイクを捌くシステムや
対スパイクコンポーネント「M.I.E.S.」を共に開発し
てくれる仲間を募集しています。
ご興味あればお声がけください。
GAEの本当に怖い話
● システム障害報告が遅い、ぬるい
● admin console の数字がリアルではない
● デプロイが詰まる
● サポートは飾り(ではなかったかも)

GAEでスパイクを捌く