不可逆な毎日ブログ

2度と過ごすことのない毎日をつらつらと･･･

はてな x DeNA合同企画　Mobage 運用技術勉強会に行ってきた

はてな x DeNA合同企画　Mobage 運用技術勉強会
2012.06.19
台風ですが、決行！！終わったら、Sakura Cafeで懇親会。

1. DeNAインフラ部門簡易紹介

登壇者：DeNA小野様

インフラ部門
ネットワークとMobage基盤
プラットフォームは、日本、US、韓国、中国向けがある
サーバの拠点は、名古屋、東京、サンフランシスコ、上海

特徴

1. 高いソフトウェア開発力
- Handler socket plugin
- MySQL-MHA
2. 非富豪的感覚
- サーバ台数は、グリーの半分くらいと思われる

2. Mobage運用技術Web編

Mobage Webサーバ機の資源管理について

登壇者：DeNA樋口様
2-1. Mobageの佐波郡構成について

1. 基本、LAMP
2. WebサーバとDBサーバが大部分
3. Apache と FastCGI が同居
4. FastCGIはマルチプロセス型サーバ
5. ゲームごとに分離されているわけではない
- ゲーム間連携が簡単にできるメリットがある
6. オープンプラットフォームはアプリごとに独立している

2-2. Webサーバ機の資源消費について
  1. Webサーバ機は、CPUまたは、メモリがネック
  2. メモリ使用量が、1Gbyteを超えてしまう
2-2-1. FastCGIワーカ数の管理
  1. サーバ1台あたり 〜100プロセス程度
  2. CPUコア数の2,3倍は必要
  3. 1つのリクエストを処理する間の半分以上の時間はネットワークIO街などでsleepしているから
  4. ワーカーは、多いほど、耐障害性が高まる
  5. 多すぎるとメモリ不足になる
2-2-2. デバッガを使った状況モニタリング

1. 走っているプロセスにデバッガをアタッチし、アタックとレースをとり、すぐにデタッチ
2. 前プロセスのスタックトレースを一定周期で取得
3. httpdとFastCGIが対象
4. gdbを使っていたが、bulkdbgというものを作成し利用している
- デタッチしたあとにシンボル解決している
5. Mobageでは、約5秒おきにhttpdとFastCGIの前プロセスのスタックトレースを取得、ログ出力
6. 利用状況モニタリングと障害調査に利用
- オーバヘッドはほとんどなし
7. accept()でブロックしているワーカーの数が減ってきたら枯渇が近い
- メールで警告
8. ログを見れば分かる状態

2-2-3. 障害調査の手法
  1. gdb等で確認できるのは、Cのスタック
  2. Perlのスタックトレースも見たい
  3. gdbperl.pl というものを作成
  4. Perlがデバッグシンボル付きでコンパイルされていないと動かない
  5. 本番でも使っている
  6. NYTProfでプロファイルデータの取得
  7. 状況を把握できないよな自体は現状ほぼなくなった
2-3. メモリ利用効率化
基本
  1. 独立したPerlモジュールにしている
Perlモジュールプリロード
  1. 昔のMobage : forkされた各ワーカがperlをexec、モジュールを読み込みリクエスト処理
  2. 今のMobage : アプリのもウールを読み込んだ後にワーカープロセスをforkしリクエスト処理
  3. forkのタイミングで、Socket等を開いたままだと問題を起こすことがある

- 処理の実行順序が変わることによる影響があった
- 移行後は、メモリの使用量は半分になった

OSページキャッシュの効率化
  1. アプリが履くログファイルがキャッシュされてしまう
  2. メモリをけちると、ログ回収のタイミングでswapしていた
  3. 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

1. auto increment
- same schema - different database
2. MyISAM sequence table
アプリケーション側で対処

Scale back
Reduce scale-outed servers
  1. 1サーバで複数プロセス起動して対応している
  2. MySQLはマスタを1つしか指定ができない
  3. 仮想IPアドレスを割り当て、それのみ、LISTENするようにする(my.cnf)
  4. ポートを変える方法は、ポート管理が大変
  5. アプリケーション側で変更がなくなるので、仮想IPアドレスの方法を行なっている
Databackup
  1. ただのスレーブ。サービスに入っていない
  2. mysqldumpで行なっている
  3. それを使って、slaveをいつでも作ることができる
  4. slaveの追加が、サービスに影響を与えずできる
MHA
  1. マスタが落ちた際に、自動で、マスタ昇格するスクリプト
Big Data
Purge
  1. よくあるものは、古いデータを消す
  2. 古いバージョンでは、DELETEで消していく方法しかなかった
  3. DELETEは重い処理
  4. 5.1以降では、パーティション機能でテーブルによっては、簡単に削除できるようになった
  5. range partition を使えば簡単に削除できる
  6. drop table と同じ感覚
High Traffic
  1. Range Scan は気をつけるべき
  2. Primary KeyでSELECTすることが多い
  3. Handler socket plugin (made by higuchi)
  4. Too many UPDATE
  5. ロックの時間をできるだけ短くする
  6. SINが落ちることはある
  7. コネクションをはったあとでロックしていく
  8. いろんなマスタに対し、1回で更新を行いたい
  9. 1つのサーバで発生した場合は、検知ができるが、複数サーバで発生した場合は、設定ファイルで回避するしかない。→時間がかかる
  10. まずは、デッドロックが起きないようにするチューニング
  11. 楽観的ロック。バージョンカラムというものを用意する
  12. 更新するときに、バージョンカラムを更新する
  13. レプリケーション遅延が起きてしまう
  14. その遅延をどのようにして計測するか
  15. バックアップサーバは、スレーブよりスペックが低いことが多い
  16. バックアップサーバで遅延が発生したら、スレーブでも発生するだろうという考え
  17. バックアップサーバの状態を確認し、チューニングしていく
  18. SSD は、レプリケーション遅延が発生しにくい
  19. レプリケーションは、1スレッドで行うため、どうしても遅延しやすい
  20. HDDでは遅延するが、SSDでは余裕というケースは多々ある
  21. SATA-SSD is good
  22. SAS-SSD は、現時点ではまだ使えるレベルではないと考えている