負荷試験の準備〜性能検証〜性能改善のやり方について(自分がいつもやってるやり方を)まとめました。負荷試験の準備〜性能検証〜性能改善の自分自身のやり方や考え方についてまとめました。僕がいつもやる負荷試験の準備〜実施〜性能改善の流れはこんな感じです。普段利用している結合環境などとは別に環境を用意します。工数もらえないとかお金かかるから負荷試験専用環境を用意されない現場もあったりします。負荷試験するタイミングで開発者に触らせず(無風状態にする)に、スペックを本番相当に揃える感じで使い回して準備します。負荷試験の場合のみAPIから繋ぐDBの向き先を大量データが登録されたDBに切り替えて利用したりします。負荷試験環境のデータベースやシナリオ作成のためのヒアリング負荷試験シナリオを作成したり負荷試験環境のデータベースを作成するために自分はまずはこの辺りをヒアリングするようにしています。負荷試験は自分は指定がない限り1日当たりの取引数を元に、1年間運用後を想定して取引系データを登録してから実施します。(取引に種別があるのであればそのバラつきもある程度リアルに)データ量が少ないと問題がなかったけど、データ量が増えてくるとだんだんレスポンスタイムが劣化する。(例えばインデックスが最適に貼れていないからとか)そんなケースは結構あります。結合や検証環境だと問題なかったけど、本番リリース後すぐ問題になったりとか、なので大体1年間くらいシステムを運用したことを想定してデータを積むためのネタ集めをします。負荷試験シナリオを作って業務を想定した負荷をかけるためにどれくらいの負荷(ピーク時には同時リクエストがどれだけ来るか)で、どういうシナリオで流すのかを決めるためのネタ集めも必要です。あと、ふわっとさせたままリリース間際で揉めるのが。負荷試験を実施してるときにレスポンスタイムは全リクエストのうち90%が何秒以内で遅くとも何秒。明確な目標として開発者が掲げるという意味でも重要だと僕は考えています。大量データ登録ヒアリング事項を元に大量データを登録します。追加でデータを積んだり何度も積んだり消したりなどやることになることが多いです。簡単にでもいいのでinsert文が自動で作れる何か簡単なツールを用意しておくのがオススメです。簡単なバッチ登録処理をプログラムで作ったりを現場でやってたりはしました。負荷試験ツールで大量データ登録用のシナリオを使ってしまうのが良かったりもします。負荷試験を始める前に大量データ環境で、APIを単発で叩いてレスポンスタイムを計測をします。DBAがいてスロークエリは開発段階でチェックして対処できている現場はあまりないと思います。製造〜単体〜結合試験を終えて負荷試験を始めるこの段階になっても、インデックスが最適に貼れていないなかったり、クエリ自体が性能ダメダメだったりすることも多いと思います。大量データが登録できたら、シナリオに関係する機能単発でレスポンスタイムや処理時間の問題がないことの確認をするのがオススメです。今の所k6が個人的にはお手軽で書きやすくて好みです。学習コストが低くて、動作が軽くて(多重度上げても問題ない)、最低限やりたい分析ができてくらいできれば十分かと。シナリオを作ったら、システムのネットワーク的に距離が近い場所にEC2などを立ててそこからシナリオを流します。直近実施したものだと700多重で負荷をかけ続ける必要があったので、3台に分けて負荷をかけたりしました。負荷試験ツールによっては、重くてそこまで多重度を上げられないとかあるのかも。問題なければ本当の負荷をかける。登録系のAPIに負荷をかけて問題ないことを確認して・・・など本来であれば細かいステップを踏んだりするそうです。一気にいきなりシナリオを流してしまうと何か課題があった際に原因の切り分けが難しくなります。小さいステップで確認していくことは大事だと思います。以上が自分が性能試験を実施する際の考え方や準備〜実施〜改善の流れでした。性能改善を初めて担当する方などの参考になれば幸いです。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。