パフォーマンス テストのためのアーキテクチャ戦略

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

パフォーマンス テストは、さまざまな条件下でのワークロードの動作を評価するために使用される非機能テストプラクティスです。 これは、パフォーマンスの低下を早期に特定し、問題に事前に対処し、サービス レベル アグリーメントとの継続的な連携を確保するのに役立ちます。

応答時間、スループット、リソース使用量、安定性を測定すると、ワークロードが定義された目標を一貫して満たし、ビジネスに必要なパフォーマンスレベルを提供するという証拠を収集します。

この記事の重要な戦略は、 OE:09 のテストのためのアーキテクチャ戦略で説明されている基本的なテスト プラクティスに基づいて構築されています。 まず、その記事を確認することをお勧めします。 このガイドの推奨事項は、パフォーマンスを対象とし、ワークロードが進化するビジネス目標に合わせて調整されるように、パフォーマンス目標の達成に重点を置きます。

次の表では、この記事全体で使用される主要なパフォーマンス用語を定義します。

パフォーマンス テストの測定可能な目標を設定する

測定可能なパフォーマンス目標は、主観的な期待を、テストおよび検証できる客観的な基準に変えます。

パフォーマンス目標を定義し、予算を割り当てます。 サポートする必要がある同時ユーザーの数など、特定のパフォーマンス目標を定義して文書化します。 これらのターゲットがサービス レベルの目標 (SLO) と一致していることを確認し、測定可能なテスト目標に変換します。

ワークロードのさまざまなレイヤーにパフォーマンスとエラーの予算を割り当てます。 パフォーマンス テストが失敗した場合、予算は、どのレイヤーが責任を負い、どこで最適化作業に集中するかを特定するのに役立ちます。 予算がない場合、失敗したテストでは、問題がどこにあるかではなく、パフォーマンス目標が満たされていないことのみが示されます。

たとえば、API 応答時間の予算を 400 ミリ秒、データベース クエリに 150 ミリ秒、失敗した要求に 1% 上限を設定できます。 テストが失敗した場合は、各レイヤーの結果を予算に照らして確認し、問題が API 応答の遅さ、データベース クエリの遅さ、エラーの急増のいずれであるかを判断できます。

合格と失敗のしきい値が明確な受け入れ基準を定義します。 受け入れ基準は、待機時間、応答時間、スループット、リソース使用率、エラー率、およびパフォーマンス目標に合ったその他のパフォーマンス インジケーターなどのパフォーマンス メトリックに基づきます。

テストで明確な合格または失敗の結果が生成されるように、各メトリックのしきい値を定義します。 SLO で 200 ミリ秒以内に完了するために 95% の要求が必要な場合は、API 応答時間のしきい値を 95 パーセンタイルで 200 ミリ秒に設定します。 95 パーセンタイルが 200 ミリ秒を超えるテスト実行は失敗です。

早期に開始し、継続的にテストする

初期のパフォーマンス分析では、修復にコストがかかる前にアーキテクチャのボトルネックがキャッチされます。

ワークロードのソフトウェア開発ライフサイクルで、できるだけ早くパフォーマンス テストを開始します。 開始するために完全なアプリケーションは必要ありません。 開発者は、コードをローカルでプロファイリングし、応答時間を測定し、リソースを集中的に使用する操作を特定できます。 初期テストでは、設計上の決定を通知し、パフォーマンス目標に対するアーキテクチャの選択を検証し、最適化の機会を特定します。

新しい要件を満たすように進化するワークロードを継続的にテストします。 コードを変更するたびに、パフォーマンスの低下が生じる可能性があります。 これらの変更を早期にキャッチするために、定期的にテストを実行します。 デプロイ パイプラインにパフォーマンス テストを組み込み、定期的な自動テストを実行して、運用環境に到達する前にパフォーマンスの誤差を検出します。

トレードオフ。 初期のパフォーマンス テストには、専用のインフラストラクチャと専門の専門知識が必要であり、運用コストが増加します。 この投資と、後期発見の問題と本番環境でのインシデントで検出されたパフォーマンス問題のコストとのバランスを考慮します。

実際の条件下でテストする

パフォーマンス テストは実際の条件と一致する必要があるため、結果は意味を持ちます。

運用環境をミラー化する

テスト環境では、運用環境をほぼ実用的にミラーリングする必要があります。 ワークロードのリスク プロファイルに基づいて、環境に合わせてアプローチを調整します。

重要なワークロードの場合、運用環境を次のように正確に一致させます。

• 計算 SKU と構成
• 自動スケール設定
• キャッシュ設定
• ネットワーク条件 (待機時間、帯域幅)
• 外部依存関係

クリティカルでないワークロードの場合、運用環境を模倣するスケールダウンされた環境でテストすると、より低コストで有用な分析情報を得ることができます。

構成の誤差を防ぎます。 構成の誤差は、誤解を招くテスト結果につながる可能性があります。 テスト環境が運用環境と一致することを確認するための自動チェックを実装します。 テストを実行する前に、正しいバージョンがデプロイされていることを確認します。

トレードオフ。 パフォーマンス テスト用の完全な運用レプリケーションにより、インフラストラクチャ のコストが大幅に増加します。 運用環境でのパフォーマンスの問題のリスクによって、ワークロード専用のパフォーマンス テスト インフラストラクチャのコストが正当化されるかどうかを評価します。

運用環境でのパフォーマンスを検証する

テスト環境では、パフォーマンスに影響を与える実際の条件を完全にレプリケートすることはできません。 実稼働テストでは、実際の使用でのみ発生する問題が明らかにされ、将来の最適化のための正確なベースラインが提供されます。 一部のパフォーマンス要件は、実際のユーザー、データ、インフラストラクチャが交差する場所でのみ検証できます。

制御された運用テストを実行します。 ピーク時以外の時間にテストをスケジュールして、リソースの枯渇の下でのワークロードの動作を把握し、障害から復旧します。

実稼働テストでは、次のような実際の条件下でパフォーマンス特性が明らかになります。

• 現実的なユーザー動作パターンとデータ ボリューム
• 真のネットワーク待機時間と帯域幅のバリエーション
• 地理的分布の効果
• サード パーティ製 API のパフォーマンスと依存関係
• 実際のキャッシュ動作とインフラストラクチャの特性

プログレッシブ テスト手法を使用します。 トラフィックのごく一部から始めて、徐々に増加します。 各ステップで応答時間、スループット、エラー率、リソース使用率を監視します。 この段階的なアプローチでは、障害点を特定し、ボトルネックを明らかにし、需要の増加に伴うシステム動作の正確なビューを提供しながら、リスクを制限します。

運用環境のテストを継続的に監視 して、早期に問題を見つけます。 自動ロールバック メカニズムやリアルタイムアラートなど、ユーザーに悪影響を与えた場合にテストを停止する自動セーフガードを実装します。 これらの手法により、迅速な対応が保証され、中断が最小限に抑えられます。

リスク： 運用テストは、追加の負荷を発生させ、トラフィックを中断する可能性があるため、実際の顧客に直接影響します。 常にセーフガードを実装し、公開を制限し、潜在的なビジネスへの影響を最小限に抑えるためのロールバック 計画を用意します。 現実的なテストの利点と、ライブ ユーザーの混乱による潜在的なビジネスへの影響とのバランスを取る。

仮説に基づく実験を使用して変更を検証する

仮説主導の実験を使用して、パフォーマンス テストをガイドします。 個々のパフォーマンス実験を設計して、意味のある結果を生み出します。

まず、ワークロードのパフォーマンスに関する重点的な仮説から始め、実行可能な意思決定につながる測定可能な成功基準を定義します。 たとえば、仮説として"orders テーブルにインデックスを追加すると、ピーク時の負荷の下でクエリ時間が 70% 短縮されます。ベースラインは現在のスキーマであり、バリアントは新しいインデックスを持つスキーマです。 両方のバージョンに対して同じロード テストを実行します。 クエリの待機時間、データベースの CPU 使用率、スループットをキャプチャし、結果を比較して仮説が正しいかどうかを判断します。

トレードオフ。 仮説駆動型の実験では、ベースライン構成とバリアント構成の両方に対して同じテストを実行する必要があり、インフラストラクチャ コストとテスト実行時間が増加します。 潜在的なパフォーマンスの向上によって追加のテスト作業が正当化される、影響の大きい変更に焦点を当てた実験。

複数のパフォーマンス テストの種類を適用する

パフォーマンス テストは、さまざまな条件下で速度、安定性、スケーラビリティを評価するさまざまなテストを対象とします。 各テストの種類は、ワークロードの個別のパフォーマンス側面を対象とします。 独自の分析情報を明らかにし、機能テストを超えた完全な評価を可能にします。

複数のテストの種類を使用して、さまざまな角度からワークロードを検証します。 たとえば、ストレス テストはピーク時の負荷の下でブレークポイントを検出しますが、耐久テストでのみ、数時間または数日にわたって発生するメモリ リークが明らかになります。

検証する必要がある内容に基づいてテストの種類を選択します。

次の表は、各テストの種類を使用するタイミングと、ワークロードに関する内容を示しています。 この表は網羅的なリストではありませんが、例示の例として機能します。

すべてのテストの種類をすぐに実装しないでください。 基本的なロード テストから始め、ベースラインのパフォーマンスを理解します。 リスクを特定し、経験を積むにつれて、ストレス テスト、スパイク テスト、最終的には耐久テストまで拡張します。

