ロードテストの種類とシミュレーション

なぜロードテストとパフォーマンステストが重要なのか

今日の高速なデジタル世界において、企業にとってオンラインプレゼンスは不可欠であり、ウェブサイトやウェブアプリケーションのパフォーマンスと信頼性を確保することは絶対条件です。読み込みが遅い、または応答しない非効率なウェブページは、直接的に収益に影響を与えます。潜在的な災害を避けるためには、適切な負荷シミュレーションを用いたパフォーマンステストを実施することが重要です。正しく実行されない場合、ユーザーはフラストレーションを感じ、問題が後で解決されたとしてもタスクを放棄して代替手段を探す可能性が高くなります。このエンゲージメントの損失は収益に影響を与えるだけでなく、消費者の信頼やブランドの健全性を損なうことになり、これはビジネスにとってさらに深刻な損害となります。解決の遅れは消費者との信頼再構築を困難にし、製品、チーム、組織への投資からのリターンの実現を遅らせます。したがって、パフォーマンステストとモニタリングはソフトウェアおよびアプリケーション開発において欠かせない要素となっています。

負荷シミュレーションパフォーマンステストはこのプロセスで重要な役割を果たし、組織が様々な状況下でシステムのスケーラビリティと応答性を測定することを可能にします。利用可能な多くの負荷シミュレーション手法の中で、パフォーマンステストプラットフォームはHTTP/S、ヘッドレス、リアルブラウザベースのテストなど幅広い負荷シミュレーション方法を提供しています。本記事ではそれぞれの主な側面を概説し、その後、適切なシミュレーション手法を選択する際に役立つ比較マトリックスを紹介します。

さまざまな種類の負荷・パフォーマンステスト

ロードテスト: ロードテストとは、予想される負荷をシステムにかけて、その応答を評価するテストです。主な目的は、システムが通常およびピーク時の負荷条件下でどのように動作するかを判断することです。負荷を徐々に増加させることで、応答時間の遅延やリソース制限のようなパフォーマンスの瓶頸を特定できます。

ストレステスト: ストレステストはロードテストを超え、システムの限界およびそれ以上を押し広げます。目的はシステムが故障する限界点や閾値を特定することです。テスターは非常に高い負荷や予期しないシナリオを適用し、システムが極端な状況をどのように処理するかを観察します。ストレステストは脆弱性、弱点、潜在的な故障点を明らかにします。

ソークテスト: ソークテスト（耐久テストとも呼ばれる）は、持続的な負荷の下で長期間にわたるシステムの安定性を評価します。他のテストが即時のパフォーマンス指標に焦点を当てるのに対し、ソークテストは長期的なパフォーマンス、リソースのリーク、メモリ問題を評価します。このタイプのテストはミッションクリティカルなシステムに特に重要で、長時間にわたって最適な性能を維持できることを保証します。

スパイクテスト: スパイクテストはトラフィック量の急激な増減に対するシステムの応答を評価します。急激な負荷の増減を伴うテストで、フラッシュセールやバイラルコンテンツのような実際のシナリオをシミュレートします。スパイクテストはシステムが突発的なトラフィックの急増に対応し、ダウンタイムやクラッシュなしにスケールできるかを判断するのに役立ちます。

ボリュームテスト: ボリュームテストは大量のデータを扱う際のシステムのパフォーマンスを評価します。大量のデータセット、トランザクション、ユーザーインタラクションを処理してもパフォーマンスや安定性が損なわれないかを調べます。データの保存、取得、処理の管理方法を分析することで、データ量の増加に伴うスケーラビリティと効率性を保証します。

コンカレンシーテスト: コンカレンシーテストは複数の同時ユーザーやトランザクションを処理する際のシステムの挙動を評価します。コンカレンシー制御機構、データベースロック戦略、リソース配分を評価し、衝突を防ぎデータ整合性を確保します。複数同時アクセスシナリオをシミュレートすることで、並行処理やリソース競合に関連するボトルネックを特定できます。

スケーラビリティテスト: スケーラビリティテストはリソースを追加または水平スケールさせることによって増大する負荷を処理できるシステムの能力を評価します。応答時間、スループット、リソース利用率といったパフォーマンス指標がシステムのスケールに応じてどのように変化するかを分析します。スケーラビリティテストはインフラのアップグレード、リソース配分、キャパシティプランニングの意思決定を支援します。

HTTPベースの負荷シミュレーションの説明

HTTPベースの負荷シミュレーション（プロトコルレベルテストとも呼ばれる）は、システムとのユーザーインタラクションをHTTPリクエストを生成してシミュレートします。この手法は、ウェブサーバー、API、バックエンドインフラのパフォーマンスを評価するために、ウェブ取引で使用される通信プロトコルを直接エミュレートすることに焦点を当てています。

デジタル時代の初期には、HTTPベースのテストが広く支持されましたが、Web 2.0アプリケーションで使われる高度なウェブクライアント技術の登場により、この方法は時代遅れとなりました。同様に、JMeterのような従来のパフォーマンステストツールも関連性を失っています。モダンアプリケーションはクライアントサイドスクリプトを多用しますが、HTTPベースのテストではこれらのスクリプトを考慮しないため、正確なパフォーマンス測定には不十分です。さらに、クライアント側で生成されるセッションIDが無いため、複雑なユースケースのプロトコルレベルでのシミュレーションが制限されます。

HTTPベースのテストは、負荷注入マシンへのオーバーヘッドが少なく、最大800の同時セッションを処理できますが、複雑なプロトコルベースのシナリオには苦戦します。パフォーマンスエンジニアは、CookieやセッションIDのような動的パラメータの管理に取り組む必要があり、テスト実装を複雑にしています。さらに、システム更新によるウェブフォーム名の変更はHTTPベースのスクリプトの失敗につながりやすいです。

サンプルスクリプト

以下のサンプルスクリプトは非常に技術的な性質を示しています。アプリケーションの技術的属性が変わると、スクリプト全体を書き直さなければならず、それは言うほど簡単ではありません。

