テストとパフォーマンス分析は、さらに議論したいトピックです。 悪名高いPatterns＆Practicesチームから、主要業績評価指標の必要性に関するガイドの翻訳を公開し始めています。 翻訳について-テストに関する資料の著者であるカスペルスキーのIgor Shcheglovitovに感謝します。 テストのトピックに関する残りの記事は、 mstestingタグにあります。
はじめに
パフォーマンス分析は複雑な分野です。 彼女はシステムを調べてパフォーマンス要件を満たし、これらの要件が達成されなかった場合の理由を判断します。 このシリーズのパフォーマンス分析入門では、優れたパフォーマンスを実現するためにクラウド開発で使用されるツールとアプローチを説明するこのトピックの概要を説明します。
このガイドの目的は、システムのパフォーマンスを調査する方法を学ぶことです。 特に、このガイドでは、注意が必要な主要なパフォーマンスメトリックと、これらのメトリックを使用してシステムのパフォーマンスを判断する方法について説明します。
注 ：大規模アプリケーションでのパフォーマンスの問題の多くは、比較的低い負荷では再現せず、高（ストレス）負荷では大幅なスローダウンまたはシステムクラッシュにつながるという事実によるものです。 スケーラブルなシステムを開発する重要な側面は、これらの状況を防ぐことです。 このタスクを支援するために、クラウドシステムのパフォーマンスの一連のアンチパターン（ クラウドベースのアンチパターン ）を含む記事を公開しました。
主要業績評価指標の概念
システムのパフォーマンスは、次の要因によって決まります。
- 特定の期間にシステムが実行できる操作の数はいくつですか？ （帯域幅）
- 一度にいくつの操作を実行できますか？ （並行性）
- システムはどのくらいの時間操作を実行しますか？ （応答時間/遅延）
- システムは負荷の増加をサポートするためにどのくらいの待機電力を必要としますか？ （資源のストック）
- 負荷がかかると、システムはいくつの例外を生成しますか？ （エラー率）
これらの要因は明らかかもしれませんが、もちろん、システムの負荷レベルによって異なります。 十分なリソースと低負荷で、ほとんどのシステムは操作を迅速に実行します。 負荷が特定の制限レベルまで増加すると、重大な瞬間が発生します。 システムは、数百万の同時リクエストまたは利用可能なリソースを大量に消費するリクエストをどのように処理しますか？ グラフは、ユーザーリクエストを受信して処理するテストクラウドサービスの一般的なプロファイルを示しています。 このグラフは、ユーザー負荷の増加に伴って帯域幅と平均応答時間がどのように変化するかを示しています。 このグラフは、制御された負荷テストのプロセスで取得されました。 横軸は時間です。 このテストでは、各リクエストにほぼ同じ時間と量のリソースが必要であると想定しています。 リクエスト間の時間間隔は正規分布に従い、仮想ユーザーの現実的な動作をシミュレートします。
注 ：現実的なユーザーの行動は、ストレステストの重要な機能です。 このアプローチを適用しないと、結果が不正確になる可能性があります。 詳細については、負荷テストシナリオでのWebサイトのヒューマンインタラクション遅延をシミュレートするための思考時間の編集を参照してください。
シンプルなクラウドサービスのユーザー固有のパフォーマンスプロファイル
最初は、スループットは低くなりますが、負荷が増加すると、サービス自体の機能（容量）に依存する特定の制限まで増加します。 この容量は、ほとんどの場合、開発段階で設定されるか、サービスで使用されるリソースによって決定されます。 次のものに制限される場合があります。
- クライアントとサービス間のネットワークトラフィックの量
- CPU負荷、スレッド数、使用可能なメモリ
- サービスがデータベースを使用する場合、ここでデータベースへの利用可能な接続の数、サービスとデータベース間のトラフィック量などを追加できます。
- サービスが依存する外部システムの容量。 たとえば、Azure SQL Databaseの容量は、DTU（データベーススループットユニット）という用語で定義されます。 割り当てられたDTUを超えた場合、追加の容量が購入されるまで、後続のデータベースクエリは完了しません。 他のサービスには、物理リソース（スレッド、メモリ、接続など）に制限があります
注 ：パフォーマンステストに使用するツールが誤った結果を生成しないようにしてください。 たとえば、必要な負荷をシミュレートするのに十分な数のテストエージェントをツールが提供できない場合、スループットが正しく決定されない可能性があります。
ただし、このグラフは必ずしも全体像を示すとは限りません。 最大帯域幅が表示されるという事実にもかかわらず、レイテンシー（遅延）はパフォーマンスがさらに向上するにつれて増加します。 これは、ますます多くのリクエストが待機キューに入ることを意味します。 ある時点で、これらのリクエストはタイムアウトになり始め、対応する結果がクライアントに返されます。 さらに、サービスがWebサーバー（IISなど）を使用している場合、Webサーバー自体の外部接続の制限を超えると、後者は新しい接続を拒否し始めます。
別の注意 ：システムが依存するサービス容量の不足は、「バックエンドのプレッシャー」と呼ばれます。 多くのシステムでは、そのようなサービスはしばしばパフォーマンスを制限する要因です。 これらのサービスは多くの場合外部であり、その管理はパフォーマンスに影響を与える可能性のある他の人に移すことができます（または既に管理されています）。
図は、高負荷下での同じテストクラウドサービスの負荷プロファイルを示しています。
このグラフは、負荷が600ユーザーに達するとすぐに、リクエストがタイムアウトになり始め、システムが例外をスローし始めることを示しています。 負荷が増加すると、エラー生成が増加します。 成功したリクエストの頻度も低下することに注意してください。 平均リクエスト時間も低下することに注意してください、なぜなら サービスはすぐにリクエストを拒否し始めます。 重要なポイント-応答時間を測定することは、システムがどれだけうまく機能するかの指標ではありません。
もう1つの困難は、システムが（少なくとも一時的に）回復するのに十分安定していること、およびキューで待機している要求の数が消え、後続の要求が正常に処理されることを考慮することです。 システムは、正常に実行されたリクエストの頻度の変動が失敗率で周期的に置き換えられる期間に入る場合があります。 図は、この現象を示すグラフを示しています。これは、アンチパターンの不適切なインスタンス化を反映しています。
増加する負荷の下での成功および失敗したサービスコールの頻度の変動
この例では、システムは定期的に復元され、その後再びクラッシュします。 例外の頻度は、後続のピークごとに増加し続けることに注意してください。これは、ある時点でシステムが完全に故障することを示しています。
これらのグラフの主な目標は、ストレス下にあるシステムの「幸福」を判断するのに役立つ要因間の関係を強調することです。それは、健全であるか、崩壊しようとしている、またはその間の何かです。 テスト環境での負荷テストは、サービスの許容可能な容量を決定し、パフォーマンス要件を満たすためにスケーリングする必要があるかどうかを評価するのに役立ちます。
上記のグラフでは、テストされたサービスが分離されている単純な（理想的な）状況について話していました。 しかし、現実の世界では、外部ノイズの問題があります。「ユーザーは予測できない動作をし、同時に多くの異なる操作を実行します。この場合、任意の時点でのシステムパフォーマンスは、その時点で実行される点操作のセットによって決まります。
ユーザーがエラーを受信し始めるか、システムの速度が低下する場合、これはロジックの特定のセクションではなく、システムの合計負荷が原因である可能性があります。 これらはすべて、継続的なパフォーマンス監視の重要性を強調しています。 正確で最新のパフォーマンス情報がある場合は、要求を処理するために追加のリソースを必要とする突然のユーザーアクティビティにすばやく対応できます。 収集するパフォーマンスデータには、さまざまなメトリックをシステムプロセスのライフサイクルの完全なビューに取り込むことができるように、十分なコンテキスト情報が含まれている必要があります。 この情報は、パフォーマンス分析中に不可欠です。 システムを構成するさまざまな並列プロセスがどのように共存、相互作用、および競合するかを理解するのに役立ちます。 この情報を収集するプロセスは、 パフォーマンス分析入門で詳細に説明されています。
抽象化レベルによる指標の分析：
ほとんどのシステムには、収集および分析できる多くのメトリックがあります。 慎重に検討しないと、収集されたデータの量が非常に簡単に失われたり、重要な値が失われたりして、主要なメトリックの収集を忘れることがあります。 以下の分類は、特定の抽象化レベルごとにメトリックを整理するのに役立ちます。 正しく配布することにより、適切なレベルのパフォーマンスを決定するデータのみに集中できます。 この一連の記事では、次のレベルの抽象化について説明します。
- クライアントメトリクス これらのメトリックは、クライアントアプリケーションのパフォーマンスの測定に重点を置いています。 たとえば、クライアントアプリケーションがローカルでアクションを実行し、サーバー側からの応答を処理する期間。 これらのメトリックは、メモリ使用量やCPU使用率などのデータを対象としています。 モバイルデバイスでは、CPUの使用率が高く、ネットワークを頻繁に使用すると、バッテリーの寿命が短くなる可能性があります。また、一般的にメモリを使いすぎると、アプリケーションの起動が妨げられます。
- ビジネス指標 。 これには、ビジネスプロセスを定義するデータが含まれます。 これらはエンドユーザーのアクティビティに関連しています。 これらの指標には、システムが実行する主要なビジネスオペレーションを含める必要があります。
- アプリケーションメトリック 。 これらのメトリックは、アプリケーションレベルのアクティビティとパフォーマンス（アプリケーションソースコード、フレームワーク、.NET Frameworkなどのランタイム、ASP.NET、CLRなど）の測定に重点を置いています。 これらのメトリックの目的は、多数の同時リクエストを伴うアプリケーションのフローを調査し、消費されたリソースを分析し、パフォーマンスの問題の可能性を評価することです。
- システムメトリクス これは低レベルのパフォーマンスデータです（基本的なインフラストラクチャレベル）。 通常、これらは、メモリ、ネットワーク使用率、ディスクアクティビティ、およびプロセッサ使用率に関連する主要なパフォーマンスインジケータを対象としています。
- サービスメトリック これには、Azure Storage、メッセージングインフラストラクチャ、外部キャッシュ、データベース、アプリケーションで使用できるその他の外部サービスなどの外部サービスのパフォーマンスに関連するデータが含まれます。 このデータは、外部サービスの純粋なパフォーマンスを反映するものではなく、システムが要求を送信するリクエストの実行に関する情報のみを含んでいます。
ご清聴ありがとうございました。 次のパートでは、これらのメトリックをより詳細に検討し、次のトピックに進みます。
記事の一部：
主要業績評価指標分析-パート1
主要業績評価指標分析-パート2、カスタム、ビジネス、およびアプリケーションメトリックの分析について
主要業績評価指標分析-パート3、システムとサービスに関する最後のメトリック。