初心者エンジニアの歩み[パフォーマンステスト１]

現場でパフォーマンステストをしたので、理解したこと・あやふやなこと含めて、記録として書きます。

あくまで「初心者」が行った一連のテストですので、理解不十分な点や、無駄が多い点もあるかと思います。

パフォーマンステストってなに？

パフォーマンステストとは、負荷テストの中でも「対象システムが、何人までのユーザーの同時アクセスを処理することが可能か、又は何人以上になってくると処理不能（サーバーエラー）が発生するか」といったことをテストし、品質を保証します。

使用ツール・環境

• EC2（本番webサーバー・バッチサーバー）
• cloudwatch（webサーバー・バッチサーバーの負荷状況をいろんなグラフにしてくれます。）
• Apache JMeter（負荷を与えるためのツール）
• Excel（私は今回、cloudwatchだけでは不十分なグラフデータを取得するためにエクセルで作りました）
• Rlogin（サーバー接続はすべてこれで）
• WinSCP（JMeterを本番環境のサーバー上で、コマンドラインで動かすとなると、ファイルの移動等が非常に面倒になるので、SCPを使うと早いです）
• windows 10（ローカル）→　virtual Box　→　centOS（開発環境）

このテストの短所

正解・不正解といった答えが曖昧ではっきりしません。JMeterの結果から、データが間違っていたり、シナリオが間違っていたりと、ある程度の見極めはできますが、最終的にはエラーが綺麗になくなるということはなく（何人まで耐えられるかというテストなので当然ですが・・・）、何度も流してみて、「データを取る限り、この辺りがシステムの限界だろう」といった見極め方になります。

私の場合はこのような流れで行いました＞＞＞＞

当初５０００人テストを保証したかったけれど、最初は１０００人の段階でエラーが続出しました。
（すべて結果データをとります。）
↓

データの修正などを行って、２０００人まではエラー数が０になりましたが、２５００人にすると、エラーが続出
（最初のエラーはテストユーザーのデータに誤りがあったりしたので、JMeterのログをcsvにしてExcelで読み込み、
抽出機能を使うことでユーザーの誤りは修正できました。）
↓

サーバーのメモリやCPUが足りてないのでそれらを増やしました
（EC2の方だけでは容量を増やすのにお金がかかるためだと思いますが、途中でGCPも使い始めました）
↓

エラー数はだいぶ抑えられましたが、エラー人数が１００～５００人規模で出ます（これで次の人数に進めるのか・・・！？）
（今度はJMeterの方が処理が追い付いてなさそう）
↓

JMeterサーバーを２台にしました
（JMeterサーバーの接続について次項で説明します）
↓

負荷が分散されて落ち着きました（エラーはこの時点で１０人程）
↓
３５００人でまた１０００人規模のエラー
（DBサーバーのCPU処理が追い付かなくなりました）
↓
・・・・・・・・・・・

結論から言うと、データベースサーバーを２台に増やし、ロードバランサーを用いることで５０００人まで保証できるようになったのですが、そちらは縮退構成テストの環境として予定していたため、縮退構成でないテストはパフォーマンスとして３０００人を保証することで一度キリを付けました。

縮退構成テストとは、webサーバーやDBサーバーが１台動かなくなった時のパフォーマンスをテストして１台動かなくなっても何人までなら動くよ！ということを保証します。最後は４０００人、５０００人での通常テストも行って、結局、５０００人だと１００人位は時折、５００や５０２等のサーバーエラー画面に遭遇する、という結果で終了。

・・・・とこのような感じで、結果とエラーの種類、サーバーの状況を比較しながら進めていくのがパフォーマンステストでした。取り留めのない感想ですが、”答えがあるようで無く、無い様である”といった感じでした。

実際に行ってみて、躓いた点について