Downloaded 67 times
モンスターストライクにおける負荷対策
- 1.
- 2.
- 3. 自己紹介 - 氏名 - 白川裕介 -経歴 - 2012年に新卒でミクシィに入社。 - SNS「mixi」でアドネットワークを担当したのちXFLAGのアドテクスタジオへ異動 - その後、モンストの開発に携わりマネージャーを経験 - 現在では開発室の室長として、モンストに関わるエンジニア組織を統括
- 4.
- 5.
- 6.
- 7.
- 8.
- 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.
- 32. まとめ • モンストのサーバー負荷のピークは年末年始 • 5周年を迎えるサービスだがまだまだ改善の余地あり •今回はクライアントも巻き込んだ負荷対策を実施 • 実施した負荷対策に関しては確実に効果があり • 今回の対策を気に次にやるべきことは見えている • 2019年年末を見据えて動き出している • max connectionの上限設定見直し • ログイン処理の根本見直しなどなど…
- 33.