◆◆DevOpsあれもこれも<第10回>◆◆

SaaSとローカルの負荷テストツール

LoadRunnerはオンプレミスの負荷テストツールとして非常に有名であり、名前をご存じの方も多いと思います。ブラウザへのアクセスをプロトコル単位で記録し、ジェネレータによってテストの多重度を増やして仮想的に数百、数千、数万の負荷をかけることでサーバの動作を検証することが出来ます。(最新のバージョンでは製品名がOpenText™ Professional Performance Engineeringと変更されています)

OpenText™ Software Delivery PlatformにはLoadRunnerのSaaS版であるOpenText™ Core Performance Engineeringの機能があり、クラウド上のリソースを使ってテスト対象のサーバに多重度を上げてテストを行うことが出来ます。

OpenText™ Core Performance Engineering(旧製品名 : LoadRunner Cloud)

OpenText™ Core Performance Engineeringはクラウド上にコントローラおよびジェネレータを用意しており、作成した負荷テストスクリプトをアップロードしてテストを行うことが可能です。

大規模な負荷テストを実施したい場合多くのジェネレータが必要になる可能性がありますが、SaaSであればクラウドのリソースを使用することが出来るので、必要な時に必要な分のリソースを使って効率的なテストを実施することが出来ます。

図:OpenText™ Core Performance Engineering

OpenText™ Professional Performance Engineering(旧製品名 : LoadRunner Professional)

OpenText™ Professional Performance Engineering(旧製品名:LoadRunner Professional)は非常に広く使用されているオンプレミス型の負荷テストツールですが、そのスクリプトをSaaSのOpenText™ Core Performance Engineeringで使用することが出来ます。

図:OpenText™ Professional Performance Engineering

OpenText™ Core Performance Engineering上の負荷テスト実行

オンプレミスのOpenText™ Professional Performance Engineeringで作成した負荷テストスクリプトを、SaaSのOpenText™ Core Performance Engineeringのアセットとして登録し負荷テストとして設定および実行します。

SaaSにおける負荷テストシナリオの作成方法はオンプレミス型のOpenText™ Performance Engineeringと非常に似ており、スクリプト毎にユーザ数や継続時間、ランプアップ/ダウンなどの負荷テストの内容を設定する流れです。

図:負荷テストの作成

負荷を発生させるジェネレータは複数の国のデータセンターから選択可能であり、日本では東京(2拠点)と大阪から選択することが出来ます。

図:負荷配分の設定

JMeterスクリプトの活用

既存のJMeterスクリプトがある場合、OpenText™ Core Performance Engineeringにアップロードしてパフォーマンステストシナリオを設定することで、SaaSのリソースを活用して効率的に高負荷のテストを実行することが可能です。

普段JMeterでテストを実施していて、大規模な負荷テストが必要になった場合に環境の用意やセットアップが大変という場合にも、一時的にOpenText™ Core Performance Engineeringと合わせて使用することで簡単に環境を用意することが可能となります。

図:OpenText™ Core Performance EngineeringにおけるJMeterスクリプトの活用

ただ、JMeterのスクリプトを使用する際には以下の点に注意する必要があります。

①「Number of Thread」「Ramp up period」などの情報は移行されないため、OpenText™ Core Performance Engineering上で負荷テストシナリオの設定が必要です

②「Thread Group」を使用している場合、OpenText™ Core Performance Engineering上ではThread Group毎に別々のテストスクリプトとして認識されます。

①に関してはアップロード後にOpenText™ Core Performance Engineering上でRamp Upなどの設定を行うだけなので、テストをSaaS上から行うという意味では新たに条件を設定してテストのシナリオを調整することは自然な流れかと思います。

図:OpenText™ Core Performance EngineeringにおけるJMeterスクリプトの活用

②のThread Groupを使用している場合に関しては、スクリプトをアップロードした後にJMeterでスクリプトを修正して再度アップロードする場合に注意が必要となります。

「Thread Group」を使用している場合にはアップロード時に自動的に別のテストケースに分割されますので、アップロード後にJMeterで「Thread Group」を削除した場合にアップロードされたスクリプトとの整合をとる必要があります。OpenText™ Core Performance Engineering上にあるスクリプトは一旦削除して、新たに「Thread Group」の数を変更したスクリプトをアップロードするなどした方が良いかもしれません。

図:OpenText™ Core Performance EngineeringアップロードしたJMeterスクリプトのメンテナンス

今回のまとめ

OpenText™ Software Core Performance EngineeringはSaaS型の負荷テストサービスであり、クラウド上のリソースを使用することが出来るため、大量の負荷を発生させるのに必要なジェネレータを必要な分だけ効率よく使用することが可能です。

オンプレミス版OpenText™ Professional Performance Engineeringで作成した負荷テストスクリプトをそのまま使用出来るため、既存のテスト資産やスクリプト作成のスキルを無駄にすることなく、効率的なテスト作成とメンテナンスを実現することが出来ます。

OpenText Japan

OpenText™ は、AIの時代に企業がデータを安全に管理し、正しく活用できるように支援する、情報管理ソリューションのグローバルリーダーです。私たちの技術は、データに意味や背景(コンテキスト)を加えることで価値ある情報へと変え、AI の学習に必要なナレッジベースを作り出します。詳しくは www.opentext.com をご覧ください。