こんにちは、セムです。
先月１周年を迎えましたがそんな中セム内部では、とてもハードな超絶負荷テスト真っ最中でございました。
そんな超絶負荷テストでピリピリムードな時、、、
おいおいセム５号
くだらねぇブログ書いてないで
少しは技術屋として、技術的なブログを書いた方がいいんじゃねーのか
どうなんだ
それとも、スタジオセムは技術に自信がないのか、おい
どうなんだ
HPで偉そうにやれますアピールしてる割には
実際どうなんだ？って感じじゃないのか、おい
という、パワハラが横行してるので
書かなアカン！
ということでゲームサーバの負荷テストについて語ります。
そんな小学生レベルのブログは書くつもりはないので割愛します。
こんなことはgoogle先生に聞いたら、ありとあらゆるところで記事が乱発してるので割愛します。
せっかくなので読んでくれた方に大事なところだけ補足
負荷テストを行うにあたってテスト内容やサーバ構成によって負荷テストのやり方、使うツールも変わってくるので
この辺り何を使ってどんな負荷テストをするのかは慎重に。
また、通信方式も単純なHTTP通信なのかリアルタイム通信なのかによって
負荷テスト方法は大きく変わってくるかと思います。
判断を間違えると自身の負荷テストへと変わるので要注意ですね！
さてここからが本ブログの本題ですよ！！
おーーー、まってましたーーー
と、その前に
あくまでも負荷テストの話しなので
・プログラムがクソ
・スケールできないうんちプログラム
・スケールできてもリソースの無駄使い
とかそんな話もしません。
では、
負荷テストをやる上で大事なことはなんでしょう？
今回は負荷テストで大事なことを２つだけ特別にこっそり書きますね。
ひとーーーーつ。【事前準備】です
めちゃくちゃ大事です。
負荷テストで一番大変なのは、負荷をしっかりかけるまでの道のりが長くなりがちなところです。
それは、
・負荷かけ元のサーバが思いのほかうまく動いてくれない
・整合性の取れたテストデータを作れていない
・負荷テストシナリオが想定と全然違う
・シナリオのパターン数が違う
・ミドルウェア、OSの設定で負荷がかからない
など様々な理由がありますが大抵どこかでハマるのでは？
ふたーーーーつ。当然ですが【負荷分析】です。
サーバが数十台、数百台になると細かな分析は相当大変になりそうですよね？
では具体的に見てみましょう。
これは
・想定負荷に対して負荷かけ元サーバが少なすぎて負荷がかけられない
・負荷かけ元サーバの台数が多すぎてうまくテスト実施者がハンドリングできない
などあります。
この辺りを意識して負荷かけ元サーバ台数に余裕を持たせたり（スペック含め
台数が多い場合は、負荷テスト実行するのを自動化しておいたり
負荷かけサーバに負荷をかけるのが本来の目的ですが
負荷かけ元サーバが今どういう状態なのかもしっかり確認を。
負荷をかける際には、ある程度事前に負荷テストをうまくかけるためにダミーのデータを入れたりしますが
※サービス開始時想定の負荷テスト、サービスインしてから１年ぐらい経過した時の負荷テストなどのシナリオによっても事前のデータは変わりますが。
この事前データが整合性の取れたデータでなかったりすると
負荷テスト中にエラーが発生したり、よからぬ謎のエラーに遭遇し本来の負荷テストの目的とは関係のない原因調査などに時間を取られるケースもあります。
また、本来ありえないデータなのにそれを真に受けて
エラーが出てるから、スロークエリが出てるから、コネクション足りないからと
必要のない対策を講じてしまうケースもあるのでは？
そのデータは本当に正しいですか？
そんなこんなで事前準備が大事でございます！
ろくにそのサービスを触らずに適当にざっくり負荷テストのシナリオを組んでしまう
そんなことをしてしまうと
いざサービスインするとそれは想定と違う負荷が大量に流れるのでシステム構成が当然的を外しております。
炎上ですね。
逆に想定よりめちゃくちゃ負荷のかかったシナリオを組んでしまって
超オーバースペックなシステム構成を組んでしまう。
炎上はしないかもですが...
ランニングコストもったいないですね。
数十台で済むはずなのに数百台のサーバを用意してしまう。そんなケースも。
はい、そのままです。
サービスには様々なシナリオがあるはずです。
サービス開始時。イベント開始時。メンテナンス明け時。サービスインしてから数年たったケース。
各状況によってデータ数、容量、アクセス数は全く違いますね。
それを見極めずに適当に負荷テストをして終わらせてしまうケース
そんなことをしてしまうと
負荷テストをクリアしたけどその時の状況によって...
はい炎上です。
これもまたハマりポイントですが
サーバリソースは余裕なのに何故かアプリケーションでエラーが出る。
なんでだろう？なんでだろう？ですね。
サーバで使ってるミドルウェアやOSで制限がかかってるケースもあり
リソースに余裕があるのに負荷がかからないということがけっこうあります。
これを意識せずにただエラー出てるから負荷が高い！
サーバ増やさなアカン！！！
サービスイン近いからとりあえず増やさなアカン！
きっと負荷高いんだ！増やさなアカーーーン。
となって
無駄なリソースが沢山増え、運営コストを逼迫する。
数十台で済むはずなのに数百台のサーバを用意してします。そんなケースも。
ようやく負荷がサーバにかかりましたが
負荷テスト時にサーバリソースに問題ないかをしっかりと分析しなければなりません。
CPUがどうだとか、メモリが足りてるのか、コネクション数どうよ？帯域たりてんの？遅いSQLないよね？処理時間遅くないよね？
秒間いくつ捌いてる？目標値達成してる？同接いくつよ？
とかとか。
とはいえ、サーバ台数もそれはそれは数は半端ないです。
１つ１つリモートでサーバの中覗いて監視したりログ漁ったりは到底やってられません。
ではどうしましょうか？
中にはサーバのリソースを監視してくれるGUIツールを使う。というのも１つですよね。
ただその辺りのツールを使っても
アプリケーション寄りの分析・秒間とか同接とか処理時間まで細かく見てはくれないのでどうしましょう？
ということですが
負荷分析をスムーズにやるポイントは
・各サーバの必要なログやシェルなどを自動で動かす仕組みを構築しておく
・収集したログを自動で分析する仕組みを作る
でしょうか。
その辺りはプロジェクト個々に分析君なるツールを作ったりして
しっかりとアプリケーションのログを分析し
さくっと分析できる仕組みは作っておいた方がいいと思いまっす！
本記事はあくまでセム５号の勝手な妄想です。
「いやいや、今どきはこうでしょ！」とかあれば
ぜひご指摘くださいませ！
また、ゲームサーバの負荷テストをどう実施していいかわからない企業様、会社様
我々セムはその辺りのサポートなどもしておりますので
お困りの際はぜひお問い合わせください！
これで少しはくだらねぇブログ書いてんじゃねーよ。なんて言われなくなるかな？
以上、セムでした。
--
負荷テストについてのブログ閲覧を多くいただいております。
スタジオセムは
2020/05「ゲームサーバAPIの負荷テストに特化したサービス」を提供しました。
負荷テストでお困りの方は、ぜひ本サービスをお試しください。
本ブログに記載のある問題点や時間がかかる個所など全て解決し
誰でも簡単に負荷テストが実施できるサービスとなっております。
