JP7312208B2 - ストレステスト方法及び装置、電子機器、コンピュータ可読記憶媒体並びにコンピュータプログラム - Google Patents

Description

本出願の実施例はコンピュータ技術分野に関し、具体的にクラウドコンピューティング技術分野に関し、特にストレステスト方法及び装置、電子機器、コンピュータ可読記憶媒体並びにコンピュータプログラムに関する。

インターネット産業の発展に伴い、製品プロモーション、新製品の発売、その他のイベントがますます多くなり、次第に登場し、これらのイベントの主な特徴は、トラフィックのピークをもたらし、バックエンドサービスの容量に対するアタックが激しくなり、クラウド時代の背景において、大部分の企業の基礎となるアーキテクチャはいずれもクラウドを基にして構築され、そのため、クラウド環境において、如何に容量解析と評価を合理的に行うかは多くのインターネット企業が直面している１つの重要な課題である。

ストレステストは、システムにストレスを加えることにより、システムの最大負荷能力を測定するための方法であり、容量解析と評価を行う際に、効果的なストレステストに依存し、ストレステスト技術の正確性とテスト効率はシステムの容量解析及び評価に直接的な影響を与える。

ストレステスト方法及び装置、電子機器、コンピュータ可読記憶媒体並びにコンピュータプログラムを提供する。

第１態様において、少なくとも１つのテストトラフィックを含む事前設定されたストレス・テスト・コンフィグレーション情報に基づいて、クラウドサービスにおけるサービスシステムにストレス・テスト・リクエストを発送することと、サービスシステムによるストレス・テスト・リクエストに応答した性能監視データを取得することと、事前設定されたストレス・テスト・コンフィグレーション情報と性能監視データとに基づいて、サービスシステムのサービスリクエスト容量情報を確定することと、を備えるストレステスト方法を提供する。

第２態様において、少なくとも１つのテストトラフィックを含む事前設定されたストレス・テスト・コンフィグレーション情報に基づいて、クラウドサービスにおけるサービスシステムにストレス・テスト・リクエストを発送するように構成されるリクエストユニットと、サービスシステムによるストレス・テスト・リクエストに応答した性能監視データを取得するように構成される取得ユニットと、事前設定されたストレス・テスト・コンフィグレーション情報と性能監視データとに基づいて、サービスシステムのサービスリクエスト容量情報を確定するように構成される確定ユニットと、を備えるストレステスト装置を提供する。

第３態様において、少なくとも１つのプロセッサと、少なくとも１つのプロセッサと通信可能に接続されるメモリとを備え、メモリに、少なくとも１つのプロセッサにより実行可能な指令が格納され、指令は少なくとも１つのプロセッサにより実行されると、少なくとも１つのプロセッサに本出願の第１態様のいずれかの実施形態に記載の方法を実行させる、電子機器を提供する。

第４態様において、コンピュータ指令が格納される非一時的なコンピュータ可読記憶媒体であって、コンピュータ指令は、本出願の第１態様のいずれかの実施形態に記載の方法をコンピュータに実行させる非一時的なコンピュータ可読記憶媒体を提供する。

第５態様において、プロセッサにより実行されると、本出願の第１態様のいずれかの実施形態に記載の方法を実現するコンピュータプログラムを提供する。

本出願の実施例により提供されるストレステスト方法及び装置は、まず、事前設定されたストレス・テスト・コンフィグレーション情報に基づいてクラウドサービスにおけるサービスシステムに対してストレス・テスト・リクエストを発送し、次に、サービスシステムがストレス・テスト・リクエストの性能監視データに応答し、最後に、事前設定されたストレス・テスト・コンフィグレーション情報と性能監視データとに基づいて、サービスシステムのサービスリクエスト容量情報を確定する。そのため、本出願は事前設定されたストレス・テスト・コンフィグレーション情報に基づいてサービスシステムにストレス・テスト・リクエストを発送することで、クラウドサービスにおけるサービスシステムに予め要求したストレステストを発送でき、事前設定されたストレス・テスト・コンフィグレーション情報と性能監視データとに基づいて、サービスシステムのサービスリクエスト容量情報を確定し、テスト・コンフィグレーションと性能監視データの一致性を保持する上で、クラウドサービスにおけるサービスシステムに対してストレステストを便利かつ効率的に行うことができ、且つ、低コストで正確なリクエスト容量評価結果を取得できる。

この部分に記載された内容は、本出願の実施例の肝要又は重要な特徴を標識するものではなく、本出願の範囲を限定するものでもないことを理解すべきである。本出願のほかの特徴は以下の説明を通して容易に理解される。

図面は本解決手段をさらによく理解させるためのものであり、本出願を限定するものではない。
図１は本出願のストレステスト方法による１つの実施例のフローチャートである。 図２は本出願の実施例による適用可能な例示的なシステムアーキテクチャを示す図である。 図３は本出願のストレステスト方法によるもう１つの実施例のフローチャートである。 図４は本出願のストレステスト方法による第３の実施例のフローチャートである。 図５は本出願のストレステスト装置の実施例による構造概略図である。 図６は本出願の実施例のストレステスト方法を実現するための電子機器のブロック図である。

以下は図面を参照して本出願の例示的な実施形態を説明し、ここでは理解を助けるため、本出願の実施形態の様々な詳細が記載されるが、これらは単なる例示であるに過ぎない。従って、本出願の範囲および要旨を逸脱しない限り、当業者が本明細書の実施形態に対して様々な変更と修正を行うことができることを理解すべきである。なお、以下の説明では、明確化および簡略化のため、公知の機能および構成については説明を省略する。

図１は本出願のストレステスト方法による１つの実施例のフロー１００を示す。上記ストレステスト方法は以下のステップを含む。

ステップ１０１、事前設定されたストレス・テスト・コンフィグレーション情報に基づいてクラウドサービスにおけるサービスシステムに対してストレス・テスト・リクエストを発送する。

