Comments
Description
Transcript
ボトルネック特定（RBI）手法 - 効率的な負荷テストの実行
ボトルネック特定（RBI）手法 - 効 率的な負荷テストの実行 Oracle ホワイト・ペーパー 2008 年 6 月 ボトルネック特定（RBI）手法 - 効 率的な負荷テストの実行 はじめに 重要な Web アプリケーションの稼働準備が整ったとします。適切なアプリケー ション・パフォーマンスの確保が重要ですが、時間は限られています。期限内に アプリケーションの最適なテストを実行するには、どうすればいいでしょうか。 最速ボトルネック特定（RBI）は、品質保証（QA）の専門家が Web アプリケーショ ンのパフォーマンスの制約を迅速に検出し、エンドユーザー・エクスペリエンス 全体のボトルネックを識別する最速ボト ルネック特定（RBI）は、組織による非常 にスケーラブルな Web アプリケーショ ンの作成を可能にする改良された負荷テス ト手法です。 へのそれらの制約の影響を判断できる新しいテスト手法です。あらゆるタイプの プラットフォームで長年にわたりテストして構築された RBI 手法では、負荷テス ト・サイクルが大幅に削減されます。また、さらに徹底的なテストを実行できま す。組織はこの方法を使用することにより、アプリケーション品質の改善、顧客 経験の向上、および新しいシステムをデプロイする際のコスト削減を実現できま す。 定義されたパフォーマンス・テスト パフォーマンス・テストは、"指定したパフォーマンス要件でシステムまたはコン ポーネントのコンプライアンスを評価するテスト"として定義できます。ただし、 すべてのアプリケーションには少なくとも 1 つのボトルネックがあり、わずかで はあるものの、一部のシステムは初期パフォーマンス要件さえ満たしていません。 この現実を反映するため、"アプリケーションのパフォーマンス要件の達成を妨げ るシステムとアプリケーションの問題（ボトルネック）を分離および識別するテ スト"として、パフォーマンス・テストを再定義します。 評価としてのテストから、問題を分離および解決する積極的な調査としてのテス トへ全体的にシフトすることで、RBI 手法が構築されました。全体のボトルネッ クを識別する最速ボトルネック特定（RBI）は、組織による非常にスケーラブルな Web アプリケーションの作成を可能にする改良されたテスト手法です。 ボトルネック特定（RBI）手法 - 効率的な負荷テストの実行 2 Oracle Corporation 発行「Rapid Bottleneck Identification. - A Better Way to do Load Testing」の翻訳版です。 ボトルネック、スループット、および同時実行性の理解 RBI 手法の詳細を調査する前に、ボトルネックとその検出箇所といった共通認識 を最初に確立し、スループットと同時実行性テストを区別する必要があります。 ボトルネック - 主要なパフォーマンスの阻害要素 データ・フローや処理速度の制限を定義するハードウェア、ソフトウェア、帯域 幅などのシステム・リソースによって、ボトルネックが発生します。Web アプリ ケーションでは、データ・スループットの量やアプリケーション接続数の制限に よって、ボトルネックがパフォーマンスおよびスケーラビリティに直接影響しま す。これらの問題は、ネットワーク・レイヤー、Web サーバー、アプリケーショ ン・サーバー、データベース・サーバーを含むあらゆるレベルのシステム・アー キテクチャで発生します。これまでの実際の顧客アプリケーションのテスト経験 では、図 1 に示されているようなコンポーネントでボトルネックが検出されてい ました。 Web アプリケーションでは、データ・ス ループットの量やアプリケーション接続 数の制限によって、ボトルネックがパ フォーマンスおよびスケーラビリティに 直接影響します。 図 1 システム・インフラストラクチャのボトルネックの推測された分散 テストの複雑さの複合的な影響 テスト方法の選択は、ボトルネックの分離および解消の難度に直接影響します。 しかしながら、多くの場合、本番アプリケーションの使用方法を正確にシミュレー トする複雑なシナリオからテスト手順が開始されます。これには、異なる方法で アプリケーションとやり取りするさまざまなタイプのユーザーをシミュレートす る複数の異なるトランザクションの実行が含まれる場合があります。これによっ て、大きなテスト障害が発生します。複数の異なるトランザクションを含む複雑 さが増しているシナリオをテストに用いることによりボトルネックが複数発生す るので、根本原因の識別が困難になるためです。 たとえば、図 2 のグラフは、約 2,000 の同時ユーザーでボトルネックが発生した 標準の電子商取引アプリケーションのテスト結果を示しています。このサンプル・ テストで使用されたシナリオでは、項目の参照、検索、および購入を決定する ショッピング・カートへの項目が追加されています。ここで示すのは、3 つのトラ ンザクショ ボトルネック特定（RBI）手法 - 効率的な負荷テストの実行 3 Oracle Corporation 発行「Rapid Bottleneck Identification. - A Better Way to do Load Testing」の翻訳版です。 ンのみのテスト結果ですが、あらゆるレベルのアプリケーション・アーキテクチャ とやり取りする各トランザクションでボトルネックが発生する可能性があります。 さらに複雑なことに、システムの問題によってもボトルネックが発生する可能性が あります。テストに変数が多く含まれるほど、問題の原因の特定が困難になります。 図 2 電子商取引アプリケーション・テストの結果グラフ 問題がどのアーキテクチャ層にも存在する可能性がある場合、特定の層に問題が ある可能性がほかの層よりも高くなるとは限りません。それでは、どこを参考に すればいいのでしょうか。 2 つの主要な問題：スループットと同時実行性 ほとんどのシステムおよびアプリケー ションのパフォーマンスの問題は、ス ループットの制限から発生します。 スループットとは、システムでサポートされるデータ・フローの量です。1 秒あ たりのヒット数、1 秒あたりのページ数、1 秒あたりのメガビット単位のデータで 測定されます。同時実行性とは、アプリケーションを使用している場合に同時に 接続しているユーザーの数です。これまでのほとんどのシステムおよびアプリケー ションのパフォーマンスの問題は、スループットの制限から発生します。ただし、 アプリケーションのパフォーマンスには、同時実行性の問題も重要です。また、 同時実行性の問題の分離がより困難になります。 スループットのテスト スループットのテストでは、システムへのユーザー接続数を可能な限り少なくし、 接続するユーザーが実行する処理量を最大化するようにします。これによって、 システムとアプリケーションが最大限に動作しすべての問題が明らかになります。 システム・レベルのスループット・テストでは、テスト用に Web サーバーおよび アプリケーション・サーバーに基本となるファイルを追加します。次に、各層で 最大のシステム・スループットとなるように、追加したテスト用ファイルを要求 する設定をし負荷テストを行います。 ボトルネック特定（RBI）手法 - 効率的な負荷テストの実行 4 Oracle Corporation 発行「Rapid Bottleneck Identification. - A Better Way to do Load Testing」の翻訳版です。 通常、テスト担当者は、帯域幅テストには大きいイメージ・ファイルを、ヒット 率テストには小さいテキスト・ファイルまたはイメージを、ページ率テストには "Hello World"ページなどの非常に簡単なアプリケーション・ページを使用します。 システムがこれらの簡単なテスト・ページの要求といった基本的なアプリケー ション・パフォーマンス要件を満たしていない場合は、設定のチューニング、ハー ドウェア容量の拡張、または割り当てられる帯域幅の拡張によってシステム自体 が改善されるまでテストを中断してください。 実際のアプリケーションのスループット・テストでは、さまざまな機能コンポー ネントの 1 秒あたりのページ数制限を確認するために、リクエスト間の遅延時間 を設定し、アプリケーションの主要なページとユーザー・トランザクションを実 行します。最低レベルのページ・スループットのページまたはトランザクション でもっともチューニングが必要となります。 同時実行性のテスト システムおよびアプリケーション・レベルの同時実行性は、セッションやソケッ ト接続によって制限されます。コードの欠陥と不適切なサーバー構成設定も同時 実行性を制限する可能性があります。同時実行性テストには、システムのユーザー 数の増加と現実的なページ遅延時間の使用が含まれます。各レベルの負荷テスト で有用なデータを収集するために少しずつユーザー数を増やします。スループッ ト・テストと同様に、テスト・アプリケーションの主要なページとユーザー・ト ランザクションのテストが重要です。 スループット・テストと同時実行性テストの違い ほとんどのボトルネックはスループット・ テストで検出できますが、アプリケーショ ンを正しくテストするにはスループット と同時実行性の両方をテストする必要が あります。 100 仮想ユーザーの負荷テスト（1 秒の思考遅延時間）の負荷は、1,000 仮想ユー ザーの負荷テスト（10 秒の思考遅延時間）の負荷とは異なります。図 3 に示され ているように、2 つのテストはスループットの観点で同じですが、同時実行性の 観点では大きく異なっています。 シナリオ 100 のユーザー （1 秒/ページ） スループット ページ/秒 = （100VU x 1 ページ/VU） ÷ 1 秒 = 100 1,000 のユーザー ページ/秒 = （10 秒/ページ） （1000VU x 1 ページ/VU）÷ 10 秒 = 100 同時実行性 ボトルネック・ ポイント 100 の接続 50 ページ/秒 1,000 の接続 25 ページ/秒 図 3 100 の仮想ユーザーの負荷テストと 1,000 の仮想ユーザーの負荷テストの比較 最初のシナリオのスループット・テストでは、アプリケーションのボトルネック が 50 ページ/秒で発生しました。2 つ目のシナリオの同じトランザクションの同時 実行性テストでは、アプリケーションのボトルネックが 25 ページ/秒で発生しま した。この 2 つのテストの違いは、システムのユーザー数とユーザーがページに 費やした時間だけです。さらに少ないユーザーと短いページ表示遅延のスループッ ト・テストでは、アプリケーションのスループットが向上しました。ただし、2 つ 目のテストのアプリケーションの同時実行性は制限されました。テスト担当者が スループットだけを確認した場合、本番アプリケーションが実行されるまで同時 実行性の問題は検出されなかったと思われます。 ボトルネック特定（RBI）手法 - 効率的な負荷テストの実行 5 Oracle Corporation 発行「Rapid Bottleneck Identification. - A Better Way to do Load Testing」の翻訳版です。 次のページの図 4 と図 5 は、各テストの結果を表し、スループットと同時実行性 のテストの重要性を示しています。 この 2 つのテストの違いは、システムの ユーザー数とユーザーがページに費やし た時間だけです。 図4 1 秒間ページを表示する 100 のユーザーのスループット・テストは、50 ページ/秒でボトルネック を示します 図5 10 秒間ページを表示する 1,000 のユーザーの同時実行性テストは、25 ページ/秒でボトルネック を示します ボトルネック特定（RBI）手法 - 効率的な負荷テストの実行 6 Oracle Corporation 発行「Rapid Bottleneck Identification. - A Better Way to do Load Testing」の翻訳版です。 RBI テスト方法 これまでパフォーマンス・テストの担当者は、アプリケーションのスケーラビリ ティの主要なメトリックとして同時ユーザーに注目していました。しかし、ほと んどのアプリケーションおよびシステム・レベルの問題がスループット・テスト で確認される場合、新しい方法が必要になります。 以下の 3 つの原則が RBI 手法の基礎になります。 • すべての Web アプリケーションにボトルネックがある • このようなボトルネックを一度に 1 つずつ検出できる • ボトルネックがもっとも発生しやすい場所にとくに注意する 同時実行性テストは重要ですが、RBI 手法では、もっとも一般的なボトルネック を排除するスループット・テストに最初に注目してから、アプリケーションの実 際のユーザー数を反映した負荷条件でパフォーマンスを評価する同時実行性テス トに注目します。また、問題が発生した場合は、ほかに考えられるすべての原因 を取り除くため、RBI テストでは、簡単なテストを試してから、複雑なテストを 構築します。スループット・テスト、同時実行性テストの順に注目してテスト・ プロセスの構造的な方法を使用すると、ボトルネックがすばやく分離されます。 これによって、効率性が向上し、コストが削減されます。 RBI テストの利点 RBI 手法によって、すべてのシステムとアプリケーションの問題（簡単な問題と 複雑な問題を含む）を体系的に検出する迅速かつ徹底的なテストを実行できます。 テスト時間の削減 最初にスループット・テストに注目すると、どれだけ時間を節約できるのでしょ うか。ページあたり平均 45 秒参照する 5,000 の同時ユーザーを処理するシステム の例を検討します。アプリケーションのスケーラビリティが 25 ページ/秒に制限 されるというボトルネックが存在する場合、同時実行性テストによって、1,125 ユーザー付近（ページあたり 45 秒で 25 ページ/秒）でこのボトルネックが検出さ れます。 通常の同時実行性テストは、データが偏らないように少しずつ時間をかけて実行 してください。たとえば、5 秒ごとに 1 人のユーザーの実行を検討します。この 階層型アプローチを使用してボトルネッ クを検出することによって、迅速に問題 を識別し、知識が不足しているコンポー ネントの問題を分離できます。 例では、テストを開始してから 5,625 秒、つまり 94 分後にボトルネックが発生し ます（5 秒ごとに 1 ユーザーで 1,125 ユーザー）。ただし、ボトルネックを検証す るため、ユーザーを追加してもスループットが向上しないポイントを超えるまで、 テストを続行する必要があります。スループット・テストは、60 秒未満でこの問 題を検出できます。 ボトルネック特定（RBI）手法 - 効率的な負荷テストの実行 7 Oracle Corporation 発行「Rapid Bottleneck Identification. - A Better Way to do Load Testing」の翻訳版です。 初期テストの複雑さの排除 パフォーマンス・テストの多くは、同時に多くのコンポーネントを網羅するよう に非常に複雑なシナリオで行われます。このため、ボトルネックが検出されにく くなります。RBI 手法では、アプリケーションが完成する前に、システム・レベ ルのテストから始めます。 品質保証の効率性の改善 RBI 手法では、もっとも簡単なテスト・ケースをテストしてから、複雑なテスト へと移行します。もっとも簡単なテスト・ケースが動作して次のレベルの複雑さ で失敗した場合、その複雑さにボトルネックがあります。階層型アプローチを使 用してボトルネックを検出することによって、迅速に問題を識別して、限られた 知識しか持ち合わせていないコンポーネントの問題も分離できるようになります。 知識の集約によるテストの有効性の向上 このモジュール型および繰返し型の手法では、ボトルネックが発生したときには 以前にテストしたすべてのコンポーネントが事前に検証されていることを示して います。たとえば、トップページを表示してもボトルネックが発生しないのに、 検索を実行するとパフォーマンスが大幅に低下した場合、ボトルネックの原因は 検索機能にあります。 一般的なシステムのボトルネックの RBI テスト パフォーマンス・テストは、アプリケーションを支える基本的なネットワーク・ インフラストラクチャの評価から開始します。システムで想定されるユーザー負 荷にこの基本システムが対応できない場合、その上で動作するアプリケーション が永続的に拡張できるように開発されていてもボトルネックは存在します。基本 的なシステム・レベルのテストを実行して、帯域幅、ヒット率、および接続数を 検証する必要があります。また、単純な"Hello World"ページなどの簡単なテスト・ アプリケーション・ページを実行する必要もあります。 アプリケーション システム・インフラストラクチャがエンドユーザーのもっとも基本的なニーズを 満たしていることを確認したあとで、アプリケーション自体に移動します。再度、 もっとも簡単なテスト・ケースから開始します。 システム・レベルの問題を検出しないで（またはそれらの問題を解決して）ここ までテストが進んだ場合、残りの問題はアプリケーション自体から発生します。 たとえば、 システム・レベルのテストで 100 ページ/秒を達成したのにも関わらず、 アプリケーションのあるページでは 10 ページ/秒でボトルネックが発生した場合、 そのページを表示する過程のどこかにオーバーヘッドがあります。 ボトルネック特定（RBI）手法 - 効率的な負荷テストの実行 8 Oracle Corporation 発行「Rapid Bottleneck Identification. - A Better Way to do Load Testing」の翻訳版です。 テスト・ページのパフォーマンスと実際 の本番アプリケーション・ページのパ フォーマンスの違いによって、調整によ るパフォーマンス向上の潜在的な利益が 決定されます。 このテストにより、2 つの貴重な情報が提供されます。1 つ目の情報は、システム 自体がボトルネックではなくアプリケーションのコードに原因があるということ。 2 つ目は、どのページの処理を調整すればパフォーマンスを向上できるのかとい うことです。システム・レベルのテスト・アプリケーション・ページのパフォー マンス（100 ページ/秒）と実際のアプリケーションのページのパフォーマンス（10 ページ/秒）の差により、チューニングによるパフォーマンス向上の最大量が決定 されます。同様に、トランザクションの各ページのパフォーマンスを分割し、全体 のトランザクションのパフォーマンスに対してそれぞれが貢献する割合を見積もり、 複数のページのトランザクションを評価できます。 実際のアプリケーション・ページでは"Hello World"テスト・ページよりも処理能 力が必要な場合が多いので、パフォーマンスの低下は確実に予測されます。ただ し、パフォーマンス低下の差が大きいほど、改善の必要性とチューニングによる 改善の余地が高くなります。テスト・ページと実際のアプリケーション・ページ のパフォーマンスの低下が大きくなく、アプリケーション・ユーザー・ベースの 必要性を満たすためのパフォーマンスが十分ではない場合、ハードウェア容量を 追加する必要があることにも注意してください。 ここまで、ページ応答時間の記述はありませんでした。応答時間は全体のパフォー マンスの主要なメトリックですが、ボトルネックが発生しない限り、ユーザー数 （1 人、1,000 人、100,000 人など）に関係なく応答時間は同じです。そのため、こ の手法の応答時間は、コードの最適化がもっとも必要なパフォーマンスの低い ページ（エラーや応答時間の遅延が発生しているページ）のボトルネックに到達 する指標（応答時間が急増した場合）または障害基準（応答時間が事前に定義し たしきい値を超えた場合）としてのみ役立ちます。 アプリケーション・ボトルネックの RBI テスト システム・レベルのテストと同様に、もっとも簡単なテスト・ケースのアプリケー ション・テストによって RBI 手法を開始し、次に複雑なテストを構築します。一 般的な電子商取引アプリケーションでは、最初にホームページをテストしてから、 実際のすべてのトランザクションがテストされるまで（最初に個別のテストを実 行してから、複雑なシナリオ使用パターンのテストを実行します）ページおよび ビジネス機能を追加します。新しく手順を追加すると、応答時間の遅延またはペー ジ・スループットの低下が発生する可能性があります。これによって、調査する 必要があるコードの分離が容易になります。 適切な同時実行性テスト・シナリオでは、 実際のユーザーがサイトで実行する処理 を正確に反映し、同じユーザー・ペース でそれらのアクションを再現する必要が あります。 必要に応じて各ビジネス機能およびトランザクションをテストして最適化したあ とで、完全なシナリオの同時実行性テストにトランザクションを組み込むことが できます。このような同時実行性テストでは、2 つの主要な構成要素に注目する 必要があります。1 つ目の構成要素は、同時実行性テストにおいて、実際のユー ザーがサイトで実行する処理（参照、検索、登録、ログイン、購入）を正確に反 映する必要があるという点です。2 つ目は、各手順の間の適切な"思考時間"を考慮 し、実際の訪問者と同じペースでそれらのトランザクションの手順を実行する必 要があるという点です。このデータは Web ロギング・ツールで収集できます。こ のツールを使用して、セッションの長さ、セッションごとに表示されるページ （ユーザー・ペースの決定）、および検出したページの割合（実際に使用されるビ ジネス機能の決定）を表示します。 ボトルネック特定（RBI）手法 - 効率的な負荷テストの実行 9 Oracle Corporation 発行「Rapid Bottleneck Identification. - A Better Way to do Load Testing」の翻訳版です。 実際のデータ（またはデプロイされていないアプリケーションの根拠のある仮定） に基づいてテストを設計したあとで、さまざまなユーザー負荷レベルで貴重な情 報を収集する方法によりテストを実行する必要があります。1,000 の同時ユーザー を処理するサイトの場合、一度にすべてのユーザーの処理を開始しないように注 意してください。代わりに少しずつ段階的にテストを実行し、定義された時間間 隔で 1,000 人に到達するまで 1 人以上のユーザーを追加します。これによって、 各レベルのユーザー負荷で全体のパフォーマンスを決定できます。また、パフォー マンスの問題が発生した場合、その問題を識別しやすくします。 結論 負荷テストの RBI 手法では、スループットでボトルネックが頻繁に発生する場所 に最初に注目することで、テストの効率性を高めます。スループットを徹底的に テストしたあとで、システムとアプリケーションの同時実行性をテストし、現実 的なユーザー負荷でパフォーマンスを評価できます。システム・テストからアプ リケーション・テストへの構造的な方法で、段階的かつ体系的に複雑なテスト・ ケースを構築していくことで、ボトルネックと関連する根本原因をすばやく分離 できます。 ここでは手法を中心に説明しましたが、自動テスト・ツールでこのプロセスの大 部分を自動化できるので注意してください。Oracle Application Testing Suite は、 Web およびサービス指向アーキテクチャ・アプリケーションの機能および負荷テ ストにおける Oracle Enterprise Manager の中心要素です。 H ボトルネック特定（RBI）手法 - 効率的な負荷テストの実行 10 Oracle Corporation 発行「Rapid Bottleneck Identification. - A Better Way to do Load Testing」の翻訳版です。 ボトルネック特定（RBI）手法 - 効率的な負荷テストの実行 2008 年 6 月 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合わせ窓口: 電話: +1.650.506.7000 ファクシミリ: +1.650.506.7200 www.oracle.com Copyright © 2007, 2008, Oracle and/or its affiliates.All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容は 予告なく変更されることがあります。 本文書は一切間違いがないことを保証するものではなく、さらに、口述による 明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合 性についての黙示的な保証を含み、いかなる他の保証や条件も提供するもので はありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、 本文書によって直接的または間接的に確立される契約義務はないものとします。 本文書はオラクル社の書面による許可を前もって得ることなく、いかなる目的 のためにも、電子または印刷を含むいかなる形式や手段によっても再作成また は送信することはできません。 Oracle は米国 Oracle Corporation およびその子会社、関連会社の登録商標です。 その他の名称はそれぞれの会社の商標です。0408