リリースを支える負荷測定

by gree_tech

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

開発体制について

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

今回の話

Slide 8

Slide 8 text

なぜ、負荷試験？

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

リリース後即メンテ

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

負荷対策は必須

Slide 14

Slide 14 text

どういう対策をする？

Slide 15

Slide 15 text

zܭଌ͢΂͠ɻܭଌ͢Δ·Ͱ͸ ଎౓ͷͨΊͷௐ੔Λͯ͠͸ͳΒͳ͍z 3PC1JLF http://www.lysator.liu.se/c/pikestyle.html 邦訳参照 https://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

想定した負荷

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

実施

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

やってみると

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

結果

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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