トレードオフ。 すべてのテストの種類にわたるパフォーマンス テストには、かなりの時間とインフラストラクチャの投資が必要です。 テスト投資をビジネス リスクと一致させます。

実際の使用パターンとデータ特性を使用する

現実的なデータを使用してテストすると、リソースの消費量、システムの動作、非表示のパフォーマンスの問題に関する正確な分析情報が得られます。

さまざまなシナリオ、ユーザー プロファイル、およびデータ ボリュームを表す多様なテスト データ セットを作成します。 入力バリエーションとランダム化を使用して、実際のユーザーの多様性を模倣します。 大きなペイロード、複雑なクエリ、高いコンカレンシーなど、パフォーマンスの問題を引き起こす可能性があるエッジ ケースを含めます。

テスト データは実際の実稼働データのようになります。 運用データの特性を持つ合成データを使用します。 トランザクションの整合性、待機時間、ボリューム処理などのデータ管理の動作を強調するなど、特定のシナリオに対して運用データセットを予約 (適切に匿名化) します。

合成トランザクションをシミュレートして、実際のユーザーワークフローを模倣します。 これらのトランザクションをスクリプト化し、それらを繰り返し実行して、ワークロードの実際の使用方法を反映した負荷を生成します。

テスト シナリオには、同時実行ユーザー アクセス、ピーク時の読み込み期間、特定のトランザクション シーケンスなどの実際の使用パターンが反映されている必要があります。 パフォーマンスの結果が真のユーザー価値を反映するように、シナリオがビジネス目標と一致していることを確認します。

読み込み中にテストする場合は、実際のサード パーティの API 呼び出しを含めます。 外部の依存関係をモックすると、テストの実行速度が速くなり、予測しやすくなりますが、実際のパフォーマンスの問題は隠されます。 アプリが支払いプロセッサ API に依存している場合は、実際の呼び出しでテストし、エンドツーエンドの待機時間を理解します。

テスト結果を使用して設計上の決定を導く

テスト結果は、信頼性の高いベースラインを確立し、最適化の取り組みを導くことで、設計上の決定を推進します。

ベースライン測定を確立します。 ベースラインを使用すると、傾向や異常、および最適化の変更によって改善が実現されるかどうかを特定できます。 時間の経過に伴うパフォーマンスの傾向を追跡するには、信頼性の高いベースラインが必要です。

初期テスト中にパフォーマンス メトリックを記録します。 この記録はベースラインであり、"通常の" パフォーマンスのスナップショットです。 後続の実行では、新しい結果をこのベースラインと比較して、パフォーマンスの変化を検出します。 さまざまな条件下でのシステム動作を理解するためにデータを調べるときに、ユーザーの影響、頻度、修正コスト、および変更基準のリスクを考慮してください。 パフォーマンスが低下する場所を示すパターンを探します。 この分析情報を使用して、最適化作業に優先順位を付けます。

最適化は反復的なプロセスであり、データによって駆動される必要があります。 パフォーマンスの最適化のために、開発サイクルに専用の時間を確保します。 ベースラインを使用して変更の影響を測定し、回帰を導入することなく期待される改善を確実に実現します。

パフォーマンスとビジネス メトリックを関連付ける。 パフォーマンスの向上を、収益、ユーザー エンゲージメント、顧客満足度、コンバージョン率などのビジネス成果に結び付けて、パフォーマンスの最適化への継続的な投資を正当化します。

テスト資産を現在の使用パターンに合わせて維持する

パフォーマンス テスト資産には、ワークロードの予想される動作、許容できるパフォーマンスしきい値、現実的なトラフィック パターンに関する重要な知識が含まれています。

テスト スイートを種類別に整理します。 ロード テスト、ストレス テスト、耐久テストは別々のスイートに保持します。 それらを混在させないでください。 種類ごとに、セットアップ要件、実行期間、成功条件が異なります。 編成されたスイートを使用すると、対象となるテストの実行、実行間での結果の比較、各スイートの個別の管理が容易になります。

テスト データを定期的に更新します。 古いテスト データは、非現実的な結果につながります。 データ モデルが変化したり、データ量が増加したり、ユーザーの人口統計が変化したりするたびに、現在の運用データの特性を反映するようにテスト データを再生成します。

ワークロードの進化に合わせてテスト シナリオを確認します。 シナリオに実際の使用状況が反映されるように定期的なレビューをスケジュールします。 シナリオは次のように古くなります。

• ユーザーの動作が時間の経過と同時に変化する
• ユーザー ベースの拡大に合わせてトラフィック パターンが変化する
• 新機能により、さまざまな使用パターンが導入される
• 新しい容量要件を満たすようにインフラストラクチャをスケーリングする

Azure ファシリテーション

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

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

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

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

関連リンク

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

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

完全なレコメンデーションのセットを参照してください。