はてな x DeNA合同企画 Mobage 運用技術勉強会に行ってきた
はてな x DeNA合同企画 Mobage 運用技術勉強会
2012.06.19
台風ですが、決行!!終わったら、Sakura Cafeで懇親会。
2. Mobage運用技術Web編
Mobage Webサーバ機の資源管理について
登壇者:DeNA樋口様
2-1. Mobageの佐波郡構成について
1. 基本、LAMP
2. WebサーバとDBサーバが大部分
3. Apache と FastCGI が同居
4. FastCGIはマルチプロセス型サーバ
5. ゲームごとに分離されているわけではない
- ゲーム間連携が簡単にできるメリットがある
6. オープンプラットフォームはアプリごとに独立している
2-2. Webサーバ機の資源消費について
- Webサーバ機は、CPUまたは、メモリがネック
- メモリ使用量が、1Gbyteを超えてしまう
2-2-1. FastCGIワーカ数の管理
- サーバ1台あたり 〜100プロセス程度
- CPUコア数の2,3倍は必要
- 1つのリクエストを処理する間の半分以上の時間はネットワークIO街などでsleepしているから
- ワーカーは、多いほど、耐障害性が高まる
- 多すぎるとメモリ不足になる
2-2-2. デバッガを使った状況モニタリング
1. 走っているプロセスにデバッガをアタッチし、アタックとレースをとり、すぐにデタッチ
2. 前プロセスのスタックトレースを一定周期で取得
3. httpdとFastCGIが対象
4. gdbを使っていたが、bulkdbgというものを作成し利用している
- デタッチしたあとにシンボル解決している
5. Mobageでは、約5秒おきにhttpdとFastCGIの前プロセスのスタックトレースを取得、ログ出力
6. 利用状況モニタリングと障害調査に利用
- オーバヘッドはほとんどなし
7. accept()でブロックしているワーカーの数が減ってきたら枯渇が近い
- メールで警告
8. ログを見れば分かる状態
2-2-3. 障害調査の手法
2-3. メモリ利用効率化
基本
- 独立したPerlモジュールにしている
3. Mobage運用技術DB編
Mobage MySQL運用
登壇者:DeNA岩永様
Many Servers
Master - Slave
critical SELECT -> master
non critical SELECT -> slave
レプリケーションは、非同期となっている。最新版は、対応できている部分もある。
Sharding
+ divide per tables ( no join )
+ record sharding (difficult range scan)
レコードで分けるのは、クライアントサイドのロジックで分ける方法と、マッピング情報を別テーブルを用意する方法がある。
hash or mapping
ScaleOut
1. auto increment
- same schema - different database
2. MyISAM sequence table
アプリケーション側で対処
Scale back
Reduce scale-outed servers
Databackup
- ただのスレーブ。サービスに入っていない
- mysqldumpで行なっている
- それを使って、slaveをいつでも作ることができる
- slaveの追加が、サービスに影響を与えずできる
MHA
- マスタが落ちた際に、自動で、マスタ昇格するスクリプト
Big Data
Purge
- よくあるものは、古いデータを消す
- 古いバージョンでは、DELETEで消していく方法しかなかった
- DELETEは重い処理
- 5.1以降では、パーティション機能でテーブルによっては、簡単に削除できるようになった
- range partition を使えば簡単に削除できる
- drop table と同じ感覚
High Traffic
- Range Scan は気をつけるべき
- Primary KeyでSELECTすることが多い
- Handler socket plugin (made by higuchi)
- Too many UPDATE
- ロックの時間をできるだけ短くする
- SINが落ちることはある
- コネクションをはったあとでロックしていく
- いろんなマスタに対し、1回で更新を行いたい
- 1つのサーバで発生した場合は、検知ができるが、複数サーバで発生した場合は、設定ファイルで回避するしかない。→時間がかかる
- まずは、デッドロックが起きないようにするチューニング
- 楽観的ロック。バージョンカラムというものを用意する
- 更新するときに、バージョンカラムを更新する
- レプリケーション遅延が起きてしまう
- その遅延をどのようにして計測するか
- バックアップサーバは、スレーブよりスペックが低いことが多い
- バックアップサーバで遅延が発生したら、スレーブでも発生するだろうという考え
- バックアップサーバの状態を確認し、チューニングしていく
- SSD は、レプリケーション遅延が発生しにくい
- レプリケーションは、1スレッドで行うため、どうしても遅延しやすい
- HDDでは遅延するが、SSDでは余裕というケースは多々ある
- SATA-SSD is good
- SAS-SSD は、現時点ではまだ使えるレベルではないと考えている