性能負荷テストの進め方 ～準備編～

概要

以前書いた、性能テストの進め方に対する記事の続きです。今回は準備について書いていきます。
性能負荷テストの進め方　～計画編～

時間がたつのは早いもので、続きを書こうと思って気づいたら4年もたっていました。怖いですね。

もともとは今回で実施についても書こうと思っていましたが、実施と評価はまとめて書きたいので、それは次回にしようと思います。

環境の準備

計画で検討した環境の要件に従い、環境の準備を行います。
以下については考慮が漏れやすいので気を付けましょう。

• サーバリソースを収集するためのパッケージやツールのインストール
• 負荷ツールを実行する端末/サーバの準備
  この端末/サーバのスペック不足のせいで思った通りの流量がでない、ということがあります。

また、性能テストで使う環境はほかのシステムテストでも使うことが多く、環境の奪い合いが起きやすいです。
性能テストは環境に負荷をかけるため、占有するスケジュールにしないとほかのテストに影響が出るので、注意が必要です。
この事前調整も早い段階で行っておくことをお勧めします。

テストケースの作成

オンライン機能とバッチ機能それぞれで考慮すべき点を挙げてみます。

• オンライン機能
  対象機能までの導線があるのか、それとも直接該当機能を実行するのかによって考慮するて点が変わってきます。

  • 実際の画面フローに従った遷移フローとする
    • ログイン認証等必要な場合はログインのリクエストを実行後に対象APIを実行する
    • 複数の入力値パターンがテスト対象である場合はテストケースに記載する
    • 前処理と測定処理に分割し、測定対象のみループさせることが可能か検討する
    • ２段階認証等の手作業が必要となる機能が途中にある場合は自動化できる手段があるか検討し、なければどのように手動実行を挟むか検討する
  • 対象となるAPIを直接実行する
    • ログイン認証等必要な場合はそのAPIを実行した後に対象APIを実行する
    • トークンが必要な場合はトークン生成などもシナリオに含んでおく
  • 実際の業務を想定した負荷をかける
    • 測定用のシナリオとは別で負荷用のシナリオを実行するようにする
    • 実運用上並行してバッチも実行されるのであれば、そのバッチも一緒に実行する

• バッチ機能
  こちらもオンラインと同様に、業務に沿った処理フローでの実行が必要です。

  • 単独で実行するバッチは単独で実行する
    （負荷として並行で流すバッチがある場合は別）
  • 直列実行するバッチは直列で実行する
  • 並行実行するバッチは同時に実行する
  • 実際の業務を想定した負荷をかける
    • 実運用上並行してオンラインアクセスがあるであれば、
      オンライン機能を実行する負荷用シナリオも並行して実行する

データの準備

テストデータの準備というと、ほかのテストと同じように考えてしまいがちですが、性能テストのデータでは考慮することが非常に多いです。ここでデータを作りこんでおかないと、性能テストでは問題なかったのに本番で性能が出ない、という悲劇を生んでしまいます。
例えば以下のようなことを考慮する必要があります。

• データの分布
  データの分布は検索速度に大きく影響します。
  以下のような点に注意しながら、運用後のデータ分布を再現する必要があります。
  • 業務的な意味を考慮せずにツールで機械的にデータを作成していないか
  • 業務上取りうる値のみになっているか
  • 業務上特殊な分布が存在しないか
    （例えばキャンペーンを打ち出すサービスの場合、その期間に登録されるユーザが多くなります）
• データ量
  データ量も検索速度に大きく影響します。
  運用後に想定されるデータ量を投入する必要がありますが、大量のデータとなるため、手作業での作成は非現実です。そのため。ツールの作成から検討する必要があります。
• 外部サービスのデータ
  外部APIなどを使用する場合、その対抗先でもテスト用のデータが必要になります。こちらも事前に調整する必要があります。

負荷ツールの準備

負荷ツールの選定、および選定した負荷ツールを使えるようにするための準備が必要です。
データの作成もそうですが、この作業も時間がかかるため、計画的に進める必要があります。

負荷ツールのシナリオ作成では以下のような点を考慮する必要があります。

• ユーザの導線を考慮する
  例えばTOPページに行ってから各機能に遷移するなど、実際にユーザがたどる動きを再現する必要があります
• 負荷用のシナリオでは機能ごとのアクセス割合を意識する
  運用時にアクセスが多くなる機能を中心にアクセスするような負荷でないと、
  本番と負荷のかかり方が違ってしまいます。
• 複数ユーザによるアクセスの必要性
  ほとんどのシステムでは様々なユーザからアクセスが来るため、
  テストシナリオでも複数のユーザを使うようにしておかないと、
  本番と負荷のかかり方が違ってしまいます。
• サーバ側によるリクエスト冪等性の保証
  サーバ側でリクエスト冪等性を保証している場合は、実行日時やシーケンス番号のインクリメント、CSVでの実行回数等を実施してリクエストのIDとなる埋め込むことによって、サーバ側に同一リクエストと認識させない工夫を実施する
• Cookieやトークンの保持
  Cookieやトークンを利用するオンライン機能では、これらを保持したままシナリオ実行するよう設定が必要です。

事前の疎通確認

性能テストの実施方法は特殊なので、ほかのテストとは異なる手順になることがほとんどです。
そのため、いきなり本番を迎えると想定外の障害に遭遇することが多いです（経験談）。

事前に疎通確認をし、スムーズにテスト実施できるようにしておくと安全です。
以下のような点は事前に確認しておくことをお勧めします。

• データが想定通り投入できること
• まずは秒間１リクエストぐらいで実施できること
• 実際に使うシナリオが動くこと
• シナリオ実行中のサーバリソースが取得できること
• テストケースの手順通りにテストできること

続きの記事

次は実施・評価について書こうと思います。今度は４年もたたずに書けると思います（フラグ）。
性能テストの進め方については次回で最後になる予定です。