ソーシャルゲーム開発の高負荷対策

http://ke-tai.org/blog/2011/01/28/snsgamesslidematome/
ここのスライドの内容から負荷対策に関して少しまとめてみた。

LAMP環境を想定
+memcachedとか

・DBへの接続切断は明示的に行う

・更新系、参照系でDBを分ける
但し、レプリケーション遅延なんて発生して当たり前。重要な参照は結局更新系から取得。

・KVSを利用する（ログイン時間管理とか結構どうでもいいような情報の負荷が糞高かったりするのに丁度いいらしい）

・キャッシュサーバーを効率的に利用する（使える所は使いまくれ。特に時間のかかるAPIのレスポンスなんか最適）

・Apache,MySQLのチューニングは必須（とにかくボトルネックとなりうる所は全てカリカリにするのだ）

・必ず負荷テスト及び過負荷テストを行う（公開3ヶ月後のユーザーデータを予測してDBに突っ込んでみる。もち本番環境で）

・ツールは大事。テストするにも監視するにも開発するにも。

・会員数数万程度を見越して作ったPGはNG

・スロースタートなんてありえない。最初から全力。でなきゃ、ずっと上には上がらない。

・WebサーバーやスレーブDBサーバーの複数台構成は当たり前。

・マスターDBの分散は難しいよねー。出来ない事無いけどとりあえずはスペックアップで耐える。
でも、最悪分散化する時の為に、テーブル構成は最初から分散を意識して構築

・レスポンスに5秒掛かった時点でアウト！プラットフォームから強制メンテモード突入のお知らせが

・サイト落ちた瞬間にユーザーは次のアプリへGo!二度と戻ってきません。

・DBの正規化はする。だけど場合によっては冗長化する。それが高負荷クオリティ。

・不要なカラムは持たない。どこかで使うかも～なんて設計の段階でちゃんと詰めとけ。

・保持するデータ量は最小限にする。（1日10GB単位でデータが増加するなんて普通という世界）

・期限が過ぎて必要なくなったデータは、さっさと削除
そして削除時のコストも考えておく（1000万レコード削除とか普通）

・インデックスは超重要！でも張りすぎたら超危険。

・LIKE検索とか馬鹿！っていうレベル

・SLOW QUERYは毎日チェック。即修正

・DBの負荷管理をどのように行うか考えておく。危険水域突破からの対策案も併せて

・トランザクションを開始したら、如何に早くコミット出来るかを考え抜く
トランザクション中に外部API呼ぶとか自殺行為

・APC(Alternative PHP cache)を利用する。むしろ使わないと馬鹿

・負荷対策は終わりなき戦い

・ユーザー数2000万超のプラットフォーム舐めんな

結構あったな。
もちろん、スライドショー内で全く言ってない事もチラホラ。
まぁそこは心の声という事で。

いやぁしかしほんとにネットワークエンジニアは尊敬するわ。
数十万の会員でもヒイヒイいうのに、facebookのネットワークエンジニアとかどうなってんだろ？

Posted in: