パフォーマンス テストに関する推奨事項

この Azure Well-Architected Framework パフォーマンス効率チェックリストの推奨事項に適用されます。

このガイドでは、テストに関する推奨事項について説明します。 パフォーマンス テストは、さまざまなシナリオでワークロードの機能を評価するのに役立ちます。 ワークロードがパフォーマンス要件を満たしていることを確認するために、ワークロードの応答時間、スループット、リソース使用率、安定性のテストが含まれます。

テストは、パフォーマンスの問題を防ぐのに役立ちます。 また、ワークロードがサービス レベル アグリーメントを満たしていることを確認するのにも役立ちます。 パフォーマンス テストを行わないと、多くの場合、予防可能なパフォーマンスの低下がワークロードで発生する可能性があります。 ワークロードのパフォーマンスは、パフォーマンス目標と確立されたベースラインから逸脱する可能性があります。

定義

主要な設計戦略

パフォーマンス テストは、ワークロードで測定可能なデータを収集するのに役立ちます。 十分な早い段階でテストを実行すると、適切な仕様に合ったワークロードを構築するのにも役立ちます。 パフォーマンス テストは、ソフトウェア開発ライフサイクルのできるだけ早い段階で実施する必要があります。 早期テストでは、開発の早い段階でパフォーマンスの問題をキャッチして修正できます。 運用コードの準備ができていない場合は、概念実証 (POC) を使用できます。

テストを準備する

パフォーマンス テストの準備とは、パフォーマンス テストを効果的に実施するために必要なリソース、構成、テスト シナリオの設定と配置を指します。

受け入れ基準を定義する

受け入れ基準では、ワークロードが許容可能または成功と見なされるために満たす必要があるパフォーマンス要件を指定します。 パフォーマンス目標と一致する条件を定義します。

パフォーマンス目標を確認します。 パフォーマンス ターゲットは、ワークロードに必要なパフォーマンス レベルを定義します。 ワークロードに対して確立されたパフォーマンス目標を確認します。 パフォーマンス ターゲットは、応答時間、スループット、リソース使用率、またはその他の関連するパフォーマンス 指標を含むメトリックです。 たとえば、応答時間が 2 秒未満など、特定のしきい値を下回るターゲットがある場合があります。

受け入れ条件を定義します。 パフォーマンスターゲットを、ワークロードのパフォーマンスを評価するために使用できる特定の受け入れ条件に変換します。 たとえば、応答時間のパフォーマンス目標が 2 秒以下であるとします。 受け入れ基準 は、ワークロードの平均応答時間が 2 秒未満である可能性があります。 これらの受け入れ条件を使用して、ワークロードが目的のパフォーマンス レベルを満たしているかどうかを判断します。

受け入れ条件を定義するときは、ユーザーとその期待に焦点を当てることが重要です。 受け入れ基準は、配信された作業がユーザーのニーズと要件を満たしていることを確認するのに役立ちます。 ユーザーの観点を受け入れ基準に組み込むには、次の考慮事項に注意してください。

• ユーザー要件: ワークロードのユーザーのニーズと目標を理解します。 これらの要件を満たすためにワークロードがどのように実行されるかを検討してください。

• ユーザー エクスペリエンス: 目的のユーザー エクスペリエンスをキャプチャする受け入れ条件を定義します。 応答時間、使いやすさ、アクセシビリティ、全体的な満足度などの要因を含めます。

• 機能要件: ユーザーがワークロードに表示すると予想される特定の機能に対処します。 これらの機能要件に関する受け入れ基準を定義して、それらが確実に満たされるようにします。

• ユース ケース: ユーザーが発生する可能性のあるさまざまなシナリオまたはユース ケースを検討してください。 これらのユース ケースに基づいて受け入れ条件を定義して、実際の状況でのワークロードのパフォーマンスを検証します。

受け入れしきい値を設定します。 ワークロードがパフォーマンス目標を満たしているかどうかを示す受け入れ基準内のしきい値を決定します。 これらのしきい値は、各メトリックの許容されるパフォーマンス範囲を定義します。 たとえば、応答時間の受け入れ基準が 2 秒未満であるとします。 しきい値は 2.5 秒に設定できます。 このレベルは、2.5 秒を超える応答時間がパフォーマンスの問題と見なされることを示します。

合格基準を定義します。 ワークロードがパフォーマンス テストに合格したか失敗したかを判断するための条件を確立します。 合格は、すべての受け入れ基準を満たすか、一定の割合を達成するように定義できます。

テストの種類を選択する

適切な種類のパフォーマンス テストを選択するには、テストを受け入れ条件に合わせることが重要です。 受け入れ基準は、要件またはバグ修正を行うために満たす必要がある条件を定義します。 パフォーマンス テストは、ワークロードがこれらの受け入れ基準を満たし、指定された条件下で期待どおりに実行されるかどうかを確認することを目指す必要があります。 パフォーマンス テストの種類を受け入れ条件に合わせることは、条件が定義するパフォーマンスの期待を満たすことにテストが焦点を当てていることを確認するのに役立ちます。

• 受け入れ基準を理解する。 要件またはバグ修正の受け入れ基準を確認します。 条件は、満たす特定の条件と機能の概要を示しています。

• 関連するパフォーマンス メトリックを特定します。 受け入れ基準に基づいて、目的の結果を達成するために重要なパフォーマンス メトリックを決定します。 たとえば、受け入れ条件が応答時間に重点を置いている場合は、ロード テストの優先順位付けが適切な場合があります。

• 適切なテストの種類を選択します。 使用可能なテストの種類を評価し、識別されたパフォーマンス メトリックと受け入れ基準に最も適したものを選択します。

次の表に、テストの種類とそのユース ケースのサンプルを示します。

ワークロードの特性と要件に基づいて、選択したテストの種類に優先順位を付けます。 パフォーマンス メトリックの重要度、ユーザーの期待、ビジネスの優先順位、既知の問題や脆弱性などの要因を考慮してください。

テスト ツールを選択する

実行するパフォーマンス テストの種類に基づいて、適切なツールを選択します。 テスト環境のインフラストラクチャ、リソース、制約を評価します。 目的のテストの種類をサポートし、監視、測定、分析、レポートに必要な機能を提供するテスト ツールを選択します。

アプリケーション パフォーマンス監視 (APM) ツールは、アプリケーションに関する詳細な分析情報を提供し、重要なテスト ツールです。 個々のトランザクションをトレースし、さまざまなワークロード サービスを介してパスをマップするのに役立ちます。 テスト後は、APM ツールを使用して、テスト データを分析し、パフォーマンス ベースラインと比較する必要があります。

プロファイリング ツールを使用して、コード内のパフォーマンスのボトルネックを特定します。 プロファイリングは、ほとんどのリソースを消費し、最適化が必要なコードの領域を特定するのに役立ちます。 コードのさまざまな部分の実行時間とメモリ使用量に関する分析情報を提供します。

次の手順は、適切なテスト ツールを選択するのに役立ちます。

• テスト要件を特定する。 まず、パフォーマンス テストの特定の要件を理解します。 さまざまな要因を検討してください。

  • ワークロードの種類
  • 応答時間やスループットなど、測定するパフォーマンス メトリック
  • ワークロード アーキテクチャの複雑さ
  • クラウドベース、オンプレミス、ハイブリッドなどのテスト環境

• リサーチ テスト ツール。 要件に合ったパフォーマンス テスト ツールを特定するための調査を行います。 市場で利用可能な商用およびオープンソースのツールを検討してください。 ロード テストやストレス テストなど、目的の種類のパフォーマンス テストをサポートし、パフォーマンス メトリックを測定するための機能を提供するツールを探します。

• ツールの機能を評価します。 各テスト ツールが提供する機能を評価します。 現実的なユーザー動作のシミュレーションや、大規模なユーザー負荷を処理するためのスケーラビリティなどの機能を探します。 さまざまなプロトコルとテクノロジのサポート、他のテスト ツールまたはフレームワークとの統合、レポートと分析の機能を検討してください。

• 互換性と統合を検討してください。 既存のインフラストラクチャとテクノロジとのテスト ツールの互換性を確認します。 ツールをテスト環境に簡単に統合でき、監視と分析に必要なワークロードと通信できることを確認します。

• コストとライセンスを評価します。 テスト ツールに関連付けられているコスト構造とライセンス条項を評価します。 初期投資、メンテナンス コスト、サポート コストなどの要因を考慮してください。 また、ユーザーまたは仮想ユーザーの数に依存する他のライセンス要件も考慮してください。

• POC を実施する。 評価に基づいて、最適と思われるツールをいくつか選択します。 小規模な POC を実施して、特定のテスト シナリオでツールの使いやすさ、機能、有効性を検証します。

