モンスターストライクにおける
負荷対策
〜エンジニアリングチームの挑戦〜
株式会社ミクシィ
モンスト事業本部 開発室 室長
白川裕介
自己紹介
自己紹介
- 氏名
- 白川裕介
- 経歴
- 2012年に新卒でミクシィに入社。
- SNS「mixi」でアドネットワークを担当したのちXFLAGのアドテクスタジオへ異動
- その後、モンストの開発に携わりマネージャーを経験
- 現在では開発室の室長として、モンストに関わるエンジニア組織を統括
モンスターストライク
モンスターストライク
自分のモンスターを引っ張って弾き、敵のモンスターに当てて倒していくという、スマートフォンの特性を活用した、
誰でも簡単に楽しめるアクションRPGです。ゲームはターン制をとっており、
一緒にいる友だちと最大4人まで同時に遊べる協力プレイ(マルチプレイ)が特長です。
2013年の10月の提供開始から現在※までの世界累計利用者数4,900万人を突破
※ 2018年12月時点
「世界累計利用者数 4,900万人を突破したスマホアプリ」
アジェンダ
モンスターストライクのアーキテクチャ構成
モンスターストライクのこれまでの負荷対策
2018年の年末に向けて実施した対策
結果(2019年を迎えて)
まとめ
◆
◆
◆
◆
◆
アーキテクチャ構成
アーキテクチャ構成
LB
App
App
App
DB(master) DB(backup)
Redis
Memcached
batch
Turn
アーキテクチャ構成
• 本番稼働中のサーバーはトータルで1,000台前後
• Turnサーバーを利用しマルチプレイを実現
• Resqueを利用した非同期処理
• バックエンドはRedis
• ハイブリッド構成
• 自社DCのオンプレサーバーとクラウドサーバーの併用
• DCの冗長構成
• 2つDCを利用しDCレベルでの冗長化
監視システム
• Nagios
• サーバー監視
• kibana
• ログ可視化
• CloudForecast
• リソースのモニタリング
• Grafana
• APIリクエストなどをモニタリング
負荷対策
モンストにおける負荷対策
• データベース
• 水平分割 / 垂直分割
• Indexやクエリの最適化
• 高性能なマシンを投入 (高いIO性能を出せるもの)
• IOMemory / NVMe
• memcached
• DB性能限界へのアプローチとしてCacheを用いる
• Cacheの比重が大きい
• app <=> memcached の往復が100回を超えるAPIもある
モンストにおける負荷対策
• アクセスの増大が予想されるタイミング
• コラボ開始のタイミング
• コラボ限定のガチャやクエストが開始
• 限定クエストが初めて開催されるタイミング
• 限定アイテムが配布されるタイミング
• 対応
• Appサーバーのスケールアウト
• 事前に負荷が想定されるDBをスケールアップ
年末年始のモンスト
• 年越しと共にアクセスが急増しピークを迎える
• 主に0時から始まるガチャがメイン
• 年越しのタイミングでログイン処理が急増
• APIリクエストが滞留
• データベースでslowクエリ多発
• 2016年はサーバー負荷による緊急メンテを実施
• 2017年は2時間程度アクセスが重い状況
• DBのシャーディングによる負荷分散
• https://speakerdeck.com/haman29/bcu-30-server-9
2018年の年末に向けて
• 昨年は緊急メンテは未実施とはいえ
• 快適なサービスの提供はできていない
• 振り返るともっとやれたことはあった
• 今年はやれることは全部やる
• やっておけばよかったという後悔はしない
• 昨年は実施しなかったアプリケーションの最適化
• クライアントエンジニアも負荷対策に巻き込む
2018年の年末に向けて
• アプリケーションからのアプローチ
• クライアント / サーバー双方からのアプローチ
• インフラからのアプローチ
• 年末に向けて機器調達や回線増強
• サーバー機器のスケールアップ
• これまでの負荷対策のメイン
アプリケーションからのアプローチ
アプリケーションからのアプローチ
• これまでの傾向から対応ポイントを絞る
• ピーク時はログイン処理で詰まる
• 年越しのタイミングでユーザはタイトルに戻る
• ボトルネック部分を見つけ出し対処
• ログイン時に必要な処理の改修
• App timeの長いAPIを高速化
アプリケーションからのアプローチ
• ログイン時に必要な処理を改修
• モンストはログイン時にデータを一気に取得する
• ログイン時の処理は5年間積み上がっている
• 改修はほとんど実施されていない
• 今回はログインフローに手を入れる
アプリケーションからのアプローチ
• アプリ起動からホーム画面に遷移するのに必要なAPI
• 合計: 13本
• これらのリクエストがすべて成功した場合のみOK
• 1つでも失敗すると最初からやりなおし
アプリケーションからのアプローチ
• 対応
• ログイン時に13本必要だったAPIを3本にまとめる
• 各APIの処理も軽量化できるものは改修
• 効果
• 高負荷時のログイン成功確率が増加
• 必要な帯域を減らせる
アプリケーションからのアプローチ
• App timeの長いAPIを高速化
• ログイン時に必要なAPIで致命的に遅いものがあった
• ユーザの所持しているキャラクターを全て取得するAPI
• 高負荷時には指数関数的に遅くなる
• 1ユーザにつき最大4200体所持可能
アプリケーションからのアプローチ
• ユーザが所有しているすべてのキャラ情報を取得
• 全所有キャラ毎にアソシエーションに任せて全件取得
• 機能によっては1ユーザで最大5体のみ所持可能な情報も最大4200体で検索
• N+1問題が発生していた
• 対応
• 事前に付随する情報のリストを取得し保持
• その後に取得したユーザが所持する全キャラを取得
• その2つの情報を照らし合わせてつなぎ合わせる
• 最大で4200回発行していたクエリが1回に削減
アプリケーションからのアプローチ
• リリース後の効果
インフラからのアプローチ
インフラからのアプローチ
• 通常時のappサーバー
• CPUコア数換算で13,000core
• モンストのシステム構成はmemcachedを多用
• memcachedはすべて自社DCのサーバーで運用
• 1つのリクエストで何度もサーバー間の通信が発生
• 自社DCとの物理的距離が大きく影響
• クラウド事業者の選定ではレイテンシーを最重要視
• 複数のクラウド事業者を利用
• 柔軟なリソースの確保が可能
• 障害発生時のリカバリーが可能
インフラからのアプローチ
• Appサーバーの増強がメイン
• リソースの状況
• オンプレサーバーの増強
• DBやmemcachedとの距離が最短
• クラウドサーバーのリソース確保
• ネットワーク帯域の増強
• 各クラウド事業者と弊社DCとの間の専用回線
• 対応
• 年末に向けては 26,000コア を確保
• max connectionの上限まで確保
インフラからのアプローチ
• オンプレサーバーの本番投入時
結果
結果(2019年を迎えて)
• 緊急メンテ
• なし
• レスポンス状況
• 0時から15分程度、動作が重たくなる
• 前年の2時間と比べると大幅な解消
結果(2019年を迎えて)
まとめ
• モンストのサーバー負荷のピークは年末年始
• 5周年を迎えるサービスだがまだまだ改善の余地あり
• 今回はクライアントも巻き込んだ負荷対策を実施
• 実施した負荷対策に関しては確実に効果があり
• 今回の対策を気に次にやるべきことは見えている
• 2019年年末を見据えて動き出している
• max connectionの上限設定見直し
• ログイン処理の根本見直しなどなど…
まとめ
エンジニアリングチームの戦いは終わらない・・・
モンスターストライクにおける負荷対策

モンスターストライクにおける負荷対策