本実施例において、事前設定されたストレス・テスト・コンフィグレーション情報はストレステストの肝要なコンフィグレーション情報の集合であり、少なくとも１つのテストトラフィックを含む。ストレス・テスト・コンフィグレーション情報はストレステストオブジェクト、ストレス受けオブジェクト、トラフィックサイズ、組成比、トラフィック内容などのコンフィグレーション情報をさらに含むことができる。事前設定されたストレス・テスト・コンフィグレーション情報のほか、ストレス・テスト・リクエストはさらにクラウドサービスにおけるサービスシステムの識別子などを含んでもよい。サービスシステムの識別子を用いてテスト対象であるサービスシステムを見つけることができ、具体的に、サービスシステムの識別子はサービスシステムのエントランスドメイン又はＩＰアドレスであってもよい。

クラウドサービスはインターネットの関連サービスに基づく増加、利用及びインタラクションモードであり、インターネットを介した動的で、容易に拡張可能で、しばしば仮想化されたリソースの提供が一般に含まれる。クラウドサービスとは、オンデマンドで簡単に拡張可能な方法で、ネットワークを介して要求されたサービスを取得することを指す。クラウドサービスは、対応するサービスシステムを構築するために、企業が必要とするソフトウェア、ハードウェア、および/またはデータをクラウドネットワークに配置することができる。クラウドサービスプロバイダは、サーバ、仮想マシン、ネットワークセグメントなどのサービスリソースを企業に提供する。

現在では、一般的なクラウドサービスはパブリッククラウド（Ｐｕｂｌｉｃ Ｃｌｏｕｄ）とプライベートクラウド（Ｐｒｉｖａｔｅ Ｃｌｏｕｄ）の二種類がある。パブリッククラウドはもっとも基礎的なサービスであり、複数のクライアントは１つのサービスプロバイダのシステムリソースを共有でき、機器をセットアップしたり、管理者を配置したりすることなく、プロフェッショナルＩＴサービスを利用できる。

プライベートクラウドは１つのクライアントが単一のクライアントによって使用されるように構築されており、データ、安全性およびサービス品質に対するもっとも効果的な制御を提供する。該クライアントはインフラストラクチャを持ち、且つこのインフラストラクチャ上でアプリケーションをデプロイする方式を制御できる。プライベートクラウドはクライアントのデータセンタのファイアウォール内にデプロイすることが可能であり、それらを１つの安全なコロケーションプラットフォームにもデプロイ可能であり、プライベートクラウドのコア属性は独自のリソースである。

本実施例において、サービスシステムは、クラウドサービスのリソースを共有し、且つ１つのサービス機能（例えば、支払い、記憶、権限）を実現できるシステムであり、図２に示されるように、サービスシステムはクライアントサービスシステムであってもよい。クライアントサービスシステムはエントランスモジュール、データベース及び複数のサービスモジュールＡ、Ｂ、Ｃを備え、本出願のストレステスト方法を通してサービスシステムの容量評価を実現できる。

サービスシステムのサービスリクエスト容量情報は、サービスシステムが負担できるサービスリクエスト量を示す情報であり、最大サービスリクエスト速度、最大サービスリクエスト量、各事前設定されたタイプのリクエストの最大リクエスト量又はリクエスト速度のうちの少なくとも１つを含むが、それらに限定されない。

具体的に、ストレステスト方法が実行される実行主体は、クラウドサービスにおけるサービスシステムにストレス・テスト・リクエストを発送する前、まず、事前設定されたストレス・テスト・コンフィグレーション情報を取得できる。具体的に、ユーザ端末から取得するか、メモリから読み取るなどの方式により、事前設定されたストレス・テスト・コンフィグレーション情報を取得することができる。事前設定されたストレス・テスト・コンフィグレーション情報は、本体が事前に構成した情報であってもよく、実行主体が確定した変更可能な情報であってもよく、繰り返して利用できる。

本実施例の一部のオプション的な実施形態において、ストレス・テスト・コンフィグレーション情報を取得することは、サービスシステムにおけるユーザが設定した事前設定されたストレス・テスト・コンフィグレーション情報を取得することを含む。実行主体は、ユーザ端末を通して、ユーザが設定した事前設定されたストレス・テスト・コンフィグレーション情報を取得でき、ストレス・テスト・コンフィグレーション情報を取得する正確性と即時性を高め、さらに、図２に示されるストレステストプラットフォームを設置でき、それにより、サービスシステムのユーザが該ストレステストプラットフォームにアクセスして、サービスシステムに対応する事前設定されたストレス・テスト・コンフィグレーション情報を設定することができ、ユーザが事前設定されたストレス・テスト・コンフィグレーション情報をストレステストプラットフォーム又はユーザ端末にすでに設定した場合、即ち、ストレステストプラットフォーム又はユーザ端末に履歴コンフィグレーション情報がある場合、上記実行主体は、履歴コンフィグレーション情報を現在のストレス・テスト・リクエストに対応するストレス・テスト・コンフィグレーション情報として取得でき、ストレス・テスト・コンフィグレーション情報の再利用度を高める。

上記事前設定されたストレス・テスト・コンフィグレーション情報に基づいてテスト対象のサービスシステムにストレス・テスト・リクエストを発送し、具体的には、設定された少なくとも１つのテストトラフィックに基づいてユーザのアクセス操作を模擬し、アクセスリクエストをサービスシステムに発送し且つサービスシステムのフィードバックを待つことができる。

ステップ１０２、サービスシステムがストレス・テスト・リクエストに応答する性能監視データを取得する。

本実施例において、サービスシステムはストレス・テスト・リクエストに応答し、ストレス・テスト・リクエストの内容に基づいて、対応するデータ処理とフィードバック動作とを実行することができる。

性能監視データは、サービスシステムの性能を評価する監視データであり、該性能監視データは、ＣＰＵ使用率、メモリ使用率、読み取り／書き込み使用率、ＣＰＵ入出力トラフィック、リクエスト応答時間、エラーコードなどの少なくとも１つを含むが、それらに限定されない。性能監視データは、サービスシステムのフィードバック結果の正確性指標、フィードバック時間指標など、サービスシステム処理効率又は処理能力を示すデータ（例えば、ストレス・テスト・リクエストに対するサービスシステムの応答時間）、及び／又は、ストレステスト過程中に、サービスシステムのリソース使用状況を示す性能データ（ネットワークカードのＩ／Ｏデータなど）を含むことができる。

ステップ１０３、事前設定されたストレス・テスト・コンフィグレーション情報と性能監視データとに基づいて、サービスシステムのサービスリクエスト容量情報を確定する。

