名前はゲームだが、技術的に見るとwebサービスである。
超高トラフィックってどのくらい
ピーク時の秒間httpリクエストは5桁req./sec
サーバ3桁からなるシステムで運用している
順調なPV
サービスを支える技術
サービスに仕様しているサーバ環境は、一般的なLAMP環境
LB ソフトウェア ZeusとDNSラウンドロビンを併用している。
基本スケールアウトで、フロントサーバのスケールアウト
機能分割とシャーディングを続ける
read機能が足りないならreadレプリカも追加する
Google先生に聞けば理屈の上では可能だが、
実際にはいろいろと問題が…
サーバはクラウドなのか
パブリッククラウドではない
Disk I/O性能が不安定
物理ディスクを占有できるサービスがなかったため
内部ネットワークのトラフィックの限界が分からない
クラウドサービス全体のメンテナンスに都合を合わせる必要がある。
毎月のメンテナンスを一度にやる必要がある。
クラウドだと、パフォーマンスが不安定であることが問題だし、
インフラは外注なので、自分たちでは制御できない原因がありうる。
専用のパブリッククラウドは断念した。
新しい環境に、アプリとデータを移す
メンテナンス時間を短かくすることが肝要である。
問題はDB
総データサイズは数百GBとなっていた。
コピー&展開では時間がかかるし無理
レプリケーションで解決
逆方向のレプリケーションもやる。
理論上可能であっても、引越し前と引越し後で物理的に500km
あったので、不安ではある。
結果はメンテナンスも短時間で終了した。
5秒問題
モバイルソーシャルアプリ特有の仕組み
ガジェットサーバ(GREE) → コンテンツサーバ(KONAMI)
5秒以内にレスポンスを返さないといけない。
5秒を越えるとタイムアウト
タイムアウトが規定の数を越えると、GREEから公開停止をくらう。
レスポンスに5秒以上かかりそうなときは、PHPの処理を中断して、
瞬間的な最悪の事態を回避する(GREEからの懲罰逃れ)
set_time_limit()
プログラムの実行時間のみで、
100%非同期シグナルセーフではないため、変更にリスクは伴う
ソースコードを直接弄って
時間指定の単位を1秒未満などにした。
マイクロバースト問題
一部のレスポンスが、遅い問題(しかも法則性がない)
全て9秒強で終了していることが分かった
Webサーバ DBサーバのTCP接続に時間がかかっている
SYNパケットをLostしていた
RFC(TCPパケットの再送)
RTOは3秒
二回目以降はRTOを2倍したものを追加する
SYNパケットを2回ロストすると、(3+6)秒かかる
スイッチのキューで瞬間的にパケットがあふれている(マイクロバースト)こと
が原因であることが判明した。
無駄なリトライをする必要がない
RTOの値、再送のルール(ローカル内でのみ)を、直接弄った
再送のたびに倍にするルールを殺した
ちょっとソース変更を行う必要がある。
ミドルウェアのパフォーマンスチューニング
いざというときの輪番アクセス
負荷テストが出来ない
サーバーの物量が多いので、負荷予測がしづらい
ユーザーを8分割して、時間毎にアクセス制限をかける
人数をずらしていく(全ての人間にプレイできるチャンスがある)
定期的に利用できる範囲を変える。
サービスの開放率をコントロールできる
システムのどこかがパンクしたら、ボトルネックの
パラメータのグラフを見て、開放率をコントロールして、ピークが
過ぎるのを待つ。
