はてな×DeNA 「Mobage 運用技術」勉強会

はてなさんよりお誘いを受けましたので、「Mobage 運用技術」という勉強会に参加してきました。

Mobageを支える技術 ~ソーシャルゲームの舞台裏~ (WEB+DB PRESS plus)

Mobageを支える技術 ~ソーシャルゲームの舞台裏~ (WEB+DB PRESS plus)

場所は渋谷ヒカリエの新オフィスです。


[前半]運用技術Web編:Webサーバーの資源管理について

  • CPUかメモリがネックになる。
  • ソフトウェアではなくハードウエアがネックになる。
  • 工夫しないとメモリ使用量がネックになる
    • メモリ使用量がネックとなってワーカープロセスが苦しくなる
    • ワーカー数が不足すると、CPU使用率が頭打つより前にリクエストをさばけなくなる
  • ワーカープロセスの空きを調べることが重要となる
    • あと何%の余裕があるか、を知りたい
    • スタックトレースを取り、すぐにデタッチする仕組みを作った。全プロセスのスタックトレースを一定周期で取得。リクエストを待っているプロセスが「空き」
    • gdbを使ってスタックトレースを取っていたが、今はbulkdbgというのを作って利用している
      • gdbでは、アタッチされたプロセスは、シンボルを解決するのに時間がかかる
    • accept()でブロックしているワーカーの数が減ってきたら枯渇が近い。メールで警告
    • Cのスタックトレースではなく、Perlスタックトレースも見たい。
      • 作った。
    • OSページキャッシュ利用の効率化。ページキャッシュ利用の効率化。
      • アプリのログを大量にはいている。ログファイルがOSキャッシュされてしまう。ログ回収のタイミングでSWAPしてしまう

[後半]運用技術DB編:Mobage MySQL運用

  • MySQLはMasterとSlabeが非同期。
    • CUDとクリティカルなものはMaster。それ以外はSlabe
  • シャーディング(入りきらないものを別DBに出すこと)
    • 最初は、テーブル単位で分割する。レプリーケーションでDBを分ける。
    • JOINできなくなる。基本的にJOINしないように作るように指示している。
  • 次はレコードベースで振り分ける。
    • 1.MemcacheDのイメージで、IDキーにたいして振り分けるハッシュを使う
    • 2.マッピングの情報自体を別の場所に持たせて、振り分ける。
    • マッピングテーブルで振り分けることが多い。レプリケーションが増えることで、管理が大変だから。(例:1→2→4→8)
    • マッピングテーブルはキャッシュする。1回聞けばOKとなっている。コードでわけるとJOINは可能だが、レンジスキャンができない。もしくは非同期でシャードをなめて更新するような仕組みを作る
  • オートインクリメントの注意
    • レコード単位で分けたい場合に、シャードごとに払い出されるとまずい。
    • MyISAMのSequenceテーブルで、アプリケーション採番する。
    • MyISAMは重くなるんでは・・・と思われるかもですが、大丈夫。
  • マルチインスタンス
    • MySQLはMasterが1つ。MySQLのデータマージは難しい。
    • そのため、1OSにMySQLdを複数上げる。仮想IPをOSに割り振って、my.cnfで設定する
    • ポートでは、アプリの管理が大変になる。IPのほうがアプリ管理が簡単。
  • バックアップサーバー
    • マスター1台でも、サーバーは2台になる。仕組み上はSlave
    • ユーザーからのリクエストが来ないSlave
    • Masterが落ちた時に、代わりにMasterになる。そして、MySQLDumpでダンプを取っている。
  • MHA
    • ツール。バックアップのMasterかを自動化。
  • パージ
    • 5.1より前。DELETEするしかない。レンジのWHERE句で消すはしない。IDを取っておいて、コツコツ消す。
    • 5.1以降は、Partitionをドロップする。パーティションをドロップできるので、簡単
  • ハイトラフィック
    • レンジスキャンに注意してと言っている
    • インデックスの張り方も想定しないと駄目。
    • 特定条件のユーザーを取りたいというときに、カラムとINDEXの設計をちゃんと考えないとだめ。
    • ほとんどはPKで引くはず。独自ミドルウェア、HandlerSocketPlugIn(松延いわくMemcachedより早いだろう)
  • 一貫性が大事。Memcahced
    • DB更新を検知するトリガから、Memcachedを更新する必要がある。
    • HandlerSocketPluginを使うほうが簡単
  • 更新
    • ロック時間を短くすることが重要。
    • ネットワーク接続がSINが落ちてしまう。ロック中に落ちるとまずい。
    • まず複数DBにコネクションをかけるコネクション張り終わってからロック。
    • Masterに一括更新することがある。
    • デットロックが1つのDBで起きた場合はMySQLは検知してくれる。複数の場合は検知できない。
    • 基本はソート順と更新順が重要。全DBに対しての管理は難しい。
    • その場合、ロックは楽観ロックを使っている。バージョンを条件に入れる。
  • レプリケーション遅延
    • バックアップサーバーの遅延がおきたら、
    • Slaveでも遅延がおきる。(スペックの違い)
    • クエリの数を減らさないといけない。
  • SSD

懇親会

  • 24F DeNA Sakura Cafeはおしゃれでした。うらやましい。
  • 海外展開を進めているので、海外で働きたい人募集中。
  • 作ったツールOSS化について質問したら「OSSを作ろうとしているわけではないが、一度自分たちで使ったもので良いものは前向きに共有している」とのこと。
  • エラーメールは携帯電話に届く。重要なものは運用保守会社から電話でエスカレーションがある
  • 運用保守の仕方は結構スタンダードでした。運用保守上の障害パターンは大体出尽くしているので夜間対応などはそれほど大変ではないとのこと。

色々と学べることが多い良い勉強会でした。