本実施例において、サービスシステムのサービスリクエスト容量情報は、サービスシステムが同時に負担できるか又はサポートできる最大リクエスト量を指し、即ちストレステスト容量であり、サービスリクエスト容量情報はサービスシステムに関連するストレステスト容量の情報であり、例えば、サービスリクエスト容量情報は、様々なリクエストタイプの最大リクエスト量情報を含み、さらに、サービスモジュールにおけるリソースボトルネックモジュール、サービスシステムのリソース拡張需要量などを含んでもよい。

性能監視データに基づいてサービスシステムの性能を評価でき、例えば、性能データの値が所属する区間を通してサービスシステムの性能レベルを確定することができる。その後、ストレス・テスト・コンフィグレーション情報における対応するテストトラフィックによって、対応するテストトラフィックにおけるサービスシステムの性能を確定できる。且つ、さらに、各テストトラフィックにおけるサービスシステムの性能によって、サービスシステムが、対応するテストトラフィックを負担できるか否かを確定し、或いは、サービスシステムが負担できる最大テストトラフィックを確定し、さらに、サービスシステムのサービスリクエスト容量情報を確定することができる。

異なる性能監視データについて、異なる解析方案を作成することができ、例えば、ストレステストプラットフォームがフィードバックしたテストコンフィグレーション情報に対応する性能監視データについて、所定時間内の性能監視データの平均値を取ることができ、平均値が平均値閾値範囲内にあることに応答して、サービスシステムのサービスリクエスト容量情報がストレス・テスト・リクエストを満たすと判定し、即ち、サービスシステムのリクエスト容量がストレス・テスト・リクエストの中のリクエスト量以上であると判定できる。

本出願の実施例に係るストレステスト方法は、まず、事前設定されたストレス・テスト・コンフィグレーション情報に基づいてクラウドサービスにおけるサービスシステムに対してストレス・テスト・リクエストを発送し、次に、サービスシステムがストレス・テスト・リクエストの性能監視データに応答し、最後に、事前設定されたストレス・テスト・コンフィグレーション情報と性能監視データとに基づいて、サービスシステムのサービスリクエスト容量情報を確定する。そのため、本出願の事前設定されたストレス・テスト・コンフィグレーション情報に基づいてサービスシステムにストレス・テスト・リクエストを発送することは、クラウドサービスにおけるサービスシステムに事前設定された所望のストレステストを発送でき、事前設定されたストレス・テスト・コンフィグレーション情報と性能監視データとに基づいて、サービスシステムのサービスリクエスト容量情報を確定し、テスト・コンフィグレーション情報と性能監視データの一致性を保持する上で、クラウドサービスにおけるサービスシステムに対してストレステストを便利かつ効率的に行うことができ、且つ、低コストで正確なリクエスト容量評価結果を取得できる。

図２は本出願の実施例が適用可能な例示的なシステムアーキテクチャ図を示し、該アーキテクチャ図において、インテリジェントな解析システムは上記実施例のストレステスト方法を実行できる実行主体とされてもよい。さらに、該システムアーキテクチャ図はストレステストプラットフォーム、クライアントサービスシステム及び監視システムを備える。ここで、ストレステストプラットフォームはストレス・テスト・コンフィグレーション情報の設定インターフェースを提供し、クライアントサービスシステムの稼働・保守作業員は、クラウドサービスにおけるクライアントサービスシステムに対してストレス・テスト・リクエストを発送するために、ストレステストプラットフォームを通してストレス・テスト・コンフィグレーション情報を設定することができる。クライアントサービスシステムはエントランスモジュール、データベース及び複数のサービスモジュールＡ、Ｂ、Ｃを備え、ストレステストプラットフォーム及び監視システムはエントランスモジュールを通してクライアントサービスシステムにおける各サービスモジュールＡ、Ｂ、Ｃにアクセスし、且つ、サービスモジュールＡ、Ｂはそれぞれの情報をデータベースに格納することができる。

さらに、ストレス・テスト・コンフィグレーション情報は少なくとも１つのテストトラフィックを備え、インテリジェント解析システムはさらにストレステストプラットフォームを通してクラウドサービスにおけるクライアントサービスシステムに対してストレス・テスト・リクエストを発送することができ、ストレステストプラットフォームはさらに、クライアントサービスシステムがストレス・テスト・リクエストに応答した動作データ（例えば、応答時間など）を記録し、且つインテリジェント解析システムに送信することができる。

さらに、図２に示される監視システムは、クラウドサービスにより提供される監視システムであってもよく、図２に示される監視システムは、クライアントサービスシステムがストレス・テスト・リクエストを受信した後、クライアントサービスシステムにおける様々なタイプのリソースの使用状況を監視することができる。監視システムはさらにクライアントサービスシステムのリソース使用状況をインテリジェント解析システムに送信することができる。

本出願のもう１つの実施例において、性能監視データは、サービスシステム及びサービスシステムに含まれる各サービスモジュールがストレス・テスト・リクエストを処理するリソース占有量を示すリソース類監視データを備えてもよい。さらに図３に示されるように、図３は本出願のストレステスト方法によるもう１つの実施例のフロー３００を示し、上記ストレステスト方法は以下のステップを含む。

ステップ３０１、各テストリクエストトラフィックに基づいてサービスシステムにストレス・テスト・リクエストをそれぞれ発送する。

具体的に、テストリクエストトラフィックはサービスシステムに発送されるトラフィックであり、それに対応してストレス・テスト・コンフィグレーション情報は該テストリクエストトラフィックのコンフィグレーション要求を含み、例えば、１つのテストリクエストトラフィックに対応するストレス・テスト・コンフィグレーション情報は、ストレステストオブジェクト、ストレステスト内容、トラフィックサイズ、トラフィック比率、応答時間の閾値、リターンエラー率の閾値を備える。ストレステストオブジェクトはクライアントサービスシステムなどであり、ストレステスト内容はテストリクエストトラフィックの内容などであり、トラフィックサイズは上限１０ｗｑｐｓなどであり、トラフィック比率は、ログイン類が５０％、ブラウズ類が３０％、支払い類が２０％を占めすなどを備えてもよい。

