負荷テスト on AWS のすすめ

負荷テストとは、その名の通り、構築したアプリケーションに高負荷をかけることでアプリケーションの性能を確認するテストです。では、ここで言う「性能」とは具体的に何でしょうか ?

例えば、 EC サイトのセールについて考えます。普段はユーザが快適に商品ページを閲覧し、気になる商品があれば簡単にカートに入れて購入できていたとします。ところが、セールで多くのユーザが同時にアクセスすると、アプリケーションが遅延し、ユーザは商品が閲覧・購入できるまで長時間待たされ、最悪の場合はエラーが返ってくる・・・といったケースです。このケースを考えると、性能には「処理量」という観点と「処理時間」という観点の 2 つがあることがわかります。オンラインの Web アプリケーションの場合、処理量としてスループットを、処理時間としてレスポンスタイムを指標として用います。

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

• スループット不足 → セールでの新規流入ユーザーがアクセスできず、売上の機会損失を招く
• レスポンスタイム遅延 → 画面レスポンスが遅いためにユーザーが購入を諦める・離反するリスクを生む

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

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

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

パフォーマンス効率の柱のベストプラクティスとして、「PERF01-BP07 ワークロードの負荷テスト」という項目があります。この中に、ベストプラクティス・アンチパターンとして以下のような内容が記載されています。(記載内容を筆者見解で抜粋・補完)

ベストプラクティス

• 実際のワークロードを使用して負荷テストを行い、自身のワークロードが本番環境でどう動作するのかを確認すること
• 本番環境同等のサイズの環境を利用して試験を行うこと。また、本番環境同等の量・バリエーションのデータを、本番環境データを匿名化したり模擬的に作成したりして用意すること
• ユーザーの実際の行動をリプレイ、もしくはプログラム的に再現することで、大規模にアーキテクチャ全体に対して負荷をかけること
• デリバリーパイプラインの一環として負荷テストを自動的に実行し、事前に定義した性能目標と比較して評価し、要求性能を満たせるかどうかを継続的に保証すること (筆者注 : こちらはより発展的な内容ですので、まずはこれ以外のベストプラクティスから実現していくことをおすすめします)

アンチパターン

• ワークロード全体ではなく、ワークロードの個々の部分について負荷テストを行うこと
• 本番環境とは異なるインフラストラクチャで負荷テストを行うこと
• 予想される負荷量までの負荷テストを実施し、それを超える負荷に対する負荷テストを実施しないこと
• AWS サポートに通知することなく負荷テストを実行すること

一言でまとめると、「本番環境同等の環境に、本番で実際に発生するユーザーのシナリオ通りの負荷を限界量までかけてパフォーマンスを評価しましょう」ということです。これを実現するためには実に多くのタスクを実施する必要があります。そこで、次章では負荷テスト全体の進め方について俯瞰していきます。

負荷テストは、実際に動くシステムに対して、ユーザーが実際に操作するシナリオでの負荷をかけてシステムの挙動を確認するものです。そのため、実装が完了したあとの総合テストの一環として実施するのが一般的です (※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 インスタンスから生成するようなケースでは、フォームで申請する必要があります。
  

最後に、今回のシリーズを通して皆さんに知ってもらいたい 分散負荷テスト ソリューションについて少しご紹介しておきます。このソリューションの使い方については、本シリーズの第 3 回でも改めて触れる予定です。

このソリューションは、性能試験における負荷クライアント部分を担うものとなっており、 OSS の負荷テストフレームワークである Taurus をベースとしています。このソリューションは大きく 2 つの要素から構成されます。

• フロントエンド : 負荷テストの実行開始・結果確認・履歴参照を行うためのコンポーネントです。Amazon S3 でホストされたコンソール画面を利用して、負荷テストのシナリオのアップロードや並列度設定を行い、負荷テストのショットを開始することができます。また、実行中のショットや過去に実施したショットの結果をダッシュボード的に表示したり、結果の詳細なファイルをダウンロードすることができます。また、API も提供しており、負荷テストを自動化パイプラインの中に組み込んで実行することも可能です。
• バックエンド：負荷テストにおいて、実際に負荷を発生させるコンポーネントです。フロントエンド側で指定した設定に合わせて AWS Fargate のタスクを起動し、指定されたシナリオと設定値にしたがって HTTP / HTTPS 等のリクエストを並列で実行します。指定された試験時間を過ぎたらタスクを停止して Amazon S3 や Amazon DynamoDB に結果を格納し、フロントエンドから実行結果を確認できるようにしてくれます。実際の負荷生成にかかるコンピューティングリソースの料金は試験時間中のみ発生するため、コスト効率よく負荷をかけることができます。

このソリューションについては、 過去の builders.flash 記事 でシンプルなチュートリアルをご紹介しているほか、実装ガイド として利用時の様々な Tips が紹介されています。加えて、同ソリューションの利用ステップを詳細にガイドするワークショップを現在作成しています。完成次第 JP Contents Hub での公開を予定しておりますので、公開されたら是非お試しください。

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

• システム性能は、処理量と処理時間 (オンライン Web アプリの場合はスループットとレスポンスタイム) で評価する
• 負荷テストは、性能不足によるビジネスリスクを低減するために、性能目標を定義したうえで実施する
• AWS Well-Architected Framework のパフォーマンス効率の柱では、負荷テストのベストプラクティスとして「本番環境同等の環境に、本番で実際に発生するユーザのシナリオ通りの負荷を限界量までかけてパフォーマンスを評価することが望ましい」と述べられている
• 負荷テストは、総合テストの一貫として実施する性能試験の一部である
• 性能試験は計画・準備・実施 (複数回)・評価の 4 フェーズに分かれる
• AWS は、性能試験対象システムとしても性能試験の負荷クライアントとしてもオンプレに比べたメリットがあるが、特有の考慮事項もある
• 分散負荷テストソリューションは、簡単に負荷クライアントを立ち上げられるだけでなく、準備・実施・結果確認・評価の省力化も図れるソリューションとなっている
  
  

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

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