Web公開制限が無いらしいので、殴り書いたメモを貼り付けておく。


謎のアルゴリズムで集められたはてなユーザーに、モバゲーの運用技術を惜しげもなく教える勉強会に行ってきた。
インフラもPerlも全然わかんないんだけど何故誘われたのか謎。


モバゲーすごい・・・台風激しかったけど行ってきて良かった。特にモニタリング手法が面白くて、一瞬だけ全プロセスにデバッガをアタッチして待機状態のプロセス数を調べるとか、DBバックアップサーバーの遅延を監視してるとSlaveへの遅延発生が予測できるとか。頭いい。
たぶんMobageを支える技術に書いてある内容の一部だと思われるので、本も買ってみる。

あと社食で閉店前に「モバゲ〜」って歌が流れててわかめ高校みたいで面白かった。


2012年6月19日 @ DeNA


  • 渋谷ヒカリエの21階
  • 台風きてるからヤバかったらすぐ帰りましょう

インフラ部門紹介（小野氏）


  • 世界展開
    • mobage（アメリカ）
    • mobage（日本）
    • Daum mobage（韓国）
    • mobage なんとか宝谷（中国）（読めない）
  • Rackspace、AmazonEC2を使用
  • インフラも運用だけじゃなく開発する
    • Handler socket plugin
    • MySQL-MHA
  • 非富豪的感覚
    • 古株が多いのでこだわる
    • サーバー台数少ない
    • G社の半分ぐらい

運用技術 Web編（樋口氏）


  • ケチなのでサーバー台数少ない
  • webサーバーの資源管理
    • FastCGI
    • デバッガ
    • 障害調査
  • 全体構成
    • 基本的にLAMP
    • FW/LB
    • Webサーバ・DBに大別
    • Apache+FastCGI
  • 一枚岩アプリ
    • ゲーム・掲示板・コミュニティ全て同じアプリとして動作
    • ゲームごとに別ではない
    • メリット
    • ゲーム間の連携が容易
    • サードパーティのOpenPlatform使ったゲームはMobageと呼んでない
  • Webサーバ機はCPUやメモリがネック
    • Mobageの全機能をloadするとメモリ1GB使う
    • 全pmファイル読むだけで1GB
    • メモリ使用量を抑えてワーカープロセス数を増やしたい
    • 工夫する
    • サーバー1台あたり100プロセスぐらい動いている
  • FastCGIワーカー数
    • IO待ちでsleepしているのでCPU数の2,3倍起動する
    • プロセス数が多いほど耐障害性高い
    • バックエンドDBが詰まった時に影響が少なくなるので
  • ワーカープロセス数の空きを調べる
    • あと何％空いてるか？
    • 走っているプロセスにデバッガをアタッチ、スタックトレース取ってすぐデタッチ
    • リクエスト受付状態にあるプロセス数を数えればわかる
  • bulkdbg
    • 複数プロセスのスタックトレースを高速に取得
    • gdbより速い
    • シンボル解決のタイミングがgdbと違うらしい
    • 複数プロセスなのでライブラリ同じ、無駄なので読まない
    • 5秒ごとに実行している
    • オーバーヘッドほとんど無い
  • gdbperl.pl
    • Perlのスタックトレースをとる
    • 内部でgdbを使ってPerlインタプリタの内部変数を読む
  • どっちも実サービスで使っている
    • 問題起きたこと無し
  • 障害調査の手法
    • gdbperl.plをアタッチ
    • straceをアタッチ
    • bulkdbgでモニタリング
    • NYTProfでプロファイルデータ取得
    • DBのログ
  • メモリ利用効率化
    • メモリに全部読むと1GB
    • 特定のゲームだけならそんなに行かない
    • サーバをグループにわける
    • Perlモジュールプリロード
    • OSページキャッシュ
  • 昔のMobage
    • ワーカーをforkさせておく、それぞれPerlをexec、モジュール読み込みリクエスト処理
  • 最近のMobage
    • fork前にモジュール読み込む、その後ワーカーをfork
    • メモリ節約できる
    • Linuxだと、forkしたプロセスのメモリ領域は書き込まない限り同じ場所を参照する
    • 慎重に移行した
    • socketを開いた状態でforkすると問題が起こる事がある
    • 移行後、メモリ使用量半分になった
  • ページキャッシュの効率化
    • アプリのログがキャッシュされる
    • swapする
    • posix_fadvise(POSIX_FADV_DONTNEED)
    • ファイルをページキャッシュに載せなくする
    • 10秒ごとにログファイルをページキャッシュから追い出す

運用技術 DB編（岩永氏）


  • サーバー多い
  • データでかい
  • トラフィック多い
  • DB
    • Master/Slaveレプリケーション
    • 更新系クエリはMasterに
    • それ以外はSlaveへ
    • Masterへの書き込みがSlaveに即コピーされるわけではない
    • 課金系とかはMasterへ
  • 最初
    • 1データベースに全テーブル入れてた
    • 即あふれた
  • テーブル分割
    • JOIN基本的に使わない方針
  • レコード単位のsharding
    • 分散方法
    • consistent hashingみたいにクライアントサイドで参照先を計算
    • mapping table
    • 参照先が別のところに書いてある
    • mapping tableの方が最近はよく使っている
    • consistent hashingだと2→4→8→16..としか増やせないから無駄が多い
    • map先はmemcachedやアプリ内にキャッシュしておく
    • 両方使っている
    • 全shardを見ないとならないような機能は、基本的にゲームに付けないようにしてもらう
  • auto increment
    • MyISAMのDBを使う
    • SELECT LAST_INSERT_ID()
  • scale back
    • スケールアウトの逆
    • DBをわけちゃったのを集約したい
    • 1台でmysqldを複数起動
    • 1台に仮想IPを複数ふる
    • my.cnfのbind-addressでmysqld複数に振り分ける
    • アプリ側からは今までどおり、複数台のサーバーに分散されているように見える
  • バックアップ
    • サービスに入っていないslaveがいる
    • Master障害時にMasterになる
    • 朝3時にmysqldumpで論理バックアップ
    • バックアップがあると、slaveの追加が容易
  • MHA
    • MySQL Master High Availability
    • バックアップ等の自動化ツール
    • Masterのスキーマの更新にも使える
    • 先にSlaveのスキーマ更新しておいて、最後にMHAでMasterを切り替えるらしい
  • Purge
    • MySQL5.1以前
    • DELETE使うしかない
    • 5.1以降
    • パーティショニングが使える
    • droptable並の速度で消える
    • RANGEパーティションで日付で消せる
  • トラフィック多い
    • indexはった順番を意識してSQL書け
    • 全スキャンしないでほしい
  • ほとんどはプライマリキーで読むことが多い
    • Handler Socket Pluginを使う
    • Memcachedよりも速いというベンチマークもある
    • 元々はMemcachedでやってた
    • MySQLとMemcachedのデータの一貫性を確保するのが面倒だった
    • Handler Socketに一本化
  • updateクエリが多い時
    • SINが落ちる
    • デッドロック
    • DB lockすると他リクエストが困る
    • まず先にアプリからDBにつないで、lockする時間を最小限にするようにコード書く
    • デッドロックしないようにクエリの順番を工夫する
    • 楽観的ロック
  • モニタリング
    • バックアップサーバーの遅延を見る
    • 近いうちにSlaveにも遅延が来る、と予想できる
    • 先読みしてチューニングする
  • SSD使う
    • HDDだと間に合わない時はSSD
    • PCI ExpressのSSDは速いけど高い、まだあまりつかってない
    • SATA SSDを使っている