Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ソーシャルゲームが高負荷に陥っているとき、何が起こっているのか

akihito
September 08, 2018
13k

 ソーシャルゲームが高負荷に陥っているとき、何が起こっているのか

builderscon 2018 の 9/7 セッションのスライドになります

akihito

September 08, 2018
Tweet

Transcript

  1. 開発運営チーム • プロデューサー • ディレクター • プロジェクトマネージャー • レベルデザイナー •

    デザイナー • イラストレーター • クライアントアプリエンジニア • サーバエンジニア • インフラエンジニア • テスター • プロモーション • カスタマーサポート :
  2. ゲームシステムの構成要素 • スマホアプリ(iOS/Android) • アプリ内で保存管理するデータ • マスターデータ (キャラクター/クエスト/武器/装備) • 素材データ

    (画像/音声) • プレイヤー情報 (レベル/進行状況/入手キャラクター) • API (https) • リアルタイム通信 (websocket/photon)
  3. リリースまで 多くのチェックポイントを通過しリリースとなります • αテスト • βテスト • 予測流入数の算出 • 負荷試験

    • 障害試験 (Failover試験) • QA (インゲーム/アウトゲーム/課金試験) • 運用演習 (リリース/データ更新) : :
  4. リリース時サーバ構成 ・アプリケーションサーバ x N台 ・ DB Server Master x 1

    ・ Cache Server(Redis) x 1 ・管理用サーバ(ログサーバ兼用)
  5. 予測流入数を越えてきたので DB Server • DBのインスタンスタイプを変更しスケールアップ • Master x 1 →

    Master x 1 / Slave x 2 • DB SlaveはHAProxyにより分散 WebApp Server • 既にMaster x Slaves構成を考慮し開発をしていた • 事前にピーク時最大アクセス数での負荷試験も終えていた • インスタンスを順次追加(当時はオートスケールではなかった)
  6. ログ集約の流れ WebApp Server Admin Server Log Server Redshi ft S

    3 KPI batch 集計遅延 容量増加 ログ投稿遅延
  7. Webapp Server Realtime Server Room A Room B RoomAの状況を同期 Room

    A Room A Room B Room A Open or Close ? クライアントを介して RoomAの状況を伝える
  8. Webapp Server Realtime Server Room A Room B Room A

    Room A Room B KeyRoomA: open, members, .. KeyRoomB: close, members, .. keys keys keys
  9. Webapp Server Realtime Server Room A Room B Room A

    Room A Room B srandmemb er srandmemb er srandmemb er keys worker sad d
  10. Webapp Server Realtime Server Room A Room B Room A

    Room A Room B srandmember/za dd srandmember/zad d srandmember/zadd zremrangebyscor e worker sad d
  11. 予想アクセス数 • 既存ユーザ数 • 新規ユーザ数 • 復帰ユーザ数 • イベントスケジュールの確認 •

    広告スケジュールの確認 • 短時間あたりの最大アクセス数を見積もる
  12. ログから対応を判断 show processlist のログから以下を実施 • Closing tables/Opening tablesがstatusに頻出 • キャッシュヒットミスが起きている可能性

    • MySQLのtable_open_cache値を上げる • System Lockがstatusに頻出 • アイテムをカウントしているクエリをSlave参照に
  13. アイテムをカウントしているクエリ? SELECT COUNT(*) FROM user_item where type = 1; •

    施策前はレアアイテムだったので手持ちは数個ほどであった • ガチャ施策後一気に行数が増えて1000個を超えるようになった • 結果多くの行を読むクエリが誕生してしまった ↓ • 一部サーバ側でのカウントを停止し、クライアントアプリ側でのカウントを正とする
  14. slow log • min_examined_row_limit=1000を設定していた • レコード数増加によりslow log大量に出力 • 結果Opening Tables/System

    Lockが発生している可能性 ↓ min_examined_row_limit=3000に変更しログ出力を抑制