woshidan's blog

そんなことよりコードにダイブ。

負荷試験のアプローチとWeb系でクラウドサービスを利用している場合のそれぞれのアプローチに対する感想について

この記事はソフトウェアテストアドベントカレンダーの8日目の記事です。

以前、担当しているサービスの負荷試験を行ったのですが、負荷試験やパフォーマンステストとふわっといった時、いくつかアプローチの種類があるようなので今回の記事ではそれらの簡単にまとめて実際Web系でAWSなどクラウドサービス使っててどう思ってるかについて書きます。

それぞれのアプローチの呼び方については、Oracleの定義*1であったり、ソフトウェアテスト標準用語集*2であったりに違いがあるようなので、この記事ではOracleが使っている名称に基づくことにします。

TL;DR

継続的な負荷の監視は実質的に負荷試験の一種だなぁ、と思いました。

負荷テストのアプローチについて

負荷テストを考える際のアプローチには大きく分けて

  • 性能テスト: 想定している負荷に対し、どの程度のスループットやピーク時の処理量が出せるか
  • 限界テスト: システムが想定している以上の負荷、あるいは限界以上の負荷を与えた場合何が起こるか
  • 耐久テスト: 高負荷で長時間運用時に何が起こるか

の3つがあると思います。実際は要件に合わせて、これらのアプローチを組み合わせて行っていることも多いですが、まずそれぞれのアプローチについてどういったことを計測するのかなどを確認します。

性能テスト

サービスや新機能のリリース前に、システムの結合試験や統合試験ではテスト用のユーザでのみ動作させていると思うのですが、ユーザの数が少ないと遅い処理でも問題なく動いてるように見えます。

性能テストでは、システムが想定している負荷に対し、どの程度のスループット応答時間を返すかを確認します。

限界テスト

システムが想定している以上の負荷を与えて、システムに何が起こるのかを確認します。

たとえば、リクエスト量が想定している負荷の2倍を与えた時のシステムの振る舞い、たとえば、

  • トップページが500エラーになってしまうか
  • 特定のデータストアにアクセスが集中してスループットが下がってしまわないか
  • クラッシュしないか

といったようなことを確認します。

耐久テスト

高負荷で長時間動かした場合にどう動かすかを確認します。

たとえば、

  • 微量のメモリリークがあるプロセスのせいで、メモリ使用量が時間とともに増加する
  • キャッシュの保持期限設定を間違えてキャッシュのメモリが不足する
  • ログの出力が多すぎて、ログファイルがディスクを圧迫
  • 処理にメモリを使いすぎて、GCなどが起こりすぎて処理速度に影響

といったようなことが起きないか確認します。

それぞれのアプローチに対する個人的な感想

個人的な感想ですが、本題です。

性能テストについて

自分がWeb系の自社サービスでAWSなどのクラウドサービスを使っているという前提で話すと、かなり大規模なサービスを持っている会社がそれに付随するようなサービスを新しく展開する、といったような場合以外は、あまり性能テストという形でやらないのかな、という感じです。

  • 小さいリリースを小刻みに行っていく場合リリースごとに想定される負荷があまり変化しない
  • クラウドサービスを利用している場合、サービスを継続的に監視してCPU使用率などが高くなったタイミングで一つ上のクラスのサーバにすぐ変更することが容易

なので、リリース後の継続的な監視で済ますことが多そうです。

弊社の場合、機能のリリース前にステージング環境などある程度用意しているデータの規模が大きい環境でしばらくサーバの負荷に変化がないかなどを監視するといった方法を取ることが多いです。

限界テストについて

テレビCMなどでのアクセス増予測や、新機能リリースのために試験している印象が実はそこまでないです。

  • 新機能がそこまでヒットする予測が毎回ない*3

というのと、

  • 高負荷で障害が発生してからの負荷に対応できるインフラの調達が30分以内とかで可能
    • オートスケールの設定台数を変える(数分くらい)、で済むことが多い
  • 小さいサービスが急にバズって高負荷で止まっても仕方ないよね、頑張ってねという業界の空気がある(気がする)

ので、決済とかクリティカルなサービス以外では、リリース後にその場で対応することが多い印象があります*4

来年ユーザー数を2倍に増やす事業計画とかがあって、その前提にあわせて試験したりすることもあるかな、という感じです。ぶっちゃけると新規リリース以外の場合、リリース直前の試験の段階でパフォーマンスの問題が見つかっても、負荷に対応するためのアーキテクチャの構築、ならびに新しいアーキテクチャへのデータ移行が間に合わないので、先手を打って試験をすることもあります。

テレビで急に取り上げられた場合は違いますが、テレビCMを打つ場合、Web系のベンチャーあたりだと「ここが社運をかけた投資・拡大のタイミング」と踏まえた事業計画に基づいて行なっているので、上記のような事業計画がありそれに沿って動くのかな、という気がしています。気だけですが。

耐久テスト

これもサーバ側だと監視ですます印象です。

  • 監視していると数日に一回メモリ使用量が80%などを超えるサーバがある
    • だいたい再起動など比較的簡単な対応をすればその場はしのげるので暫時対応で時間を稼ぎながら根本対応をしていく

みたいな。リリースしたらお客さんが運用する受託であったり、リリースしたらユーザの手元で動くアプリの場合はまた違うのかな、と思います。

締め切りギリギリのポエムですが、監視は試験である、とはこのことなんだなぁ、ということで現場からは以上です。

参考

*1:https://www.oracle.com/technetwork/jp/ats-tech/tech/useful-class-8-520782-ja.html

*2:http://jstqb.jp/dl/JSTQB-glossary.V2.3.J01.pdf

*3:このお話は一般論です

*4:それでなんとかならないソシャゲとかあった気がしますがどういう修羅なんでしょうか