負荷試験
ユーザ数が増えた場合にサービスが期待する性能が出せるかを試験するもの
あとテレビCMとかでアクセス量がスパイクした時にサービスがダウンしないかを検証したりする
負荷試験を実施することで、ユーザ数がどれくらいまで増えるとサービスが動かなくなるかを事前に把握できる
つまり、「このままユーザ数が増えるのNヶ月後には問題が発生すると思われる」といった事前予測が可能になる
負荷試験の結果を踏まえて、マシンのスケールアップやスケールアウトが必要といった交渉の材料にできる
あるいはサービスの本番リリース前に性能がでるかを検証したりできる
注意点
自分のサービス以外に勝手に負荷をかけると最悪捕まる
自分のサービスだとしても、勝手に負荷をかけると怒られる場合がある
負荷かけすぎると課金額が跳ね上がる場合がある
大量の負荷をかけるのでリクエスト量課金とかデータ転送量課金などの課金モデルのサービスを使ってる場合は負荷試験自体がコストになったりする
負荷試験をする時は、まずローカルでしっかり検証して、少しずつ試験したい環境にたいして負荷をかけていくのが良いと思う
負荷試験に使うツール
メジャーどころだと以下
最近見かけるやつ（使ったこと無い）
scala書かないといけないらしくてめんどくさそう go製でコマンドラインからサクッと使えるっぽくて気になってはいる ただ個人的には歴史が長くて枯れたツールの方が好みなので、使い慣れたjmeterを選んでしまう
そんなに複雑な試験シナリオは書けなさそう
Goのパッケージとしても使えるので、gatlingと同じようにコードを書けばシナリオテストもできそう 当然Goが書けないとシナリオも書けないが...
ただ最近は、JMeterつかった場合も局所的にBeanShellを書かないといけなし、そんなに変わらない気がしてきた JMeterのJMXファイルはリポジトリ管理と相性あんまり良くないし...
負荷試験やる時に考えないといけないこと
テスト計画
ヒートランテストをするならどれくらい長期間負荷をかけ続けるか考えないといけない
一週間なのか二週間なのか
どうやって長期間負荷をかけるか
少なくとも会社のPCとかでやるのは無理なので専用の負荷試験用の環境が必要になる
スパイクテストをするならどれくらいのスパイク量を想定するか考えないといけない
スパイク量によってはIaaSに対して事前申請が必要だったりする
別サービスと連携してる場合は事前に連絡をしないと、連携先に迷惑がかかる
大量アクセスのデータ転送量課金がどれくらいになるか見積もっておく必要がある
スパイクテストで作られたデータをどうやって後始末するかも考えないといけない
データベース負荷テストをするならどれくらいデータを用意する必要があるか考えないといけない
ユーザ数1万人を想定する、とかそういうの
そのデータはサクッと準備できるものなのか否か
レポートのとり方
jmeterとかだとレポートのHTMLを生成してくれるけれど、それでレポートとして十分かどうか 例えばインフラサービス側のリソースも見る必要があるかどうか
CPU使用率とかメモリ使用率とか
DBの負荷状況も見ないといけないかどうか
SLOを満たせているかどうかをどうやってレポートするか 負荷試験実施までの作業量の肌感
全体 10 としたときの内訳はだいたい
試験環境の構築などの準備 5
試験の実施 2
レポートの取得 3
みたいな感じ？
試験の実施自体は負荷試験ツールを流しっぱなしにすれば良いのであんまり手間がかからない
準備とレポートの取得が結構めんどくさい