ここからはじめよう_ 7 回目　「SRL1.3　ことはじめ」

  • komiyama｜

いや～、お久しぶりです。

ここからはじめよう_６回目　「LRv12　使ってみよう（後編）」から3ヶ月以上経ってしまいました。

本当は、次はALM(Application Lifecycle Management) / QC (Quality Center) をと思っていましたが、他のメンバーが書いてくれそうなので、今回からはブログのサマリで書いたように「StormRunner Load（以後SRL）」って性能テストツールのSaaSを紹介していきたいと思います。

SaaSなので基本はインストールはないので（と言っても、スクリプト作成をローカルマシンで行うためにTruClientっていうスクリプト作成ツールのをインストールします）、使い方にフォーカスして説明していきますが、前回まで性能テストツールの「LoadRunner（以後LR）」を紹介しておいて、また性能テストツール？って思ってらっしゃるかもしれませんので、今回の1回目は「SRL」って何？「LR」と何が違うの？を説明していきます。

まず、振り返りということで、「LR」の基本構成はこんな感じでしたよね（↓）！

LR_1.png

一般に構成要素のコントローラ、ロードジェネレータなどはオンプレでテスト環境にインストールしますが、

バージョン11.53からは次のように負荷生成マシンであるロードジェネレータをAWS上に配置して管理マシンであるコントローラから管理する事ができるようになっています（↓赤枠部分）。

LR_2.png

という事で、実はLRバージョン11.53から（当然バージョン12でも）性能テスト負荷生成マシン自体のスケールキャパシティをクラウドを利用し、ぐっと広げる事が可能になっています。

では、SRLって何が違うのかと言うと、上の図の性能テスト分析や性能テスト管理マシンもクラウド上にあるSaaSという事です。

これにより、数万以上のアクセス規模をシュミレーションしなければならないような性能テスト基盤でも瞬時に構築し、終われば開放してしまうという事ができます。

どのくらい瞬時かというと、私のこれまで使った経験からいうと5分～10分程度です。え？瞬時じゃない・・・まあ、そう言わずに・・これまで性能テストを実施する際の基盤準備やその上にツールをインストールしてという時間を考えたらすごく魅力的ですよね？？構成を書くとこんな感じになります（↓）。SaaSから負荷をかけるために対象システムにグローバルIPでアクセスできることが制限になります。

SRL_00.png

ここで、SRLのアピールポイントを言わせてもらうと次の３つです。

1. シンプル

2. スマート

3. スケーラブル

まず最初の「シンプル」から説明します。

なんといっても性能テストに必要なツールセットがすべてクラウド上にあるため、スクリプトを作成する際に利用するツール以外はローカルで必要になるのは「Webブラウザだけ」という超シンプルなんです。Webブラウザで最初にSRLにアクセスした時の画面はこんな感じです（↓）。

SRL_menu.png

さらに、スクリプトさえ準備しておけば、性能テスト負荷生成マシンの

・プロビジョニング
・テストスクリプトのデプロイ
・テスト実行
・自動的ターミネート（終了したら負荷生成マシンをターミネートする事）

を全部SRL内で自動でやってしまいます。

アジャイル開発で数週間のイテレーション内で性能テストまで実施しないといけないとなると、このような大規模な負荷テストの基盤そのものを構築、設定、実行はかなりのチームにとっての負担になりますよね。そんな時にもSRLのシンプルな利用スタイルはマッチするでしょう。

次に「スマート」についてですが、SRLでは直感なインターフェースで操作をする事ができます。スクリプト作成時以外はほとんどの作業をWebブラウザ経由で行う事ができます。特に性能・負荷テスト実行中の仮想ユーザー数の増加状況やTPS（1秒あたりのトランザクション数）、ヒット数といった複数のデータを1つのダッシュボード上で表示し、ボトルネック発生時の相関関係を直感的に把握する事ができます（↓）。

SRL_graph.png

LRの時にも触れましたが、最終的にサーバーやネットワーク機器のログデータを分析にするにしても、最初のボトルネック切り分けはボトルネック発生時のサーバーやネットワーク機器のリソース情報を時系列グラフで見ると非常に効率がはやくどの箇所にあたりをつけて深堀り調査が必要かわかるわけです。

ということで、SRLでもサーバーやネットワーク機器のリソースを収集する機能が実装されています。

関連がありそうなリソース情報を相関グラフでTPSやユーザー数状況と比較する事で切り分け作業をスマートに実施できるわけです。

最後のスケーラブルは、もう何度も説明してきたので手短に話しますが、通常の性能・負荷テスト実施方法で数万以上の負荷生成環境を構築するとなるととても大変な基盤構築準備が待っているわけですが、SRLであればこれが10分内で準備完了となる訳です。このスケーラビリティはSRLがクラウド利用を最も効果的に利用しているポイントだと思います。

しかも、この後の回でも詳しく説明しますが、どこのロケーションに負荷生成マシンのインスタンスをクラウド上に起動させるかを選択するのもWebブラウザのUI経由で簡単にできます（↓）。 SRL_19.png

以上で、ここからはじめよう_７回目　「SRL1.3　ことはじめ」でお伝えしたかった、SRLって何なんだ？と、前回までに紹介した性能テストツールのLRと何が違うのかについて説明しました。ご理解いただけましたでしょうか。

特に強調したかったのはSRLの3つのポイント「シンプル」、「スマート」、「スケーラビリティ」でした。

あっと、1点だけ追加でSRLのライセンス体系についてご説明しますと、SRLは説明してきたとおり、SaaS型のサービスで基本的なライセンスは生成するユーザー数（VU（Virtual User））とそれを何時間（H）利用するかで決まります。

そのためライセンスの単位をVUH（ユーザー数　ｘ　利用時間）で購入します。

興味がある方は以下のサイトをみてみてください、現在の価格を確認することができます。

https://saas.hp.com/buy/stormrunner-load

SRLについてもっと直接聞いてみたいとか、購入したいけどHP SaaSのサイトは英語で購入方法がよくわからないというお問い合わせはこちらまでお願いします！

では、次回また会いましょう！

カテゴリ: