190905_スマホゲームリリース時に絶対サーバを落とさないための負荷試験.pdf

2019/09/05 CEDEC 2019

Transcript

1. スマホゲームリリース時に 絶対サーバを落とさないための 負荷試験 Cygames 伊藤英知
2. この講演について 本講演では、スマホゲームリリース時にサーバを落 とさないために、Cygamesが実践している負荷試験 の内容についてご紹介します。 負荷の予測と検証方法、計測項目の具体例と、負荷 試験環境の構築のポイントなどについて、具体的に 解説します。
3. 自己紹介 3/85 Ito Eichi 伊藤 英知 Cygames 技術本部コンシューマー シニアエンジニア 主にサーバ周り担当 社内の負荷試験・負荷対策に関わる 最近ではミドルウェアの検証や社内のPHP フレームワークのメンテナンス・PHPのエ クステンション作成等を行う 負荷かけるのとチューニングするのが好き
4. アジェンダ 4/85 • はじめに • 絶対サーバを落とさない負荷試験 • さらなる知見〜より効率的な負荷試験にするために • まとめ
5. 5/85 はじめに
6. はじめに 6/85 常に最高の状態で遊んでもらいたい なぜ負荷試験をするのか
7. 7/85 あるプログラムがあります。 「このプログラムをチューニングしてください」 と言われたら、あなたは一番最初に何をしますか？ はじめに
8. 8/85 あるプログラムがあります。 「このプログラムをチューニングしてください」 と言われたら、あなたは一番最初に何をしますか？ それは…「計測」ですよね。 はじめに
9. はじめに 9/85 ルール2: 計測すべし。計測するまでは速度のための調整を してはならない。コードの一部が残りを圧倒しないのであ れば、なおさらである。 Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. by Rob Pike 出典 https://ja.wikipedia.org/wiki/UNIX哲学 計測の重要性 ” “
10. 10/85 ・ 改善したければ、計測は必要 ・ 計測しなければ、改善したかわからない ・ 何を計測するか、が重要 ・ 手軽に計測できる仕組みが、改善を加速させる はじめに
11. はじめに 11/85 負荷 をかける ボトル ネックを 見つける 改善する この負荷試験サイクルを 徹底的に繰り返します
12. はじめに 12/85 負荷 をかける ボトル ネックを 見つける 改善する 本講演では 「負荷をかける」に フォーカスします
13. 13/85 • 負荷試験チーム • 全プロジェクトのノウハウを集約 • ほかプロジェクトと同じ過ちを繰り返さない • 負荷試験技術の専門性を高める はじめに 負荷試験サイクルを徹底的に繰り返すために
14. 14/85 絶対サーバを落とさない負荷試験
15. 15/85 • 負荷試験のポイント • 想定アクセス数の決め方 • 負荷のかけ方 • 計測項目のリストアップ • 計測用ツールの準備 • ツールの使い分け • 負荷試験対象の優先度を決める • 負荷試験環境の構築のポイント 絶対サーバを落とさない負荷試験
16. 16/85 • 負荷試験のポイント • 想定アクセス数の決め方 • 負荷のかけ方 • 計測項目のリストアップ • 計測用ツールの準備 • ツールの使い分け • 負荷試験対象の優先度を決める • 負荷試験環境の構築のポイント 絶対サーバを落とさない負荷試験
17. 17/85 • 正しく見積もる • 限界値をみつける • ボトルネックをみつける 絶対サーバを落とさない負荷試験 負荷試験のポイント
18. 18/85 リリース時に起きる現象 • 想定以上にユーザーのアクセスが集中した • DBやキャッシュの負荷が上がりサーバが落ちた • サーバが落ちてないのに実際アクセスするとエラー 絶対サーバを落とさない負荷試験 負荷試験のポイント
19. 19/85 • 想定以上にユーザーのアクセスが集中した ➡アクセス数の見積もりが間違っていた DBやキャッシュの負荷が上がりサーバが落ちた ➡負荷試験で仕様の最大値テストをしていなかった • サーバが落ちてないのに実際アクセスするとエラー ➡計測項目の不足 現象から考えられる原因 絶対サーバを落とさない負荷試験 負荷試験のポイント
20. 20/85 • 想定以上にユーザーのアクセスが集中した ➡アクセス数の見積もりが間違っていた (正しく見積もれていない) • DBやキャッシュの負荷が上がりサーバが落ちた ➡負荷試験で仕様の最大値テストをしていなかった (限界値を見つけてられていない) • サーバが落ちてないのに実際アクセスするとエラー ➡計測項目の不足 (ボトルネックを見つけられていない) 現象から考えられる原因 絶対サーバを落とさない負荷試験 負荷試験のポイント
21. 21/85 • 負荷試験のポイント • 想定アクセス数の決め方 • 負荷のかけ方 • 計測項目のリストアップ • 計測用ツールの準備 • ツールの使い分け • 負荷試験対象の優先度を決める • 負荷試験環境の構築のポイント 絶対サーバを落とさない負荷試験
22. 22/85 • 1ユーザのAPIのアクセス比率を計測する • 運用中タイトルの測定値を集めておく • 安全率を2.0以上とる 絶対サーバを落とさない負荷試験 想定アクセス数の決め方
23. 1ユーザのAPIのアクセス比率を計測する 23/85 • 1クライアントが一定時間あたりどのAPIをどのくらい コールするかを開発サーバ等から集計する • どのAPIがたくさんコールされるか等の傾向を把握 想定アクセス数の決め方 1ユーザのAPIのアクセス比率を計測する
24. 運用中タイトルの測定値を集めておく リリース直後等アクセス集中時の下記項目を記録 継続的に複数タイトルのデータを集めると傾向がわかる • DAU(Daily Active User) • HAU(Hourly Active User) アクセス数の推定には直接は不要だが集中度合いを比較しやすい • MiAU(Minutely Active User) • 1ユーザ当たり分間アクセス数 • スループット[req/sec] 24/85 想定アクセス数の決め方 運用中タイトルの測定値を集めておく
25. 運用中タイトルの測定値を集めておく 下記の式で想定DAUからアクセス数の予想材料にする 25/85 スループット[req/sec] = 想定DAU * 1分間集中率 * 1ユーザ当たり分間アクセス数 / 60 アクセス集中したときの MiAU/DAU比率 テストプレイ中の 開発サーバのログ等から測定 想定アクセス数の決め方 運用中タイトルの測定値を集めておく
26. 安全率を2.0以上とる 26/85 安全率 = 限界性能[req/sec] / 想定アクセス[req/sec] 「安全率」とは…限界性能に対する余裕度 例: 想定スループット数3000[req/sec]に対して 限界性能6000[req/sec]のサーバを用意した場合 6000/3000 = 安全率2.0 負荷試験での 限界値測定結果 アクセス数 見積もりの値 想定アクセス数の決め方 安全率を2.0以上とる
27. 安全率を2.0以上とる • 少なくとも2倍以上のアクセス数急増は想定しておく ・時間帯、曜日が違うだけでもアクセスが大きく変動する ・プッシュ通知、生放送、イベント開始/終了等で容易に増減 ・SNSでバズる等運用以外の予測しづらい要因もある ・クライアント側のバイナリ更新でアクセス数が増えることもある • リリース時はさらに注意 ・リリース時は注目を集めやすいのでさらに変動は大きい 27/85 想定アクセス数の決め方 安全率を2.0以上とる
28. 安全率を2.0以上とる • 想定よりも2倍以上の負荷を目標値にする • 今まで以上のユーザーが想定される場合は3倍以上も ・クラウドであれば安全率4.0のケースも検討の余地あり 例えば2.0の状態でさらに2倍にスケールアウトしてリリース 28/85 想定負荷とほぼ同じだけの処理能力ではNG! 想定アクセス数の決め方 安全率を2.0以上とる
29. サーバ台数の決め方 安全率を考えたうえで必要十分な台数にする • Webサーバ1台当たりの限界値を測定 • 安全率込みの想定スループットから台数を推定 例: 安全率込み想定スループット / 一台当たり限界値 ※ DBやキャッシュ等考慮しない単純化した例 • 推定した台数に想定スループットの負荷をかけて確認 29/85 想定アクセス数の決め方
30. 30/85 • 負荷試験のポイント • 想定アクセス数の決め方 • 負荷のかけ方 • 計測項目のリストアップ • 計測用ツールの準備 • ツールの使い分け • 負荷試験対象の優先度を決める • 負荷試験環境の構築のポイント 絶対サーバを落とさない負荷試験
31. 31/85 • 各APIの限界値を測るように負荷をかける ・限界値を測定するのは工数がかかるが、 安全率を割り出すのにも使える • 仕様の最大値まで入力した想定の負荷試験をする ・入力値によって負荷が変わる。一番大きい/長い値をテストする • DBのレコード数も想定ユーザ数以上入れておく ・レコード数で負荷が変わるので、レコード数は増やしておく 絶対サーバを落とさない負荷試験 負荷のかけ方
32. 32/85 • 負荷試験のポイント • 想定アクセス数の決め方 • 負荷のかけ方 • 計測項目のリストアップ • 計測用ツールの準備 • ツールの使い分け • 負荷試験対象の優先度を決める • 負荷試験環境の構築のポイント 絶対サーバを落とさない負荷試験
33. 33/85 サーバが落ちないよう多角的に計測項目を設定する • 計測項目の意味を理解する ・ memcached のUnfetched Evictionはどういうときに出るのか? ・ Time WaitなどTCPの各ステータスがどんなときに上昇するか? …等 • 負荷の計測手段を複数用意する ・得意分野が違うのでプロファイラと監視ツール最低限各1つは あった方が良い。 例: mackerelとnewrelic (後述) • 運用中の負荷を普段からよく見ておく ・特に最初に異常を示し始める計測項目を知っておく 計測項目のリストアップ 絶対サーバを落とさない負荷試験
34. • PHP Idle Worker • MySQL Row Lock Time, Slow Query, Abort Client, Slave status • Memcached Unfetched Eviction, Hit/Miss率 • Redis Evictions, CPU1コア毎の使用率, Hit/Miss率 34/85 • Node.js Context switch, CPU1コア毎使用率 • Linux全般 Time Wait, File Descriptor, Disk Latency, Free Storage, Inode, Traffic • LB HTTP Code Count etc... 負荷試験中によく使うメトリクスの例 絶対サーバを落とさない負荷試験 計測項目のリストアップ
35. 35/85 一見CPU使用率は正常… CPU 使用率 Worker Process 使用率 全Worker Processが Busyに！ リクエスト受付不可能 な状態 計測項目のリストアップ 絶対サーバを落とさない負荷試験
36. 36/85 • 負荷試験のポイント • 想定アクセス数の決め方 • 負荷のかけ方 • 計測項目のリストアップ • 計測用ツールの準備 • ツールの使い分け • 負荷試験対象の優先度を決める • 負荷試験環境の構築のポイント 絶対サーバを落とさない負荷試験
37. 監視/計測用ツールの準備 計測ツールの役割 • ボトルネック箇所の特定 • 負荷試験サイクル速度の向上 ・適切な計測ツールがあることで、修正・確認しやすい • 正しいチューニングの実施 ・うかつに台数増やす方向に流れないように • 問題を見逃さない ・負荷試験結果が本当に問題ないか裏付け 37/85 絶対サーバを落とさない負荷試験 計測用ツールの準備
38. 監視/計測用ツールの準備 38/85 • 監視ツール系 Mackerel Datadog ※APMも有 Munin Cloud Watch top sar vmstat kibana • プロファイラ系 各種言語対応 Newrelic ※監視機能も有 PHP Tideways(Xhprof) xdebug(Valgrind系) C/C++ Vtune Amplifier , gperf, Valgrind Node.js Node-Inspect(inspectオプション) etc... ミドルウェア・得意分野に応じて適切なものを選択 絶対サーバを落とさない負荷試験 計測用ツールの準備
39. 39/85 • 負荷試験のポイント • 想定アクセス数の決め方 • 負荷のかけ方 • 計測項目のリストアップ • 計測用ツールの準備 • ツールの使い分け • 負荷試験対象の優先度を決める • 負荷試験環境の構築のポイント 絶対サーバを落とさない負荷試験
40. 40/85 • JMeter 主にHTTP(s)の負荷試験向き • Mocha+ダミークライアント 主にSocket.IOの負荷試験・外形テスト向き • C#製自作ツール TCP/UDPの負荷試験向き • Vegeta-mysql MySQLのチューニング・性能比較向き 向き不向きがあるので複数使う(作る) 絶対サーバを落とさない負荷試験 ツールの使い分け
41. JMeter • 特徴 ・昔からあり枯れている ・GUIがある ・プラグインをJavaで書くことで拡張でき、集計機能が豊富 ・Websocket/Socket.ioなどのステートフルな通信の負荷試験には 向いていない ・Webサイトの負荷試験には自動でシナリオを作る機能があり 非常に向いている ・ブラウザゲームだけでなくゲームAPI部分の負荷試験にも使用 41/85 ツールの使い分け
42. • 使用したケース ・ゲームタイトルの公式ページの負荷試験 ・ブラウザアクセスのproxyとしてJMeterの HTTP(S) Test Script Recorderを指定しリクエストを記録。 これを負荷シナリオとして再編集。 ・ HTTP(S)のみのゲームAPIの負荷試験 ・シリアライズ・暗号化等含めたバイナリのBodyをリクエスト カスタマイズしたHTTP Samplerを作成して負荷試験 42/85 JMeter ツールの使い分け
43. • 特徴 ・元々単体テストツールなのでCIに組み込みやすい ・シナリオが作りやすい/デバッグしやすい ・Websocket/Socket.ioの負荷試験がしやすい ・日常的にAPIの外形テストとしてデグレードの検知にも使える ・もともと負荷試験用ではないので、 通信部分(ダミークライアント)や分散して負荷をかける部分等、 負荷試験で使用する機能を実装する必要がある。 43/85 mocha+ダミークライアント ツールの使い分け
44. describe('クエスト開始準備', () => { it('ホストからメッセージ送信', () => { const promises = []; promises.push(host.waitForEmitAndAssert(define.EVENT .QUEST , define.URI.READY)); promises.push(guest1.waitForEmitAndAssert(define.EVENT .QUEST , define.URI.READY)); promises.push(guest2.waitForEmitAndAssert(define.EVENT .QUEST , define.URI.READY)); promises.push(host.emitAndAssertAll(define.EVENT .QUEST , define.URI.WAVE_READY , { 'ready_state': define.READY_STATE.QUEST_START , 'frame': 0 }, guest1, guest2)); return Promise.all(promises); }); }); 44/85 Mocha負荷シナリオの例 メッセージイベント 待ち受け メッセージ送信 ツールの使い分け mocha+ダミークライアント
45. C#自作ツール • 特徴 ・Unityでクライアントを開発している場合 クライアントのコードを流用しやすい ・CSX(後述)を使うことでリビルドせずに挙動を変えやすい ・プロセス起動時の負荷は高い ・負荷試験のスケールアウトは自前でやる必要がある ・レポート機能は弱い 45/85 ツールの使い分け
46. C#自作ツール 46/85 手間を取られることが多い シナリオ作成・修正が効率的 ツールの使い分け • CSX(C# Script) ・ビルド不要 ・文法はC#とほぼ同じ ・ビルド済みのC#クラスを呼び出せる
47. await Connect();// 前処理 await SendSignup();// ユーザ登録 await SendTutorial();// チュートリアル await SendMyPage();// マイページアクセス // 10回クエストを行う for (var i = 10; i < 10; ++i) { await SendQuestStart();// クエストスタート await Wait(500);// 500ms待ち await SendQuestFinish();// クエスト終了 } await Disconnect(); Stop();// 後処理 47/85 awaitで非同期の処理を 簡潔に記述 CSX負荷シナリオの例 ループ回数・処理順等 挙動の変更が容易 ツールの使い分け C#自作ツール
48. Vegeta-mysql 48/85 • 特徴 ・Go製 ・パフォーマンス高い ・DBの負荷だけ測りたい時に便利 ・テキストファイルに投げたいクエリのリストを記載して使う vegeta-mysql attack -dsn “user:pass@tcp(localhost:3306)/dbname” -body sql.txt ¥ -duration=60s | tee results.bin | vegeta-mysql report 負荷試験で投げたい SQLのリスト ツールの使い分け
49. Vegeta-mysql 49/85 • 使用したケース DBバージョン間の性能比較(MySQL5.7と8.0など) パラメータA パラメータB Vegeta-mysql sql.txt Vegeta-mysql sql.txt 同一負荷条件で 性能比較可能 ツールの使い分け
50. 50/85 • 負荷試験のポイント • 想定アクセス数の決め方 • 負荷のかけ方 • 計測項目のリストアップ • 計測用ツールの準備 • ツールの使い分け • 負荷試験対象の優先度を決める • 負荷試験環境の構築のポイント 絶対サーバを落とさない負荷試験
51. 51/85 負荷試験対象の優先度を決める • 優先すべき箇所の分類 1. 全ユーザーが必ずリクエストする箇所 2. リクエストされる頻度が高い箇所 • APIごとのアクセス回数の調査方法 パラメータの組み合わせを含めたうえですべてのAPIを負荷試 験できるケースは少ない 限られた負荷試験期間で致命的なボトルネックを探す 絶対サーバを落とさない負荷試験 負荷試験対象の優先度を決める
52. 優先すべき箇所の分類 1. 全ユーザーが必ずリクエストする箇所 2. リクエストされる頻度が高い箇所 52/85 負荷試験対象の優先度を決める 優先すべき箇所の分類
53. 優先すべき箇所の分類 1. 全ユーザーが必ずリクエストする箇所 2. リクエストされる頻度が高い箇所 特に合計レスポンスタイムと転送量に注意 CPUやworker processなどの時間を取られている箇所 ≒DBやKVSにも負担がかかっているケースが多い 53/85 負荷試験対象の優先度を決める 優先すべき箇所の分類
54. 優先すべき箇所の分類 1. 全ユーザーが必ずリクエストする箇所 2. リクエストされる頻度が高い箇所 特に合計レスポンスタイムと転送量に注意 CPUやworker processなどの時間を取られている箇所 ≒DBやKVSにも負担がかかっているケースが多い 54/85 負荷試験対象の優先度を決める ここのチューニング次第でサーバ台数が決まる 優先すべき箇所の分類
55. 優先すべき箇所の分類 • 全ユーザーが最初にアクセスし負荷が上がる箇所 • ユーザー登録、チュートリアルのようなAPI リセマラを行われた際にもよくアクセスされる • DBのレコード数を本番に近づけるためにも必要 • 耐久試験にも使えるので真っ先に負荷試験シナリオを作っ ておくと便利 55/85 1. 全ユーザーが必ずリクエストする箇所 負荷試験対象の優先度を決める 優先すべき箇所の分類
56. • 大量に呼ばれるAPIは少しでも遅くなると影響が大きいため マイページのようなリクエスト頻度が高いAPI • レスポンスタイムの合計値を集計した時間も考慮 集計データがなければ平均レスポンスタイム*アクセス数で代用 56/85 2. リクエストされる頻度が高い箇所 優先すべき箇所の分類 負荷試験対象の優先度を決める 優先すべき箇所の分類
57. 57/85 • APIごとのアクセス回数の調査方法 どのAPIがどれくらいアクセスされているかを集計 • 方法(1) Newrelicのツールの統計機能を使う 合計レスポンスタイムもわかるので便利 ’Transactions’->’Show all transactions table…’で表示できる • 方法(2) KibanaのVisualizeで集計する ログの取り込みや設置の手間はかかるが 不具合調査に利用でき、カスタマイズ性も高い。 平均レスポンスサイズも合わせて集計するのがおすすめ 負荷試験対象の優先度を決める
58. 58/85 • 負荷試験のポイント • 想定アクセス数の決め方 • 負荷のかけ方 • 計測項目のリストアップ • 計測用ツールの準備 • ツールの使い分け • 負荷試験対象の優先度を決める • 負荷試験環境の構築のポイント 絶対サーバを落とさない負荷試験
59. 負荷試験環境の構築のポイント 59/85 どんな規模の負荷でも再現したい 本番想定の環境に近づけることで精度を高める • 負荷かけ元のスケールアウトが必要な理由 • AWSのAPIを使って必要な負荷かけ元を確保 • 大量の負荷かけ元サーバの管理 絶対サーバを落とさない負荷試験 負荷試験環境の構築のポイント
60. 60/85 • 開発中に目標値が上方修正されることがある 事前登録の伸び リリースするリージョンの増加 • 限界値を測定しているとかけ元サーバが足りなくなる 安全率の想定の変更 負荷かけ元サーバ台数もコンテナ合わせて1000台以上必要な時も 例: Socketの60万同時接続, APIアクセス10万rps以上を再現する チューニングの進展 開発プロジェクトの状況の変化への素早い対応が必要 負荷かけ元のスケールアウトが必要な理由 負荷試験環境の構築のポイント
61. 61/85 負荷試験環境の構築のポイント 各種負荷ツールを インストール済み のAMI AWS のAPIをコール 任意のAMIから EC2インスタンス作成 このインスタンス群から 負荷をかける EC2 * N台 大量にインスタンスを立てるの で、インスタンス管理をしっか りする必要がある インスタンス 作成完了時 Slackに通知
62. 62/85 一時的にサーバを立てるのに向いているSpot Instanceを採用 • 大量に負荷かけ元サーバを立てると管理が大変 ・たくさんサーバがあると立てっぱなしのものが出てしまう ・逆に止めてはいけないインスタンスかどうか判断難しい • 負荷をかけているときだけ起動していてほしい ・同じ予算でもより大きな負荷が再現できる 負荷試験環境の構築のポイント 大量の負荷かけ元サーバの管理
63. 63/85 • Spot Instanceの利点 ・安い ・基本的にEC2と同様の動作 • Spot Instanceの欠点 ・価格が変動することがある ・起動し続ける保証はない ・インスタンスを自分で作成・管理・破棄する必要がある Spot Instanceの作成・管理・破棄の システムを作ることで欠点を補う 大量の負荷かけ元サーバの管理 負荷試験環境の構築のポイント
64. 64/85 • コストの差 Spot Instance $0.0675 /時間 On demand Instance $0.214 /時間 -0.05 0.05 0.15 0.25 1 2 3 4 5 6 7 8 Ondemand Instance -0.05 0.05 0.15 0.25 1 2 3 4 5 6 7 8 Spot Instance 正味の負荷試験時しか コストが発生しない 時間あたりでも 値段が約1/3 ※c5.xlarge , 2019年8月時点 1日負荷試験に使った場合の例 実質コスト差は約1/6になるケースも $1.284 /日 $0.2025 /日 大量の負荷かけ元サーバの管理 負荷試験環境の構築のポイント
65. 65/85 負荷試験環境の構築のポイント (xhprof) 計測 起動 負荷実行 停止 破棄 負荷かけ元 インスタンス作成 負荷シナリオ実行 負荷シナリオ停止 負荷かけ元 インスタンス破棄 負荷かけ元 本番同等の ゲームサーバ KVS DB Jenkins EC2 Spot Instance Fargate プロファイラ/ 監視ツール等 ELB エンジニア PC 大量の負荷かけ元サーバの管理
66. 66/85 インスタンスの起動・破棄や負荷試験実施を Jenkinsのjobにしておく • パラメータ次第で任意の規模の負荷がかけられる • 誰でも好きなタイミングに負荷試験がかけられる • 負荷試験に必要な時だけサーバを起動/破棄できるのでコ ストが抑えやすい • AMIを変えることで任意のツールで試験実施 負荷試験環境の構築のポイント 大量の負荷かけ元サーバの管理
67. 67/85 さらなる知見 ~より効率的な負荷試験にするために
68. より効果的な負荷試験にするためには 68/85 • 負荷試験時の注意点 • CIに小規模な負荷試験を組み込む • 内製ツールでより問題を発見しやすく
69. 69/85 • ELB等クラウドのロードバランサは暖気しておく • 負荷をかける元サーバにNATを挟まない • 外部のAPIは必ずoffにできるようにしておく • PCから負荷をかけない • バッチのボリュームテストは必ず行う • 耐久試験(エージングテスト)も行う より効果的な負荷試験にするためには 負荷試験時の注意点
70. • ELB等クラウドのロードバランサは暖気しておく 暖気していないと急激な負荷増加にはスケールアウトが追従しない 追従できなかったときはHTTP 503エラーになってしまう AWSであればPre-Warmingの申請しLBを予めスケールアウト(暖気) した状態にしておく 本番LBも同様なので対応漏れがないように • 負荷をかける元サーバにNATを挟まない NATが詰まり正しく負荷がかからないことがある LBがsource ip hashingで分散したとき偏る 70/85 より効果的な負荷試験にするためには 負荷試験時の注意点
71. より効果的な負荷試験にするためには • 外部のAPIは必ずOFFにできるようにしておく ・APIに負荷がかかってしまうので基本OFFにして負荷試験する ・本番動作時にAPIのレイテンシが上がったりした場合にも有効 ・ゲームサーバ-API間のNATもボトルネックになっていないか注意 • PCから負荷をかけない ・会社の回線がパンクしてしまう ・正しく負荷もかからない 71/85 負荷試験時の注意点
72. より効果的な負荷試験にするためには • バッチのボリュームテストは必ず行う ・バッチはレコード数によって挙動が大きく変わるため 本番相当のレコード数で行う ・PHPの二次元配列は件数が増えると加速度的にメモリ消費する ・件数の増加でDBへのコネクションがタイムアウトしないこと確認 • 耐久試験(エージングテスト)も行う ・メモリリーク・キャッシュのevictionなどがあぶりだせる ・バッチも稼働させておくと負荷がかかっているときの挙動もわかる 72/85 負荷試験時の注意点
73. より効果的な負荷試験にするためには 73/85 • 負荷試験時の注意点 • CIに小規模な負荷試験を組み込む • 内製ツールでより問題を発見しやすく
74. より効果的な負荷試験にするためには • 負荷条件をビルドログとして残し再利用できる チューニング→負荷試験で測定のイテレーションがしやすい • いつでも負荷試験を実施でき、開発担当のメンバが すぐ効果を確認できる イテレート速度向上により負荷試験の効果を高める • 可能であればスケールアウトできるようにしておく そのまま負荷試験のJobとして実行できる 74/85 CIに小規模な負荷試験を組み込む
75. より効果的な負荷試験にするためには • APIの外形テストの代わりとしてデグレードチェッ ク・バグ再現等にも利用可能 ・通常のテストプレイでは出づらいレースコンディションバグを 確認しやすい ・バグチケットと1:1対応する再現シナリオを作ると 再現確認・修正確認・デグレードと3通りに使えて効果的 75/85 CIに小規模な負荷試験を組み込む
76. より効果的な負荷試験にするためには 76/85 • 負荷試験時の注意点 • CIに小規模な負荷試験を組み込む • 内製ツールでより問題を発見しやすく
77. 内製ツールでより問題を発見しやすく 77/85 • “QueryChecker”-SQLのExplainを自動でチェックする ➡ DBの負荷軽減 • “Duplicate SQL Log”-重複クエリをログに出す ➡ DBの負荷軽減 ➡ KVSの負荷軽減 • “xhprof helper”-プロファイラを見やすく ➡ Webサーバの負荷軽減
78. 内製ツールでより問題を発見しやすく 78/85 開発サーバからSQLクエリログ収集 EXPLAIN実行＆パース 修正すべきクエリを記録 開発サーバでWeb表示 クエリの深刻度を判定 QueryChecker
79. 内製ツールでより問題を発見しやすく 79/85 • チェックの手間を省力化 • Explainチェック漏れが起きづらくする • 問題のあるクエリの存在を共有 QueryChecker QueryChecker
80. 内製ツールでより問題を発見しやすく 80/85 SELECT * FROM table_name_00 WHERE id=N AND name=’S’ x 3 SELECT * FROM table_name_00 WHERE id=102 AND name=’username2’ SELECT * FROM table_name_00 WHERE id=101 AND name=’username1’ SELECT * FROM table_name_00 WHERE id=100 AND name=’username0’ 全く同一あるいはループで発行されたクエリを集計 パラメータを 抽象化して集計 発行したクエリ Duplicate SQL Log Duplicate SQL Log
81. 内製ツールでより問題を発見しやすく 81/85 2回以上発行しているクエリをDB のドライバクラスの デストラクタで ログに出力 N+1問題の検出を容易に Duplicate SQL Log Duplicate SQL Log
82. 内製ツールでより問題を発見しやすく 82/85 標準状態のXhprof(tideways)の表示 リンクを開かないと結果がわからない たくさん結果があると探しづらい Xhprof helper Xhprof helper
83. 内製ツールでより問題を発見しやすく 83/85 API名で測定結果を 絞り込み レスポンス速度・メモリ使用 量に応じて色分け表示 Xhprofの結果表示を見やすくする ChromeExtensionを作成 PJ要望に応じて機能追加 絞り込まれた結果を 強調表示 Xhprof helper Xhprof helper
84. まとめ 84/85 • 想定アクセス数でも快適に。安全率2.0以上とる • 運用タイトルから測定値を集めておく • サーバが落ちないよう多角的に計測項目を設定する • リクエストが多い箇所を優先して負荷試験する • どんな規模の負荷でも再現できる環境を作る • CIも活用する • 内製ツールでより問題を発見しやすくする
85. 最後に 85/85 サーバーに安定を、 ユーザーに安心を。