AWSで負荷試験を実施してみて｜負荷試験準備〜実施〜改善〜ハマったことなどなど

はじめに

最近、
AWSのECS上で動くAPIが元々多重度30で負荷をかけてなんとか耐えられる(5TPS)くらいの状態から、

SQLチューニング、
DBコネクション数、
ECSのコンテナのCPU・メモリ・クールダウンタイムなどなど

調整して700多重で負荷をかけて耐えられる(50TPS)状態まで
改善したので、
負荷試験の準備〜性能検証〜性能改善の自分自身のやり方や考え方についてまとめました。

負荷試験の準備〜実施〜性能改善

僕がいつもやる負荷試験の準備〜実施〜性能改善の流れはこんな感じです。

本番環境相当のスペックで環境構築

負荷試験専用環境を用意してもいい場合は、
普段利用している結合環境などとは別に環境を用意します。
その場合はシンプルなのですが・・・

負荷試験は軽視される現場も少なからずあり、
工数もらえないとかお金かかるから負荷試験専用環境を用意されない現場もあったりします。

そういう現場では、、、

(自分の場合は)普段使ってる結合環境を、
負荷試験するタイミングで開発者に触らせず(無風状態にする)に、
スペックを本番相当に揃える感じで使い回して準備します。

しかし、
データベースだけは大量データ環境が絶対必要なので

それだけは結合環境のDBコピーするなりして別で用意してもらって、
そっちに負荷試験のための大量データを登録して、

負荷試験の場合のみ
APIから繋ぐDBの向き先を大量データが登録されたDBに切り替えて
利用したりします。

負荷試験環境のデータベースやシナリオ作成のためのヒアリング

負荷試験シナリオを作成したり負荷試験環境のデータベースを作成するために
自分はまずはこの辺りをヒアリングするようにしています。

ヒアリング事項は上記の通りですが、
なぜヒアリングをしているかざっくり説明すると・・・

負荷試験は自分は指定がない限り1日当たりの取引数を元に、
1年間運用後を想定して取引系データを登録してから実施します。
(取引に種別があるのであればそのバラつきもある程度リアルに)

データ量が少ないと問題がなかったけど、
データ量が増えてくるとだんだんレスポンスタイムが劣化する。
(例えばインデックスが最適に貼れていないからとか)

そんなケースは結構あります。
結合や検証環境だと問題なかったけど、本番リリース後すぐ問題になったりとか、

なので大体1年間くらいシステムを運用したことを想定してデータを積むためのネタ集めをします。


また、
負荷試験シナリオを作って業務を想定した負荷をかけるために
どれくらいの負荷(ピーク時には同時リクエストがどれだけ来るか)で、
どういうシナリオで流すのかを決めるためのネタ集めも必要です。


あと、ふわっとさせたままリリース間際で揉めるのが。。。
負荷試験を実施してるときにレスポンスタイムは
全リクエストのうち90%が何秒以内で遅くとも何秒。
などのネタです。
関係者と早い段階で握っておくということも重要ですが、
目標を定めなければ性能改善系のタスクは終わりがなくなってしまういので、
明確な目標として開発者が掲げるという意味でも重要だと僕は考えています。

大量データ登録

ヒアリング事項を元に大量データを登録します。
それだけで終われるならいいのですが・・・


負荷試験実施していると課題が出て追加でこういうデータも登録してとか、
連携している対向先システムから負荷試験したいからこういうデータ積んでとか、
追加でデータを積んだり何度も積んだり消したりなどやることになることが多いです。


なので、簡単にでもいいので
insert文が自動で作れる何か簡単なツールを用意しておくのがオススメです。

GASを使ってスプレッドシートでデータの元ネタを作っておいて
insert文を生成するようなツールとか、
簡単なバッチ登録処理をプログラムで作ったりを現場でやってたりはしました。


ただ、
どうしても整合性を合わせようとするとinsert文が複雑になったりするので、
負荷試験ツールで大量データ登録用のシナリオを使ってしまうのが良かったりもします。

単発でレスポンスタイム計測・改善

僕は大体いつも、
負荷試験を始める前に大量データ環境で、
APIを単発で叩いてレスポンスタイムを計測をします。


DBAがいてスロークエリは開発段階でチェックして対処できている現場は
あまりないと思います。(僕が今まで見てきた現場ではそうだった)

なので、
製造〜単体〜結合試験を終えて負荷試験を始めるこの段階になっても、
インデックスが最適に貼れていないなかったり、
クエリ自体が性能ダメダメだったりすることも多いと思います。


この状態では負荷試験以前の問題なので、
大量データが登録できたら、
シナリオに関係する機能単発で
レスポンスタイムや処理時間の問題がないことの確認をするのがオススメです。


クエリチューニングについては別記事にまとめてるので
よければ参考にしてみてください！！

2022年1月15日 SSMSでSQL Serverの実行計画を見てSQLチューニング

負荷試験シナリオ作成

負荷試験ツールはJMeter、Gatling、Locust、k6など色々ありますが、
今の所k6が個人的にはお手軽で書きやすくて好みです。


どんなツールを使ってもいいとは思いますが、
学習コストが低くて、動作が軽くて(多重度上げても問題ない)、最低限やりたい分析ができて
くらいできれば十分かと。


シナリオを作ったら、
システムのネットワーク的に距離が近い場所にEC2などを立ててそこからシナリオを流します。

直近実施したものだと700多重で負荷をかけ続ける必要があったので、
3台に分けて負荷をかけたりしました。
負荷試験ツールによっては、重くてそこまで多重度を上げられないとかあるのかも。。。
(昔の現場で、開発者10人くらい集めて10台のPCから負荷かけたりしてた)


k6での負荷試験シナリオの作成例はそのうちまとめてみようと思います。

負荷試験実施・改善

負荷試験実施は、
自分は作成したシナリオを1多重で1イテレーション回して、
問題なければ負荷試験でかけたい多重度で1イテレーション回して、
問題なければ本当の負荷をかける。

という流れで自分は行っていますが、


書籍などを参考にしていると、
まずはヘルスチェック的なエンドポイント(DBアクセスなし)
に対して負荷をかけてみて問題ないことを確認して、
検索系のAPIに負荷をかけて問題ないことを確認して、
登録系のAPIに負荷をかけて問題ないことを確認して・・・

など本来であれば細かいステップを踏んだりするそうです。


確かに、
一気にいきなりシナリオを流してしまうと
何か課題があった際に原因の切り分けが難しくなります。

アプリケーションが遅いのか、
アプリケーションサーバーのスペックが足りていないのか
アプリケーション-データベース間のコネクションが足りていないのか、
データベースのスペックが足りていないのか
アプリケーション-外部サービス間のコネクションが足りていないのか、
外部サービスが遅いのか
とかとか


課題が発生した時の切り分け方は性能課題でも他でも同じだと思いますが、
原因の切り分けがしやすいように、
小さいステップで確認していくことは大事だと思います。


以上が自分が性能試験を実施する際の考え方や準備〜実施〜改善の流れでした。
性能改善を初めて担当する方などの参考になれば幸いです。