この記事は、負荷テスト初学者向けの記事の第 1 回として『負荷テストとは？』『AWS上での負荷テストの方法』を解説しています。
次回の記事以降にて、「 Distributed Load Testing on AWS 」を利用して実際に負荷テストを実施するまでの試験計画〜実施までの流れを解説します。
こんにちは！エンタープライズクラウド部クラウドコンサルティング課の日高です。 もし私のことを少しでも知りたいと思っていただけるなら、私の後輩が書いてくれた以下のブログを覗いてみてください。
はじめに
現在、私は ANGEL Dojo 2024 という 3 ヶ月間でサービスの企画から開発まで行うトレーニングに参加をしています。
※ANGEL Dojo 2024 について詳しくは以下の記事をご覧ください。
そこで、実際に作成したサービスが稼働している AWS環境 において、システムが想定されるユーザー数に応じてスケールできるのか、またその負荷に耐えられるのかを検証したいと考えました。
しかし、当時私には負荷テストは全くの未経験でした。
そこで、過去の私と同じように負荷テストに詳しくない方に向けて、負荷テストの基礎から、実際にどのように試験を計画し、目標性能を設定していくかといった思考の流れを記載していきます。
また、本記事で紹介している実践内容は、負荷テスト on AWS のすすめ を参考にしています。
そのため、記事内では同ガイドの内容を引用・参考にした箇所がいくつか含まれています。
負荷テストの基礎
負荷テストとは何か
負荷テストとは、アプリケーションに意図的に高い負荷をかけ、その性能を確認するためのテストです。
システムがどれだけのユーザーに耐えられるかや、どこにパフォーマンスのボトルネックがあるのかを把握するために行われます。
負荷テストでは「パフォーマンス（性能）」を確認しますが、これには主に以下の2つの観点があります。
- 処理量（スループット）
- 処理時間（レスポンスタイム）
この2つの観点が、システムの応答性や耐久性を評価するための重要な指標となります。
処理量（スループット）
スループットは、単位時間（通常1秒）あたりに処理されるリクエストの数を示します。
オンラインアプリケーションでは、秒間に処理できるトランザクション数（TPS: Transactions Per Second）やリクエスト数（RPS: Requests Per Second）で定義されます。
またリクエスト数は、リクエストの数 ＝ 同時接続ユーザー数 × リクエスト発行頻度 で表すことができます。
- 同時接続ユーザー数：同時にリクエストを送信しているユーザーの数。
- リクエスト発行頻度：1秒間にユーザーが送るリクエストの回数や、リクエストを送る間隔。
例えば、10人のユーザーが1秒間に1回ずつリクエストを送る場合、スループットの理論値は10RPSです。
ただし、実際のスループットはシステムの処理能力に依存します。システムが処理能力を超えた負荷を受けると、スループットは理論上の最大値に達せず、性能が低下します。
処理時間（レスポンスタイム）
レスポンスタイムは、ユーザーからのリクエストを処理するのにかかる時間です。
ユーザーにとって重要なのは、リクエストがどれだけ速く処理されるかです。
レスポンスタイムが短いほど、ユーザーはアプリケーションを快適に利用できます。
レスポンスタイムの評価には、単に平均値を使うのではなく、パーセンタイル値が用いられます。
たとえば「95パーセンタイルで3秒以内」とは、全リクエストのうち95%が3秒以内に完了することを意味します。
このようにパーセンタイル値を使うことで、性能の安定性や一部の遅いリクエストがユーザー体験にどれほど影響するかを正確に把握できます。
Tips: レスポンスタイムを平均値ではなく統計的に見る理由
レスポンスタイムを平均値ではなく、パーセンタイルなどの統計手法で評価する理由は、システムのパフォーマンスのばらつきをより正確に把握するためです。以下に、主な理由を簡潔に説明します。
1.平均値の限界
- 少数の極端に遅いリクエスト（アウトライヤー）が、平均値を大きく引き上げてしまうことがあります。
- そのため、ほとんどのリクエストが高速でも、平均値が実際のパフォーマンスを正確に反映しないことがあります。
2.パーセンタイルの利点
- パーセンタイルは、全リクエストの中で何パーセントがどの時間内に処理されたかを示します。
- たとえば、95パーセンタイルで3秒なら、全リクエストの95%が3秒以内に処理されたことを意味します。
- これにより、実際のパフォーマンスがどの範囲に収まっているのかが分かります。
3.ユーザー体験の反映
- 多くのユーザーがどれくらいの時間で応答を得られるかを正確に把握できます。
少数の遅いリクエストが平均値に影響するのではなく、ほとんどのユーザー体験を基に評価できるため、システムの健全性を把握しやすくなります。
SLAやSLOに対応
多くのサービスレベル目標（SLO）やサービスレベル合意（SLA）では、パーセンタイルを使って目標が設定されます。
- 例えば「95パーセンタイルで2秒以内」といった形で、より現実的でユーザー体験に基づいた目標を設定できます。
パーセンタイルを使うことで、システムのパフォーマンスをより正確に把握でき、ユーザー体験やサービスレベル目標にも対応した評価が可能になります。
そのため、平均値ではなく統計的手法で評価することが一般的です。
なぜ実施するのか
負荷テストの目的は、アプリケーションがビジネスの要求に応える性能を持っているか確認することです。
アプリケーションの「性能が足りない」とは、スループットやレスポンスタイムがビジネスの要求に応えられない状態を指します。
※動画配信サービスの例
- スループット不足：新作映画の公開時、多くのユーザーが同時にアクセスすると、処理能力が足りず、サイトにアクセスできない、動画が再生できないなどの問題が発生する可能性があります。
- レスポンスタイム遅延：動画の再生が遅いと、ユーザーは離脱し、他のサービスに移るリスクがあります。
例に挙げた通り、アプリケーションがビジネス要求に応えられるかを確認し、ピーク時のパフォーマンスや限界性能を把握することは非常に重要です。
負荷テストでは、このようなビジネス上の損失を防ぐために実施します。
定義
負荷テスト等の性能に関する試験の名称はさまざまなものが挙げられています。
この章では負荷テストの言葉について定義していきます。
また、負荷テストの定義や性能試験の種類・定義については、負荷テスト on AWS のすすめ 第 2 回 : 負荷テストを計画しよう - 本題に入る前に : 性能試験の種類と言葉の定義で非常にわかりやすく解説されています。今回は、その中から特に重要な部分を抜粋して紹介させていただきます。
結論（負荷テスト on AWS のすすめ 第 2 回 : 負荷テストを計画しよう の抜粋）
- 性能試験 : システム性能を担保するために実施するテスト全体を指すものとして定義します。以下で挙げる試験種別をすべて包含する、テストの大きな 1 カテゴリを指します。
- 負荷テスト : 「負荷クライアントを用いて、オンライン処理の負荷を発生させるテスト」として定義します。すなわち、以下で挙げる試験種別のうち「②ピーク性能試験」「③限界性能試験」「④長時間負荷試験」「⑦オンライン・バッチ並走負荷試験」がその対象となります。
- オンライン単性能試験：単体でレスポンスタイムを測定し、問題がないか確認する。
- ピーク性能試験：大量のユーザーリクエストを模擬し、目標とする負荷でエラーなく、レスポンスタイムが基準内に収まるか確認する。
- 限界性能試験：負荷を徐々に増やしていき、システムが応答できなくなるポイントを確認し、ボトルネックを特定する。
- 長時間負荷試験：長時間の負荷をかけ、メモリリークや性能劣化が発生しないか確認する。
- バッチ単性能試験：バッチ処理を単体で実行し、目標の処理時間に収まるか確認する。
- バッチ複合試験：複数のバッチ処理が並走する環境で、全体の処理時間が問題ないか確認する。
- オンライン・バッチ並走負荷試験：オンライン処理とバッチ処理が並走する環境で、両方に性能問題がないか確認する。
負荷テストの進め方
負荷テストの進め方については、負荷テスト on AWS のすすめ 第 1 回 : 負荷テストの全体像を理解しよう - 2. 負荷テストの進め方で非常にわかりやすく解説されています。
今回は、その中から特に重要な部分を抜粋して紹介させていただきます。
全体像
試験計画
まず初めに行うのが「試験計画」です。この段階では、テストの目的や目標、試験項目を決定し、負荷テスト全体の枠組みを固めます。
計画の段階でしっかりとした土台を作ることで、後のテストがスムーズに進みます。
負荷テストの目的・目標を決定する
- 負荷テストでは、システムが想定される最大アクセス量を処理できるか、そしてその時にレスポンスタイムが目標内に収まっているかを確認します。
例えば、オンラインショップでの大規模セール時のピークアクセスや、バッチ処理の重複など、具体的なビジネス上のシチュエーションを基に、性能の目標を定めます。
例: 「セール開始直後に発生する大量のアクセスに耐えられるか確認する」
- 目標の設定には、過去の実績データやビジネスの予測を基に、最大アクセス数やレスポンスタイムを数値化して定義します。
負荷シナリオと負荷モデルを作成する
- 次に、システムにかかる負荷のシナリオを作成します。
- 例えば、ユーザーがトップページにアクセスし、商品を検索してカートに追加、最終的に購入するという流れをシミュレートします。このシナリオに基づいて、どの操作にどれだけの負荷がかかるかを決定します。
- 負荷モデルでは、全ての操作を再現することは難しいため、アクセスログなどを基に主要なリクエスト（80〜90％を占めるもの）を選定し、それに基づいて負荷を再現します。
前提条件の設定
- システムのパフォーマンスに影響を与える要因として、データベースのデータ量やキャッシュの状態などを考慮する必要があります。
- 例えば、データベースに大量のデータが格納されている状態や、キャッシュがクリアされた状態でのテストを行い、本番に近い条件で負荷をかけます。 例: データベースに大量のレコードが存在する場合、検索処理のパフォーマンスに影響が出るため、実際のデータ量を模倣した状態でテストを行います。
試験環境の構築
- テストを実施する環境も重要です。
- クラウドを使用する場合は、本番環境と同じスケールでテスト環境を構築し、負荷に対して正確な評価を行えるようにします。
- 縮小版環境では実際の負荷テストの効果が薄れるため、できるだけ本番同様の環境を準備することが推奨されます。
監視ツールの選定
- 負荷テスト中にはシステムの動作状況を監視するためのツールが必要です。
- レスポンスタイムやスループットの測定、リソース使用率をリアルタイムで確認し、テスト後のボトルネック分析に役立てます。
試験準備
計画が整ったら、次に「試験準備」に移ります。ここでは実際にテストを実行するための環境やツールを準備します。
試験用システムの準備
- 負荷をかける対象のシステムやクライアント環境を整えます。
- 例えば、データベースやアプリケーションサーバーが適切に構成されているかを確認し、試験中に使用するツール（例：JMeter）の設定も行います。
負荷クライアントの設定
- 負荷をかけるためのクライアント（テストツール）を準備し、どのような負荷をどのタイミングでかけるかをシナリオに基づいて設定します。
- 分散型の負荷テストツールを使う場合、クライアント数や負荷量を自由に調整できるため、スムーズなテスト実施が可能です。
データ作成
- テストを行う際のデータベースの状態を整えることも重要です。
- データベースに大量のデータが格納されている状態や、キャッシュがクリアされた状態でテストを行い、本番環境に近い条件で負荷をかけます。
監視とトラブルシューティングの準備
- 負荷テスト中にシステムに何か問題が発生した場合、すぐに原因を特定できるよう、ログやメトリクスの監視をセットアップします。
- 特に、モニタリングツールを利用して、パフォーマンスの問題を早期に発見できるようにすることが重要です。
試験実施
いよいよ負荷テストを実施する段階です。テストは一回で終わることは少なく、目標を達成するために複数回実行することが一般的です。
この段階で重要なのは「ショット」と呼ばれるテストを繰り返しながらチューニングしていくことです。
- ショット準備: ショットとは、一回のテストのことです。どのショットで何を確認するか、例えば「ピーク時の負荷に耐えられるか」や「前回のテスト後の改善点がどのように影響したか」を定義します。
- ショット実行: テストツールを使ってシステムに負荷をかけ、結果を確認します。この時、データベースの状態を一定に保つためにデータの初期化なども行います。
- ショット分析: スループット（処理速度）やレスポンスタイム（応答時間）を確認し、目標を達成できたかを評価します。また、システムのボトルネックがどこにあるかを分析します。
結果評価
負荷テストが完了したら、その結果をもとにシステムの評価を行います。
この評価を基に、運用中にどのようにシステムを改善するかを検討します。
- テスト結果の取りまとめ: テストで得られたデータをまとめ、システムがどのくらいの負荷に耐えられるか、またはどこが改善の余地があるかを報告します。
- チューニング結果の整理: テスト中に行ったチューニング内容を整理し、それによってどのような効果があったかをまとめます。
- 次のアクションを検討: テスト結果を基に、今後の改善や運用方針を決定します。例えば「ピーク時にスケーリングする基準を設ける」などです。
AWSでの負荷テストツール
AWS のサービスとして、AWS Fault Injection Simulator（FIS）とDistributed Load Testing on AWS が存在しています。
いずれもアプリケーションのテストを目的としたAWSのサービスですが、目的とアプローチが異なります。
以下にその違いを説明します。
AWS Fault Injection Simulator (FIS)
FIS を利用する目的は、 カオスエンジニアリングを行い、システムの耐障害性や回復力をテストすることです。
FISは、故意にシステムやアプリケーションに障害を注入することで、アプリケーションの回復能力や回復方法を確認するツールです。
例えば、インスタンスの停止や遅延を発生させたり、ネットワーク接続の断絶などをシミュレートすることができます。
このプロセスは「カオスエンジニアリング」と呼ばれ、障害が発生した際にシステムがどう動作するかを確認し、予期せぬ問題やボトルネックを発見するために使われます。
主な特徴を以下に示します。
- システム全体の障害注入シナリオを実行。
- インスタンスやコンテナの停止、CPU負荷増加、ネットワークの問題などをシミュレーション。
- システムの復旧プロセスやオートスケーリングの動作確認。
- 利用シーン: 可用性が重要なシステムや、システム障害時にどう対処するかをテストする場合に有用。
Distributed Load Testing on AWS
Distributed Load Testing on AWS を利用する目的は、分散負荷テストを行い、アプリケーションやシステムのパフォーマンスを確認することです。
Distributed Load Testingは、WebアプリケーションやAPIなどに対して大量のユーザーアクセスをシミュレーションし、システムのスケーラビリティやパフォーマンスを評価するためのツールです。
これにより、トラフィックが集中する状況でシステムがどのように応答するか、負荷に耐えられるかをテストします。
AWSのこのサービスはJMeterをベースにしており、負荷を複数のリージョンに分散させて実施することが可能になっています。
主な特徴を以下に示します。
- 高トラフィックのシナリオをシミュレーションし、システムの限界を測定。
- 負荷分散のパフォーマンスやスケーリングの確認。
- リクエスト遅延、エラーレート、スループットなどの指標を計測。
- 利用シーン: WebアプリケーションやAPIのスケーラビリティ、負荷処理能力、応答時間を測定したい場合に有用。
違いのまとめ
- AWS FISは、システムの耐障害性や回復力をテストするために意図的に障害を引き起こすツールで、カオスエンジニアリングに焦点を当てています。
- Distributed Load Testing on AWSは、システムに大量のトラフィックをかけて負荷をシミュレーションし、パフォーマンスやスケーラビリティをテストするツールです。
どちらもシステムの堅牢性をテストするために役立ちますが、FISは「障害発生時の動作確認」、Distributed Load Testingは「高負荷時のパフォーマンス確認」が主な目的となると考えています。
まとめ
負荷テストについて全くの初学者だったので、全体像を把握するのに苦労しました。
本記事が誰かの助けになれば幸いです。
また、後編の記事では、「 Distributed Load Testing on AWS 」を利用して実際に負荷テストを実施するまでの試験計画〜実施までの流れを解説していきたいと思います。
それでは、また 次回の記事 でお会いしましょう !
日高 僚太(執筆記事の一覧)
2024 Japan AWS Jr. Champions / 2024 Japan AWS All Certifications Engineers
EC部クラウドコンサルティング課所属。2022年IT未経験でSWXへ新卒入社。
記事に関するお問い合わせや修正依頼⇒ hidaka@serverworks.co.jp
