不可逆な毎日ブログ

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

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

本日は、台風の中でしたが、このような機会を設けていただきありがとうございました。
業務でお忙しいなか、ご対応いただき感謝いたします。
Markdown形式で書いたけど、そのまま載せます。（kobito使用）

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

# 1. DeNAインフラ部門簡易紹介
### 登壇者：DeNA小野様
インフラ部門
ネットワークとMobage基盤
プラットフォームは、日本、US、韓国、中国向けがある
サーバの拠点は、名古屋、東京、サンフランシスコ、上海
#### 特徴

  1. 高いソフトウェア開発力

- Handler socket plugin
- MySQL-MHA

  1. 非富豪的感覚

- サーバ台数は、グリーの半分くらいと思われる

# 2. Mobage運用技術Web編
## Mobage Webサーバ機の資源管理について
### 登壇者：DeNA樋口様

#### 2-1. Mobageの佐波郡構成について

  1. 基本、LAMP
  2. WebサーバとDBサーバが大部分
  3. Apache と FastCGI が同居
  4. FastCGIはマルチプロセス型サーバ
  5. ゲームごとに分離されているわけではない

- ゲーム間連携が簡単にできるメリットがある

  1. オープンプラットフォームはアプリごとに独立している

#### 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というものを作成し利用している

- デタッチしたあとにシンボル解決している

  1. Mobageでは、約5秒おきにhttpdとFastCGIの前プロセスのスタックトレースを取得、ログ出力
  2. 利用状況モニタリングと障害調査に利用

- オーバヘッドはほとんどなし

  1. accept()でブロックしているワーカーの数が減ってきたら枯渇が近い

- メールで警告

  1. ログを見れば分かる状態

##### 2-2-3. 障害調査の手法

  1. gdb等で確認できるのは、Cのスタック
  2. Perlのスタックトレースも見たい
  3. gdbperl.pl というものを作成
  4. Perlがデバッグシンボル付きでコンパイルされていないと動かない
  5. 本番でも使っている
  1. NYTProfでプロファイルデータの取得
  2. 状況を把握できないよな自体は現状ほぼなくなった

#### 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

  1. 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. 更新するときに、バージョンカラムを更新する
  1. レプリケーション遅延が起きてしまう
  2. その遅延をどのようにして計測するか
  3. バックアップサーバは、スレーブよりスペックが低いことが多い
  4. バックアップサーバで遅延が発生したら、スレーブでも発生するだろうという考え
  5. バックアップサーバの状態を確認し、チューニングしていく
  6. SSD は、レプリケーション遅延が発生しにくい
  7. レプリケーションは、1スレッドで行うため、どうしても遅延しやすい
  8. HDDでは遅延するが、SSDでは余裕というケースは多々ある
  1. SATA-SSD is good
  2. SAS-SSD は、現時点ではまだ使えるレベルではないと考えている