本記事は
WebアプリWeek
最終日の記事です。
🌀
4日目 ▶▶ 本記事 🌴
はじめに
はじめまして、WebアプリWeek5日目を担当しますNTシステム事業部の勝浦です。
みなさん、負荷試験してますか？
システムの特性上そんなに負荷かからないし、性能も求められないし、、
と負荷試験を実施しない場合もあるかと思いますが、負荷試験をしてみると意外な箇所に落とし穴があったりすることに気づくものです。
私自身、今まで何度か負荷試験を実施する機会がありました。
本記事では負荷試験を実施するにあたって、私がはじめに考えていることを書き出してみたいと思います。
負荷試験は何のために？
「負荷試験やっておいてね」と言われたとき、まず何を考えるでしょうか？
私がはじめて負荷試験をやったときは
「とりあえずたくさんリクエストなげてエラーがでたりレスポンス遅延がおこらないか確認すればいいかー」
ぐらいにしか思わなかった記憶があります。
（もちろん場合によってはそれでOKかもしれませんが）
もちろん試験をやるからには目的があるはずです。
目的が曖昧だと漫然とパフォーマンスを測定するだけになってしまい、余分な情報まで取得してしまうこともあります。
細かい目的は多々あるかもしれませんが一番大きな目的としては
「負荷をかけることで現れるシステムの特性を把握し、改善できる点は改善しておきたい」
につきると思います。
どんな負荷試験を実施すればいいのかを考えてみる
上記を踏まえた上で負荷試験を行う上ではまず
- 試験をすることで何を確認・把握したいか
- それを確認するためにどのような負荷をかけてテストをすればよいか
を決めておくことが重要になります。
このあたりのテスト内容をどのように決めていくかを次に書いていきます。
負荷試験の種類
確認したい内容を考える前に負荷試験にはどんなバリエーションがあるかを把握しておきます。
- ロードテスト
- 通常時の負荷やピーク時の負荷をかけてシステムのパフォーマンスを測ります。
- ストレステスト
- 高い負荷をシステムにかけ限界点付近での振る舞いを探るテストです。
- 徐々にかける負荷をあげていくテストをストレステスト、急激に高負荷を与えるテストをスパイクテストとしてわけることもあります。
- ソークテスト
- 長期間にわたり負荷をかけつづけるテストです。
- 短期間では見えない、パフォーマンスの低下やリソースの枯渇を発見するために実施されます。
このあたりは k6 の公式ドキュメントにわかりやすく書かれているので興味のある方はそちらもご参考ください。
負荷試験で確認したいこと
今回の負荷試験で確認したいことを決める必要があります。
確認する内容は毎回同じではなく、負荷試験を実施するときの状況によって目的は変わります。
例えば以下の2パターンを考えてみましょう。
①クラウドサービスを使って新規 Web アプリを構築した。
② 既存のインフラ上で既存アプリに機能追加をした。
① のケースでは、想定される負荷がかかったときにどのくらいのパフォーマンスがでるか、高負荷時にどういう挙動を示すか、用意したインフラリソースに問題はないか、スケールアウトが問題なく実施されるかが負荷試験の確認ポイントでしょうか。
一方 ② のケースではどのくらいのパフォーマンスが出るかを確認したいのは同じでしょうが、インフラリソースに変更がないのであればそのあたりのテストは優先度はさげてもいいかもしれません。
このように負荷試験を実施する状況によって、確認したいポイントは変わりますが、
私自身は以下の３点をベースに、負荷試験時の状況を踏まえて確認したい事を決めていきます。
- 構築したシステムのユースケースにおけるシステムのパフォーマンス
- 高負荷時におけるシステムの挙動
- 用意したインフラリソースに問題がないかの確認
どの負荷試験を実施するか
どのような負荷試験があり、それぞれどのような目的で実施されるのかを理解し、
今回の負荷試験で確認したいことを決めました。
あとはどの負荷試験を実施するか決めましょう。
上で書いたようなそれぞれの負荷試験で確認できることを把握しておけば、それを当てはめていくだけです。
試しに上のケースでどのような負荷試験をするのか勝浦が考えてみました。
①クラウドサービスを使って新規 Web アプリを構築した。
はじめて構築するアプリなのでユースケースでのパフォーマンスを図るためのロードテストや、限界時や長期間稼働時の挙動も確認するためにストレステストやソークテストは実施したいです。
またスパイクの発生が予想されるようなシステムであればスパイクテストも実施しておきたいところです。（ようするにモリモリのテスト）
これを踏まえると負荷試験の実施優先度としては以下のような感じでしょうか。
- MUST ロードテスト、ストレステスト、ソークテスト
- SHOULD スパイクテスト
②既存のインフラ上で既存アプリに機能追加をした。
一度既存アプリの負荷試験を実施しているのであれば、機能追加箇所を加えたロードテストは実施するとしても、他のテストはケースバイケースかと思われます。
例えば追加した機能がデータベースに凄い負荷をかける可能性がある、とかであればストレステストやソークテストの実施も考える必要があります。
これを踏まえると負荷試験の実施優先度としては以下のような感じでしょうか。
- MUST ロードテスト
- MAY ストレステスト、ソークテスト、スパイクテスト
おわりに
負荷試験をはじめるにあたって、私が考えている試験内容の決定について紹介させていただきました。
試験の大枠を決めておくことで、負荷試験ツールは何を使うか、モニタリングがどうするか、いつ試験をするか、実施環境をどうするか、、といったことも決めやすくなると思います。
