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

[アーティクル]
11/15/2023

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

PE:06	パフォーマンスをテストする。運用環境に一致する環境で定期的なテストを実行します。パフォーマンス目標とパフォーマンスベンチマークと結果を比較します。

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

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

定義

期間	定義
カオステスト	ランダムで予測不可能な障害または中断を意図的に導入することで、システムの回復性と安定性をテストすることを目的としたパフォーマンステスト。
ロードテスト	一般的で負荷の高いシステムパフォーマンスを測定するパフォーマンステスト。
パフォーマンスベースライン	テストによって検証される通常の条件下でのワークロードの動作を表すメトリックのセット。
ストレステスト	システムが壊れるまでシステムをオーバーロードするパフォーマンステスト。
合成テスト	アプリケーションでのユーザー要求をシミュレートするパフォーマンステスト。

主要な設計戦略

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

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

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

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

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

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