ステップ３０２、サービスシステムがストレス・テスト・リクエストに応答するリソース類監視データを取得する。

具体的には、リソース占有量のリソース類監視データは、サービスシステムの各サービスモジュールのＣＰＵ使用率、メモリ占有率のいずれかを含むことができるが、それらに限定されない。

ステップ３０３、サービスシステムの各サービス処理モジュールのリソース類監視データのテストリクエストトラフィックに伴う変化に基づいて、サービスシステムのリソースボトルネックモジュールを確定する。

具体的には、ストレス・テスト・コンフィグレーション情報に設定されたリクエストトラフィックの上限により限定された範囲内、ストレス・テスト・リクエストのリクエストトラフィックを次第に増大し、サービスシステムのリソース類監視データのトラフィックの増大に伴う変化を測定することができる。リソース類監視データは１つのトラフィック位置に急に変化する場合（急に大幅に上がるか或いは下がる）、サービスシステムはボトルネック状態に達したことを示す。この時、サービスシステムの異なるサービス処理モジュールのリソース類監視データのテストリクエストトラフィックに応じた変化をさらに解析し、さらにリソースボトルネックモジュールを確定することができる。Ｃａｎｎｉｋｉｎ Ｌａｗという法則に基づいてサービスシステムのリソースボトルネックモジュールを確定することができる。本実施例において、サービスシステムがサポートできる最大ストレス・テスト・リクエストトラフィックは、各サービスモジュールにおけるストレス・テスト・リクエストをサポートする能力が一番低いサービスモジュールにより決められ、該ストレス・テスト・リクエストをサポートする能力が一番低いサービスモジュールはリソースボトルネックモジュールである。

具体的に、各サービス処理モジュールのリソース類監視データのテストリクエストトラフィックによる変化を監視する過程中、サービスシステムにおいて、各サービス処理モジュールのリソース類監視データにおけるテストリクエストトラフィックの増加に伴って最初に急に変化（例えば、突然低下又は突然上昇）するサービス処理モジュールを、サービスシステムのリソースボトルネックモジュールとして確定することができる。

本実施例により提供されるストレステスト方法は、ストレステスト過程中に、各テストリクエストトラフィックに基づいてサービスシステムにストレス・テスト・リクエストをそれぞれ発送し、サービスシステムにおける各サービス処理モジュールのリソース類監視データのテストリクエストトラフィックに伴う変化に基づいて、サービスシステムのリソースボトルネックモジュールを確定することができ、リソースボトルネックモジュールを正確に特定でき、したがってさらに指向性を持つ評価結果を取得でき、サービスシステムのリソースコンフィグレーションに効果的なサポートを提供し、トラフィックピークになる時にサービスシステムがトラフィックによって衝撃されて正常に稼働できないことを効果的に回避できる。

本実施例の一部のオプション的な実施形態において、上記性能監視データは、サービスシステムの応答能力を示す動作類監視データを含む。

具体的に、動作類監視データは、平均応答時間、９０パーセンタイル応答時間、リターンエラー率のいずれかを含むが、それらに限定されない。

上記事前設定されたストレス・テスト・コンフィグレーション情報と性能監視データとに基づいて、サービスシステムのサービスリクエスト容量情報を確定することは、サービスシステムにおいて、ストレス・テスト・コンフィグレーション情報における最大テストリクエストトラフィックに対する動作類監視データが対応する閾値範囲を超えていないことを確定したことに応答して、サービスシステムのサービスリクエスト容量情報が最大テストリクエストトラフィックの要求を満たすと判定することを備える。

動作類監視データに対応する閾値範囲は、動作類監視データのタイプに基づいて設定されることができ、ここで、動作類監視データのタイプは時間、エラー許容率を備える。例示として、動作類監視データが時間タイプのデータである場合、動作類監視データの閾値は１０００ｍｓに設定されてもよく、動作類監視データはエラー許容率タイプのデータである場合、動作類監視データの閾値はリターンエラー率９０％に設定されてもよい。

さらに、最大テストリクエストトラフィックはストレス・テスト・コンフィグレーション情報に設定されたすべてのテストリクエストトラフィックの上限であり、サービスシステムのサービスリクエスト容量情報が最大テストリクエストトラフィックの要求を満たす場合、サービスシステムのサービスリクエスト容量情報はストレステスト要求を満たす容量情報である。該実施形態は動作類監視データに対して閾値の解析を行い、したがって、サービスシステムのサービスリクエスト容量を素早く評価できる。

本出願のもう１つの実施例において、性能監視データは、サービスシステムの応答能力を示す動作類監視データを備え、性能監視データは、サービスシステム及びサービスシステムに含まれる各サービスモジュールがストレス・テスト・リクエストを処理するリソース占有量を示すリソース類監視データをさらに備え、即ち、性能監視データは動作類監視データとリソース類監視データとを備える。さらに図４に示されるように、図４は本出願のストレステスト方法による第３の実施例のフロー４００を示し、上記ストレステスト方法は以下のステップを含む。

ステップ４０１、各テストリクエストトラフィックに基づいてサービスシステムにストレス・テスト・リクエストをそれぞれ発送する。

ステップ４０２、サービスシステムがストレス・テスト・リクエストに応答した動作類監視データとリソース類監視データとを取得する。

ステップ４０３、サービスシステムの、ストレス・テスト・コンフィグレーション情報における少なくとも１つのテストリクエストトラフィックに対する動作類監視データが対応する閾値範囲を超えたと判断されたことに応答して、サービスシステムの各サービス処理モジュールのリソース類監視データのテストリクエストトラフィックに伴う変化に基づいて、サービスシステムのリソースボトルネックモジュールを確定する。

本実施例において、サービスシステムにおいて、ストレス・テスト・コンフィグレーション情報における少なくとも１つのテストリクエストトラフィックに対する動作類監視データが対応する閾値範囲を超えた場合、サービスシステムのサービスリクエスト容量情報が最大テストリクエストトラフィックの要求を満たさないことがわかる。

本実施例において、まず、テストリクエストトラフィックの動作類監視データを評価し、少なくとも１つの動作類監視データが閾値範囲を超えた場合、リソース類監視データのテストリクエストトラフィックに伴う変化に基づいて、リソースボトルネックモジュールをさらに確定し、サービスシステムの漸進的な容量評価戦略を通して、ストレステスト結果の解析効率と解析結果の信頼性を高める。

