負荷試験
https://gyazo.com/4a56e3a8d48b91b562d8adbb3a6d2873
実際に負荷試験を進めていくにあたって、何をどこまでやるのか
の考え方紹介
その負荷試験は何のために行うのか、を改めて問うと、意外とハッキリしていないことがあります。また、その成功と不足の境界線や、完全な終わりというのも案外曖昧なものだったりもします。
どのようなデータを採取し整理すれば、ゴールに向かっていきやすいのか、を考えていきます。
分類と優先順位を丁寧に整理しつつ、負荷試験を実行しつつ、アプリケーションの性質を理解していきます
本番ただ1点のみを想定した試験は使えない
トラフィックがスケールするか、また逆にどのように縮退するかも考える必要がある
パラメータを変化させて傾向を推測する
目的：非線形な傾向（品質劣化）が出るのを炙り出す
この原因を特定して解決する
実際にはどのような変化なのか、はたまた例外にはどのようなものがあるのか
どのような単位を意識し、どのように性能値を算出していくと、より信頼できる安定した結果になるのか
早めにこういう取り組みをしておくと、開発における負荷試験フェーズを短縮でき、エンジニアのストレス軽減にもなる
負荷試験における火葬のユーザーの振る舞い
負荷試験を行うにあたって重要な事が２つあります。
適切で意味のある内容
効率的な準備と実行
そのためには、サービスが取り扱うプロトコルと、アプリケーションの仕組みや構造を理解する必要があります。
プロトコルの理解が深くなれば、負荷試験ツールでの表現が柔軟で正確になり、
アプリケーションの理解はより本番想定に近い条件や実行計画を立てやすくなります。
負荷試験の重要度は高めなはずですが、時間や人的リソースが足りなくて、開発者が片手間で試験を手掛けることも少なくないでしょう。早めに負荷試験方法を確立しておくことは、そういった不幸を減らし、長期的にみて各所で活用できるので、かなり価値の高い研究開発と考えます。
全般
スケジュールは十分に確保
サーバ1台に負荷掛けて限界点を調べた上で複数台に負荷掛ける
事例
DBの場合はアプリケーションみたいにソッと混ぜて試すことができないので、キャッシュをOFFにして、クエリの値をランダムにして、クライアント接続数をvCPUの倍くらい用意してガーッとぶん回す。っていつものをテスト環境でやる感じでしょうか。
シナリオは実際ほぼほぼクライアントに限りなく近い実装を Lua で起こす必要があります。さらに FGO を熟知する必要もあります。
かなりしんどい作業で、実際仕様通りに動かないなんてこともよくある話です。その場合の仕様確認などをしながらのシナリオ作りは相当大変です。
本気の負荷試験をやるには負荷試験専門家、負荷試験ツール開発者、負荷試験のための本番と同等の環境を維持する覚悟が必要になります。はっきり言って普通に大変です。
ツール比較
負荷をかけるツール
何をどう選ぶのかの指標
基本的には機能や扱いやすさを重視した方が幸せになれる
Apache Benchは複雑なシナリオには不向きですが、単純な参照系APIの簡単な試験には使ったりします
上の記事を書いた会社はQA向きではなく開発者向きのk6をリリースした Scala is obscure, and the DSL obfuscates any kind of logic you want to put in your test code
議論の余地がありそうkadoyau.icon
Jemeterは定番で負荷試験のシナリオは大半Jmeterで出てきます
私の最近のおすすめはLocustです、シナリオが書きやすく簡単に分散環境で実行できます。
スケージュール