こんにちは、前回はSRLの画面に表示されるステップに基づいて「テスト作成」＞「スクリプト指定」＞「負荷設定」＞「モニタリング」まで実施しましたね。
画面は、こんな状態になってますね？まだの方は前回までの内容を読み返ししてもらい、準備してみてください。
今回は、画面の左メニューペインに表示されている次ステップである「分布」から設定していきます。
画面の左メニューペインから地球儀のアイコンの「分布」をクリックしてみましょう (赤枠箇所)。この分布で、負荷テストで必要な負荷生成マシンをSRLのクラウド上のどこのエリア（拠点）から起動するかを選択する事ができます。同じテスト対象マシン（AUT）に対して、複数拠点からインターネット経由で負荷テストを実施する事で、地理的な条件でどのくらい性能値が変化するのかを確認する事ができます。日本以外からのユーザーにアクセスを想定したサイトであれば、この分布を設定する事でどの程度遅延が発生するのか計測する事が前もって検証できます。
すると次のような画面が開き、デフォルトでは、拠点としてAWSの「バージニア州」拠点が割り当てられていますが、今回は別の拠点で実施したいので、これを削除しましょう。右側の× (赤枠箇所)をクリックしてください。削除されましたね？
軽く素通りしてしまいましたが、AWSとはそう、Amazon Web Serviceを指しています。つまりSRLのSaaSでは、バッググラウンドでAWSを使っているんです。AWSの他にもマイクロソフト社のAzureも使っています。ユーザーはSRLのサービスをSaaSで購入してもらえれば、AWSやAzureへは特に追加の費用は必要なく、負荷生成マシンを使う事ができるのもSRLのメリットと言えるでしょう。
「バージニア州」の代わりの拠点を追加するために、左上にある「＋場所の追加」をクリックしてみましょう (赤枠箇所)。
すると次のように「場所」ウィンドウが別に開くので、ここで、今回は2拠点から負荷をかける事を想定して「シンガポール」と「東京」を選択してください。選択すると下図のように青色にハイライトされますのでその状態で「OK」をクリックしてみましょう。
そうすると、先ほどの画面に戻りますね、今度は「バージニア州」ではなく選択した「シンガポール」と「東京」が表示されていますね？？ここで、負荷生成比率を設定しましょう。最初の8回目でTruClientを使った仮想ユーザ数は最大30までと説明しましたね。その30VU（Virtual User：仮想ユーザ）をシンガポールと東京の拠点で比率を%で指定します。
シンガポール 40% （30VU x 40% = 12VU）
東京 60% (30VU x 60% = 18VU)
としてみましょう。設定すると次のような状態になっていればOKです (赤枠箇所)。負荷生成比率以外にもこの設定箇所で回線品質を設定する事ができます。WAN-Good、 WAN-Typical、 WiFi、 Mobile-Typical、 Mobile-Busy という項目です。これにより負荷テストを実施する際に拠点からテスト対象（AUT）までどの程度の回線品質（帯域、パケットロスや遅延など）かを設定してテストできます。回線品質をシュミレートしないでテストした場合とした場合で大きく性能が異なるケースがありますが、説明はまた機会があればしたいと思います。ここでも特に回線品質の設定はせずに進めます。
次は左メニューペインからグラフアイコンの「SLA」をクリックしてみましょう (赤枠箇所)。
ここで、今回TruClientのスクリプト編集で設定した3つのトランザクションについて(トランザクションについて不明な方は再度トランザクションの設定回に戻って説明を読んでみてください)表示されていますね？それぞれについてSLA(Service Level Agreement)として応答時間の90パーセンタイル値を設定します。SRLではここでSLAを設定する事でテスト実施中やレポートに閾値を超えた場合の結果が表示されます。
SRLでは90パーセンタイルを採用しており、90以外は設定できません。パーセンタイルとは多重負荷と実行時間内の反復で何度も計測されるトランザクション応答時間の分布を平均値を50とした時に90を超える場合は異常値としてSLA違反とするものです。その90はどこかをここで設定します。今回は前回のテスト結果が残っていたので、それを元に右の赤枠箇所のように設定してみました。
次は、左メニューペインの最後である「ナビゲーションブレークダウン」です。赤枠箇所をクリックしてみましょう。
すると、次のような画面が表示されますね？ここでは、SRLによる負荷テスト実施のピーク時(仮想ユーザ数が最大に達した状態、今回は30VUとなる)の特定のWebページURLの詳細応答時間情報を取得する場合にそのURLを設定します。
ここでは、登録画面のURLを指定しています。複数設定できますので、追加する場合は「＋」ボタンをクリックして追加してください。私の場合、今回はこの登録画面のみを指定する事にします。
具体的に登録画面とは、次の画面になります。どこだっけ？という方は再度TruClientのスクリプト記録の回を見てみてください。
はい、ここまでできたら、いよいよ実行ができます！右上にある「テストの実行」をクリックしてみましょう。
すると、次のように「初期化」画面が立ち上がってきますね。これは、SRLが負荷テストの設定を反映した負荷生成マシンやモニタリングマシンをセットアップしている状況を表示しています。だいたい、5分から10分程度で完了します。
すべての項目が100%になると完了します。この後、すぐに自動でテストが開始します。
自動で「結果」画面に移動し、現在の実行状況をリアルタイムに表示してくれます。全体状況は赤枠箇所に表示されます。この下図であれば、仮想ユーザが10まで達した状況で、スループットが60.5KB、トランザクションは0.6、ヒットPerSecは16.6になっていると分かります。失敗したトランザクションがあればそれも表示されます。全体状況表示の下には時系列でのメトリック（仮想ユーザ推移やリソース推移）が複数グラフのダッシュボードとして表示されているのが分かると思います。
ここで表示されているメトリックを編集していきましょう。編集は実行中でもリアルタイムに反映されます。では、最初の「実行中の仮想ユーザ」の項目で左のある分岐アイコンにマウスを当ててください。プルダウンメニューから「場所」をチェックしてみましょう。これにより、デフォルトでは総計になっている仮想ユーザ数の推移を拠点単位（今回はシンガポールと東京を選択したので2拠点）に別々に表示できます。
こんな感じになりましたね？負荷生成比率を拠点ごとに変えたので、このように表示されていれば正しく設定した比率で負荷が生成されている事が分かります。
「実行中の仮想ユーザ」以外にもデフォルトでメトリックが表示されていますが、ここで、表示されていないが収集されていたメトリックの表示方法を説明していきたいと思います。画面の下に表示されている青いタブ (赤枠表示箇所)をクリックしてみましょう。
すると、次のように下からするっとメニューが表示されますね？左に注目してください。大きくメトリックを「クライアント」、「トランザクション」、「モニタ」として分類して収集していますので、そこから選択していきます。ここで、前回設定したNew Relic の APM を使ったNode.js サービスのメトリックを表示させてみたいと思いますので、「モニタ」タブをクリックし、表示されるメトリックの中から「Memory/Physical/used_mb_by_host」というをクリックしてみましょう。使用されている物理メモリ量のメトリックになります。ここはもし他のメトリックに興味があればみなさん自身でいろいろ適宜選択してみてください。
選択したメトリックが一番下に追加されてますね？下図のように表示されているはずです。このようにデフォルトで表示されていないメトリックでも収集されているのであればテスト実行中でも後からでも追加できます。また、このグラフを一番下ではなく上の方に移動させたいのであれば、メトリックのタイトル部分をマウスでドラッグしてあげれば簡単に移動させられますのでやってみてください。
次に同様の方法で「トランザクション」タブからTRTの「HOME画面に戻る」を選択してみましょう。私の場合はSLA違反がでましたので、○ が表示されています。
開示から2分弱の時点でSLAで設定した90パーセンタイルの閾値を超えた応答時間が計測されている事が確認できます。拠点ごとの表示をするとシンガポールと東京どちらでも超えた記録が存在した事がわかります。
次は、グラフの相関表示を説明します。負荷テストでボトルネック切り分けをする際に一次切り分けの道具としても相関表示は非常に有効です。ここでは「実行中の仮想ユーザ」グラフに「秒ごとのヒット数」を追加してみます。「実行中の仮想ユーザ」の右上に「+結合」ボタンがあるのでこれをクリックします (赤色箇所)。
すると、画面の下に先ほどのグラフの追加と同様に追加するメトリックを選択できるようになりましたね？先ほどのグラフの追加と違うのは、タブ名が「（結合モード）」になっている事です。では、ここで、「クライアント」から「秒ごとのヒット数」をクリックしてみましょう。
すると、「実行中の仮想ユーザ」グラフに「秒ごとのヒット数」が追加されて相関関係が把握できるようになりました。今回は特にボトルネックも発生しませんでしたが、もしある仮想ユーザ数に達した際にヒット数が急激に落ち込んだり（あがったり）すれば、その時点の別のメトリックを相関してテスト対象システム（AUT）のどこに問題が発生したのかを切り分けて行く事ができます。その上でサーバー内のログなどの調査に移っていくいけば最初からログ分析をするよりはぐっと効率的でしょう。
追加した情報も上述の拠点ごとにブレークダウンして表示できます。試してみましょう。「場所」をチェックしてください (赤枠箇所)。
このように、拠点ごとの「秒ごとのヒット数」が「実行中の仮想ユーザ」と相関されて表示する事ができました。
ここまででグラフについての見方や追加の設定を終えます。実行中のテストが終了すると自動的に負荷生成マシンのターミネート処理やPDFレポートのメール送信などの事後処理が自動で始まります(下図)。
終了したら、登録画面URLを設定した「クライアントブレークダウン」を見てみましょう。画面の上にある「クライアントブレークダウン」ボタンをクリックしてみましょう (赤枠箇所)。
「拠点」、「ブラウザ」で比較する事ができます。拠点によってはすべてのブラウザで計測できない事もあります。例えば東京では、Chrome での計測は対応していません。見方は「負荷下」というのは仮想ユーザのピーク時である30VUの時点で計測したURLに対する応答時間で「負荷なし」はSRLによる負荷が発生していない状態での応答時間を意味しています。ギャップの値が大きいほど負荷による性能劣化が発生していると言えます。
今回は、シンガポールからFireFox (バージョン33) でアクセスした場合にSRLで30VUの負荷をかけた場合に応答時間が悪かったと言えます。
では、実際にこのシンガポールの状況を確認してみましょう。マウスでクリックしてみてください (赤枠箇所)。
するとシンガポールのSRLによる負荷下（30VU）での登録画面URL詳細が表示されます。DNS ルックアップにどのくらいかかっているか、コネクション初期化にどのくらいかかったか等、URL全体が表示されるまでの応答時間のブレークダウンを把握する事ができます。これにより、コンテンツを軽量化するとか、ある特定のコンテンツ表示についてサーバー側からのレスポンスが遅いと言った応答時間の遅延を発生させている原因を絞る事ができ、先ほど紹介した相関グラフと共にボトルネック分析に有効な機能です。
最後に、今回設定した「電子メールレポート」できちんとレポートがメールとして届いてるか確認してみましょう。ちゃんとこんな感じに届いてますね？もし届いてないという場合は、最初にHP SaaS の登録をした際のEメールアドレスがあっているか確認してみましょう。
添付PDFの中身はこんな感じです(下図)。
ここまでで、7回目からはじまったSaaS 型負荷テストソリューションHP StormRunner Load の基本的な使い方を終えたいと思います。お疲れ様でした。
SRLについてもっと直接聞いてみたいとか、購入したいけどHP SaaSのサイトは英語で購入方法がよくわからないというお問い合わせはこちらまでお願いします！
次回のここからシリーズでは何を紹介しようか決めていませんが、またお会いしましょう！