• サポートとトレーニングを検討してください。 ツールのベンダーまたはコミュニティが提供するサポートとトレーニングのレベルを評価します。 テスト プロセス中に発生する可能性のある課題や問題を支援するために、ドキュメント、チュートリアル、テクニカル サポート チャネルの可用性を判断します。

テスト シナリオを作成する

テスト シナリオの作成とは、ワークロードのパフォーマンスのテストに適した特定の状況または条件を設計するプロセスを指します。 テスト シナリオは、現実的なユーザー動作とワークロード パターンをエミュレートするために作成されます。 これらのシナリオは、パフォーマンス テスト担当者がさまざまな条件下でワークロードがどのように実行されるかを評価する方法を提供します。

テスト シナリオでは、同時実行ユーザー アクセス、ピーク時の読み込み期間、特定のトランザクション シーケンスなど、さまざまなワークロード パターンをレプリケートできます。 さまざまなワークロード パターンでワークロードをテストすることで、パフォーマンスのボトルネックを特定し、リソースの割り当てを最適化できます。

• ユーザーの動作を定義します。 ユーザーがワークロードと対話するときに実行する手順とアクションを識別することで、現実的なユーザーの動作とワークロード パターンをエミュレートします。 サインイン、検索の実行、フォームの送信、特定の機能へのアクセスなどのアクティビティを検討してください。 各シナリオを、ユーザーとワークロードとの対話を表す特定の手順とアクションに分割します。 ページ間の移動、トランザクションの実行、ワークロードのさまざまな要素の操作を含めることができます。

• データの関与を決定します。 テスト シナリオの実行に必要なテスト データを特定します。 さまざまなシナリオ、ユーザー プロファイル、またはデータ ボリュームを表す現実的なデータ セットの作成または生成を含めることができます。 包括的なパフォーマンス評価を提供するために、テスト データが多様であり、さまざまなユース ケースをカバーしていることを確認します。

• テスト スクリプトを設計する。 定義されたテスト シナリオの実行を自動化するテスト スクリプトを作成します。 テスト スクリプトは、通常、一連のアクション、HTTP 要求、またはワークロード API またはユーザー インターフェイスとの対話で構成されます。 パラメーター化、相関関係、動的データ処理などの要因を考慮して、パフォーマンス テスト ツールまたはプログラミング言語を使用してスクリプトを記述します。 テスト スクリプトの正確性と機能を検証します。 スクリプト エラー、不足しているアクションや正しくないアクション、データ関連の問題などの問題をデバッグします。 テスト スクリプトの検証は、正確で信頼性の高いパフォーマンス テストの実行を保証するために重要です。

• テスト変数とパラメーターを構成します。 テスト スクリプト内で変数とパラメーターを構成して、変動性を導入し、実際のシナリオをシミュレートします。 ユーザーの動作やワークロードの応答を模倣するために、ユーザー資格情報、入力データ、ランダム化などのパラメーターを含めます。

• スクリプトを反復的に調整する。 フィードバック、テスト結果、または要件の変更に基づいて、テスト スクリプトを継続的に調整および強化します。 スクリプト ロジック、パラメーター化、エラー処理の最適化、または追加の検証とチェックポイントの追加を検討してください。

テスト環境を構成する

テスト環境の構成とは、運用環境によく似た環境を作成するために必要なインフラストラクチャ、ソフトウェア、およびネットワーク構成を設定するプロセスを指します。

パフォーマンス効率を向上させる方法でテスト環境を設定するには、構成プロセスに次の手順を含めます。

• 運用環境をミラー化します。 運用環境によく似たテスト環境を設定します。 インフラストラクチャの構成、ネットワーク設定、ソフトウェア構成などの要因を考慮してください。 目標は、パフォーマンス テストの結果が実際の条件を代表していることを確認することです。

• 十分なリソースをプロビジョニングします。 CPU、メモリ、ディスク領域などの十分なリソースをテスト環境に割り当てます。 使用可能なリソースが予想されるワークロードを処理し、正確なパフォーマンス測定を提供できることを確認します。

• ネットワーク条件をレプリケートします。 テスト環境でネットワーク設定を構成して、実際のワークロードのデプロイ中に予想されるネットワーク条件をレプリケートします。 帯域幅、待機時間、ネットワーク プロトコルを含める必要があります。

• 依存関係をインストールして構成します。 ワークロードを正しく実行するために必要なソフトウェア、ライブラリ、データベース、およびその他の依存関係をインストールします。 予想される運用環境と一致するようにこれらの依存関係を構成します。

