「WFS Tech Talk #2」で発表された資料です。 https://gree.connpass.com/event/158257/

1. リリースを支える負荷試験
2020.1.14
藤田 貴大

2. 自己紹介
• 藤田 貴大 @takfjt
• WFS サーバエンジニア
• (前職)組み込み → (転職)インフラ → Webゲーム
→ QA → WFSサーバ

3. 開発体制について

4. 開発体制
インフラチーム サーバチーム
プロダクトチーム プロダクトチーム プロダクトチーム
プロダクトチーム プロダクトチーム プロダクトチーム

5. サーバチーム
プロダクトチーム プロダクトチーム プロダクトチーム
プロダクトチーム プロダクトチーム プロダクトチーム
担当としてプロダクトチームの中で開発
私は全体のサポート

6. プロダクトチーム プロダクトチーム プロダクトチーム
インフラチーム
インフラチーム
プロダクトチーム プロダクトチーム プロダクトチーム
プラットフォーム (GCP, AWS)
ミドルウェア (K8s, MySQL, etc…)
モニタリング (Grafana, sumologic, etc…)

7. 今回の話

8. なぜ、負荷試験？

9. ゲームはリリースが大切
●スケジュールは入念に計画されている
●CM、広告、生放送、etc...
●原作があるものであれば、テレビ放映や
映画上映にタイミングをあわせることも

10. サーバエンジニアが
最も恐れること

11. リリース後
即メンテ

12. どれくらい止まるのか
●サーバ追加 ⇒ 数時間
●バグ修正 ⇒ 数時間〜数日
●けっこう根本的な見直し ⇒ 数週間
●イチから書き直し ⇒ 数ヶ月？

13. 負荷対策は必須

14. どういう対策をする？

15. ”計測すべし。計測するまでは
速度のための調整をしてはならない”
-- Rob Pike
http://www.lysator.liu.se/c/pikestyle.html
邦訳参照
https://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6

16. ということで計測
↓
負荷試験

17. 確認したいこと
• 想定した負荷をかけて問題無く動作すること
• 過大な負荷をかけたとき、まずどこがボトル
ネックになるのかが明らかになること
• 想定より負荷が高いAPIがないか確認すること

18. 想定した負荷

19. ユーザの量と行動を
想定した負荷

20. ユーザの量
• プロダクトに試算してもらう
• 過去の経験

21. ユーザの行動
• 実際にプレイしたAPIアクセスと
リクエスト、レスポンスの情報を準備して貰う
• インタビューして、だいたいの動作を想定する
• 最終的には、簡易的にゲームアプリ相当の
処理を実装することになる（つらい）

22. 負荷試験ツール
• 既存のツールを使う(Locust)
• 自分で作る
• 要求すること
• dockerイメージを作ってKubernetesで運用
• WorkerからMasterに接続

23. Master
Worker
Worker
Worker
Worker
Worker
Worker
Kubernetes + Workerから接続
Worker Worker Worker
• 環境構築が簡単
• 台数が多いと費用もかかる
• ReplicaSetだけでWorkerの
数を制御できる
• Masterへの接続は名前解決に任せ
られる

24. Kubernetes
• 負荷試験では必需品
• 本番のゲームサーバもKubernetesを使っています
• 今後も利用する予定です
• Kubernetesによる運用は現在進行形で
経験値を蓄積中です

25. 実施

26. 負荷試験環境
• 本番相当の環境
• リリース前の本番環境をつかっています
• タイミングによっては、そのまま本番投入
• 本番相当のモニタリングが必須

27. MySQL
Redis
Memcached
ゲームサーバ
モニタリング
負荷計測ツール
Master
Workers
構成図

28. 負荷試験ツール モニタリング (CPU)
試験中画面の例

29. やってみると

30. 次々と現れるボトルネックや不具合
ちょっとの負荷で落ちるAPIサーバ
飽和するMemcached
失敗する名前解決
Bad Gateway
何故か偏るDB負荷
跳ね上がるログの量

31. 地道に解決
• ちょっとの負荷で落ちるAPIサーバ
→ Dockerコンテナ内の設定漏れ
• 飽和するMemcached
→ サーバ追加
• 失敗する名前解決
→ DNSキャッシュサーバを設置

32. 地道に解決
• Bad Gateway
→ ロードバランサとAPIサーバの
KeepAlive設定のミス
• 何故か偏るDB負荷
→ 負荷試験ツールのバグ
• 跳ね上がるログの量
→ 開発モードの状態で大量のデバッグログを
出している状態で、本番相当の負荷を
かけてしまった

33. その他
• モニタリングの調整なども同時進行で実施
• 数値がおかしい
• こういうグラフが欲しいなど
• インフラチームと連携
• 想定以上の負荷が発生したとき
DBのレイテンシが悪化することを確認

34. 負荷試験ビフォーアフター
ビフォー
アフター
トラフィック

35. 結果

36. 無事リリース🎉
(海外配信を含む)

37. まとめ
• 負荷試験を実施した
• リリース後の負荷に関する問題はゼロ
• Kubernetesを活用している
• プロダクトチーム、インフラチームとの
連携でやっている