PHPカンファレンス2012レポート Part2
PHPカンファレンス2012のレポートPart2です。
ソシャゲでお馴染みGREEさん。
バックエンドエンジニアのお仕事をされている方のお話ということで、主にWebクライアント系PGやってる僕にはサッパリのお話でした／(^o^)＼
いや、本来は知っておくべきことなのでしょうけど…
大規模の話ということですが、どうやって続けて行くのかという方をメインとした話。
いまだからできる、ふつうのはなし
グリー株式会社 開発本部 GREE プラットフォーム統括部 上村 宏紀
概要
レスポンスを素早く、確実に返す。そんな普通のことが、バックエンドのエンジニアの仕事です。
とても単純な話に聞こえますが、GREEというサービスの規模でそれを実現することは簡単ではありませんでした。
どのような問題があって、どのように乗り越えてきたのか。エンジニアの立場から見た長く続くサービスの基盤の作り方について、実例を交えながらお話しします。
何してる人？
- SNS全般を正常に動作させる
- 世界に通用するSNS基盤の構築
- チームを横断した開発支援
長く続くサービスの基盤の作り方
大規模 × 継続
大規模
データが沢山あってたくさん処理しなきゃいけない→「大規模」と定義
データ的に
- ５０億レコードあるとか
- メモリやディスクに収まらなくなる
トランザクション的に
- １００万トランザクション/secとか
- スループットが足りなくなる
最初から大きくなることがわかってるテーブル
最初に計画して分割、別々のサーバーに置くことを前提とする
→あとから分割することもできるが、とても難しい
購入履歴だったら…
- 日付ごとのテーブルにするとか
所持カードのリストだったら…
- ユーザIDでmodとって１００分割
- 分割したテーブルをサーバにマッピング
- サーバー５台で足りるなら、１～２０までをサーバー１に…みたいな
対応
スレーブ増やす
- 参照クエリの数が増えた時
スケールアップ
- メモリ増やす
- Fusion-io使う
クエリのチューニング
- covering index
- index full scan
負荷対策の実例
- 1master/6slave で運用中のDBセット
- 月に数回 slow query が発生してレプリケーションが発生する
- DBサイズ10GB強
- スレートエンジンをMyISAMからInnoDBに
- メモリを16GBから24GBへ
オンサービスでのDB切り替え
ここはちょっとビックリしたのですが、GREEではオンサービスで入れ替えを行なっているとのこと。
ざわ・・・ざわ・・・
- 新セットを現行セットの slave につける（並列）
- ウォームアップ後、参照を新セットに向ける
- 両方のマスタに書き込みを行う
- 完全にマスタに書いてる状態になったら新セットのみにする
やっぱりお金のあるところは規模が違いますね。後半は正直、話が分からなすぎて挫折しました／(^o^)＼
結局重要なのは
完璧さを求めるよりも
変化していく環境に常に対応できることが重要
→どうにかする
greeのgithub
まとめ
- ディスクから読んだら負け
- フルスタックフレームワークは夢
- 移行は段階的に
- 早く見つけて早く直す
http://www.ustream.tv/embed/recorded/25413608?v=3&wmode=direct
http://www.ustream.tv/embed/recorded/25414328?v=3&wmode=direct
コメント