負荷テスト設計のポイントをまとめていきます。ポイントは次の通りです。
- 負荷テストツールの選定
- 負荷テスト環境
- シナリオ
- 積み上げデータ
- 利用データ
- 負荷テスト用のシステム改修の有無
負荷テストツールの選定
負荷テストをどのツールを使って行うかを決めていく必要があります。
OSSで主要なツールは、
- ab（apache bench）
- JMeter
ではないでしょうか。
abは、httpdパッケージに標準搭載されており、「単体のURLのみ」など簡易的な負荷テストを実施する用途に向いています。反対に、ログインを伴うような複数の画面遷移が必要な負荷テストには向いていません。
JMeterは、abとは反対に複雑なシナリオが必要となるケースに向いています。具体的には、ECサイトのようにcookieや動的なパラメータの受け渡しを伴い、複数の画面遷移が必要なシステムの負荷テストが実施できるようになります。
より実践的な負荷テストを行うために、当社ではJMeterを利用したテストを多く行っています。
負荷テスト環境
負荷テスト専用環境を構築するのか、本番環境を利用するのかについても決める必要があります。
リリース前のシステムであれば本番環境を利用するケースが多くなりますが、運用中のシステムの場合は、どちらを利用するかの検討が必要です。それぞれの違いは次の通りです。
| 比較項目 | 本番環境 | 負荷テスト専用環境 |
|---|---|---|
| 本番への影響 | 高負荷障害の可能性あり | 影響なし |
| 本番との差異 | なし | 発生する可能性あり |
| 追加工数 | かからない | 新規環境構築と動作確認が必要 |
| 実施時間の制約 | アクセスが少ない夜間やメンテナンス中 | 特になし |
| データの制約 | 本番データのため変更不可 | テスト用に加工や追加削除が可能 |
| アプリケーションの制約 | 本番ソース | テスト用に改修が可能 |
本番環境への影響を考えると、運用中のシステムであれば、負荷テスト専用環境を構築することをお勧めしています。「どうしても本番環境での確認もしておきたい」という場合は、専用環境で負荷テストを行い、最終確認のために最後に一度だけ本番環境で実施するケースもあります。
シナリオ
負荷テストでは、ユーザーの動きを想定したシナリオを作成し、複数人が同時実行するシュミレーションを行います。そのため、どのようなシナリオにするかは非常に重要です。
アクセスが多いページが含まれていなければ適切な負荷がかからなくなり、アクセスが少ないページが含まれていれば余計な負荷がかかることになります。
サイトの特徴やGoogleAnalyticsなどから、ユーザーの動線を理解し、代表的なユーザーの遷移を把握しておきましょう。
また、シナリオは複数のものを同時に実行することが可能です。たとえば、
- 閲覧のみのユーザー
- 会員登録して購入まで行うユーザー
- ログインして購入まで行うユーザー
のような3つのシナリオを同時実行できます。
その場合、各シナリオの割合も決める必要があります。閲覧のみのユーザーが8割なのか、2割なのかによってシステムの負荷は大きく変わります。複数のシナリオを同時実行する場合は、その割合についても決めておきましょう。
積み上げデータ
積み上げデータは、データベースに格納されているデータの件数です。
どんなシステムでもデータ件数が少ない場合は、性能の問題は発生しにくいものです。しかし、データ件数に大きく依存するようなつくりのシステムの場合、データの増加とともに急激に性能の問題が顕在化してきます。
運用中の問題を解決したいのであれば本番と同等のデータ件数を、リリース前や未来のために行う場合は想定したデータ件数を用意する必要があります。
必要以上にデータが多い場合、負荷テスト専用環境でのみ発生する性能問題が起き、切り分けに無駄な工数を割くことになります。反対に、必要以上にデータが少ないと本番で発生するはずの性能問題のシュミレーションができなくなり、本番環境で想定外の性能問題に苦しむことになります。
積み上げデータの試算を行い、根拠ある件数を用意するようにしましょう。
利用データ
積み上げデータ以外にも、負荷テストで利用するデータの検討も必要です。具体的には、ログインユーザー情報や購入商品の情報などが該当します。
データの特性に応じて、同一のものを使いまわすのか、複数件用意するのかを考える必要があります。
ログインユーザーは、複数件のユーザーをあらかじめ用意し利用します。1件のものを使いまわすとセッションエラーが発生し、シナリオが正常に進まない可能性があります。
購入する商品データは、1件にするか複数件にするかで結果に大きく影響するため、システムの特性によって検討が必要です。
一般的には購入処理には排他処理が入っているため、1件の商品に購入が集中すると性能が劣化しやすくなります。反対に同じ購入件数でも複数商品に分散すると排他処理の影響を受けにくくなり、性能の劣化が起きにくくなります。そのことを踏まえて、利用する商品データの件数を決めていきます。
実際の購入実績から逆算して、100件中80件は同一商品、残りの20件は別の商品というような設定の仕方が最適です。
負荷テスト用のシステム改修の有無
負荷テストでは、通常発生する以上の負荷をかけるため、思わぬ箇所へ影響を及ぼすことがあります。また、JMeter等のツールを使うためシナリオ上の制約が発生します。それらを回避するために、システムの改修が必要になる場合があります。
よくある例は次の通りです。
- 決済モジュールとの連携
- 他システムとの連携
- 会員登録時に発行する仮登録URLのメール通知
- 商品購入時のメール通知
- CAPCHA認証やトークン決済(javascripで完結するような処理)
他システム連携部分は、規約により負荷テストを禁止しているところもあり影響が大きくなる可能性があるので、必ず確認しておきましょう。
まとめ
負荷テスト設計を適切に行うことで、実施フェーズを円滑に進めることが可能です。逆に十分な設計ができていないと、問題が頻発し余計な工数をかけることになってしまいます。
負荷テストは関係者が多くなりがちなので、設計段階で必要な調整ごとをすべて洗い出し、実施フェーズを円滑にすすめられるようになりましょう。
参考．
全体的な負荷テストの進め方が気になる方は、「負荷テストの進め方」をご覧ください。