読者です 読者をやめる 読者になる 読者になる

taiyoh's memorandum

@ttaiyoh が、技術ネタで気づいたことを書き溜めておきます。

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

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

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

Mobage 運用技術 Web編

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

Mobage 運用技術 DB編

  • speaker: 岩永さん(りーおさん)
  • Many Servers
    • スケールアウト:レプリケーション
    • スレーブへの情報の遅延が起こりうるので、クリティカルな情報へのselectはmasterへ
    • シャーディング
      • 1つのデータベースに入りきらないデータを分散して登録
        • 負荷分散
        • joinするSQLは書けない
        • DeNAはjoinなるべくかかない
      • レコード単位でのシャーディング
        • クライアント側でどのレコードがどこにあるかを保持する必要がある
      • 2で割るとか4で割るとかの方法は段々数が増えるからよくない
      • memcachedやアプリのメモリに、そのマッピングテーブルを保持する
    • auto increment
      • レコード単位でのシャーディングとなると問題になる
      • ソレ用にMyISAMのDBを用意して、そこから発番
        • DeNAレベルで問題になってない
    • マルチインスタンス
      • mysqldを1マシンに複数上げる
      • マシン上に仮想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でデータのストアが2層になる
      • 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使ってる人ー」と言って手を上げたのが自分だけだった。。。