図４に示される実施例の一部のオプション的な実施形態において、上記サービスシステムの各サービス処理モジュールのリソース類監視データのテストリクエストトラフィックに伴う変化に基づいて、サービスシステムのリソースボトルネックモジュールを確定するステップの後、さらにリソースボトルネックモジュールに対応するリソース類監視データに基づいて、サービスシステムのリソース拡張需要情報を推測することができる。

リソースボトルネックモジュールは、ストレステスト過程中に、サービスシステムにおけるリソースの突然変化が最初に現れたサービスモジュールである。各サービス処理モジュールのリソース類監視データのテストリクエストトラフィックに伴う変化を監視する過程中、ストレステスト方法が実行される実行主体は、サービスシステムにおいて、各サービス処理モジュールのリソース類監視データにリソースの突然変化（例えば、突然低下又は突然上昇）が発生したか否かを判断することにより、サービスシステムのリソースボトルネックモジュールを確定する。

さらに、リソースボトルネックモジュールが急に変化する勾配又は比率によって、サービスシステムのリソース拡張量を推測することができる。

このオプション的な実施形態において、性能監視データは、動作類監視データとリソース類監視データを含み、サービスシステムのリソースボトルネックモジュールを確定した後、リソースボトルネックモジュールに対応するリソース類監視データに基づいてサービスシステムのリソース拡張需要情報を推測し、サービスシステムの拡張に根拠を提供し、サービスシステムの拡張に効果的なサポートを提供する。

さらに図５に示されるように、上記各図に示される方法の実現として、本出願はストレステスト装置の１つの実施例を提供し、該装置の実施例は図１に示される方法の実施例に対応し、該装置は具体的に様々な電子機器に適用できる。

図５に示されるように、本実施例により提供されるストレステスト装置５００は、リクエストユニット５０１と、取得ユニット５０２と、確定ユニット５０３とを備える。ここで、上記リクエストユニット５０１は、事前設定されたストレス・テスト・コンフィグレーション情報に基づいてクラウドサービスにおけるサービスシステムに対してストレス・テスト・リクエストを発送するように構成され、ここで、ストレス・テスト・コンフィグレーション情報は少なくとも１つのテストトラフィックを含む。上記取得ユニット５０２は、サービスシステムがストレス・テスト・リクエストに応答した性能監視データを取得するように構成されてもよい。上記確定ユニット５０３は、事前設定されたストレス・テスト・コンフィグレーション情報と性能監視データとに基づいて、サービスシステムのサービスリクエスト容量情報を確定するように構成されてもよい。

本実施例において、ストレステスト装置５００において、リクエストユニット５０１、取得ユニット５０２、確定ユニット５０３の具体的な処理及びそれがもたらす技術的効果は、それぞれ図１に対応する実施例におけるステップ１０１、ステップ１０２およびステップ１０３の関連する説明を参照することができるため、ここで説明を省略する。

本実施例の一部のオプション的な実施形態において、上記ストレステスト装置５００はさらにコンフィグレーションユニット（図示されていない）を備える。ここで、コンフィグレーションユニットは、サービスシステムにおけるユーザが設定した事前設定されたストレス・テスト・コンフィグレーション情報を取得するように構成されてもよい。

本実施例の一部のオプション的な実施形態において、上記リクエストユニット５０１はさらに、各テストリクエストトラフィックに基づいてそれぞれサービスシステムにストレス・テスト・リクエストを発送するように構成され、上記性能監視データは、サービスシステム及びサービスシステムに含まれる各サービスモジュールがストレス・テスト・リクエストのリソース占有量を示すリソース類監視データを備え、上記確定ユニット５０３はリソースモジュール（図示されていない）を備える。上記リソースモジュールは、サービスシステムの各サービス処理モジュールのリソース類監視データのテストリクエストトラフィックに伴う変化に基づいて、サービスシステムのリソースボトルネックモジュールを確定するように構成されてもよい。

本実施例の一部のオプション的な実施形態において、上記性能監視データは、サービスシステムの応答能力を示す動作類監視データを含み、確定ユニット５０３は動作類モジュール（図示されていない）を備える。ここで、上記動作類モジュールは、サービスシステムにおいて、ストレス・テスト・コンフィグレーション情報における最大テストリクエストトラフィックに対する動作類監視データが対応する閾値範囲を超えていないと判断されたことに応答して、サービスシステムのサービスリクエスト容量情報が最大テストリクエストトラフィックの要求を満たすと判定するように構成されてもよい。

本実施例の一部のオプション的な実施形態において、上記リクエストユニット５０１は、各テストリクエストトラフィックに基づいてサービスシステムにストレス・テスト・リクエストをそれぞれ発送するようにさらに構成される。上記性能監視データは、サービスシステム及びサービスシステムに含まれる各サービスモジュールがストレス・テスト・リクエストを処理するリソース占有量を示すリソース類監視データをさらに備える。上記確定ユニット５０３はリソースモジュール（図示されていない）をさらに備える。上記リソースモジュールは、サービスシステムにおいて、ストレス・テスト・コンフィグレーション情報における少なくとも１つのテストリクエストトラフィックに対する動作類監視データが対応する閾値範囲を超えたと判断されたことに応答して、サービスシステムの各サービス処理モジュールのリソース類監視データのテストリクエストトラフィックに伴う変化に基づいて、サービスシステムのリソースボトルネックモジュールを確定するように構成されてもよい。

本実施例の一部のオプション的な実施形態において、上記確定ユニット５０３はさらに拡張モジュール（図示されていない）を備える。上記拡張モジュールは、リソースボトルネックモジュールに対応するリソース類監視データによってサービスシステムのリソース拡張需要情報を推測するように構成されてもよい。

