複数台のGatlingサーバを用いた負荷試験について
メディアシステム開発部の野崎です。 メディアシステム開発部では、「au Webポータル」や「au スマートパス」といった、 多くのユーザ様にご利用頂いているサービスを担当しています。 このようなシステムでは新規開発や機能追加時には負荷試験を実施することは必須となります。
そこで今回は、Webシステムの負荷試験について 負荷を生成する環境にフォーカスして、 これまで行ってきたノウハウをまとめてみます。
はじめに
負荷試験と言われるものには幾つか種類があります。
性能試験、耐久試験、限界試験、ロードテストなどがありますが、
今回は簡単のために、以下の目的の試験をまとめて負荷試験と呼ぶことにします。
- 非機能要件で定義した性能を担保できるか？
- システムの性能の限界はどのくらいなのか？
- 長時間連続して負荷をかけて、サービスイン後状況を再現し、期待通りに動作するか？
生成する負荷としては、秒間数百から数千リクエストを想定しています。
システム前提条件
以下のような環境である前提で話を進めます。
- 負荷試験対象のシステムはAWSで構築されている。
- 負荷生成側のシステムもAWSにてEC2上に構築する。
- 負荷生成側のサーバはGatlingを使用する。(OSは、Amazon Linux)
- 負荷生成の指示はローカルのPCから行う。
- レポートの生成はローカルのPC上で行う。
Gatlingは、Async, Netty, Akkaを用いたScala製でHTTPリクエストを対象とした負荷試験ツールです。 個人的に、構築が容易なところと結果レポートが見やすいところが気に入っています。 公式サイトと、ソースコードが以降の説明で、参考になります。
準備
負荷試験の準備段階で、計画や環境をどのようにそろえるかを記載していきます。
準備1 - 試験の計画
試験を計画する際に注意したことです。
◯ 新規開発時には、すべてのURLを対象とした試験計画にしましょう。
「このURLは大した機能でないから試験範囲から外そう」と思いがちですが、 バグが有ったり、想定外の負荷がかかったりして、結果的に全体に影響することもあります。 サービスイン後は全体の試験を行うことは難しいので、新規開発時にやっておくことが望ましいです。
◯ 負荷試験の項目をすべて行える日程を複数回計画しましょう。
特に新規開発の場合ですが、往々にして期待どおりの性能を発揮できることはありません。 結果をレビューし、原因を特定修正し、再度負荷試験実施できる期間を設けましょう。
◯ キャッシュが有り無しのパターンをテストケースに含めましょう
多くのユーザリクエストを受けるシステムの場合、何らかのキャッシュ機構を組み込むことが多いと思います。 その際キャッシュが有る場合、無い場合を想定しテストケースを作成しましょう。 アプリケーションにキャッシュを使わないモード実装が必要な場合もあります。
◯ 別システムと連結している場合の考慮
オンラインでバックエンド側から別システムへ連結している場合、 別システムも含めた試験の範囲にするか確認しましょう。 範囲外であれば、スタブの作成などを検討しましょう。
準備2 - 負荷生成サーバ準備
負荷試験生成サーバの準備を行っていきます。 GatlingサーバはEC2上に構築します。構築時はインスタンスタイプは適当で大丈夫です。
◯ インストール
こちらを参考にGatlingをインストールしましょう。 JDK8のインストールとGatlingのパッケージを解凍し、適当なディレクトリに設置します。
◯ OSのチューニング
こちらを参考に、EC2のディスクリプタやカーネルパラメータを変更します。 ここを怠ると、あとで多くの台数のサーバが必要になったりします。
◯ 1台のGatlingサーバがある程度の負荷を掛けられるかを確認
ある程度のオーダーの負荷が掛けられるかを確認しておきましょう。 もし期待する負荷を生成出来ない場合は、「OSのチューニング」を見直しましょう。 それでも負荷生成が十分でない場合は、インスタンスタイプを徐々にあげてみましょう。 場合によってはこの確認をするために、後述の申請が必要になったりします。
◯ Gatlingのテストケースの作成
テストケースを作成し、構築したGatlingサーバに配置しましょう。
※テストケースに関しては多くの情報がWeb上にあることもあり、今回書き方は説明しません。
※GatlingDSLのチートシートを参照すれば調べやすいです。
◯ Gatlingサーバを複数台用意する
ここまで来たら、1台での負荷生成性能を元に、 複数台Gatlingサーバを作成しておきましょう。 後述の申請と関連するためで、2台以上あると試験当日に期待する負荷が生成出来ない場合でも、 インスタンスタイプを上げていけば必要な負荷を生成出来るでしょう。
◯ AWSへの負荷試験の申請
ELBなどのAWS上のリソースに対して負荷をかけるときは、AWSへ事前の申請が必要です。 試験内容によってどういったことを申請する必要があるかはサポートなどで確認しましょう。
※ 2017年4月時点での申請においては、負荷生成サーバのインスタンスIDが必要でした。(ということは、申請後にサーバ台数を増加できない・・！？)
準備3 - Gatilngサーバのスケーリングアウト
ところで、GatilngにはJMeterの用にクラスタを構築する機能は提供されていないようですが、 こちらにある、スケーリングアウトの方法を取れば、 複数台のGatilngサーバから同時に負荷を生成することが出来ます。 今回はこちらの方法を取ってみます。
準備4 - ローカルPCの準備
ローカルPCはMacとして、以下の準備をします。
◯ Gatilngのインストール
後述するレポートの作成をするために、ローカルPCにもGatilngを設置しておきます。 負荷生成サーバのインストールと同じ方法で大丈夫です。 (ローカルPC上で負荷生成はしないので、OSのチューニングは不要です。)
◯ csshx or i2cssh のインストール
homebrewなどでcsshxやi2csshをインストールしておきましょう。
これらは、ターミナルアプリをクラスタリングするアプリケーションで
1度のコマンド操作で、複数のサーバを同時に操作出来たりします。
実施
以下図の流れで試験を実施します。
Gatlingサーバ2台あるとし、gatling01,gatling02というホスト名とします。
$GATLING_HOMEをインストールしたディレクトリとします。
1.1 ローカルPCからGatlingを実行指示
# ローカルPCのからGatlingサーバへログイン
$ csshx gatling01 gatling02
(ターミナル.appの複数ウィンドウが立ち上がる以降はサーバ内操作)
# 2台同時に実行指示
$ cd $GATLING_HOME
$ ./bin/gatling.sh \
-s mediba.SampleCluster \
-nr \
-rd "cluster test"
#オプション説明
-s : シナリオの指定
-nr : レポート出力しない
-rd : 説明の記載
(実行中は以下のようになります。)
1.2 負荷生成
テストケースの実行が終わるまで待ちましょう。
csshxを利用した理由は、負荷生成の実行状況がGatlingサーバそれぞれにて確認できるからです。
Gatlingサーバのリソース不足が合った場合は、実行状況から確認できます。実行を止めて、インスタンスタイプを上げるなどしましょう。
レポート作成
負荷試験が無事終わったら、レポートを作成しましょう。
2.1 サーバごとの実行ログをローカルPCにDLする
# ローカルPC
$ cd $GATLING_HOME
# 適当なディレクトリをresults以下に作成
$ mkdir -p ./results/samplecluster
# Gatlingサーバからsimulation.logをDLする
$ scp gatling01:/$GATLING_HOME/results/{実行ID}/simulation.log simulation_gatling01.log
$ scp gatling02:/$GATLING_HOME/results/{実行ID}/simulation.log simulation_gatling02.log
2.2 サーバごとのログからレポートを作成する。
./results/samplecluster/配下のログファイルを読み込んで、レポートを生成します。
$ sudo ./bin/gatling.sh -ro samplecluster
# オプション説明：
-ro : ログからレポートの作成のみ行う。
GATLING_HOME is set to /opt/gatling-charts-highcharts-bundle-2.2.3
Parsing log file(s)...
Parsing log file(s) done
Generating reports...
================================================================================
---- Global Information --------------------------------------------------------
> request count 40 (OK=40 KO=0 )
> min response time 26 (OK=26 KO=- )
> max response time 113 (OK=113 KO=- )
> mean response time 39 (OK=39 KO=- )
> std deviation 14 (OK=14 KO=- )
> response time 50th percentile 37 (OK=37 KO=- )
> response time 75th percentile 40 (OK=40 KO=- )
> response time 95th percentile 47 (OK=47 KO=- )
> response time 99th percentile 100 (OK=100 KO=- )
> mean requests/sec 2 (OK=2 KO=- )
---- Response Time Distribution ------------------------------------------------
> t < 800 ms 40 (100%)
> 800 ms < t < 1200 ms 0 ( 0%)
> t > 1200 ms 0 ( 0%)
> failed 0 ( 0%)
================================================================================
Reports generated in 0s.
Please open the following file: /opt/gatling-charts-highcharts-bundle-2.2.3/results/samplecluster/index.html
こちらに有るような、 見やすいHTMLのレポートが生成されます。
このレポートをS3などにアップすれば、複数人での結果のレビューも行いやすく、 次のアクションも取りやすいと思います。
まとめ
AWS環境でのGatlingを使った負荷試験について主に環境周りについてまとめてみました。
負荷試験の本来の目的は、試験対象システムを評価することです。
負荷試験生成の環境は、今回の手順などを参考に楽に構築し自由に負荷生成を行える様にしておけば、スムースに試験を実行できるかと思います。
今回の記事が皆さんの開発の参考になれば幸いです。
以上となります。
