はてな x DeNA Mobage運用技術勉強会に行ってきた
本日は、台風の中でしたが、このような機会を設けていただきありがとうございました。
業務でお忙しいなか、ご対応いただき感謝いたします。
Markdown形式で書いたけど、そのまま載せます。（kobito使用）
はてな x DeNA合同企画 Mobage 運用技術勉強会
2012.06.19
台風ですが、決行！！終わったら、Sakura Cafeで懇親会。
# 1. DeNAインフラ部門簡易紹介
### 登壇者：DeNA小野様
インフラ部門
ネットワークとMobage基盤
プラットフォームは、日本、US、韓国、中国向けがある
サーバの拠点は、名古屋、東京、サンフランシスコ、上海
#### 特徴
- 高いソフトウェア開発力
- Handler socket plugin
- MySQL-MHA
- 非富豪的感覚
- サーバ台数は、グリーの半分くらいと思われる
# 2. Mobage運用技術Web編
## Mobage Webサーバ機の資源管理について
### 登壇者：DeNA樋口様
- ゲーム間連携が簡単にできるメリットがある
- オープンプラットフォームはアプリごとに独立している
#### 2-2. Webサーバ機の資源消費について
- Webサーバ機は、CPUまたは、メモリがネック
- メモリ使用量が、1Gbyteを超えてしまう
##### 2-2-1. FastCGIワーカ数の管理
- サーバ1台あたり 〜100プロセス程度
- CPUコア数の2,3倍は必要
- 1つのリクエストを処理する間の半分以上の時間はネットワークIO街などでsleepしているから
- ワーカーは、多いほど、耐障害性が高まる
- 多すぎるとメモリ不足になる
##### 2-2-2. デバッガを使った状況モニタリング
- 走っているプロセスにデバッガをアタッチし、アタックとレースをとり、すぐにデタッチ
- 前プロセスのスタックトレースを一定周期で取得
- httpdとFastCGIが対象
- gdbを使っていたが、bulkdbgというものを作成し利用している
- デタッチしたあとにシンボル解決している
- オーバヘッドはほとんどなし
- accept()でブロックしているワーカーの数が減ってきたら枯渇が近い
- メールで警告
- ログを見れば分かる状態
##### 2-2-3. 障害調査の手法
- gdb等で確認できるのは、Cのスタック
- Perlのスタックトレースも見たい
- gdbperl.pl というものを作成
- Perlがデバッグシンボル付きでコンパイルされていないと動かない
- 本番でも使っている
- NYTProfでプロファイルデータの取得
- 状況を把握できないよな自体は現状ほぼなくなった
#### 2-3. メモリ利用効率化
#### 基本
- 独立したPerlモジュールにしている
#### Perlモジュールプリロード
- 昔のMobage : forkされた各ワーカがperlをexec、モジュールを読み込みリクエスト処理
- 今のMobage : アプリのもウールを読み込んだ後にワーカープロセスをforkしリクエスト処理
- forkのタイミングで、Socket等を開いたままだと問題を起こすことがある
- 処理の実行順序が変わることによる影響があった
- 移行後は、メモリの使用量は半分になった
#### OSページキャッシュの効率化
- アプリが履くログファイルがキャッシュされてしまう
- メモリをけちると、ログ回収のタイミングでswapしていた
- posix_fadvise
- 本来ファイルを利用するアプリ自体が宣言するもの
- 10秒に1回、daemonを動かしている
- ログファイルがキャッシュに乗らなくなった
# 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
- auto increment
- same schema - different database
- MyISAM sequence table
アプリケーション側で対処
### Scale back
#### Reduce scale-outed servers
- 1サーバで複数プロセス起動して対応している
- MySQLはマスタを1つしか指定ができない
- 仮想IPアドレスを割り当て、それのみ、LISTENするようにする(my.cnf)
- ポートを変える方法は、ポート管理が大変
- アプリケーション側で変更がなくなるので、仮想IPアドレスの方法を行なっている
##### 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つのサーバで発生した場合は、検知ができるが、複数サーバで発生した場合は、設定ファイルで回避するしかない。→時間がかかる
- まずは、デッドロックが起きないようにするチューニング
- 楽観的ロック。バージョンカラムというものを用意する
- 更新するときに、バージョンカラムを更新する