//sample protocol level script
transaction TMain
var
hContext: number;
begin
WebPageUrl(“https://lab3/st/”, “Greetings”);
WebPageStoreContext(hContext);
WebPageLink(“Join the experience!”, ” – New Visitor”);
WebPageSubmit(“Continue”, CONTINUE001, “Main menu”);
WebPageLink(“Products”, “ShopIt – Products”);
WebPageLink(NULL, “ShopIt – Product”, 3);
WebPageSubmit(“Search”, SEARCH001, ” – Search”, 0, NULL, hContext);
end TMain;

dclform
CONTINUE001:
“name” := “jack”,
“New-Name-Button” := “Continue”;

SEARCH001:
“search” := “boot”;

プロトコルレベルスクリプトは継続的インテグレーション環境でのコンポーネントレベルテストに適しており、負荷注入マシンに与える負荷が小さいため、ストレステストに最適な設定です。

利点

軽量かつ効率的: HTTPベースの負荷テストはネットワーク通信のみに注目し、ブラウザベースの方法と比べてリソース消費が少ないです。

スケーラビリティテスト: サーバーが多量のHTTPリクエストを処理する能力を、ウェブページレンダリングの負荷なしに評価できます。

ヘッドレスブラウザベースの負荷シミュレーション

ヘッドレスブラウザベースの負荷シミュレーションは、フロントエンドレベルでユーザーインタラクションをエミュレートするより包括的なアプローチを取ります。HTTPベースのテストがバックエンドインフラに焦点を当てるのとは異なり、この方法はJavaScriptコードのレンダリングと実行を通じて実際のユーザーのウェブアプリケーションへの操作を再現します。

Web 2.0の進化とともに、リッチなブラウザアプリケーションのテストは大きな課題に直面しました。従来のテストではクライアント側のロジックをシミュレートできなかったためです。そこでHtmlUnit、PhantomJS、SlimerJSのようなヘッドレスブラウザが登場し、重いGUIなしでリアルブラウザの利点を提供しました。

これらのヘッドレスブラウザは今やテスト自動化やパフォーマンステストで広く使われています。自社開発する企業もありますが、ブラウザのアップデートに追随するためにはコミュニティサポートの活用が容易です。ヘッドレスブラウザの利用にはコストが伴い、典型的なサーバーは最大8同時セッションを処理できます。

テストスクリプトの作成とカスタマイズはそれほど難しくなく、基本的なコーディングスキルがあれば対応可能です。ただし、すべてのヘッドレスブラウザがビジュアルリプレイ機能を持っているわけではなく、視覚的なフィードバックなしではデバッグが難しい場合があります。

サンプルスクリプト

以下のサンプルスクリプトは簡単なPOSTリクエストを実行します。この種のテストスクリプトをカスタマイズするにはJavaのプログラミングスキルが必要です。

//sample phantomjs script
“use strict”;
var page = require(‘webpage’).create(),
server = ‘https://posttestserver.com/post.php?dump’,
data = ‘universe=expanding&answer=42’;

page.open(server, ‘post’, data, function (status) {
if (status !== ‘success’) {
console.log(‘Unable to post!’);
} else {
console.log(page.content);
}

phantom.exit();
});

これを踏まえると、プログラミングスキルがあり、視覚的なスクリプトリプレイが可能なソリューションを使っているなら、ヘッドレスブラウザが最良の選択肢です。

利点

リアリスティックなシミュレーション: ヘッドレスブラウザベースのテストはユーザーインタラクションをより正確に再現し、フロントエンドのパフォーマンスボトルネックやユーザー体験の問題を特定できます。

エンドツーエンドテスト: フロントエンドとバックエンドの両方のコンポーネントを包含し、ユーザー視点からシステム性能の全体像を提供します。

リアルブラウザベースの負荷シミュレーション

リアルブラウザベースの負荷シミュレーションはパフォーマンステストにおけるリアリティの頂点であり、実際のウェブブラウザを用いてユーザーインタラクションをシミュレートします。この手法はユーザーの行動やフロントエンドパフォーマンスを比類なく正確に再現します。

Web 2.0アプリケーションはJavaScript、Flash、AJAX、CSSなどさまざまな技術を利用しています。エンドツーエンドの応答時間を正確に測定するには完全なブラウザが必要です。リアルブラウザベースのパフォーマンステストはサイトの機能と速度がユーザー期待に沿っていることを保証します。

このテストでは画像、JavaScript、CSSなどの読み込み時間をキャプチャし、ウォーターフォールチャートでコンポーネントごとの読み込み時間を可視化します。リアルブラウザベースのテストはヘッドレスブラウザよりも多少多くのリソースを必要としますが、よりリアルなシミュレーションを提供します。そのため、テスト手法としては推奨されています。ユーザーアクションが正確に反映されるため、テストスクリプトの作成やメンテナンスも容易ですし、ビジュアルリプレイによるデバッグも助けとなります。

サンプルスクリプト

以下のサンプルスクリプトはブラウザがURLを開き、ユーザーのパスワードを入力し、ログインボタンをクリックします。

//sample real browser-based script
transaction TMain
begin
BrowserStart(BROWSER_MODE_DEFAULT, 800, 600);

//ログインサイトに移動
BrowserNavigate(“https://demo.com/TestSite/LoginForm.html”);
//セキュアサイトの認証を設定
BrowserSetText(“//INPUT[@name=’user’]”, “User1”);
BrowserSetPassword(“//INPUT[@name=’pwd’]”, “Password1”);
//ログイン
BrowserClick(“//INPUT[@value=’Login’]”, BUTTON_Left);
end TMain;

結局、リアルブラウザシミュレーションは現実的なエンドツーエンドロードテストに有用ですが、負荷注入サーバーへの負荷が非常に高いためストレステストには向きません。

利点

本物のユーザーシミュレーション: リアルブラウザベースのテストは実際のユーザー行動を忠実に模倣し、異なるブラウザやデバイスにおけるフロントエンドのパフォーマンスやユーザー体験に関する洞察を提供します。

包括的テスト: 実際のブラウザを利用することで、ブラウザ互換性の問題、レンダリングの違い、クライアント側スクリプトの実行に関連する問題を明らかにできます。

ロードテストの種類比較

プロトコル、ヘッドレス、リアルブラウザベースのユーザーシミュレーションそれぞれに適した理由と状況があります。以下のマトリックスが適切なテスト手法選択の参考になります。

この記事がロードシミュレーションとパフォーマンステストの種類理解に役立ったことを願っています！ロードおよびストレステストの実行に関するご質問やLoadViewソリューションについて興味がある場合は、ぜひ当社チームまでお問い合わせいただくか、無料トライアルにご登録ください。LoadViewの無料トライアルにご登録いただくと、すぐに始められる補完的なロードテストを差し上げます。