RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

トップ > JMeter > アクセス限界値を知るための負荷試験のやり方について

アクセス限界値を知るための負荷試験のやり方について

JMeter

はじめに

はじめまして。ラクスのインフラエンジニアのcappy_potterと申します。

弊社で提供しているクラウドサービスを担うサーバに（クラスタ）ついて、どの程度のアクセスまでであれば 問題なくサービス提供できるのか、という限界値を知るための負荷試験を過去に実施しました。

Webシステムを構成するサーバ群に対し、どのようにして負荷をかけ、限界値を探るのか、いろいろ方法は あると思いますが、実際に弊社で試したやり方をご紹介しますので、参考にしていただければと思います。

サーバ構成

今回負荷をかけるサーバの構成は下図のようになっています。 対象のシステムは複数のサーバからなっていますが、外部からのアクセスは全てロードバランサで受けて、 配下のサーバに通信を振り分ける形となっています。

負荷試験環境準備

● 本番システムと同じ構成（台数、スペック）の負荷試験用サーバを用意する。

今回、負荷限界値を正確に測るため、本番環境と全く同じハード構成・台数の試験用サーバを用意しました。 リソースが足りず難しい場合は、各サーバのスペックを同じ割合で落としたものを用意して試験を行うことで とりあえず「ボトルネックはどこか」を探ることはできると思います。


● Apache JMeterサーバの用意

試験用サーバに対して負荷をかけるためのサーバとして、Apache JMeterサーバを用意しました。 このとき、同時に大量のアクセスをかけられるようにするため、上図のようにマスタサーバ以外に 4台のスレーブサーバを用意しました。

　※JMeterサーバ側が貧弱だと、負荷限界に達する前にJMeterサーバ側の方が先に限界に達する可能性が
　　ありますので、そうならないように考慮しました。


● 各サーバのパフォーマンスデータ収集準備

負荷試験対象の各サーバにはZabbixエージェントをインストールし、パフォーマンスデータを取得できるようにしました。 弊社では、もともとサーバの監視用としてZabbixを利用していますので、これを用いて、各サーバのCPU使用率、 ロードアベレージ、Disk I/O、swap使用量、ネットワーク帯域のデータを収集するようにしました。
　→ 負荷をかけたときに、どのサーバの何のリソースがボトルネックになっているかを確かめるため。

なお、データの取得間隔は30秒にしました。間隔を短くした方がブレが少ないデータとなりますが、短くしすぎると データ取得自体も負荷になる可能性があるためです。

負荷試験パターンの検討とJMeter用シナリオの作成

今回、負荷試験を行うことにより、大きく分けると以下の2パターンの限界値を求めたいと考えました。

　① Webサーバ1台あたり、秒間何アクセスまで耐えられるのか
　② システム全体として秒間何アクセスまで耐えられるのか

ただ、ひと口に「秒間何アクセスまで耐えられるのか」といっても、アクセスするページやユーザの操作内容によって 変わってきますので、基準を設けなければなりません。

基本的には最もアクセスが多いページや、標準的なユーザの操作内容がわかっているのであれば、それを基準にすればよい と思いますが、定まらない場合はいくつかのパターンについて試験を行い、その結果をもとに判断するしかありません。

弊社では、①の試験を行うために9パターンのシナリオを作成しました。また、①の試験はWebサーバ1台だけに対して アクセスが流れるようにするため、ロードバランサーでの振り分け先を1台のWebサーバのみとなるように設定を変更して試験を行いました。
（②の試験のときは、3台のWebサーバに対して均等にアクセスが振り分けられるようにしました。）

JMeterで負荷をかける

作成したJMeterのシナリオを使って負荷をかけますが、秒間のアクセス数限界値を探るのが目的ですので、 以下のような流れで負荷をかけていきました。 （各シナリオで同じように試験を行い、それぞれのシナリオでの限界値を探りました。）

　１）対象のサーバに対して、まずは「おおよそこれぐらいではないか」と思う秒間のアクセス数を5分間かける。
 　　　→例えば、秒間20アクセスを5分間かける場合、JMeterの設定は以下のようになります。

　　【Ramp-Up期間：】負荷をかける時間 ＝ 300(秒)
　　【スレッド数：】Ramp-Up期間(秒) × 秒間アクセス数 ÷ 負荷をかけるJMeterサーバの台数 ＝ 300×20÷4 ＝ 1500



　２）5分間負荷をかけた結果、JMeterでエラーを検知しているようであれば、秒間のアクセス数を減らし、
 　　　再度負荷をかける。エラーを検知していなければ秒間のアクセス数を増やして再度負荷をかける。

JMeterでエラーを検知しているかどうかは、実行結果の画面で「Status」の部分をクリックして、 ステータス別に並び替えすることにより判断できます。
（下図のように赤い「×」マークがあれば、エラーが発生しているということになります。）


　３）上記２）で秒間のアクセス数を増減させながら何度かテストを行い、最終的に「これ以上秒間のアクセス数を
 　　　増やすとエラーが出る」という値が判明すれば、それが限界値となる。

ボトルネックの調査

限界となる負荷をかけられているときのZabbixデータを確認し、どのサーバの何がボトルネックになっているか 確認します。

下図は、負荷をかけている間の各サーバのパフォーマンスデータを記録した資料の抜粋ですが、これを見ると WebサーバのCPU使用率が100%に達していることがわかります。 そのため、この場合は、「WebサーバのCPUを増設する」「Webサーバの台数を増やす」などすれば、システム全体としての 限界値は延びることが予想されます。

おわりに

本記事では、負荷試験によってサーバの限界値を求めるための方法に絞って記載していますが、実際は試験を実施する前に 負荷試験を行う目的、求められた負荷試験結果をもとに今後どう運用していくのか、ということを明らかにしてから 実施しないと、何度も負荷試験を実施しなければならなくなる可能性があるため、これらをしっかり認識したうえで 実行するようにして下さい。

◆TECH PLAY
techplay.jp

◆connpass
rakus.connpass.com

ラクスの技術 / デザイン情報サイト
Copyright © RAKUS Co., Ltd. All rights reserved.