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

　はてなの方からメールにて招待いただき（ありがとうございます！）、折角だからと体調悪い上に台風近づいてるにも関わらず昨日行って来ました。
　口外するな、と書かれていたので、相当やばい情報も話してくれるのか、とか、「活発に」リクルーターが話しかけにきてくれたりするのか、とか、妙な妄想たっぷりで臨んだのですが、その辺は見事に裏切られ、発表内容は「Mobageを支える技術」にほぼ含まれていて、リクルートエージェントについては、基本裏方にいるだけで、最後にアンケート書くだけで終わってしまいました。なんか残念。

　以下、発表内容のメモ（他の方の方がより詳しいかも。。。）

Mobage 運用技術 Web編

• speaker: 樋口さん

• Mobageのサーバ群構成について
  • 基本的にLAMP
  • HTTPサーバ（Apache）とFastCGIアプリのプロセスが同期
    • UNIX domain socket
    • ゲームごとに変えたりしていない。一枚岩
• Webサーバ機の資源管理について
  • FastCGIワーカー数の管理
    • メモリ量がまたはCPU使用率がネック
      • ほぼPerlだけど、ちょっとだけC
      • ソフトウェア起因のネックはない
      • １枚岩アプリなので、メモリ使用量が1GB超える
    • メモリ使用量がネック
      • サーバ１台あたり〜100プロセス程度
      • FastCGIワーカープロセス数は、CPUコア数の２〜３倍は必要
      • ワーカー数が不測すると、リクエストを捌き切れない
      • 多ければ多いほど耐障害性が高まる
        • バックエンドのDBなどが詰まった時に影響を受けにくくなる
        • でも、増やしすぎるとメモリ不足
  • デバッガを使った状況モニタリング
    • ワーカープロセスがいくつ空いてるか
      • あと何%余裕あるか
      • 走っているプロセスにデバッガをアタッチする
      • スタックトレースを取り、すぐにデタッチ
      • 前プロセスのスタックトレースを一定周期で取得
      • HTTPDとFastCGIプロセスが対象
      • リクエスト受付状態にあるプロセスが「空き」
    • bulkdbgというツールを作った。gdb遅い
      • ５秒おきにhttpdとFastCGIの前プロセスのスタックトレースを取得、ログに出力
      • オーバーヘッドほぼなし
      • acceptでブロックしているワーカーの数が減ってきたら枯渇が近い
        • メールで警告
  • 障害調査の手法
    • Perlのスタックトレースと言っても、gdbで見れるのはCのもの
    • Perlコードのどこを実行中なのか知りたい
      • gdbperl.plを作った（これ、去年のYAPCのだ）
      • Perlがデバッグシンボル付きでコンパイルされていないと動かないけど。。。
      • よくやること
        • gdbperl.plをアタッチ
        • straceをアタッチ
        • bolkdbgを使ったモニタリング
        • NYTProfでプロファイルデータ取得
        • DBアクセス等のログ
• メモリ利用効率化のための取り組み
  • 使用するPerlモジュールがなるべく独立しているようなサーバグループに分ける
  • 他に
    • Perlモジュールプリロード
    • OSページキャッシュ利用の効率化
  • 昔： forkされたワーカープロセスがPerlをexecしてモジュールを読む
  • 今： アプリのモジュールを読み込んだあとにワーカープロセスをforkしリクエスト処理
  • 今の方式へは時間をかけて慎重に移行
    • forkのタイミングでsocket等を開いたままだと問題を起こす
    • 処理の実行順序が変わることによる影響もあった
    • 移行後、メモリ使用量が半分になった
  • アプリが吐くログファイルがキャッシュされてしまう
    • メモリ足りないと１日１回のログ改修のタイミングでswapする
  • posix_fadvise(POSIX_FADV_DONTNEED)
    • これを１０秒に１回、ログファイルをposix_fadviseするdaemonを動かす
      • ログがキャッシュに乗らなくなり、swapもしなくなった

Mobage 運用技術 DB編

• speaker: 岩永さん（りーおさん）

• Many Servers
  • スケールアウト:レプリケーション
  • スレーブへの情報の遅延が起こりうるので、クリティカルな情報へのselectはmasterへ
  • シャーディング
    • １つのデータベースに入りきらないデータを分散して登録
      • 負荷分散
      • joinするSQLは書けない
      • DeNAはjoinなるべくかかない
    • レコード単位でのシャーディング
      • クライアント側でどのレコードがどこにあるかを保持する必要がある
    • 2で割るとか4で割るとかの方法は段々数が増えるからよくない
    • memcachedやアプリのメモリに、そのマッピングテーブルを保持する
  • auto increment
    • レコード単位でのシャーディングとなると問題になる
    • ソレ用にMyISAMのDBを用意して、そこから発番
      • DeNAレベルで問題になってない
  • マルチインスタンス
    • mysqldを１マシンに複数上げる
    • マシン上に仮想IPを用意して、my.cnfのbind-addressをそれぞれ指定
  • バックアップ
    • 通常のスレーブではあるが、リクエストは来ない
      • アクティブスタンバイ
      • バックアップのダンプを流し込めばすぐにslaveができる
  • MHA
    • マスターが落ちた時にバックアップを昇格させる

• Big Data
  • Purge
    • 古いデータを消す
  • データが増えると劣化する
  • 性能を維持するには、レコード数をある程度にする
  • 5.1時代はDELETEするしかない
    • でないと運用に支障がでる
    • 5.1移行はすぐできる
      • range partition

• High Traffic
  • range scanには気をつけろとよく言ってる
  • なるべくPrimary Keyで引っ張る
    • それなんてhandler socket
  • memcachedとmysqlでデータのストアが２層になる
    • memcachedへのデータ更新。。。
    • なので、Handler Socketでmemcached使わずに済む
  • 5.6ではmemcached APIがサポートされた
  • update は色々ネック
    • ちょっとしたことがネックになる
      • SIN？
  • マスターサーバに対する更新の場合、デッドロックが起こりうる
  • Optimistic Lock
  • レプリケーションの遅延の測り方
    • バックアップサーバの遅延をモニタリングする
    • SSD
      • slaveはかなりの量がSSD
      • レプリ遅延が少ない
    • SATA-SSDが今のところ一番リーズナブル

　懇親会（但し酒はない）の時にりーおさんと話す機会があったのですが、特にDB周りについては、あまり独自のことはせずに、MySQL自体のバージョンアップに任せるとか、MySQLの仕様をきっちり理解した上でアプリで本当にやりたいことを曲げずに、基本に忠実なチューニングで対処できるようにするか、という辺りに気を配っている印象でした。また、樋口さんともお話させていただいて、去年のYAPC::Asiaの発表見てました！と伝えられたのがよかった。あの発表はこういうところに使われていたんですね。
　にしても、テーブルを囲んで話してる中で、DeNAのT部さんが「Perl使ってる人ー」と言って手を上げたのが自分だけだった。。。