本出願の実施例に係るストレステスト方法及び装置は、まず、事前設定されたストレス・テスト・コンフィグレーション情報に基づいてクラウドサービスにおけるサービスシステムに対してストレス・テスト・リクエストを発送し、次に、サービスシステムがストレス・テスト・リクエストの性能監視データに応答し、最後に、事前設定されたストレス・テスト・コンフィグレーション情報と性能監視データとに基づいて、サービスシステムのサービスリクエスト容量情報を確定する。そのため、本出願の事前設定されたストレス・テスト・コンフィグレーションに基づいてサービスシステムにストレス・テスト・リクエストを発送することは、クラウドサービスにおけるサービスシステムに事前設定されたストレステストを発送でき、事前設定されたストレス・テスト・コンフィグレーションと性能監視データとに基づいて、サービスシステムのサービスリクエスト容量情報を確定し、テスト・コンフィグレーションと性能監視データの一致性を保持する上で、クラウドサービスにおけるサービスシステムに対してストレステストを便利かつ効率的に行うことができ、且つ、低コストかつ正確なリクエスト容量評価結果を取得できる。

本出願の実施例により、本出願は電子機器と可読記憶媒体をさらに提供する。

図６に示されるように、本出願の実施例のストレステスト方法による電子機器のブロック図である。電子機器は、ラップトップコンピュータ、デスクトップコンピュータ、ワークステーション、パーソナルデジタルアシスタント、サーバ、ブレード型サーバ、メインフレームコンピュータおよびその他の適切なコンピュータ等の様々な形態のデジタルコンピュータを表す。また、電子機器は、個人デジタル処理、携帯電話、スマートフォン、ウェアラブル機器およびその他の類似するコンピューティングデバイス等の様々な形態のモバイルデバイスを表すことができる。なお、ここで示したコンポーネント、それらの接続関係、およびそれらの機能はあくまでも例示であり、ここで記述および／または要求した本出願の実施形態を限定することを意図するものではない。

図６に示すように、該電子機器は、１つまたは複数のプロセッサ６０１、メモリ６０２、および各コンポーネントを接続するためのインタフェース（高速インタフェースおよび低速インタフェースを含む）を含む。各コンポーネントは、互いに異なるバスで接続されており、共通のマザーボード上に実装されていてもよいし、必要に応じて他の方式で実装されていてもよい。プロセッサは、電子機器内で実行される指令を処理することができ、前記指令は、インタフェースに結合された表示装置等の外部入出力装置にグラフィカルユーザインタフェース（ＧＵＩ，Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）のグラフィック情報を表示するために、メモリ内またはメモリ上に格納される指令を含む。他の実施形態では、必要に応じて、複数のプロセッサおよび／または複数のバスを、複数のメモリとともに使用することができる。また、複数の電子機器が接続されていてもよく、各機器は、例えば、サーバアレイ、ブレードサーバ群またはマルチプロセッサシステムなど、一部の必要な動作を提供する。図６では、１つのプロセッサ６０１を例としている。

メモリ６０２は、本出願に係る非一時的なコンピュータ可読記憶媒体である。ここで、メモリには、少なくとも１つのプロセッサに本出願に係るストレステスト方法を実行させるための少なくとも１つのプロセッサにより実行される指令が格納される。本出願の非一時的なコンピュータ可読記憶媒体はコンピュータ指令を格納し、該コンピュータ指令は、コンピュータに本出願に係るストレステスト方法を実行させるために用いられる。

メモリ６０２は、非一時的なコンピュータ可読記憶媒体として、非一時的なソフトウェアプログラム、非一時的なコンピュータ実行可能なプログラム並びに、例えば本出願の実施形態におけるストレステスト方法に対応するプログラム指令／モジュール（例えば、図５に示されるリクエストユニット５０１、取得ユニット５０２および確定ユニット５０３）などのモジュールを格納することに用いられる。プロセッサ６０１は、メモリ６０２に格納された非一時的なコンピュータ実行可能なプログラム、指令及びモジュールを実行することにより、サーバの様々な機能アプリケーション及びデータ処理を実行し、上記方法の実施例におけるストレステスト方法を実現する。

メモリ６０２は、オペレーティングシステム、少なくとも１つの機能に必要なアプリケーションを格納できるプログラム記憶領域、およびストレステスト方法を実行する電子機器の使用に作成されるデータ等を格納できるデータ記憶領域を備えてもよい。また、メモリ６０２は高速ランダムアクセスメモリを含むことができ、また非一時的メモリ（例えば、少なくとも１つの磁気ディスク記憶装置、フラッシュメモリデバイスまたはその他の非一時的ソリッドステート記憶装置）を含み得る。いくつかの実施形態において、メモリ６０２は任意選択でプロセッサ６０１に対して遠隔に設置されたリモートメモリを含み、これらのリモートメモリはネットワークを介してストレステスト方法を実行する電子機器に接続することができる。上記ネットワークとしては、例えば、インターネット、企業イントラネット、ローカルエリアネットワーク、移動体通信網およびこれらの組み合わせなどが挙げられるが、それらに限定されない。

ストレステスト方法の電子機器はさらに入力装置６０３と出力装置６０４とを備えてもよい。プロセッサ６０１、メモリ６０２、入力装置６０３および出力装置６０４はバス６０５又はほかの方式で接続可能であり、図６はバス６０５で接続することを例示とする。

入力装置６０３は（例えばタッチパネル、キーパッド、マウス、トラックパッド、タッチパッド、ポインティングデバイス、１つまたは複数のマウスボタン、トラックボール、ジョイスティック等）は、入力された数字や文字情報を受信でき、ストレステスト方法を実行する電子機器のユーザ設定および機能制御に関するキー信号入力を生成することができる。出力装置６０４は表示装置、補助照明装置（例えば、ＬＥＤ）および触覚フィードバック装置（例えば、振動モータ）等を含むことができる。該表示装置は、液晶ディスプレイ（ＬＣＤ）、発光ダイオード（ＬＥＤ）ディスプレイおよびプラズマディスプレイを含むことができるが、これらに限定されない。いくつかの実施形態において、表示装置はタッチパネルであってもよい。

ここで記述するシステムおよび技術の各実施形態はデジタル電子回路システム、集積回路システム、特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ，ＡＳＩＣ）、コンピュータハードウェア、ファームウェア、ソフトウェア、および／またはそれらの組み合わせにおいて実装され得る。これらの各実施形態は、１つまたは複数のコンピュータプログラムに実装され、該１つまたは複数のコンピュータプログラムは少なくとも１つのプログラマブルプロセッサを含むプログラマブルシステムにおいて実行および／または解釈することができ、該プログラマブルプロセッサは専用または汎用プログラマブルプロセッサであってもよく、記憶システム、少なくとも１つの入力装置および少なくとも１つの出力装置からデータおよび指令を受信することができ、且つデータおよび指令を該記憶システム、該少なくとも１つの入力装置および該少なくとも１つの出力装置に伝送することを含み得る。