トレードオフ: 個別のテスト環境の維持、データの格納、ツールの使用、テストの実行に関連するコストがあります。 パフォーマンス テストのコストを把握し、支出を最適化する方法を見つけます。

リスク: 運用データには機密情報を含めることができます。 堅牢なスクラブとマスクの戦略がないと、テストに運用データを使用するときに機密データが漏洩するリスクがあります。

テストを実行する

選択したテスト ツールを使用して、パフォーマンス テストを実行します。 テストには、パフォーマンス メトリックの測定と記録、正常性の監視、発生したパフォーマンスの問題のキャプチャが含まれます。

応答時間、スループット、CPU とメモリの使用率、その他の関連インジケーターなどのパフォーマンス メトリックを監視して収集します。

定義済みのテスト シナリオを使用して、ワークロードを予想される負荷の下に置きます。 これらのさまざまな負荷条件でテストを実施します。 たとえば、標準レベル、ピーク レベル、ストレス レベルなどのレベルを使用して、さまざまなシナリオでのワークロードの動作を分析します。

結果を分析する

テスト結果を分析するには、パフォーマンス テストから収集されたデータとメトリックを調べて、ワークロードのパフォーマンスに関する分析情報を得る必要があります。 目標は、パフォーマンスの問題を特定し、フィードバックを使用してアプリケーション開発の優先順位を調整することです。 次のアクションは、テスト結果を分析するための重要な手順です。

パフォーマンス メトリックを確認します。 応答時間、スループット、エラー率、CPU とメモリの使用率、ネットワーク待機時間など、パフォーマンス テスト中に収集するパフォーマンス メトリックを確認します。 これらのメトリックを分析して、ワークロードの全体的なパフォーマンスを把握します。

• ボトルネックの特定 パフォーマンス メトリックを評価して、非効率的なパフォーマンスのボトルネックまたは領域を特定します。 評価には、応答時間の長さ、リソースの制約、データベースの問題、ネットワーク待機時間、スケーラビリティの制限が含まれます。 これらのボトルネックの根本原因を特定すると、パフォーマンスの向上に優先順位を付けるのに役立ちます。

• メトリックを関連付ける。 さまざまなパフォーマンス メトリック間のリレーションシップと相関関係を評価します。 たとえば、負荷やリソース使用率の増加が応答時間に与える影響を分析します。 これらの相関関係を理解することで、さまざまな条件下でのワークロードの動作に関する貴重な分析情報を得ることができます。 時間の経過に伴うパフォーマンス データのパターンと傾向を探します。 さまざまな負荷レベルまたは特定の期間中のパフォーマンスを分析します。 傾向を検出すると、季節の変動、ピーク使用時間、または定期的なパフォーマンスの問題を特定するのに役立ちます。

受け入れ条件を評価します。 再テストの結果を、定義済みの受け入れ基準とパフォーマンス目標と比較します。 ワークロードが目的のパフォーマンス標準を満たしているかどうかを評価します。 ワークロードが受け入れ条件を満たしていない場合は、最適化をさらに調査して調整します。

分析を反復処理して調整します。 必要に応じて、その他の調整と改善を行います。 収集されたデータとメトリックを使用して、特定のパフォーマンスの問題を診断します。 診断には、ワークロード コンポーネントのトレース、ログ ファイルの調査、リソースの使用状況の監視、またはエラー メッセージの分析が含まれる場合があります。 データを深く掘り下げて、パフォーマンスの問題の根本的な原因を理解します。

テスト結果の分析に基づいて、特定されたパフォーマンスの問題に優先順位を付け、必要な改善を実装します。 この機能強化には、コードの最適化、データベース クエリのチューニング、キャッシュ メカニズムの改善、ネットワーク構成の最適化が含まれます。

基準を確立する

ベースラインは、時間の経過に伴うパフォーマンスの結果を比較するための参照ポイントを提供します。 ベースラインは、ワークロードパフォーマンスの意味のあるスナップショットである必要があります。すべてのテストをベースラインとして使用する必要はありません。

ワークロードの目標を検討し、時間の経過と同時に学習して最適化できるパフォーマンス スナップショットを文書化します。 これらのベースライン測定は、将来のパフォーマンス テストのベンチマークとして使用し、それらを使用して、低下や改善を特定します。

パフォーマンス テストのベースラインを確立し、将来のパフォーマンス テストのベンチマークとして使用するには、次の手順に従います。

