負荷テストはシステム開発において、リリース後の運用にかかわる重要なテストです。システムが事前に想定しているキャパシティを確保できているか、性能限界が来た場合にどのような対応をしたらよいか、高負荷障害の原因は何かなどを確認することが可能です。
しかしながら、時間的な制約等から実施されないケースも多くあります。そのため、十分な知識がないケースもあるようです。
この記事では、ディーネットがどのような形で負荷テストを進めているのかをご紹介していきます。また、負荷テストサービスの内容が気になる方はこちらをご覧ください。
負荷テストの流れ
全体の流れ
負荷テストは次のような流れで進めていきます。
- 目的設定
- 現状調査
- 負荷テスト設計
- 負荷テスト準備
- 負荷テスト実施
- 結果分析
- 結果報告
- （必要に応じて）チューニングを実施し、効果測定のために負荷テスト実施
以降で、それぞれの概要について説明していきます。
目的設定
まずは実施目的の設定を行います。
負荷テストを実施するシチュエーションによって目的は大きくことなります。リリース前のシステムであれば性能要件の証明など定量的にわかりやすい目的を立てることが可能です。しかしながら、運用中のシステムの場合は、目的に認識がずれやすくなるので、しっかりと共有することが重要です。
よくある目的設定には次のようなものがあります。
- 事前定義した性能要件を満たしていることを証明する
- どの程度の負荷に耐えることができるのかを事前把握しておく
- 目標性能を達成させるために性能向上させる
- 高負荷時に発生した障害の原因特定を行う
- 高負荷障害の対策を実施する
目的が具体的であればあるほど望ましい状態になります。一方で「高負荷時に発生する障害の対策を実施する」のように、目的があいまいなものは認識のずれが発生しやすくなるので注意が必要です。
現状調査
運用中のシステムが対象の場合は、負荷テスト設計のために現状調査を実施します。
調査内容は次のようなものになります。
- インフラ構成
- リソース状況
- アクセス状況
- サイト特性
- 他システム連携
調査に必要なログが残っており、適切な調査ができると、どのようなアクセスが発生し、どこかボトルネックになりそうかの当たりをつけることが可能です。その情報をもとに負荷テスト設計へと進んでいきます。
ここで十分な情報が取得できないと、設計や実施で場当たり的な対応が多くなり、大きな時間がとられることになります。時間短縮のためにも、可能な限り事前調査は行うようにしましょう。
負荷テスト設計
目的で定めたことをどのように実現していくかとまとめていくのが、負荷テスト設計です。
具体的には、
- 負荷テストツールの選定
- 負荷テスト環境
- シナリオ
- 積み上げデータ
- 利用データ
- 負荷テスト用のシステム改修の有無
などを決めていきます。
ここでの設計内容がその後の工数や成功可否に大きく影響していきます。苦労して実施した負荷テストが全く効果がないものだった。ということも起こりかねません。特にデータに関しては意外と盲点となるので、検討項目に漏れがないように注意しましょう。
負荷テスト準備
負荷テスト設計が完了したら、実施の準備を行います。具体的には次のようなことを行います。
- 負荷テスト専用環境構築
- 負荷テストツール環境構築
- 必要なシステムの改修
- データ積み上げ
- テストデータの用意
- 他システムとの調整
- シナリオ作成
- 負荷テストデータのクリア手法の実装
シナリオ作成はシナリオ本数や、扱うデータによって必要な時間が大きくかわります。最終的にテストデータが正常に動作するかの確認も必要になり「このデータでは動作するが、このデータでは動作しない。」というようなことも多発します。動作確認も含めて長めに時間を確保しておきましょう。
また、負荷テストを再実施する前に購入データをクリアする必要がある場合もあります。その場合は、クリア用のSQL等の用意も必要です。
JMeterのシナリオ作成については別途まとめているので参考にしてください。
負荷テスト実施
準備ができたら負荷テストを実施します。
意義のある負荷テストをするためには、注目する指標や進め方のポイントを押さえておく必要があります。
「同時接続500人に耐えられること」といった要件を証明するためにありがちな誤りとして、「JMeterで同時接続数を表す、スレッド数を500に設定する」ということがあります。
「スレッド数」は「タイマー」や「ランプアップ」といった設定値の影響を大きく受けます。設定次第で同じスレッド数500でも、超高負荷になることもあれば、負荷が全くかからないこともありえます。
それを回避するために、同時接続数を表す「スレッド数」という設定値ではなく「スループット」という結果指標を重視していきます。「スループット」とは、秒間あたりのトランザクション数のことを指し、単位は「tps（Transaction Per Second）」です。
またここでは、後続の分析フェーズをスムーズに行うために、負荷テスト実施時の設定ファイルやログファイル、リソース状況などのデータを取得し、整理しておく必要があります。
また、負荷テストの実施前に「基礎データの取得」と「低負荷テスト」を行うことで、手戻りが少なく効果的なテストを行うことが可能です。
結果分析
負荷テスト実施で取得したデータを分析します。
性能が劣化しはじめたタイミングのデータを使い、次のようなものについて分析していきます。
- サーバリソース状況
- スロークエリ
- リクエストごとの平均応答時間
それらをもとに、「目的が達成されているか」「ボトルネック」について分析します。「ボトルネック」が確認できた場合は、「チューニング案」についてもまとめていきます。
具体的な分析方法については別記事を確認ください。
結果報告
負荷テストの目的から設計、分析までの報告書をまとめて、その共有を行います。共有は対面の報告会形式をとることが多くあります。その内容をもとに「終了（または本番適用）」するのか「チューニング」へ進むのかを決めていきます。
「終了」の場合はプロジェクト終了の場合と、負荷テストで実施した施策を本番適用する場合の2パターンがあります。本番適用する場合は、適用スケジュールなどの調整を行います。
（必要に応じて）チューニングを実施し、効果測定のために負荷テスト実施
目的未達でチューニングが必要。という判断となった場合は、分析フェーズで特定した「ボトルネック」のチューニングを行います。チューニング実施後はその効果測定のために、「負荷テスト実施」「結果分析」「結果報告」とサイクルを回していきます。
一般的にはインフラ側でチューニングを行うよりも、アプリケーション側のチューニングを実施したほうが効果が高くなります。安易にインフラ拡張を行うのではなく、適切にボトルネックを見極めチューニングを実施していきましょう。
まとめ
この記事では具体的な負荷テストの進め方についてまとめていきました。
負荷テストを行うことで、次の効果を期待できます。
- 運用中のトラブル発生を未然に防ぐ
- 低コストなインフラで安定稼働させる
ぜひ適切な負荷テストを行い、システム安定稼働を実現してください。
負荷テストの流れ