負荷テスト on AWS のすすめ ~ 第 1 回 : 負荷テストの全体像を理解しよう

みなさん、こんにちは。ソリューションアーキテクトの馬渕です。AWS 入社前は SIer で性能試験・性能問題解決に特化した部署におり、さまざまな業種のお客様のシステムに対する支援を実施していました。

さて、みなさんは AWS ソリューションライブラリ をご存知でしょうか。AWS ソリューションライブラリは、世界中のユーザーが直面する一般的な問題の解決策を提供するものとなっています。AWS CloudFormation のテンプレートと導入手順が用意されているため、すぐにデプロイしてお客様の課題に対応できます。また、アーキテクチャ図やその説明、コスト試算なども用意されています。

私がご紹介したいのが、その中でも人気のソリューションの一つである 分散負荷テスト ソリューションです。このソリューションは、負荷テストに必要な負荷クライアントを必要なタイミングで必要量だけ立ち上げて負荷掛けを実行し、試験が終了したら自動で停止できるソリューションとなっています。負荷テストを行う際には、

• 負荷クライアント側が負荷テストのボトルネックにならないように、クライアント側にも十分なコンピューティングリソースが必要となる

• 一方で、高性能な負荷クライアントを Amazon EC2 インスタンスとして常時立ち上げるとコストがかかる

というジレンマがあるのですが、本ソリューションを利用するとそういったお悩みを解消できます。

今回の記事は、このソリューションを皆様に有効に使っていただくことを目的として執筆しています。しかし、負荷テストを有効に実施するためには、ツールそのもの以上に負荷テスト全体のプロセスに関する理解が重要となります。そのため、これから全 3 回の連載記事を通じて、負荷テストの全体像や勘所をお伝えしつつ、分散負荷テストソリューションがどう役立つか、どう使っていくのがよいかをお伝えしていきたいと思います。

Part 1：負荷テストの全体像を理解しよう
Part 2：AWS での負荷テストを計画しよう
Part 3：AWS での負荷テストを準備・実施しよう

今回の記事では、まず負荷テストの意義や目的、全体的な進め方をご説明したのち、負荷テストにおける AWS の活用ポイントと、AWS ソリューションである分散負荷テストソリューションの簡易なご紹介をしていきます。

※ ソリューションの概要や役立つポイントをサクっと知りたい場合、 負荷テスト・性能試験の全体像 から読み始めることをおすすめします。

X ポスト » | Facebook シェア » | はてブ »

builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。 

「アプリケーションの性能が足りない (= 性能問題)」という事象は、スループット・レスポンスタイムがビジネス上の要求に応えられないことと言い換えることができます。EC サイトの例では、

• スループット不足 → セールでの新規流入ユーザーがアクセスできず、売上の機会損失を招く

• レスポンスタイム遅延 → 画面レスポンスが遅いためにユーザーが購入を諦める・離反するリスクを生む

といった形で、性能問題がビジネス損失に直結してしまっています。これを防ぐために、アプリケーションが要求性能を満たせることを確認するのが負荷テストの目的です。オンラインの Web アプリケーションの場合、以下のようなことを確認します。

• アプリケーションが、予想される最大量のアクセス量 (スループット) をエラーなく処理することができるか、その際にもレスポンスは目標のレスポンスタイムに収まっているかどうか (ピーク性能の確認)

• アプリケーションが、目標のレスポンスタイムを遵守しながらどれだけのアクセス量を捌くことができるか、性能の限界に到達するときのボトルネックはどこにあるか (限界性能の確認)

上に述べた確認項目を考えたとき、まずはアプリケーションの性能目標を定量的に決定するところから負荷テストという活動が始まるということがおわかりいただけたでしょうか。

負荷テストは、実際に動くシステムに対して、ユーザーが実際に操作するシナリオでの負荷をかけてシステムの挙動を確認するものです。そのため、実装が完了したあとの総合テストの一環として実施するのが一般的です (※2)。

ウォーターフォール型の開発であれば、システムの稼働前の総合テストのフェーズで実施します。アジャイル開発の場合、どういったサイクルで総合テストを実施するかはそのチームのテストの考え方に依存しますが、 W-A に記載されているように CI/CD のパイプラインの一環として自動化すれば継続的に性能担保していくことが可能です。なお、今回紹介する分散負荷テストソリューションは API を通じて負荷テストの実行・結果取得が可能なため、自動化パイプラインに組み込むことも可能です。

