REL12-BP03 スケーラビリティおよびパフォーマンス要件をテストする
負荷テストなどの技法を使用して、ワークロードがスケーリングおよびパフォーマンス要件を満たしていることを検証します。
クラウドでは、ワークロードの本番環境規模のテスト環境をオンデマンドで作成できます。運用環境の動作を正確に予測できない可能性がある、スケールダウンされたテスト環境に依存する代わりに、クラウドを使用して、予想される運用環境を厳密に反映したテスト環境をプロビジョニングできます。この環境は、アプリケーションが直面する実際の条件をより正確にシミュレーションしてテストするのに役立ちます。
パフォーマンステストの取り組みと並行して、基本リソース、スケーリング設定、Service Quotas、回復性設計が負荷状態で期待どおりに動作することを検証することが重要です。この包括的なアプローチにより、最も厳しい条件下でも、アプリケーションを必要に応じて確実にスケーリングおよび実行できることを確認します。
期待される成果: ワークロードは、ピーク負荷にさらされている場合でも、期待される動作を維持します。アプリケーションが成長および進化するにつれて発生する可能性のあるパフォーマンス関連の問題には、積極的に対処します。
一般的なアンチパターン:
-
本番環境と厳密に一致しないテスト環境を使用する。
-
負荷テストは、デプロイメントの継続的インテグレーション (CI) パイプラインの統合された一部としてではなく、個別の 1 回限りのアクティビティとして扱う。
-
レスポンスタイム、スループット、スケーラビリティのターゲットなど、明確で測定可能なパフォーマンス要件を定義していない。
-
非現実的または不十分な負荷シナリオでテストを実行し、ピーク負荷、急激なスパイク、持続的な高負荷をテストできない。
-
予想される負荷制限を超えてワークロードをストレステストすることはない。
-
不十分または不適切な負荷テストとパフォーマンスプロファイリングツールを使用する。
-
パフォーマンスメトリクスを追跡し、異常を検出するための包括的なモニタリングおよびアラートシステムが不足している。
このベストプラクティスを活用するメリット:
-
負荷テストは、本番環境に移行する前に、システムのパフォーマンスの潜在的なボトルネックを特定するのに役立ちます。本番環境レベルのトラフィックとワークロードをシミュレートすると、レスポンスタイムの遅延、リソースの制約、システム障害など、システムが負荷の処理に苦労する可能性のある領域を特定できます。
-
さまざまな負荷条件下でシステムをテストすると、ワークロードのサポートに必要なリソース要件をよりよく理解できます。この情報は、リソース配分について十分な情報に基づいた意思決定を行い、リソースの過剰プロビジョニングや過少プロビジョニングを防ぐのに役立ちます。
-
潜在的な障害点を特定するには、ワークロードが高負荷条件下でどのように機能するかを監視します。この情報は、必要に応じて耐障害性メカニズム、フェイルオーバー戦略、冗長性対策を適切に実装することによって、ワークロードの信頼性と回復力を向上させるのに役立ちます。
-
パフォーマンスの問題を早期に特定して対処できるため、システム停止、レスポンス時間の遅延、ユーザーの不満などによるコストのかかる結果を回避できます。
-
テスト中に収集された詳細なパフォーマンスデータとプロファイリング情報は、本番環境で発生する可能性のあるパフォーマンス関連の問題のトラブルシューティングに役立ちます。これにより、インシデント対応と解決が迅速になり、ユーザーと組織のオペレーションへの影響が軽減されます。
-
特定の業界では、プロアクティブなパフォーマンステストを行うことにより、ワークロードがコンプライアンス基準を満たすのに役立ち、罰則や法的問題のリスクが軽減されます。
このベストプラクティスを活用しない場合のリスクレベル: 高
実装のガイダンス
最初のステップは、スケーリングとパフォーマンス要件のすべての側面をカバーする包括的なテスト戦略を定義することです。まず、スループット、レイテンシーヒストグラム、エラー率など、ビジネスニーズに基づいてワークロードのサービスレベル目標 (SLO) を明確に定義します。次に、平均使用量から突然の急増や持続的なピーク負荷まで、さまざまな負荷シナリオをシミュレートできる一連のテストを設計し、ワークロードの動作が SLO を満たしていることを確認します。開発プロセスの早い段階でパフォーマンスの低下を検出するには、これらのテストを自動化し、継続的インテグレーションおよびデプロイパイプラインに統合する必要があります。
スケーリングとパフォーマンスを効果的にテストするには、適切なツールとインフラストラクチャに投資します。これには、現実的なユーザートラフィックを生成できる負荷テストツール、ボトルネックを特定するためのパフォーマンスプロファイリングツール、主要なメトリクスを追跡するためのモニタリングソリューションが含まれます。重要なのは、テスト環境がインフラストラクチャと環境条件の点で本番環境と厳密に一致していることを確認して、テスト結果を可能な限り正確にする必要があります。本番環境のようなセットアップを確実にレプリケートしてスケーリングしやすくするには、Infrastructure as code およびコンテナベースのアプリケーションを使用します。
スケーリングとパフォーマンステストは継続的なプロセスであり、1 回限りのアクティビティではありません。包括的なモニタリングとアラートを実装して、本番環境でのアプリケーションのパフォーマンスを追跡し、このデータを使用してテスト戦略と最適化の取り組みを継続的に改善します。パフォーマンスデータを定期的に分析して、新しい問題を特定し、新しいスケーリング戦略をテストし、最適化を実装してアプリケーションの効率と信頼性を向上させます。反復的なアプローチを採用し、本番データから常に学習する場合、アプリケーションがさまざまなユーザーの需要に適応し、時間の経過と共に回復力と最適なパフォーマンスを維持できることを確認できます。
実装手順
-
レスポンスタイム、スループット、スケーラビリティの目標など、明確で測定可能なパフォーマンス要件を確立します。これらの要件は、ワークロードの使用パターン、ユーザーの期待、ビジネスニーズに基づいている必要があります。
-
本番環境の負荷パターンとユーザーの動作を正確に模倣できる負荷テストツールを選択して設定します。
-
テスト結果の精度を向上させるために、インフラストラクチャや環境条件など、本番環境に近いテスト環境を設定します。
-
平均使用パターンからピーク負荷、急速なスパイク、持続的な高負荷まで、幅広いシナリオをカバーするテストスイートを作成します。開発プロセスの早い段階でパフォーマンスのリグレッションを検出するために、テストを継続的インテグレーションおよびデプロイパイプラインに統合します。
-
負荷テストを実行して実際のユーザートラフィックをシミュレートし、アプリケーションがさまざまな負荷条件下でどのように動作するかを理解します。アプリケーションのストレステストを行うには、予想される負荷を超えて、レスポンス時間の低下、リソースの枯渇、システム障害などの動作を観察します。これにより、アプリケーションの限界点を特定し、スケーリング戦略を通知するのに役立ちます。負荷を段階的に増やしてワークロードのスケーラビリティを評価し、パフォーマンスへの影響を測定してスケーリング制限を特定し、将来の容量ニーズに備えます。
-
包括的なモニタリングとアラートを実装し、パフォーマンスメトリクスを追跡し、異常を検出し、しきい値を超えたときにスケーリングアクションまたは通知を開始します。
-
パフォーマンスデータを継続的にモニタリングして分析し、改善すべき分野を特定します。テスト戦略と最適化の取り組みを反復します。
リソース
関連するベストプラクティス:
関連ドキュメント:
関連する例:
関連ツール:
