仕事で、人生初の WEB アプリケーションのスループット云々系の負荷テストを実施しました。
負荷テスト実施で得られた知見、実施後に記事を見返して思ッたことを記載します。
何か思い出したら、随時追記をしていこうかと思います。

初負荷テストについて

まず、初負荷テストについて記載します。

実施した時期

2016年8月-9月 です。

負荷テスト 対象のアプリケーション構成

  • HTTP サーバ
    Apache

  • JAVA AP サーバ
    Glassfish

  • DB サーバ
    AWS RDS

評価対象のモジュール

どの画面からも必ず呼び出されるされる共通処理です。
1呼び出しの負荷は高くないのですが、実行回数が多い処理でした。

負荷テスト対象サービスの状況

  • 既にリリース済。それなりに安定稼働している。

  • 過去負荷テストの実施記録はない。1

自分の立場

  • ざっくり計画と評価をし、且つ、サーバ側のメトリクスを取る人
    受け入れテストの品質面での責任者であり、その流れで負荷テストの計画も行いました。
    実施担当者は別に立てており、テスト計画にしたがって実施して頂きました。
    サーバ側のメトリクスと言っているのは top コマンドで取得できる指標、Glassfish での指標を指しています。
    これは権限の問題でテスト担当者が取得できず、私が依頼を受けて取得しました。

負荷テストで確認したかったこと

  • リリース対象の機能がパフォーマンス面で、サービスの安定稼働に悪影響しないこと。
    軽い処理でしたが、至る所から呼び出されるため、CPU が高負荷にならないこと、RDB へ発行するクエリの負荷が許容できる範囲 に収まることの確認をしました。

知見

負荷テスト実施を通して、以下のような知見が得られました。

1. 当たり前だが、事前に計画はすべき

想定負荷はどれくらいか? はメトリクスが事前に収集可能であれば取得すべきだと思いました。
闇雲に負荷をかけてもパフォーマンスが出なかったり、
負荷の見積もりが甘くて、負荷テスト自体は OK だが、実際に本番サーバでは全然耐えられないというパターンもあるかと思います。

2. 適当に負荷をかけても得られる情報はある

1. の裏返しですが、適当な負荷テストでも得られるものはあると思いました。
とりあえず負荷テストを実施してみて、メトリクスを収集し、それによってわかることもありました。
基礎試験で傾向を把握する - JMeterAtoZ を見て思いましたが、基礎試験に近いことをやっていた気がします。

3. Java の メモリ使用量は、Linux の top コマンドではわからない。

VM オプションによるかもしれませんが、top コマンドの memory サマリでは、memory 使用量の変化はありませんでした。
-Xms と -Xmx が同じ値 なのでこの状態になったのかと思います。
jstatコマンド 等で、 Java のメトリクスは別途取得する必要があるとわかりました。

4. Jmeter の response time 計測で、ざっくり良い悪いはすぐわかる。

response time 計測で、外部品質としてのレスポンスの良い、悪いは感覚的に把握できました。
その後、詳細な調査は必要になりますが、response time だけ見ておくでもいいのかなと思います。

5. スループットが要求される処理では、ホワイトボックスなチューニングも必要

計測で下手にスループットが出てしまい、問題が潜在化してしまいました。
サーバリソースが潤沢で上手く処理できていましたが、当初の負荷見積もりよりもサーバ負荷が上がり、サーバ調達を急ぐ必要出てきてしまいました。
ものすごいアクセス数が多い処理だと、弾数が多い分、少しの無駄な処理で多くのサーバリソースを使用するため、ホワイトボックスでのボトルネックレビューは別途必要に思いました。

負荷テストを振り返り思うこと

当時を振り返り、やっておけば良かったこと、今ならこうするを記載します。

想定負荷 は HTTP サーバのアクセスログで取得が難しい場合も、Google Analytics で簡単に取得ができる

HTTP サーバのアクセスログが残っていない。もしくは検索、集計が面倒な場合、Google Analytics が使える場合があります。
Bot を除去等、一部のアクセスが除外されている可能性がありますが、一部の URL のみのアクセス数 の集計が GUI から行えるので、サーバ側のメトリクス取得環境が整備されていない場合は使用するのもありだと思います。
ただ、エンジニアには参照権限がなかったりしますので、ディレクターや、マーケターに相談して権限をつけてもらいましょう。

Google Analytics でサイトの速度が拾える。

Google Analytics の話が続きますが、サイトの速度から、現在のサーバレスポンスタイムを取得することができます。
デフォルトでは 1% のユーザのリアルなレスポンスタイムがサンプリングされて記録されていますので、「機能追加により、現状から xx 秒劣化する見込み」等の算出ができるようになります。
継続的なパフォーマンス測定をしていない、現状のパフォーマンスを測る時間がない場合、参考情報として使用できるかと思います。
以下は、サイトの速度のドキュメントへのリンクです。
* サイトの速度について - アナリティクス ヘルプ

並列で負荷をかける前にユニットテスト、機能テストでパフォーマンス観点の問題を検知しておく。

負荷テスト として計画したテストの実施時に これはユニットテスト、機能テストでも見つかりであろう問題が検知される時があります。
Jmeter 等の負荷テストツールでしか見れないテスト観点は、複数並列実行下で問題なく動作するかどうかという観点かと思いますので、1シーケンスでの処理の遅さはユニットテスト、機能テストフェーズで検知したほうがトータルコストでは幸せになれるかと思います。

Chrome の Lighthouse で 静的コンテンツも含めた読み込み速度を評価する。

Jmeter の response time は あくまでサーバ側の応答速度になります。
そこからブラウザが静的コンテンツの読み込み、CSS と DOM を解釈して画面が描画されます。
Jmeter での 負荷テストの前の、ユニットテスト、機能テストの段階で静的コンテンツも含めた読み込み速度の評価をしたほうがいいかと思います。
以下、lighthosue の Github リポジトリの URL になります。 * GoogleChrome/lighthouse: Auditing, performance metrics, and best practices for Progressive Web Apps

継続的に実行できる環境の整備

Jmeter でシナリオを作成し、top コマンド で性能検証 という流れで実施しましたが、2000 年代の負荷試験のツールの組み合わせな感じで非常に面倒な作業でした。
以下の観点を満たす負荷試験環境を準備したいです。

  • 構成管理で一元管理された負荷テストシナリオがある
    構成管理上で過去の負荷テストシナリオが一元管理されているのが理想に思います。

  • スケジュール実行されている、または、コマンド１つで実行可能
    作業者に、Jmeter インストールしてもらって、張り付きで負荷テストを実施してもらうのは人的リソースの無駄です。
    負荷テストテンプレートが自動スケジュール実行される。または、自動スケジュール実行されなくてもコマンド1つで実行できる環境を構築したいです。

  • サーバ側のデータ収集、データ可視化が自動化されている
    サーバリソースの監視メトリクス収集が自動化されていて、データ可視化もできるのが理想に思います。

上記の観点を満たせそうなツールを調べてみました。

sar コマンド、sadf コマンドの存在

実施していた時は、top コマンドの結果を、リダイレクトして テキストファイルに書き出し、top コマンドの結果をCSVファイルに出力する | Monotalk で記載している Python スクリプトで CSV にして エクセルでグラフ化するという手順を踏んでいましたが、非常に面倒くさかった思い出があります。
今、実施するなら sar コマンドをインストールして、sadf コマンドで JSON フォーマット、CSV フォーマットで書き出すかなと思います。
sadf コマンドの使い方は以下が参考になります。
sadfコマンドの使い方 - Qiita

ROI として負荷テストやる意味あるの? 問題

負荷テストは、機能テストの実施後に実施するのがセオリーかと思います。
リリースに対して工程として後ろの方に位置するため、何らかの理由でスケジュールが押すと、簡略化される、最悪の場合やらない等の選択肢を取られがちです。
そして実施には機能テストよりもコストがかかる場合が多いです。
個人的な実施、要不要の判断基準を以下にまとめてみました。
負荷テスト実施要/実施不要の判断基準を示すマトリックス | Monotalk
必ず実施ではなく、機能やサービスによりリスクはあるけど、やらないというのも有りかと思います。

参考

以上です。

  1. これは実施はしていたのかもしれませんが、その実施記録が残っていない状況でした。やろうと試みた実施手順書類などは存在していました。 ↩

コメント

カテゴリー

最近の投稿