負荷テストの目的とツール

仕事で新機能における負荷テストを実施していました。
負荷テストとは、システムに対して高負荷をかけることでアプリケーションの性能を確認するテストのことです。なぜ負荷をかけるのかというと主な目的は４つあります。

１つ目は想定したユーザー数やアクセス数に対して耐えきれるかどうか。最近、Nintendo Switch2の抽選販売を巡ってマイニンテンドーストアが頻繁に落ちるということがありました。もちろん、任天堂ですから事前に耐えられるだけの準備をしていたと思いますが、Nintendo Switch2の需要が想定以上に多かったということでしょう。

２つ目はスケーラビリティ特定を把握すること。AWSのようなクラウド上で構成されたアプリケーション、たとえばサーバ（EC2）、データベース（RDS）、キャッシュ（ElastiCache）のような簡単な構成であった場合、何をスケール（スケールアウト or スケールアップ）させれば性能が向上するのかを把握することは大事です。トラフィック過多になってしまい処理が遅くなった場合に、サーバ台数を増やせば性能が線形的に伸びていくことがわかっていればどんどん増やすことで対処できますね。

３つ目はシステムの性能限界を把握すること。さきほどのようにスケールすることでいくらでも処理を捌ききれるかというとそうでもなく、実際にはアプリケーションの構成や実装によっては処理できる限界がどこかできます。AWSの各コンポーネント（EC2、RDSなど）をスケールさせ続けても処理がこれ以上増えないという限界点を探ります。

４つ目はボトルネックを特定すること。システムパフォーマンスの向上を行う際に、低いシステム負荷だとどこで処理が詰まりやすいのかは分かりづらいです。高負荷をかけることで、どこが遅くなっているのか "正しく" 把握できていれば、それを改善することで性能を向上させることができます。

ただし、"正しく" と表記したのは、ボトルネックの特定が意外と難しいからです。「全体がなんとなく遅くなっているけどどこが原因かははっきりわからない」ということはよくあります。そういうときは小さく、泥臭く、そして可視化しやすくなどをして特定していくことになると思います。
「なんとなく（根拠が薄いけど）ここが遅そうだから改善しよう」「ここが改善しやすいから改善しよう」と本来のボトルネックでない部分を改善してしまうと逆に性能（=スループット）が落ちてしまう危険性があります（続きは明日以降にでも）。

ツール

今回の負荷テストでは、AWS公式が提供している分散負荷ソリューションを使いました。

aws.amazon.com

採用理由は３つです。

1．システムがAWS上に構築されており、AWSで負荷テスト環境を構築した方が効率が良いから。
2．CloudFormationによる構築なので簡単にできる。
2．攻撃側がAmazon ECSタスクによって分散されるため、負荷テストでありがちな攻撃側の性能がボトルネックになる問題が発生しづらい。

参考書籍

負荷テストを実施する度、『Amazon Web Services負荷試験入門』には毎回助けられています。
出版日は少々古いですが、負荷テスト自体の考え方ややり方は現在においても変わることがありません。本書で書かれているAWSの構成はクラシックですが、それゆえに今の構成に置き換えて考えやすいのも良いですね。
本ブログ記事で書いている内容も本書を参考にさせていただきました。