(※2) : それ以外にも、アーキテクチャや処理方式、インスタンスタイプ等を検討する際に、性能の基礎値取得のために負荷テストを実施するケースもあります。今回の記事では、完成したアプリケーションで要求性能を満たせるかどうか確認する目的の負荷テストにフォーカスして記載します。

さて、アプリケーション開発が進んできて負荷テストを検討することになったら、実際に何をすればいいのでしょうか？負荷テストは性能試験の一種 (※3) ですが、性能試験それ自体が一つのプロジェクトのようなもので、全体像を理解して計画を立てて進めていく必要があります。

(※3) : 次回で詳しく説明しますが、性能試験は単体性能試験と複合性能試験から構成されており、負荷テストは後者の一部として位置付けられます。

性能試験のプロセスは、大きくまとめると 4 つのフェーズに分けることができます。以下、それぞれのフェーズでのタスクを大まかに記載していきます。

試験計画

性能試験の全体像を決定するフェーズです。この計画の質が性能試験の質を決めると言っても過言ではありません。
大きくは以下のような内容を定めていきます。

• 性能試験の実施目的 : 当該システムで性能を担保すべきシチュエーションを明確化

• 性能目標・試験項目 : 想定シチュエーションで発生する負荷の内容 (スループットとその内訳) や、システムが満たすべきレスポンスタイムを明確化・定量化

• 負荷シナリオ・比率 : システムへの負荷が、具体的にどのようなリクエストで構成されるかをモデル化

• 前提条件 (データ等) : 想定シチュエーションにおけるシステム状態の前提条件を検討 (DB データ量やキャッシュの状態など)

• スケジュール・体制 : 実施スケジュールと体制を確定

• 試験実施環境 : 負荷テスト対象となる環境 (含・外部システムのスタブ要否) を決定

• 負荷クライアント : 負荷を発生させるクライアントを選定 (例：分散負荷テスト ソリューション)

• 監視ツール : 負荷テスト時の結果分析・ボトルネック分析・リソース状況確認に用いるツールを選定し、 オブザーバビリティ (※4) の実現を検討 (すでに本番の監視方式が定まっているのであればそのツールを利用しますが、それで不足がないかもここで確認します。)

これらの検討の具体的な内容については、次回連載記事にてさらに詳細に説明していきます。

※4 : オブザーバビリティ : システムの動作状況 (どこで、何が、なぜ起こっているか) を把握できている状態のこと。メトリクス・ログ・トレースを収集して分析可能にしておくことで実現されるものであり、システムのトラブルシューティングや顧客体験の確認・向上に役立ちます。

試験実施

準備が出来たらいよいよ負荷テスト本番です。負荷テストで最初からエラーなく目標性能を達成できるケースはまずないため、複数回のショットを繰り返します。以下のことを繰り返しながら性能目標の達成や限界性能の計測を目指していきます。

• ショット準備

  • ショット目的定義 : 同ショットで確認したいことを定義 (例 : ピーク比 50 % 性能が出せることの確認、前ショット後のチューニング効果の確認)

  • 目的に応じた実施条件修正 : 負荷クライアントのシナリオや負荷量を修正

    • 分散負荷テスト ソリューションでは、JMeter スクリプトの変更なしにタスク数やスレッド数で負荷量の調整が可能です。

  • DB 状態整備 : 更新系処理を含む負荷テストの場合、毎ショットの実施条件をそろえるためにデータの状態を戻す

• ショット実行 : 負荷クライアントからの負荷掛け実行

• ショット分析 :

  • 性能指標分析 : スループット・レスポンスタイムが目標を満たしているかどうかを確認

    • 分散負荷テスト ソリューションは、スループットやレスポンスタイムを自動で可視化するダッシュボード機能も備えています。

  • ボトルネック分析 : システムのボトルネックがどこにあるかを分析

• チューニング : 目標未達の場合、 パラメータ変更やスケールアップ / アウト、アプリケーション改修などを実施

結果評価

実施すべき試験項目をすべて完了したら、試験は終了です。あとは、性能試験の結果をまとめたうえで、本番稼動に向けて Next Action を整理します。

• 試験結果取りまとめ : 最終的に出た性能やその際のリソース状況、最終的なボトルネック等の取りまとめ

• チューニング内容取りまとめ : 試験中に実施したチューニングの目的・効果や、そのトレードオフについて取りまとめ

