不可逆な毎日ブログ

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. ApacheFastCGI が同居
  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. httpdFastCGIが対象
  4. gdbを使っていたが、bulkdbgというものを作成し利用している

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

  1. Mobageでは、約5秒おきにhttpdFastCGIの前プロセスのスタックトレースを取得、ログ出力
  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 は、現時点ではまだ使えるレベルではないと考えている

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 は、現時点ではまだ使えるレベルではないと考えている

2. Mobage運用技術Web編

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

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

1. 基本、LAMP
2. WebサーバとDBサーバが大部分
3. ApacheFastCGI が同居
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. httpdFastCGIが対象
4. gdbを使っていたが、bulkdbgというものを作成し利用している
- デタッチしたあとにシンボル解決している
5. Mobageでは、約5秒おきにhttpdFastCGIの前プロセスのスタックトレースを取得、ログ出力
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を動かしている
- ログファイルがキャッシュに乗らなくなった

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

登壇者:DeNA小野様

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

特徴

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

SphinxでPDF作成

LaTeX経由でのPDF作成 Sphinx-Users.jp
http://sphinx-users.jp/cookbook/pdf/latex.html

手順が新しくなったこと、日本語PDF周りの修正が適用されたものが用意されたことで新しく環境を構築しなおした。
インストールも easy_install でできるし、Tex の環境もバイナリでインストール可能なので、特に問題ない。
PDF 出力だが、以前は、結構手こずった覚えがあって、PDF 出力が簡単にできれば業務でも採用しやすいのだけど
と思っていた。
しかし、今回の修正が原因なのか、驚くほど簡単に出力できた。
一部、for 文の構文のエラーがあったため修正した。この対応が正しいかは不明。
ただ、PDF は生成されている。

all-pdf-ja:
       for %%f in (*.pdf *.png *.gif *.jpg *.jpeg) do ebb %%f
       for %%f in (*.tex) do platex -kanji=utf8 $(LATEXOPTS) %%f
       for %%f in (*.tex) do platex -kanji=utf8 $(LATEXOPTS) %%f
       for %%f in (*.tex) do platex -kanji=utf8 $(LATEXOPTS) %%f
       -for f in *.idx; do mendex -U -f -d "`basename $$f .idx`.dic" -s python.ist $$f; done
       for %%f in (*.tex) do platex -kanji=utf8 $(LATEXOPTS) %%f
       for %%f in (*.tex) do platex -kanji=utf8 $(LATEXOPTS) %%f
       for %%f in (*.dvi) do dvipdfmx %%f

これで、何も恐れることなく、業務に使えると考えている。やった。
Tex のエラーが少し厄介だな・・・。