これらのコンピュータプログラムは、プログラム、ソフトウェア、ソフトウェアアプリケーションまたはコードとも呼ばれ、プログラマブルプロセッサの機械命令を含み、且つ高度プロセスおよび／またはオブジェクト指向のプログラミング言語、および／またはアセンブリ言語／機械語により実装され得る。ここで、「機械可読媒体」および「コンピュータ可読媒体」という用語は、機械指令および／またはデータをプログラマブルプロセッサに供給するための任意のコンピュータプログラム、機器、および／または装置（たとえば、磁気ディスク、光ディスク、メモリ、プログラマブルロジックデバイス（ＰＬＤ））を意味し、機械可読信号である機械命令を受信する機械可読媒体を含む。「機械可読信号」という用語は、機械命令および／またはデータをプログラマブルプロセッサに供給するための任意の信号を意味する。

ユーザとのやりとりを行うために、ここで記述するシステムと技術は、ユーザに情報を表示するための表示装置（例えば、陰極線管（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ，ＣＲＴ）またはＬＣＤ（液晶ディスプレイ）モニタ）と、キーボードおよびポインティングデバイス（例えば、マウスまたはトラックボール）とを備えるコンピュータ上で実装することができ、ユーザが該キーボードおよび該ポインティングデバイスを介してコンピュータに入力を提供できる。他の種類の装置もユーザとのやりとりを行うことに用いることができる。例えば、ユーザに提供されるフィードバックは、例えば、視覚フィードバック、聴覚フィードバック、または触覚フィードバックであるいかなる形態のセンシングフィードバックであってもよく、且つ音入力、音声入力若しくは触覚入力を含むいかなる形態でユーザからの入力を受信してもよい。

ここで記述したシステムおよび技術は、バックグラウンドコンポーネントを含む演算システム（例えば、データサーバ）に実施されてもよく、またはミドルウェアコンポーネントを含む演算システム（例えば、アプリケーションサーバ）に実施されてもよく、またはフロントエンドコンポーネントを含む演算システム（例えば、グラフィカルユーザインタフェースまたはウェブブラウザを有するユーザコンピュータ）に実施されてもよく、ユーザは該グラフィカルユーザインタフェースまたはウェブブラウザを介してここで記述したシステムおよび技術の実施形態とやりとりを行っていてもよく、またはこのようなバックグラウンドコンポーネント、ミドルウェアコンポーネントまたはフロントエンドコンポーネントのいずれかの組み合わせを含む演算システムに実施されてもよい。また、システムの各コンポーネントの間は、通信ネットワーク等の任意の形態または媒体を介してデジタルデータ通信により接続されていてもよい。通信ネットワークとしては、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）およびインターネットなどを含む。

コンピュータシステムは、クライアントとサーバとを含んでもよい。クライアントとサーバは、通常、互いに離れており、通信ネットワークを介してやりとりを行う。クライアントとサーバとの関係は、互いにクライアント－サーバの関係を有するコンピュータプログラムをそれぞれのコンピュータ上で動作することによって生成される。

なお、上述した様々な形態のフローを用いて、ステップを改めて並び替え、追加または削除を行うことができる。例えば、本出願に記載された各ステップは、本出願に開示された技術案の所望の結果が達成できる限り、並行して実行されてもよいし、順序に実行されてもよいし、異なる順番で実行されてもよい。本明細書はここで制限しない。

上記具体的な実施形態は、本出願の保護範囲を限定するものではない。設計要件および他の要因に従って、様々な修正、組み合わせ、副次的な組み合わせ、および置換を行うことができることを当業者は理解すべきである。本出願の趣旨および原理を逸脱せずに行われたあらゆる修正、均等置換および改善などは、いずれも本出願の保護範囲内に含まれるべきである。

Claims (15)

1. 事前設定されたストレス・テスト・コンフィグレーション情報に基づいて、クラウドサービスにおけるサービスシステムにストレス・テスト・リクエストを発送することであって、前記ストレス・テスト・コンフィグレーション情報は少なくとも１つのテストトラフィックを含む、ことと、
   前記サービスシステムが前記ストレス・テスト・リクエストに応答する性能監視データを取得することと、
   前記事前設定されたストレス・テスト・コンフィグレーション情報と前記性能監視データとに基づいて、前記サービスシステムのサービスリクエスト容量情報を確定することと、
   前記性能監視データに基づいて前記サービスシステムの拡張すべきリソース拡張需要情報を推定することと、を含み、
   前記サービスリクエスト容量情報は、前記サービスシステムが負担できるサービスリクエスト量を示すための情報である、ストレステスト方法。
2. 前記性能監視データは、前記サービスシステムの応答能力を示す動作類監視データを含み、
   前記の、前記事前設定されたストレス・テスト・コンフィグレーション情報と前記性能監視データとに基づいて、前記サービスシステムのサービスリクエスト容量情報を確定することは、
   前記サービスシステムの、前記ストレス・テスト・コンフィグレーション情報における最大テストリクエストトラフィックに対する動作類監視データが対応する閾値範囲を超えていないと判断されたことに応答して、前記サービスシステムのサービスリクエスト容量情報が前記最大テストリクエストトラフィックの要求を満たすと判定することを備える請求項１に記載の方法。
3. 前記の、前記事前設定されたストレス・テスト・コンフィグレーション情報に基づいてクラウドサービスにおけるサービスシステムにストレス・テスト・リクエストを発送することは、
   各テストリクエストトラフィックに基づいて前記サービスシステムにストレス・テスト・リクエストをそれぞれ発送することを含み、
   前記性能監視データは、前記サービスシステム及び前記サービスシステムに含まれた各サービスモジュールが前記ストレス・テスト・リクエストを処理するリソース占有量を示すリソース類監視データをさらに含み、
   前記の、前記事前設定されたストレス・テスト・コンフィグレーション情報と前記性能監視データとに基づいて、前記サービスシステムのサービスリクエスト容量情報を確定することは、
   前記サービスシステムの、前記ストレス・テスト・コンフィグレーション情報における少なくとも１つのテストリクエストトラフィックに対する動作類監視データが対応する閾値範囲を超えたと判断されたことに応答して、前記サービスシステムの各サービス処理モジュールの前記リソース類監視データの前記テストリクエストトラフィックに伴う変化に基づいて、前記サービスシステムのリソースボトルネックモジュールを確定することを含む請求項２に記載の方法。