• Next Action 検討 : 試験結果を踏まえ、本番稼働時の性能関連のアクション方針を検討 (例 : 重点監視ポイント決定、スケーリング方針の決定、流量制御の閾値決定)

• 関係各所への報告・合意

このような流れで、晴れて性能試験が完了となります。

さて、性能試験はオンプレ・クラウドのシステムを問わず実施されるものですが、 AWS で性能試験を行う場合のメリットや、逆に注意すべき点について少し考えてみたいと思います。

AWS に性能試験対象システムがある場合のメリット

• 負荷試験用環境を、本番環境同等に立ち上げることが工数・費用の両面で容易であること。CloudFormation や AWS CDK を用いた IaC で環境を構築する場合、性能試験向け環境を構築することも容易です。また、試験終了後に環境を消してしまえばそれ以降費用が発生しないため、オンプレミスに比べて性能試験専用の環境を立ち上げるハードルが圧倒的に低くなります。

• オブザーバビリティを実現するツールセットとして、 AWS サービスや 3rd party サービスが充実していること。負荷テストを円滑に進めるうえで最も重要なことの一つがオブザーバビリティです。1 ショット 1 ショットで着実に性能ボトルネックを解消したり、実施結果を適切な Next Action に結びつけるためには、ログ・メトリクス・トレースの収集・可視化が最適に行われている必要があります。 多くの AWS サービスでは様々なログ・メトリクスを Amazon CloudWatch に標準で出力するようになっており、ログやメトリクスの収集・可視化が容易です。また、性能ボトルネックの確認のためにはトレースが重要な役割を果たしますが、 AWS X-Ray はトレースの取得・可視化の機能を備えています。さらに、性能ボトルネックになりやすい DB については、 Amazon RDS の Enhanced Monitoring や Performance Insights もボトルネック解析に役立ちます。また、 オブザーバビリティを実現する SaaS の多くが AWS との連携機能により活用可能となっています。

AWS を負荷クライアント環境として利用するメリット

試験対象のシステムがオンプレミス上にある場合でも、対象システムへのアクセスさえ可能であれば AWS を負荷クライアント環境として利用することも可能です。負荷クライアント環境として AWS を用いる場合、以下のメリットを享受することが可能です。

• 負荷クライアント側で必要となる大量のコンピューティングリソースを、従量課金でコスト効率よく活用できること。負荷テストを行う際、実は対象システムそのものがボトルネックになるだけでなく、負荷クライアント側がボトルネックになり目標性能 (スループット) まで処理できないケースが存在します。Amazon EC2 で負荷クライアント用の仮想マシンを立ち上げる場合もこのメリットはありますが、今回ご紹介する 分散負荷テスト ソリューションはさらにコスト効率よく負荷クライアントをスケールさせることができます。

AWS 上で性能試験を実施する場合の注意点

• Amazon EC2 Testing Policy で、ネットワーク負荷テストに該当しないかを確認する。 ほとんどのお客様のワークロードの負荷テストでは該当しませんが、1 Gbps (10 億ビット/秒) または 1 Gpps (10 億パケット/秒) を超えるトラフィックを EC インスタンスから生成するようなケースでは、フォームで申請する必要があります。

さて、今回の記事をまとめると、以下のようになります。

• システム性能は、処理量と処理時間 (オンライン Web アプリの場合はスループットとレスポンスタイム) で評価する

• 負荷テストは、性能不足によるビジネスリスクを低減するために、性能目標を定義したうえで実施する

• AWS Well-Architected Framework のパフォーマンス効率の柱では、負荷テストのベストプラクティスとして「本番環境同等の環境に、本番で実際に発生するユーザのシナリオ通りの負荷を限界量までかけてパフォーマンスを評価することが望ましい」と述べられている

• 負荷テストは、総合テストの一貫として実施する性能試験の一部である

• 性能試験は計画・準備・実施 (複数回)・評価の 4 フェーズに分かれる

• AWS は、性能試験対象システムとしても性能試験の負荷クライアントとしてもオンプレに比べたメリットがあるが、特有の考慮事項もある

• 分散負荷テストソリューションは、簡単に負荷クライアントを立ち上げられるだけでなく、準備・実施・結果確認・評価の省力化も図れるソリューションとなっている
  

次回の記事では、性能試験計画での検討事項を具体的に説明することで、性能試験で気をつけるべき点を深掘りしていきたいと思います。

それでは、また 次回の記事 でお会いしましょう !