• パフォーマンス メトリックを特定します。 測定および追跡する特定のパフォーマンス メトリックを決定します。例を次に示します。

  • 応答時間、またはワークロードが要求に応答する速度。
  • スループット、または時間単位ごとに処理される要求の数。
  • CPU、メモリ、ディスク使用量などのリソース使用率。

• 意味のある測定値を記録します。 テスト中に取得したパフォーマンス メトリックをベースライン測定として記録します。 これらの測定値は、将来のパフォーマンス テストを比較する開始点を表します。

• 今後のテストを比較します。 後続のパフォーマンス テストでは、確立されたベースラインとしきい値とパフォーマンス メトリックを比較します。 比較により、パフォーマンスの改善や低下を特定できます。

継続的にテストする

継続的なテストには、テストの継続的な監視と絞り込みが含まれます。 継続的なテストは、一貫した許容レベルのパフォーマンスを維持するのに役立ちます。 ワークロードは、ベースラインに対して一貫した許容可能なレベルのパフォーマンスを提供する必要があります。 パフォーマンスの許容範囲内で一貫したパフォーマンスを生成するには、時間の経過と同時にワークロードを調整する必要があります。 主なプラクティスを次に示します。

• 低下の制限を設定します。 時間の経過と同時に許容されるパフォーマンス低下のレベルを指定する数値しきい値を定義します。 これらの制限を設定することで、パフォーマンスの変動を監視し、パフォーマンスが定義されたしきい値を下回ったときにアラートを受け取ることができます。

• 品質保証を含める。 CPU 使用率や 1 秒あたりの最大要求数などのパフォーマンス要件を品質保証プロセスに組み込みます。 パフォーマンス要件は、機能要件と同じレベルの重要度で扱います。 このプロセスは、ワークロードを運用環境にデプロイする前に、定義されたパフォーマンス要件を確実に満たすのに役立ちます。

• アラートを自動化する。 ライブ環境では、迅速な検出と対応が重要です。 パフォーマンス ベースラインを参照として使用する自動アラート システムを設定します。 パフォーマンスに大きな逸脱がある場合は、必要なチームが直ちにアラートを受け取って行動します。

• 変更をテストします。 一部のパフォーマンスの問題は、ライブ設定でのみ発生する可能性があります。 提案されたコードとインフラストラクチャの変更に対して徹底的なテスト プラクティスを適用します。 コード インストルメンテーションを使用して、ホット パス、メモリ割り当て、ガベージ コレクションなど、アプリケーションのパフォーマンス特性に関する分析情報を取得します。 このテストにより、導入された変更が許容される制限を超えてパフォーマンスを低下させないようにします。

Azure ファシリテーション

テストを実行する: Azure Pipelines を使用すると、パフォーマンス テストを CI/CD パイプラインに統合できます。 ロード テストをパイプラインのステップとして組み込んで、アプリケーションのパフォーマンスとスケーラビリティを検証できます。

Azure Chaos Studio には、制御された障害挿入実験を実行できるように、実際の障害をアプリケーションに挿入する方法が用意されています。 この実験は、クラウド アプリケーションとサービスの回復性を測定、理解、改善するのに役立ちます。

Azure Load Testing は、任意のアプリケーションに対して高スケールの負荷を生成するロード テスト サービスです。 ロード テストには、ロード テストを自動化し、継続的インテグレーションと継続的デリバリー (CI/CD) ワークフローに統合するための機能が用意されています。 平均応答時間やエラーしきい値などのテスト条件を定義し、特定のエラー条件に基づいてロード テストを自動的に停止できます。 ロード テストでは、ロード テスト中に Azure アプリケーション コンポーネントのライブ更新と詳細なリソース メトリックを提供するダッシュボードが提供されます。 テスト結果を分析し、パフォーマンスのボトルネックを特定し、複数のテスト実行を比較して、時間の経過に伴うパフォーマンスの低下を把握できます。

結果の分析: Azure Monitor は、クラウドおよびオンプレミス環境からのテレメトリを収集、分析、応答するための包括的な監視ソリューションです。 Application Insights は、APM 機能を提供する Monitor の拡張機能です。 Application Insights を使用して、開発中とテスト中、および運用環境でもアプリケーションを監視できます。

トレードオフ: テストには時間とスキルが必要であり、運用効率に影響を与える可能性があります。

関連リンク

• セキュリティ テストに関する推奨事項
• 信頼性テスト戦略を設計するための推奨事項

パフォーマンス効率のチェックリスト

推奨事項の完全なセットを参照してください。