4. 前記性能監視データに基づいて前記サービスシステムの拡張すべきリソース拡張需要情報を推定することは、
   前記リソースボトルネックモジュールに対応する前記リソース類監視データの急に変化する勾配又は比率によって前記サービスシステムのリソース拡張量を推定することをさらに含む請求項３に記載の方法。
5. 前記の、事前設定されたストレス・テスト・コンフィグレーション情報に基づいてクラウドサービスにおけるサービスシステムにストレス・テスト・リクエストを発送することは、
   各テストリクエストトラフィックに基づいて前記サービスシステムにストレス・テスト・リクエストをそれぞれ発送することを含み、
   前記性能監視データは、前記サービスシステム及び前記サービスシステムに含まれた各サービスモジュールが前記ストレス・テスト・リクエストを処理するリソース占有量を示すリソース類監視データを備え、
   前記の、前記事前設定されたストレス・テスト・コンフィグレーション情報と前記性能監視データとに基づいて、前記サービスシステムのサービスリクエスト容量情報を確定することは、
   前記サービスシステムの各サービス処理モジュールの前記リソース類監視データの前記テストリクエストトラフィックに伴う変化に基づいて、前記サービスシステムのリソースボトルネックモジュールを確定することを含む請求項１に記載の方法。
6. 前記サービスシステムのユーザが設定した前記事前設定されたストレス・テスト・コンフィグレーション情報を取得することをさらに含む請求項１に記載の方法。
7. 事前設定されたストレス・テスト・コンフィグレーション情報に基づいて、クラウドサービスにおけるサービスシステムにストレス・テスト・リクエストを発送するように構成されるリクエストユニットであって、前記ストレス・テスト・コンフィグレーション情報は少なくとも１つのテストトラフィックを含む、リクエストユニットと、
   前記サービスシステムが前記ストレス・テスト・リクエストに応答する性能監視データを取得するように構成される取得ユニットと、
   前記事前設定されたストレス・テスト・コンフィグレーション情報と前記性能監視データとに基づいて、前記サービスシステムのサービスリクエスト容量情報を確定するように構成される確定ユニットと、
   前記性能監視データに基づいて前記サービスシステムの拡張すべきリソース拡張需要情報を推定するように構成される拡張ユニットと、を備え、
   前記サービスリクエスト容量情報は、前記サービスシステムが負担できるサービスリクエスト量を示すための情報である、ストレステスト装置。
8. 前記性能監視データは、前記サービスシステムの応答能力を示す動作類監視データを備え、
   前記確定ユニットは、前記サービスシステムの、前記ストレス・テスト・コンフィグレーション情報における最大テストリクエストトラフィックに対する動作類監視データが、対応する閾値範囲を超えていないと判断されたことに応答して、前記サービスシステムのサービスリクエスト容量情報が前記最大テストリクエストトラフィックの要求を満たすと判定するように構成される動作モジュールを備える請求項７に記載の装置。
9. 前記リクエストユニットはさらに、各テストリクエストトラフィックに基づいて前記サービスシステムにストレス・テスト・リクエストをそれぞれ発送するように構成され、
   前記性能監視データは、前記サービスシステム及び前記サービスシステムに含まれた各サービスモジュールが前記ストレス・テスト・リクエストを処理するリソース占有量を示すリソース類監視データをさらに含み、
   前記確定ユニットは、前記サービスシステムの、前記ストレス・テスト・コンフィグレーション情報における少なくとも１つのテストリクエストトラフィックに対する動作類監視データが、対応する閾値範囲を超えたと判断されたことに応答して、前記サービスシステムの各サービス処理モジュールの前記リソース類監視データの前記テストリクエストトラフィックに伴う変化に基づいて、前記サービスシステムのリソースボトルネックモジュールを確定するように構成されるリソースモジュールをさらに備える請求項８に記載の装置。
10. 前記拡張ユニットは、
    前記リソースボトルネックモジュールに対応する前記リソース類監視データの急に変化する勾配又は比率によって前記サービスシステムのリソース拡張量を推定するようにさらに構成される請求項９に記載の装置。
11. 前記リクエストユニットはさらに、各テストリクエストトラフィックに基づいて前記サービスシステムにストレス・テスト・リクエストをそれぞれ発送するように構成され、
    前記性能監視データは、前記サービスシステム及び前記サービスシステムに含まれた各サービスモジュールが前記ストレス・テスト・リクエストを処理するリソース占有量を示すリソース類監視データを備え、
    前記確定ユニットは、前記サービスシステムの各サービス処理モジュールの前記リソース類監視データの前記テストリクエストトラフィックに伴う変化に基づいて、前記サービスシステムのリソースボトルネックモジュールを確定するように構成されるリソースモジュールを備える請求項７に記載の装置。
12. 前記サービスシステムにおけるユーザが設定した前記事前設定されたストレス・テスト・コンフィグレーション情報を取得するように構成される構成ユニットをさらに備える請求項７に記載の装置。
13. 少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサと通信可能に接続されるメモリとを備え、
    前記メモリに、前記少なくとも１つのプロセッサにより実行可能な指令が格納され、前記指令は前記少なくとも１つのプロセッサにより実行されると、前記少なくとも１つのプロセッサに請求項１～６のいずれか一項に記載の方法を実行させる、電子機器。
14. コンピュータ指令が格納される非一時的なコンピュータ可読記憶媒体であって、
    前記コンピュータ指令は、請求項１～６のいずれか一項に記載の方法をコンピュータに実行させることを特徴とする非一時的なコンピュータ可読記憶媒体。
15. プロセッサにより実行されると、請求項１～６のいずれか一項に記載の方法を実現する、コンピュータプログラム。