この記事は、負荷テスト初学者向けに「 Distributed Load Testing on AWS 」を利用して、実際に負荷テストを実施するまでの試験計画までの流れを解説しています。
次回の記事にて、「 Distributed Load Testing on AWS 」を利用して、実際に負荷テストを実施してみた流れについて解説します。
前編のブログにて、『負荷テストとは？』『AWS上での負荷テストの方法』について解説しています。
こんにちは！エンタープライズクラウド部クラウドコンサルティング課の日高です。 もし私のことを少しでも知りたいと思っていただけるなら、私の後輩が書いてくれた以下のブログを覗いてみてください。
はじめに
本記事は、負荷テスト初学者向けに『負荷テストとは？』『AWS上での負荷テストの方法』『実際に負荷テストを実施するまでの試験計画〜実施までの流れ』を解説する記事の第2回目の記事になっています。
『負荷テストとは？』『AWS上での負荷テストの方法』について解説している前編のブログは以下になります。
本記事では、「 Distributed Load Testing on AWS 」を利用して実際に負荷テストを実施するまでの試験計画〜実施までの流れを解説します。
また、本記事で紹介している実践内容は、負荷テスト on AWS のすすめ を参考にしています。
そのため、記事内では同ガイドの内容を引用・参考にした箇所がいくつか含まれています。
前提（make it ! の概要）
現在、私は ANGEL Dojo 2024 という 3 ヶ月間でサービスの企画から開発まで行うトレーニングに参加をしています。
※ANGEL Dojo 2024 について詳しくは以下の記事をご覧ください。
そこで企画〜作成したサービスが「make it ! 」というサービスです。
「make it !」は、ITに苦手意識を持つ方の相談をAIがサポートするサービスです。
IT に関する質問の約60%はAIが自動で解決し、解決が難しい場合は状況を整理して家族や知人に転送します。
この機能により、これまでかなりの負担がかかっていた相談対応がグッと楽になり、相談を受ける側の負担が大幅に軽減されます。
簡単な操作で、誰でも使いやすく設計されているため、家族からのITに関する相談を効率的に解決できる点が特徴的なサービスです。
実践！負荷テストの計画作り
前編のブログでは、「負荷テストの目的は、アプリケーションがビジネスの要求に応える性能を持っているか確認することです」と記載しました。
ここで言う「アプリケーションがビジネスの要求に応える性能を持っている」とは、具体的に以下のような要素に分解できます。
1.ピーク性能の確認
- アプリケーションが予想される最大量のアクセス（スループット）をエラーなく処理できるかどうか、その際もレスポンスタイムが目標値内に収まっているかを確認します。
2.限界性能の確認
- アプリケーションが目標のレスポンスタイムを守りながら、どれだけのアクセス量を捌けるのか、限界に到達する際にボトルネックがどこに存在するのかを把握します。
このように、負荷テストを通じてアプリケーションのピーク性能と限界性能を明らかにすることが、ビジネスに求められる性能を確保するために重要となります。
それでは、ここからは Angel Dojo で企画・開発したサービス「make it !」の負荷テスト計画を進めていきます。
※本記事では、負荷テスト初学者である私が、Angel Dojo で企画したサービスに対して負荷テストをどのように実施するかを記載しています。そのため、実際の業務で用いられる負荷テストの定義と一部異なる点があるかもしれませんが、予めご了承ください。
負荷テストの目的
make it ! は、IT の相談事を AI チャットで解決するというテーマのサービスなので、ECサイトのように「大規模セールの開催における需要の急増」のような側面は持ち合わせていないサービスになります。
そのため、今回は以下のような目的を定義しました。
- make it ! の想定利用ユーザー数によるアクセス集中においてサービスが止まることなく稼働することを確認する
- make it ! の想定利用ユーザー数以上の需要によるアクセスによる上限緩和の必要性や、限界性能について想定する
目標性能定義・試験項目定義
負荷テストを行うためには、最初に「どれくらいの負荷をシステムにかけるのか」を具体的に決めておく必要があります。
これを 目標性能 と呼び、その後に「どんな条件で、どんなことをテストするか」を 試験項目 として定義します。
- 目標性能を決める
まずは、「どんな状況でシステムがどれだけの負荷に耐えられるか」を具体的に数値で決めます。
例えば、既存システムのリニューアルなら、過去のデータ（アクセスログなど）を参考にして、今後ユーザーがどれくらい増えるかを考慮しながら設定します。新しいシステムの場合は、ビジネスの予想に基づいてある程度決めていきます。
目標性能の例
- 閲覧のピーク時に、システムがエラーなく処理できるリクエスト数（例えば、XX リクエスト/秒）
購入が集中する時間帯に、システムがスムーズに処理できるリクエスト数（XX リクエスト/秒）
試験項目を決める
次に、その目標に沿って、「どんなシチュエーションでどんなことをテストするか」を決めます。これは、システムが実際の負荷に耐えられるかを確認するためのテストです。
試験項目の例
- ピーク性能試験①: たくさんの人が同時にページを閲覧している状態（XX リクエスト/秒）を想定したテスト
- ピーク性能試験②: たくさんの人が同時に商品を購入している状態（XX リクエスト/秒）を想定したテスト
- 限界性能試験: システムがどのくらいの負荷まで問題なく処理できるかを測定
- バッチ処理テスト: データの一括処理を行うときに、他の処理と並行してどれくらいの負荷に耐えられるかを確認
- 長時間負荷試験: 一定の負荷を長時間かけた場合、システムが正常に動き続けるかを確認
このように、目標を具体的な数値に落とし込んで、それに基づいてテスト項目を設定することで、効果的にシステムの負荷耐性を確認できます。
今回は、make it ! の「目標性能定義」「試験項目定義、」を以下の流れで進めていきます。
- ユーザー利用パターンの想定: まず、ユーザーがシステムをどのように使うのかをイメージします。これは、どんな場面でどのくらいのアクセスが集中するかを知るためです。
- 負荷テストのシナリオ: 次に、どのような負荷をかけるのかをシナリオとして具体的に作ります。これは、テスト時に現実に近い負荷を再現するためです。
- 想定サービス利用ユーザー数: その後、予想されるユーザー数を想定します。これが目標性能を設定するベースになります。
- 目標性能定義: 想定される負荷に基づいて、どれくらいのリクエストにシステムが耐えられるかの目標を定義します。
- 試験項目定義: 最後に、設定した目標に沿って、どんな条件でどのようにテストを行うかの具体的な項目を決めていきます。
この流れに基づき、make it ! の負荷テスト計画を作成していきます。
ユーザー利用パターン想定
まずは、「make it !」の主要機能である「AIによる質問対応」と「状況整理＆要約転送機能」にフォーカスし、ユーザー利用の想定パターンを想定していきます。
主要機能に絞っている理由としては、認証やその他の機能もシステムには重要ですが、負荷がかかりやすい主要機能に絞ることで、テストの効率と結果の有用性を高めるためです。
make it ! の主要機能は、以下のとおりです。
- AIによる質問対応（チャット機能）：ユーザーがチャットでAIに質問を送り、それに対してAIが回答します。
- AIによる状況整理＆要約転送機能：AIが解決できない場合、会話履歴を元に状況を整理し、要約して転送する機能です。
上記の主要機能を元にした代表的な「ユーザーシナリオ」はこちらです。
- ユーザーがチャットを開始し、AI が質問に対して回答します。
- AI が回答できない場合、AI は会話履歴を元に状況を整理し、それを要約して担当者に転送します。
上記を元にした検討するポイントは以下に絞りました。
質問の頻度
ユーザーがどのくらいの頻度でAIに質問を送るのか、例えば「1分間に何回質問を行うか」を考慮します。この頻度によってシステムにかかる負荷が変わるため、重要な指標です。AIによる処理負荷
ユーザーからの質問に対するAIのレスポンスタイム（どれくらいの速さで回答できるか）と、それに伴うシステムの負荷を評価します。レスポンスタイムが長い場合、ユーザー体験が悪くなるため、ここは重要な試験項目です。エスカレーション発生頻度
AIが質問に答えられないケースでは、会話履歴の整理や要約、そして転送の機能が発動します。この機能がどのくらいの頻度で使われ、その際のシステム負荷がどれくらいかを検討します。
負荷テストのシナリオ概要
今回は、make it ! のシステムがどのような負荷に耐えられるかを確認するために、以下の3つのシナリオを設定しました。
ピーク時のシナリオ
・説明: 特定のイベントやプロモーションが行われると、一時的にユーザー数が急増することが想定されます。これにより、システムに通常時とは異なる負荷がかかります。
・理由: イベントやキャンペーン時は、ユーザーの一時的な増加による負荷が最も大きくなる場面です。このようなピーク負荷にシステムが対応できるかどうかを確認することは、サービスの安定性を確保するために非常に重要です。質問ピーク時の負荷
・説明: 同時接続ユーザー数に基づいて、1秒間にどれくらいの質問リクエストがシステムに送られるかを定義します。例えば、1000人のユーザーが1秒に1回質問する場合、1000 RPS（リクエスト/秒）の負荷がかかります。
・理由: AIによる質問対応は、make it ! の主要機能であり、同時に多くのユーザーから質問が送られた際の負荷をテストすることが必須です。このテストによって、システムがエラーを起こさずにスムーズに回答を返せるか確認します。エスカレーションピーク時の負荷
・説明: AIが解決できない質問に対して、状況を整理して転送する「エスカレーション機能」にかかる負荷をテストします。例えば、エスカレーション率が5%の場合、50 RPSがエスカレーション処理に移行することになります。
・理由: 全ての質問にAIが対応できるわけではないため、エスカレーション機能もシステムにとって重要な負荷要因となります。この負荷を確認することで、AIが処理できない場合でもシステムが問題なく動作するかどうかを検証します。
（Tips）なぜこの3つのシナリオ概要を選んだのか？
- これら3つのシナリオで、システムが直面する主要な負荷ポイントを網羅できると考えたからです。
- まず、ピーク時の負荷は一時的なアクセス増加に対応できるかを確認し、質問ピーク時の負荷はメイン機能であるAIチャット対応の負荷耐性を測ります。
- そして、エスカレーション時の負荷では、AIが解決できない場合の負荷を測定することで、システム全体の強度をチェックします。
この3つをテストすることで、make it ! がさまざまな利用状況に耐えられるかどうかを総合的に評価できると考えました。
想定サービス利用数
先ほど設定した 3 つの負荷テストのシナリオが、どれくらいの数のアクセスがあるのかについて仮置きしていきます。
「仮置き」と記載した理由は、make it ! は実際にリリースされている(かつ、リリースする)サービスではないため、正確な想定サービス利用ユーザー数を図ることは難しいためです。
そのため、今回は実際に取ったアンケート内容をもとに「フェルミ推定」を用いて想定ユーザー数を算出していきます。
見込みユーザー数
まず、日本の20代から50代の人口を基にターゲットとなるユーザー層を見積もります。以下は、2023年10月1日時点の年齢階級ごとの人口データです。（※e-Stat - 日本の統計が閲覧できる政府統計ポータルサイトを参考にしています。）
- 20〜24歳: 約576万人
- 25〜29歳: 約630万人
- 30〜34歳: 約644万人
- 35〜39歳: 約663万人
- 40〜44歳: 約702万人
- 45〜49歳: 約713万人
- 50〜54歳: 約720万人
これらを合計すると、約4,648万人が20代から50代に該当します。
この層をターゲットに、アンケート結果に基づく推定では、サービス利用見込みの 87 %（以下のアンケート結果をもとに記載）がユーザーとなると仮定し、計算すると見込みユーザー数は 4,043万人 となります。
1人あたりの相談頻度の計算
次に、1人のペルソナが1日あたりに行う相談の頻度をアンケートから算出します。
- 1週間に1回以上相談する人: 7.5%
- → 1日あたり約0.107件
- 2週間に1回相談する人: 9.7%
- → 1日あたり約0.070件
- 1ヶ月に1回相談する人: 17.2%
- → 1日あたり約0.184件
- 2ヶ月に1回相談する人: 18.3%
- → 1日あたり約0.198件
- 2ヶ月に1回未満の人: 47.3%
- → 1日あたり約0.524件
これらを基に重みづけした結果、1人あたりの平均相談頻度は 1日あたり約0.0317件 となります。
総相談件数の算出
make it ! を 4,043万人（見込み想定ユーザー数） が利用すると仮定した場合、1日あたりの総相談件数は 約 128 万件 となります。
1秒あたりの相談件数の計算 * 利用ユーザーが、24時間フル稼働するわけではないと仮定し、12時間に集中して利用されるとした場合、1秒あたりの相談件数は次の通りです。
128 万件 ÷ 12 時間 ÷ 60 分 ÷ 60 秒 = 約 30 件/秒
つまり、make it ! では1秒あたりのリクエスト数が 約 30 件 になると推定できます。
状況整理＆要約転送機能の利用頻度
AIが全ての相談を解決できるわけではないため、エスカレーション（状況整理＆要約転送）が必要になるケースも考慮します。
エスカレーション発生率は全相談件数の40%と仮定すると、エスカレーションによるリクエスト数は次の通りです。
30 件/秒 × 40 % = 約 12 件/秒
これらの計算結果を元に 目標性能定義 を行っていきます。
目標性能定義
これまでの計算を元に、make it ! の負荷テストにおける目標性能を定義します。
A.質問処理ピーク時の負荷定義
- シナリオ: 同時接続した多くのユーザーが一斉に質問を送る状況を想定します。
- 目標性能: 同時接続数に基づき、1秒あたり30リクエスト（RPS: リクエスト/秒）の負荷を処理する。
- レスポンスタイム目標: 95パーセンタイルで、質問に対する初回応答は2秒以内に完了する。
B.エスカレーション時の負荷定義
- シナリオ: AIが解決できない質問が発生した場合に、状況整理＆要約転送機能が動作する場面を想定します。
- 目標性能: 全相談件数の40%がエスカレーションに移行すると仮定し、1秒あたり12リクエスト（RPS）を処理する。
- レスポンスタイム目標: 95パーセンタイルで、エスカレーション処理は5秒以内に完了する。
C.総合負荷定義
- シナリオ: ユーザーがチャットを利用し、その一部でエスカレーション処理が行われる状況を想定します。
- 目標性能: 1秒あたり30件の質問リクエスト（チャット機能）と、12件のエスカレーションリクエスト（エスカレーション機能）を同時に処理する総合負荷を処理する。
- レスポンスタイム目標:
- チャット機能: 95パーセンタイルで1秒以内に応答。
- エスカレーション機能: 95パーセンタイルで3秒以内に応答。
これらの目標を基に負荷テストを実施し、システムのパフォーマンスを評価します。
試験項目定義
上記の目標性能を基に、以下のように試験項目を定義します。
1.ピーク性能試験①: 質問処理のピーク負荷テスト
- シナリオ: 多くのユーザーが同時にAIに質問を送信し、システムが1秒あたり30件のリクエスト（RPS）を処理できるかを確認します。
- 目的: チャット機能がピーク時に問題なく動作し、レスポンスタイムが目標値（95パーセンタイルで2秒以内）に収まっているかを検証。
2.ピーク性能試験②: エスカレーション処理のピーク負荷テスト
- シナリオ: AIが対応できない質問に対して、エスカレーション機能が同時に1秒あたり12件のリクエスト（RPS）を処理できるかを確認します。
- 目的: 状況整理＆要約転送機能が、ピーク時に適切なレスポンスタイム（95パーセンタイルで5秒以内）で動作するかを検証。
3.限界性能試験: チャットとエスカレーションの限界負荷テスト
- シナリオ: チャット機能とエスカレーション機能の負荷を徐々に増加させ、システムがどの程度のリクエスト数まで処理できるかを確認します。
- 目的: システムの処理限界を測定し、パフォーマンスのボトルネックがどこにあるかを特定。
4.バッチ処理テスト: 質問処理と並行したバッチ処理のテスト
- シナリオ: チャットやエスカレーションの負荷がかかっている状態で、同時にデータの一括処理（バッチ処理）を実行し、システムの耐性を確認します。
- 目的: 高負荷時の並行処理がスムーズに行われるか、またその際のレスポンスタイムやシステム安定性を確認。
5.長時間負荷試験: 長時間の負荷耐性テスト
- シナリオ: チャット機能やエスカレーション機能に対して、12時間以上にわたって1秒あたり30件のリクエストをかけ続けた場合のシステム動作を確認します。
- 目的: システムが長時間の高負荷状態でも正常に動作し続けるか、安定性とパフォーマンスの維持を確認。
負荷シナリオ・比率
負荷モデルとシナリオ検討について
負荷テストを実施する際には、システムに発生しうる全てのリクエストをテスト対象とするのは現実的ではありません。
そのため、頻繁に発生するリクエストを中心に累積で80%や90%に達するリクエストを選定し、それらを負荷テストの対象とします。
この方法によって、限られたリソースの中で現実に近いシナリオを効率的に再現することが可能になります。
また、頻度は低いもののビジネスにおいて重要なリクエストも対象に含める場合があります。
これらを元にテストで再現するリクエストの比率を設定し、これを 負荷モデル と呼びます。アクセスログやユーザーの行動パターンを分析し、このモデルを決定していきます。
負荷モデルの作成手順
- リクエストの選定：システムに発生するリクエストを多い順に並べ、累積で80％または90％に達するリクエストを選びます。
- ビジネス上重要なリクエストの選定：ビジネス的に重要なものの頻度が少ないリクエストも、追加で再現対象とします。
- 負荷モデルの設定：負荷モデルに基づき、各リクエストの比率を定めます。これにより、システム全体にかかる負荷を正確に再現します。
シナリオの設計
次に、システムの使われ方を元にシナリオを設計します。
例えば、ECサイトであれば「トップページにアクセスし、商品を検索し、カートに投入して購入する」という流れをシナリオとして設計します。
同時に、負荷モデルに合致するように、各シナリオに対するユーザーの割合も決定します。
シナリオ設計のポイントは、システムの実際の使われ方への理解です。
例えば、更新系の処理（例：ECサイトでの購入）を精度高く模擬するためには、その前の行動（例：ログインやカート投入）が必要です。
さらに、「1注文あたりの商品件数」なども考慮し、複数回のカート投入フローを含めるなど、現実に即したシナリオを設計します。
make it ! の負荷シナリオ
1.AIのチャット機能で相談解決（60%）
- シナリオ: ユーザーがトップページからチャットページに移動し、AIと数回のやりとりを行い、問題が解決する流れ。
フロー:トップページ訪問 → チャットページ訪問 → AIとのチャットを複数回実施（n回） → 必要に応じて、初回時にセッションタイトルを生成（初回のみ）
転送機能利用（40%）
シナリオ: ユーザーがAIで解決できなかった場合、状況を整理し、担当者（ペルソナ）へ転送する流れ。
- フロー:トップページ訪問 → チャットページ訪問 → AI とのチャットを複数回実施（n回） → 必要に応じて、初回時にセッションタイトルを生成 → 解決できない場合、転送ボタンを押してペルソナへ状況を転送
このように、AIチャット機能を用いたシナリオでは60%がチャット機能での解決、残り40%が転送機能に依存する形でシナリオを設計しています。
make it ! の負荷モデル
これらのシナリオに基づいて、make it ! の負荷モデルを以下のように定義します。
| リクエスト名 | path | method | 累計 |
|---|---|---|---|
| AI 回答生成 | /api/generateAiReply(Lambda function URL) | POST | 100% |
| セッションタイトル生成 | /api/generate-session-title | POST | 100% |
| サマライズ実行 | /api/summarize | POST | 40% |
| サマリー送信 | /api/send-summary | POST | 40% |
これで、「負荷シナリオ」「負荷モデル」を定義することができました。
ここからは実際に負荷テストを行うツールを選択していきます。
負荷ツール選定
負荷テストは Distributed Load Testing on AWS を使用して実施します。以下の理由から、このツールを選定しました。
AWS環境内で完結できる
make it ! の検証環境が既にAWS上に構築されているため、AWSサービスを利用することでテストをシームレスに実施できます。これにより、開発者の負担を最小限に抑えることができると考えました。既存で利用しているサービスを活用したい
既に利用しているAWSのサービスを使うことで、新たなツールの導入にかかる登録や設定時間、コンソールの操作に慣れるための時間を節約できると考えましたGUIベースの操作が可能
Distributed Load Testing on AWS はGUIベースの操作が可能なため、負荷テストを実施したことが 1 人もいないチームでも直感的に操作できる点がメリットとしてあります。これにより、負荷テストの実施経験がないうちのチームでも効果的にテストを実施できると考えました。
これらの理由から、make it ! の負荷テストには Distributed Load Testing on AWS を採用します。
まとめ
負荷テスト初学者向けに「 Distributed Load Testing on AWS 」を利用して、実際に負荷テストを実施するまでの試験計画までの流れを記載してみました。
本当は、「Distributed Load Testing on AWS を使った結果」についても本記事にまとめるつもりでしたが、文字数がかなり多くなりそうだったので次回に分割して記載をします！
本記事が誰かの助けになれば幸いです。
それでは、また 次回の記事 でお会いしましょう !
日高 僚太(執筆記事の一覧)
2024 Japan AWS Jr. Champions / 2024 Japan AWS All Certifications Engineers
EC部クラウドコンサルティング課所属。2022年IT未経験でSWXへ新卒入社。
記事に関するお問い合わせや修正依頼⇒ hidaka@serverworks.co.jp
