Submit Search
Upload
モンスターストライクにおける負荷対策
•
Download as PPTX, PDF
•
4 likes
•
5,473 views
Yusuke Shirakawa
Follow
〜エンジニアリングチームの挑戦〜
Read less
Read more
Engineering
Report
Share
Report
Share
1 of 34
Download now
Recommended
Arxan導入前後で変わったこと
Arxan導入前後で変わったこと
Yusuke Shirakawa
はじめてのPRD
はじめてのPRD
Takuya Oikawa
大規模トラフィックにどのように備えて負荷対策を実施しているのか?
大規模トラフィックにどのように備えて負荷対策を実施しているのか?
Yusuke Shirakawa
ウェブセキュリティのありがちな誤解を解説する
ウェブセキュリティのありがちな誤解を解説する
Hiroshi Tokumaru
実践 NestJS
実践 NestJS
Ayumi Goto
イベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法
Tetsutaro Watanabe
PHPで大規模ブラウザゲームを開発してわかったこと
PHPで大規模ブラウザゲームを開発してわかったこと
Kentaro Matsui
Recommended
Arxan導入前後で変わったこと
Arxan導入前後で変わったこと
Yusuke Shirakawa
はじめてのPRD
はじめてのPRD
Takuya Oikawa
大規模トラフィックにどのように備えて負荷対策を実施しているのか?
大規模トラフィックにどのように備えて負荷対策を実施しているのか?
Yusuke Shirakawa
ウェブセキュリティのありがちな誤解を解説する
ウェブセキュリティのありがちな誤解を解説する
Hiroshi Tokumaru
実践 NestJS
実践 NestJS
Ayumi Goto
イベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法
Tetsutaro Watanabe
PHPで大規模ブラウザゲームを開発してわかったこと
PHPで大規模ブラウザゲームを開発してわかったこと
Kentaro Matsui
新入社員のための大規模ゲーム開発入門 サーバサイド編
新入社員のための大規模ゲーム開発入門 サーバサイド編
infinite_loop
採用スライド2022.pdf
採用スライド2022.pdf
AyumiYoanSato
WebAssemblyのWeb以外のことぜんぶ話す
WebAssemblyのWeb以外のことぜんぶ話す
Takaya Saeki
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
あなたはPO?PM?PdM?PjM?
あなたはPO?PM?PdM?PjM?
大貴 蜂須賀
Pythonによる黒魔術入門
Pythonによる黒魔術入門
大樹 小倉
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Yoshinori Matsunobu
TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
こわくない Git
こわくない Git
Kota Saito
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
Hiroshi Ito
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門
Etsuji Nakai
SQLアンチパターン - ジェイウォーク
SQLアンチパターン - ジェイウォーク
ke-m kamekoopa
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
Ormとの付き合い方
Ormとの付き合い方
豊明 尾古
DockerコンテナでGitを使う
DockerコンテナでGitを使う
Kazuhiro Suga
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
異次元のグラフデータベースNeo4j
異次元のグラフデータベースNeo4j
昌桓 李
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
モンスターストライクにおける監視システムのあれこれ
モンスターストライクにおける監視システムのあれこれ
Yusuke Shirakawa
クリエイターに大切なモノ
クリエイターに大切なモノ
Wataru Ito
More Related Content
What's hot
新入社員のための大規模ゲーム開発入門 サーバサイド編
新入社員のための大規模ゲーム開発入門 サーバサイド編
infinite_loop
採用スライド2022.pdf
採用スライド2022.pdf
AyumiYoanSato
WebAssemblyのWeb以外のことぜんぶ話す
WebAssemblyのWeb以外のことぜんぶ話す
Takaya Saeki
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
あなたはPO?PM?PdM?PjM?
あなたはPO?PM?PdM?PjM?
大貴 蜂須賀
Pythonによる黒魔術入門
Pythonによる黒魔術入門
大樹 小倉
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Yoshinori Matsunobu
TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
こわくない Git
こわくない Git
Kota Saito
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
Hiroshi Ito
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門
Etsuji Nakai
SQLアンチパターン - ジェイウォーク
SQLアンチパターン - ジェイウォーク
ke-m kamekoopa
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
Ormとの付き合い方
Ormとの付き合い方
豊明 尾古
DockerコンテナでGitを使う
DockerコンテナでGitを使う
Kazuhiro Suga
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
異次元のグラフデータベースNeo4j
異次元のグラフデータベースNeo4j
昌桓 李
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
What's hot
(20)
新入社員のための大規模ゲーム開発入門 サーバサイド編
新入社員のための大規模ゲーム開発入門 サーバサイド編
採用スライド2022.pdf
採用スライド2022.pdf
WebAssemblyのWeb以外のことぜんぶ話す
WebAssemblyのWeb以外のことぜんぶ話す
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
あなたはPO?PM?PdM?PjM?
あなたはPO?PM?PdM?PjM?
Pythonによる黒魔術入門
Pythonによる黒魔術入門
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
TLS, HTTP/2演習
TLS, HTTP/2演習
こわくない Git
こわくない Git
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門
SQLアンチパターン - ジェイウォーク
SQLアンチパターン - ジェイウォーク
Tackling Complexity
Tackling Complexity
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
Ormとの付き合い方
Ormとの付き合い方
DockerコンテナでGitを使う
DockerコンテナでGitを使う
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
異次元のグラフデータベースNeo4j
異次元のグラフデータベースNeo4j
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
Similar to モンスターストライクにおける負荷対策
モンスターストライクにおける監視システムのあれこれ
モンスターストライクにおける監視システムのあれこれ
Yusuke Shirakawa
クリエイターに大切なモノ
クリエイターに大切なモノ
Wataru Ito
『ポコロンダンジョンズ』エフェクトや演出制作ノウハウ
『ポコロンダンジョンズ』エフェクトや演出制作ノウハウ
GameCreators,CyberAgent
クラッシュフィーバー開発の裏側
クラッシュフィーバー開発の裏側
Tomotsune Murata
ポコロンダンジョンズを彩るアニメーションノウハウ
ポコロンダンジョンズを彩るアニメーションノウハウ
GameCreators,CyberAgent
VR空間特有のリアルを追え 〜メイキング「エニグマスフィア」
VR空間特有のリアルを追え 〜メイキング「エニグマスフィア」
Yomuneco
元ソシャゲプランナー幻談
元ソシャゲプランナー幻談
YukiSamuraki
Similar to モンスターストライクにおける負荷対策
(7)
モンスターストライクにおける監視システムのあれこれ
モンスターストライクにおける監視システムのあれこれ
クリエイターに大切なモノ
クリエイターに大切なモノ
『ポコロンダンジョンズ』エフェクトや演出制作ノウハウ
『ポコロンダンジョンズ』エフェクトや演出制作ノウハウ
クラッシュフィーバー開発の裏側
クラッシュフィーバー開発の裏側
ポコロンダンジョンズを彩るアニメーションノウハウ
ポコロンダンジョンズを彩るアニメーションノウハウ
VR空間特有のリアルを追え 〜メイキング「エニグマスフィア」
VR空間特有のリアルを追え 〜メイキング「エニグマスフィア」
元ソシャゲプランナー幻談
元ソシャゲプランナー幻談
モンスターストライクにおける負荷対策
1.
モンスターストライクにおける 負荷対策 〜エンジニアリングチームの挑戦〜 株式会社ミクシィ モンスト事業本部 開発室 室長 白川裕介
2.
自己紹介
3.
自己紹介 - 氏名 - 白川裕介 -
経歴 - 2012年に新卒でミクシィに入社。 - SNS「mixi」でアドネットワークを担当したのちXFLAGのアドテクスタジオへ異動 - その後、モンストの開発に携わりマネージャーを経験 - 現在では開発室の室長として、モンストに関わるエンジニア組織を統括
4.
モンスターストライク
5.
モンスターストライク 自分のモンスターを引っ張って弾き、敵のモンスターに当てて倒していくという、スマートフォンの特性を活用した、 誰でも簡単に楽しめるアクションRPGです。ゲームはターン制をとっており、 一緒にいる友だちと最大4人まで同時に遊べる協力プレイ(マルチプレイ)が特長です。 2013年の10月の提供開始から現在※までの世界累計利用者数4,900万人を突破 ※ 2018年12月時点 「世界累計利用者数 4,900万人を突破したスマホアプリ」
6.
アジェンダ モンスターストライクのアーキテクチャ構成 モンスターストライクのこれまでの負荷対策 2018年の年末に向けて実施した対策 結果(2019年を迎えて) まとめ ◆ ◆ ◆ ◆ ◆
7.
アーキテクチャ構成
8.
アーキテクチャ構成 LB App App App DB(master) DB(backup) Redis Memcached batch Turn
9.
アーキテクチャ構成 • 本番稼働中のサーバーはトータルで1,000台前後 • Turnサーバーを利用しマルチプレイを実現 •
Resqueを利用した非同期処理 • バックエンドはRedis • ハイブリッド構成 • 自社DCのオンプレサーバーとクラウドサーバーの併用 • DCの冗長構成 • 2つDCを利用しDCレベルでの冗長化
10.
監視システム • Nagios • サーバー監視 •
kibana • ログ可視化 • CloudForecast • リソースのモニタリング • Grafana • APIリクエストなどをモニタリング
11.
負荷対策
12.
モンストにおける負荷対策 • データベース • 水平分割
/ 垂直分割 • Indexやクエリの最適化 • 高性能なマシンを投入 (高いIO性能を出せるもの) • IOMemory / NVMe • memcached • DB性能限界へのアプローチとしてCacheを用いる • Cacheの比重が大きい • app <=> memcached の往復が100回を超えるAPIもある
13.
モンストにおける負荷対策 • アクセスの増大が予想されるタイミング • コラボ開始のタイミング •
コラボ限定のガチャやクエストが開始 • 限定クエストが初めて開催されるタイミング • 限定アイテムが配布されるタイミング • 対応 • Appサーバーのスケールアウト • 事前に負荷が想定されるDBをスケールアップ
14.
年末年始のモンスト • 年越しと共にアクセスが急増しピークを迎える • 主に0時から始まるガチャがメイン •
年越しのタイミングでログイン処理が急増 • APIリクエストが滞留 • データベースでslowクエリ多発 • 2016年はサーバー負荷による緊急メンテを実施 • 2017年は2時間程度アクセスが重い状況 • DBのシャーディングによる負荷分散 • https://speakerdeck.com/haman29/bcu-30-server-9
15.
2018年の年末に向けて • 昨年は緊急メンテは未実施とはいえ • 快適なサービスの提供はできていない •
振り返るともっとやれたことはあった • 今年はやれることは全部やる • やっておけばよかったという後悔はしない • 昨年は実施しなかったアプリケーションの最適化 • クライアントエンジニアも負荷対策に巻き込む
16.
2018年の年末に向けて • アプリケーションからのアプローチ • クライアント
/ サーバー双方からのアプローチ • インフラからのアプローチ • 年末に向けて機器調達や回線増強 • サーバー機器のスケールアップ • これまでの負荷対策のメイン
17.
アプリケーションからのアプローチ
18.
アプリケーションからのアプローチ • これまでの傾向から対応ポイントを絞る • ピーク時はログイン処理で詰まる •
年越しのタイミングでユーザはタイトルに戻る • ボトルネック部分を見つけ出し対処 • ログイン時に必要な処理の改修 • App timeの長いAPIを高速化
19.
アプリケーションからのアプローチ • ログイン時に必要な処理を改修 • モンストはログイン時にデータを一気に取得する •
ログイン時の処理は5年間積み上がっている • 改修はほとんど実施されていない • 今回はログインフローに手を入れる
20.
アプリケーションからのアプローチ • アプリ起動からホーム画面に遷移するのに必要なAPI • 合計:
13本 • これらのリクエストがすべて成功した場合のみOK • 1つでも失敗すると最初からやりなおし
21.
アプリケーションからのアプローチ • 対応 • ログイン時に13本必要だったAPIを3本にまとめる •
各APIの処理も軽量化できるものは改修 • 効果 • 高負荷時のログイン成功確率が増加 • 必要な帯域を減らせる
22.
アプリケーションからのアプローチ • App timeの長いAPIを高速化 •
ログイン時に必要なAPIで致命的に遅いものがあった • ユーザの所持しているキャラクターを全て取得するAPI • 高負荷時には指数関数的に遅くなる • 1ユーザにつき最大4200体所持可能
23.
アプリケーションからのアプローチ • ユーザが所有しているすべてのキャラ情報を取得 • 全所有キャラ毎にアソシエーションに任せて全件取得 •
機能によっては1ユーザで最大5体のみ所持可能な情報も最大4200体で検索 • N+1問題が発生していた • 対応 • 事前に付随する情報のリストを取得し保持 • その後に取得したユーザが所持する全キャラを取得 • その2つの情報を照らし合わせてつなぎ合わせる • 最大で4200回発行していたクエリが1回に削減
24.
アプリケーションからのアプローチ • リリース後の効果
25.
インフラからのアプローチ
26.
インフラからのアプローチ • 通常時のappサーバー • CPUコア数換算で13,000core •
モンストのシステム構成はmemcachedを多用 • memcachedはすべて自社DCのサーバーで運用 • 1つのリクエストで何度もサーバー間の通信が発生 • 自社DCとの物理的距離が大きく影響 • クラウド事業者の選定ではレイテンシーを最重要視 • 複数のクラウド事業者を利用 • 柔軟なリソースの確保が可能 • 障害発生時のリカバリーが可能
27.
インフラからのアプローチ • Appサーバーの増強がメイン • リソースの状況 •
オンプレサーバーの増強 • DBやmemcachedとの距離が最短 • クラウドサーバーのリソース確保 • ネットワーク帯域の増強 • 各クラウド事業者と弊社DCとの間の専用回線 • 対応 • 年末に向けては 26,000コア を確保 • max connectionの上限まで確保
28.
インフラからのアプローチ • オンプレサーバーの本番投入時
29.
結果
30.
結果(2019年を迎えて) • 緊急メンテ • なし •
レスポンス状況 • 0時から15分程度、動作が重たくなる • 前年の2時間と比べると大幅な解消
31.
結果(2019年を迎えて)
32.
まとめ • モンストのサーバー負荷のピークは年末年始 • 5周年を迎えるサービスだがまだまだ改善の余地あり •
今回はクライアントも巻き込んだ負荷対策を実施 • 実施した負荷対策に関しては確実に効果があり • 今回の対策を気に次にやるべきことは見えている • 2019年年末を見据えて動き出している • max connectionの上限設定見直し • ログイン処理の根本見直しなどなど…
33.
まとめ エンジニアリングチームの戦いは終わらない・・・
Download now