by shigemk2

当面は技術的なことしか書かない

ドラコレについて

名前はゲームだが、技術的に見ると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分割して、時間毎にアクセス制限をかける
人数をずらしていく(全ての人間にプレイできるチャンスがある)
定期的に利用できる範囲を変える。

サービスの開放率をコントロールできる
システムのどこかがパンクしたら、ボトルネックの
パラメータのグラフを見て、開放率をコントロールして、ピークが
過ぎるのを待つ。