コトラ（広報チーム） 
ストレステストの概要と実施する目的
ストレステストの基本的な意味
ストレステストとは、システムに通常の利用状況を上回る大きな負荷を意図的にかけ、限界や障害時の動きを確認するテストです。Webサイト、業務システム、アプリケーション、データベースなどを対象に実施します。
単に「どれだけ多くの利用者を処理できるか」を調べるだけではありません。負荷が限界を超えた際に、どの機能から遅くなるのか、エラーが適切に返されるのか、停止後に正常な状態へ戻れるのかを確かめることが重要です。
想定を超える負荷をかけて限界を確認するテスト
ストレステストでは、想定される最大利用者数や処理量を超える負荷を段階的、または急激に与えます。例えば、同時アクセス数を少しずつ増やしたり、短時間で大量の注文・検索・ログイン処理を発生させたりします。
負荷を高めることで、応答時間が悪化し始める地点、処理件数が増えなくなる地点、エラーが急増する地点を把握できます。こうした限界点を事前に知ることで、実際の運用中に予想外のアクセス集中が起きた場合にも、適切な対策を講じやすくなります。
システム障害の影響を抑えるために必要な理由
通常のアクセス量で問題なく動作していても、セール、キャンペーン、ニュース掲載、月末処理などで利用が急増すると、システムが不安定になることがあります。障害が起きた場合、利用者がサービスを使えなくなるだけでなく、取引機会の損失や問い合わせの増加、信頼低下につながる可能性があります。
ストレステストを行えば、障害のきっかけとなる弱い部分を運用前に見つけられます。また、すべての機能が停止するのではなく、重要度の低い処理を抑えながら主要機能を維持できるかも確認できます。
確認できる性能・安定性・復旧力
ストレステストでは、主に次の観点を確認します。
- 負荷が増えたときの応答時間と処理件数
- 同時に利用できる人数や処理の上限
- CPU、メモリ、データベース接続数などの使用状況
- エラーが発生した際の内容と影響範囲
- 負荷を下げた後に自動で通常状態へ戻るか
- 停止した機能やサーバーを復旧させる手順
- 処理途中のデータが失われたり重複したりしないか
性能だけでなく、限界を超えた場合に安全に処理を抑え、利用者への影響を最小限にできるかを確かめる点が特徴です。
ストレステストと他の性能テストとの違い
負荷テストとの違い
負荷テストは、想定される通常時や繁忙時の利用状況で、システムが求められる性能を満たすか確認するテストです。例えば、想定最大利用者数で画面表示や注文処理が問題なく行えるかを確認します。
一方、ストレステストは想定値を超えて負荷をかけ、システムがどこまで耐えられるかを調べます。負荷テストが「予定どおりの混雑に対応できるか」を確認するものであるのに対し、ストレステストは「想定外の混雑でどのように壊れ、どう戻るか」を確認するものです。
ロードテストとの違い
ロードテストは、一定の利用者数や処理量を継続して与えた際の性能を確認するテストです。実務では負荷テストとほぼ同じ意味で使われることもあります。
ストレステストとの違いは、主な目的にあります。ロードテストでは、設定した負荷の範囲内で安定した応答時間や処理能力を保てるかを見ます。ストレステストでは、負荷をさらに増やし、性能低下や停止が始まる条件、障害後の回復状況まで確認します。
耐久テストとの違い
耐久テストは、通常から繁忙時レベルの負荷を長時間かけ続け、時間の経過によって性能が悪化しないかを確認するテストです。数時間から数日間にわたり実施されることもあります。
耐久テストでは、メモリ使用量が徐々に増え続ける問題や、処理待ちのデータがたまり続ける問題などを見つけます。これに対し、ストレステストは、短時間でも限界を超える強い負荷を与え、障害が起きる条件や復旧のしやすさを確認します。
ボリュームテストとの違い
ボリュームテストは、大量のデータを扱った場合の動作を確認するテストです。例えば、データベースに大量の登録情報がある状態で検索や集計が遅くならないか、大きなファイルを処理できるかを調べます。
ストレステストは、同時アクセス数や処理回数の急増など、システム全体への負荷に重点を置きます。ただし、大量データの処理と同時アクセスが重なれば、ボリュームテストとストレステストを組み合わせて実施する必要があります。
目的に応じたテストの使い分け
性能に関するテストは、目的に応じて使い分けることが大切です。
- 負荷テスト・ロードテスト：想定される利用者数や繁忙時の性能を確認する
- ストレステスト：想定以上の負荷で限界、障害時の動き、復旧力を確認する
- 耐久テスト：長時間の利用で性能低下や資源不足が起きないか確認する
- ボリュームテスト：大量データによる処理遅延や不具合を確認する
重要なシステムでは、いずれか一つだけではなく、リスクや利用状況に合わせて複数のテストを計画します。
ストレステストで確認する主な項目
同時アクセス数が増えた場合の動き
同時アクセス数は、同じ時間帯にシステムを利用する人数や接続数を指します。アクセスが増えた場合に、画面表示、ログイン、検索、登録、決済などの重要な操作がどの程度まで正常に行えるかを確認します。
特に、同時利用者数を増やしても処理件数が伸びなくなった時点は重要です。この状態では、サーバーやデータベースの一部が限界に近づいている可能性があります。
処理量が急増した場合の応答時間
応答時間は、利用者が操作してから結果が返るまでの時間です。負荷が高まると、平均的な応答時間だけでは問題を判断しにくくなります。大半の利用者は問題なく使えていても、一部の利用者だけが極端に長く待たされる場合があるためです。
そのため、遅い応答がどの程度発生しているか、タイムアウトが増えていないか、処理件数がどこで頭打ちになるかを合わせて確認します。
CPUとメモリの使用状況
CPUは処理を行うための資源であり、メモリは処理中の情報を一時的に保持する場所です。CPU使用率が高い状態が続く、またはメモリが不足する状態になると、応答遅延や処理停止が起こる可能性があります。
ストレステストでは、どの処理でCPUやメモリの使用量が増えるかを確認します。負荷を下げてもメモリ使用量が戻らない場合は、不要な情報が解放されていない可能性があります。
データベースとネットワークの処理状況
システムの遅延は、アプリケーション本体ではなく、データベースやネットワークが原因となることもあります。データベースへの接続数が上限に達したり、検索処理が集中したりすると、画面側のサーバーに余力があっても処理が遅くなります。
ネットワークについては、通信量、通信遅延、接続失敗、外部サービスへの呼び出し時間などを確認します。複数のシステムが連携する構成では、一つの外部サービスの遅延が全体に広がらないかも重要です。
エラー発生時の動きと復旧までの時間
負荷が限界を超えた場合、エラーが発生すること自体を完全に避けられないケースもあります。重要なのは、エラー発生時にシステムが無秩序に停止しないこと、利用者に適切な案内を返すこと、負荷が下がった後に回復できることです。
復旧時間を確認する際は、応答時間、エラー率、処理待ち件数、サーバーの状態が通常の水準に戻るまでを記録します。自動で回復できない場合は、手動対応の内容と所要時間も整理します。
ストレステストの実施手順
テストの目的と合格基準を決める
最初に、何を確認するためのテストなのかを明確にします。例えば、最大同時利用者数を把握する、急なアクセス増加時の動きを確認する、障害後の復旧手順を検証するといった目的が考えられます。
合格基準も事前に定めます。「一定の利用者数までは応答時間を所定の範囲に収める」「エラー率が一定値を超えたら負荷を止める」「負荷低下後に指定時間内で通常状態へ戻る」といった基準です。基準がなければ、結果を客観的に評価できません。
実際の利用状況に近いテスト環境を用意する
テスト環境の構成が本番環境と大きく異なる場合、得られた結果をそのまま本番に当てはめることはできません。サーバー性能、データベース設定、通信経路、負荷分散の設定、自動増設の設定などを、できるだけ本番に近づける必要があります。
また、実際の利用に近いデータ量や操作内容を用意することも重要です。簡易的なデータだけでは、本番で起きる検索の遅延やデータベース負荷を再現できないことがあります。
利用者数・処理量・負荷のかけ方を設計する
テストでは、どの操作にどの程度の割合で負荷をかけるかを設計します。例えば、閲覧、検索、登録、更新、決済などの操作を、実際の利用傾向に近い割合で組み合わせます。
負荷のかけ方には、少しずつ増やす方法と、短時間で急増させる方法があります。段階的な負荷増加は限界点を把握しやすく、急激な増加は突発的なアクセス集中への強さを確認するのに向いています。目的に応じて使い分けます。
監視項目を設定して段階的に負荷を高める
テスト中は、利用者側の応答時間やエラーだけでなく、サーバー、データベース、ネットワーク、処理待ちの状況を同時に監視します。事前に監視設定を確認し、記録が残る状態にしておくことが必要です。
負荷は段階的に高め、各段階で状態が落ち着くまで観察します。急に最大負荷をかけると、どの水準から悪化が始まったのかを判断しにくくなります。ただし、突発的な負荷を想定する場合は、別途急増パターンのテストを実施します。
結果を記録して原因と改善点を整理する
テスト後は、負荷の水準ごとに応答時間、処理件数、エラー率、資源使用量を整理します。性能が悪化し始めた時点と、その時に上限へ近づいた資源を照らし合わせることで、原因を絞り込みやすくなります。
改善策を実施した後は、同じ条件で再テストします。一度の改善で終わらせず、最初の制約を解消した後に新たな制約が現れていないか確認することが重要です。
限界に達したときに確認すべき障害時の動き
応答が遅くなり始める負荷の水準
利用者が不便を感じ始める前に、応答時間の悪化が始まる水準を把握します。処理件数が増えているにもかかわらず応答時間だけが伸びている場合、どこかで処理待ちが発生している可能性があります。
この水準は、システムの実用上の上限を考えるうえで重要です。完全停止するまで負荷をかけられる場合でも、応答が著しく遅くなる水準を運用上の警戒ラインとして設定する必要があります。
エラーや停止が起きる条件
エラーが発生する条件は、利用者数だけでは決まりません。特定の画面や処理への集中、大量データの検索、外部サービスの遅延、データベース接続数の不足など、複数の要因が影響します。
どの操作で、どの順番で、どの種類のエラーが増えたのかを記録します。エラーの内容が利用者にとって分かりにくいものになっていないか、再試行によってさらに負荷が増える状態になっていないかも確認します。
一部の機能を止めた場合の影響範囲
高負荷時には、すべての機能を同じ優先度で維持しようとすると、全体が停止するおそれがあります。そのため、重要度の低い集計、通知、画像処理などを一時的に抑え、主要な機能を維持する設計が有効な場合があります。
ストレステストでは、一部機能を制限した際に、どの利用者や業務に影響が出るかを確認します。重要な処理まで止まらないか、停止した機能を後から安全に再開できるかも検証します。
自動復旧と手動復旧の手順
サーバーの自動再起動、予備系への切り替え、処理待ちデータの再実行などが期待どおりに動くかを確認します。自動復旧が働くまでの時間や、その間に失われる処理がないかを把握することが必要です。
手動復旧が必要な場合は、誰が、どの画面や操作で、どの順番に対応するのかを手順化します。担当者しか分からない復旧方法では、障害時の対応が遅れる可能性があります。
利用者への通知とデータ保護の仕組み
障害時には、利用者に状況を分かりやすく伝えることも重要です。単にエラー画面を表示するのではなく、混雑状況、再試行の目安、処理受付の可否などを適切に案内できるかを確認します。
また、処理途中で障害が起きた場合に、データが消失、重複、矛盾しない仕組みが必要です。特に登録、更新、決済などの処理では、利用者に完了したように見えて実際には処理されていない状態を防がなければなりません。
ストレステストで見つかりやすい課題と対策
処理が集中する箇所を特定する
ストレステストでは、一部の処理に負荷が集中していることがよくあります。例えば、特定の検索条件、登録処理、外部サービスとの連携、共通の認証処理などが原因になる場合があります。
応答時間、処理件数、エラー、CPU、メモリ、データベース接続数などを時系列で比較し、最初に悪化した箇所を特定します。見かけ上の症状だけで判断せず、処理の流れを追って原因を確認することが重要です。
サーバーやデータベースの性能を見直す
CPUやメモリが継続的に上限へ近づく場合は、サーバーの性能や台数を見直します。ただし、単純にサーバーを増やしても、データベースや外部連携が制約になっていれば改善しないことがあります。
データベースでは、検索条件の見直し、不要な処理の削減、接続数の設定、読み取り処理の分担などを検討します。改善前後で同じストレステストを行い、実際に限界点が変化したかを確認します。
処理を分散して負荷を偏らせない
一つのサーバー、データベース、外部サービスに処理が集中すると、そこが全体の弱点になります。処理を複数のサーバーに分散したり、時間のかかる処理を待ち行列に入れて後で実行したりすることで、急な負荷を吸収しやすくなります。
また、優先度の低い処理を後回しにする、利用者ごとの処理量を制限するなどの方法も有効です。重要な機能を守るために、過剰な要求を適切に制御する考え方が求められます。
監視と通知の設定を改善する
障害の兆候を早くつかむには、CPU使用率だけでなく、応答時間、エラー率、処理待ち件数、データベース接続数などを監視する必要があります。単一の指標だけでは、利用者への影響を正しく判断できないことがあります。
通知の基準は、完全停止してからではなく、性能悪化の初期段階で検知できるように設定します。一方で、通知が多すぎると重要な異常を見落とすため、対応の優先度と連絡先を整理しておくことも必要です。
改修後に再テストして改善を確認する
改善策を実施した後は、同じ条件で再度ストレステストを行います。テスト結果を比較し、応答時間が改善したか、エラー発生の水準が上がったか、復旧時間が短くなったかを確認します。
一つの問題を解決すると、別の箇所が新たな制約として現れることがあります。そのため、ストレステストは一度限りの確認ではなく、システム変更、利用者増加、大型機能の追加、繁忙期の前などに繰り返し実施することが重要です。
