主要業績評価指標分析-パート3、最新のシステムおよびサービスメトリック

主要なパフォーマンスインジケータを使用するために必要なものについて、Patterns＆Practicesチームによるテストおよびパフォーマンス分析に関する翻訳の公開を終了しています。 カスペルスキーのIgor Shcheglovitovに翻訳していただきありがとうございます。 テストのトピックに関する残りの記事は、 mstestingタグにあります。

主要業績評価指標の分析サイクルの最初の記事では 、コンテキストを確立しましたが、ここで特定のことに注目します。 2番目は、ユーザー、ビジネスインジケータ/メトリック、およびアプリケーション内の分析に必要なインジケータの分析に注目しました。 これで、最終-システムとサービス（依存サービスを含む）メトリックについて。

だから

システムメトリック...

システムメトリックを使用すると、使用されているシステムリソースとリソースの競合が発生する可能性のある場所を特定できます。 これらのメトリックは、メモリ、ネットワーク、プロセッサ、ディスク使用率などのマシンレベルのリソースを追跡することを目的としています。 これらのメトリックは、コンピューターの根底にある内部競合のアイデアを提供できます。

また、メトリックデータを追跡してパフォーマンスの側面を判断することもできます。システムパフォーマンスとアプリケーション負荷の間に関係があるかどうかを理解する必要があります。 追加のハードウェアリソース（仮想または実）が必要になる場合があります。 一定の負荷でこれらのメトリックの値の増加が発生する場合、これは外部要因-バックグラウンドタスク、定期実行タスク、ネットワークアクティビティ、またはデバイスI / Oによる可能性があります。



収集方法

Azure Diagnosticsを使用して、デバッグとトラブルシューティング、パフォーマンスの測定、リソース使用量の監視、トラフィック分析、必要なリソースのスケジューリング、および監査のための診断データを収集できます。 診断を収集した後、Microsoft Azureストレージに転送してさらに処理することができます。



診断データを収集および分析する別の方法は、 PerfViewを使用することです。 このツールを使用すると、次の側面を探索できます。

• CPU使用率 。 PerfViewは、サンプリングトレーステクノロジーを使用して、現在実行中のコードのスタックを定期的に（ミリ秒間隔で）要求し、ストリームの完全なスタックトレースを返します。 次に、PerfViewはさまざまなストリームのスタックトレースを一緒に集約します。スタックビューアーユーティリティを使用すると、コードの実行内容（およびプロセッサ時間）を確認でき、正しく実行されないコードを削除または修正できます。
• 管理メモリ 。 PerfViewは、.netガベージコレクターによって制御されるマネージヒープスナップショットを実行できます。 これらのスナップショットはオブジェクトのグラフに変換され、オブジェクトの寿命を分析できます。
• 管理されていないメモリ 。 PerfViewは、オペレーティングシステムがメモリブロックを割り当てまたは解放したときにイベントをキャプチャできます。 この情報を使用して、アプリケーションがアンマネージメモリでどのように動作するかを追跡できます。
• タイミングと閉塞 。 PerfViewは、スレッドがスリープ状態になって目覚めたときの情報を追跡および視覚化できます。 この情報を使用して、アプリケーションのさまざまなロックを検索できます。 この分析は、プロセッサの負荷が低いときにパフォーマンスの問題が発生する場合に特に役立ちます。

PerfViewはもともとローカルで実行するように設計されていましたが、現在はAzureクラウドサービスのWebロールとWorkerロールからデータを収集するために使用できます。 AzureRemotePerfView NuGetパッケージを使用して、PerfViewをロールサーバーにリモートでインストールおよび実行し、受信したデータをローカルでダウンロードして分析できます。

Windows Azure診断とPerfViewは、使用された事後リソースの分析に役立ちます。 ただし、DevOpsなどのプラクティスを適用する場合、ライブパフォーマンスデータを監視して、潜在的なパフォーマンスの問題を発生前に検出する必要があります。 APMツールはこの情報を提供できます。 たとえば、AzureポータルのWebアプリケーションのトラブルシューティングツールは、メモリ、プロセッサ、およびネットワークの使用率を示すさまざまなグラフを表示できます。







Azureポータルには、一般的なシステムメトリックを示す「ヘルスダッシュボード」があります。







同様に、診断パネルでは、よく使用されるパフォーマンスカウンターの事前構成済みセットを追跡できます。 ここでは、たとえばカウンタ値が特定の値を大幅に超えた場合など、オペレータが特別な通知を受け取る特別なルールを定義できます。







Azure Webポータルは、最大7日間のパフォーマンスデータを表示できます。 長期間にわたるデータアクセスが必要な場合は、パフォーマンスデータをAzure Storageに直接アップロードする必要があります。

WebサイトProcess Explorerを使用すると、Webサイトで実行されている個々のプロセスの詳細を表示したり、さまざまなシステムリソースの使用間の相関を追跡したりできます。







New Relicと他の多くのAPMには同様の機能があります。 以下はいくつかの例です。



システムリソースの監視は、メモリ使用率（物理および管理）、ネットワーク帯域幅、プロセッサパフォーマンス、およびディスク入出力（I / O）操作をカバーするカテゴリに分類されます。 次のセクションでは、検索対象について説明します。



物理メモリ使用量



Windows上で実行されるすべてのプロセスは、仮想メモリを使用します。仮想メモリは、オペレーティングシステムによって物理メモリに投影されます。 プロセスの仮想メモリは、予約済みと割り当て済み（コミット済み）に分けられます。

• 予約メモリは、ページファイルに保存されている物理メモリまたはページメモリとは関連付けられていません。 プロセス用に予約されているメモリの量を単純に記述し、プロセスの仮想アドレス記述子（VAD）に書き込まれます。 このメモリは物理ストレージに関連付けられていないため、パフォーマンスの監視中は無視できます。
• 割り当てられたメモリは、物理メモリおよび/またはページングファイルページメモリの割り当てに関連付けられています。 専用メモリの使用を監視する必要があります。

割り当てられたメモリの割り当てを監視して、必要なビジネス負荷をサポートし、ユーザーアクティビティの急激なバーストを処理するのに十分なメモリがクラウドサービスまたはサイトのホスティングに割り当てられているかどうかを判断できます。 次のパフォーマンスカウンターを追跡する必要があります。

• Memory \ Commit Limitは、システムが割り当てることができるメモリの最大量を示します。 通常、これはオペレーティングシステムによって決定される固定値です（ 64ビットバージョンのWindowsに適切なページファイルサイズを決定する方法を参照 ）。たとえば、8 GBのメモリを搭載したマシンでは、この数値は約11 GBになります。
• Process \ Private Bytesは、プロセスに割り当てられたメモリの量を示します。 すべてのプロセスのすべてのプライベートバイトの合計が上記のメモリ制限を超える場合、これはシステムがメモリを使い果たし、アプリケーションが失敗することを意味します。
• Memory \％Committed Bytes in Useは、Memory / Committed BytesとMemory \ Commit Limitの比率です。 このカウンタの値が大きい場合、システムに大きなメモリ負荷があることを示しています。

注： Windowsには、Process \ Virtual Bytesカウンターがあります。 このカウンタは、プロセスが使用する仮想メモリの合計量を示しますが、非常に注意する必要があります。 実際、予約済みおよび割り当て済みのプロセスメモリの量を示しています。 たとえば、w3wpプロセスの開始時にProcess / Virtual Bytesおよび.NET CLR Memory \＃total reserved bytesカウンターを調べると、このカウンターは18 GBを表示できますが、合計メモリ容量は185 MBです。

予約メモリは、ダイナミックRAMにより拡張でき、プロセスはこのメモリを物理メモリに変換できます。



OutOfMemoryエラーの主な原因は2つあります。プロセスが割り当てられた仮想メモリ領域を超えているか、オペレーティングシステムがプロセスに追加の物理メモリを割り当てることができません。 2番目のケースが最も一般的です。



以下で説明するパフォーマンスカウンターを使用して、メモリ負荷を推定できます。

• メモリ\利用可能なMバイト。 理想的には、このカウンタの値は、マシンにインストールされている物理メモリの量の10％を超える必要があります。 使用可能なメモリの量が少なすぎる場合、システムがアクティブなプロセスにページファイルの使用を開始する可能性があります。 システムに十分な物理メモリがない場合、その結果、大幅な遅延や完全なシステムハングが発生する可能性があります。
• 使用中のメモリ\％コミット済みバイト。 割り当てられたメモリの合計量が制限値の90％に近づくと、割り当てられたメモリの制限が増加します。値が95％に達すると、制限の拡大が停止し、OutOfMemoryエラーが発生する可能性があります。 割り当てられたメモリの量が制限に達するとすぐに、システムはプロセスにメモリを割り当てることができなくなります。 ほとんどのプロセスは、システムのこの動作に対応せず、実行を停止します。 したがって、このカウンタを監視することは非常に重要です。
• メモリ\ページ/秒 このカウンタは、システムがページファイルを使用している量を示します。 物理メモリに対するスワッピングの効果を判断できます。これを行うには、このカウンターの値にPhysical Disk \ Avg.Disk sec / Transferカウンターの値を掛けます。 この操作の結果は0〜1であり、ページファイルへの仮想ページの読み取りと書き込みに費やされるディスクアクセス時間の割合を特徴付けます。 0.1の値は、システムがスワップファイルを操作するためにディスクにアクセスする合計時間の10％以上を費やすことを意味します。 この値が定数の場合、これは物理メモリの問題を示している可能性があります。

また、大量のメモリが断片化を引き起こす可能性があることに留意する必要があります（隣接ブロックに十分な空き物理メモリがない場合）。したがって、十分な空きメモリがあることを示すシステムは、特定のプロセスにこのメモリを割り当てることができない場合があります。



多くのAPMツールは、メモリがどのように機能するかを深く理解する必要なく、プロセスがシステムメモリを使用する方法に関する情報を提供します。 以下のグラフは、一定の負荷の下でのアプリケーションのスループット（左軸）と応答時間（右軸）を示しています。 約6分後、パフォーマンスが突然低下し、数分後にインジケーターが発生し、応答時間が「ジャンプ」し始めます。





アプリケーション負荷テスト結果



New Relicを使用して記録されたテレメトリには、過剰なメモリ割り当てが示されており、これにより操作が失敗し、その後回復されます。 スワップファイルにより、使用済みメモリが増加します。 この動作は、メモリリークの典型的な症状です。





過剰なメモリ割り当てを示すテレメトリ



注：記事「 Visual Studio 2013を使用したAzure Webサイトでのメモリリークの調査」には、Visual StudioとAzure診断を使用して、AzureのWebアプリケーションのメモリ使用量を監視する方法が記載されています。



マネージドメモリの使用



.NETアプリケーションは、共通言語ランタイム（CLR）によって制御されるマネージメモリを使用します。 CLRは、マネージメモリを物理メモリに投影します。 アプリケーションはCLRに管理メモリを要求し、CLRは必要なメモリを割り当てて未使用のメモリを解放します。 データ構造をブロック単位で移動することにより、CLRはこのタイプのメモリのレイアウトを提供し、それによって断片化を減らします。



管理対象アプリケーションには、パフォーマンスカウンターの追加セットがあります。 メモリ問題の調査の記事には、キーカウンターの詳細な説明が含まれています。 最も重要なパフォーマンスカウンターは次のとおりです。

• .NET CLRメモリ＃コミットされた総バイト数は、ディスク上の物理メモリとページスペースに依存するメモリを処理します。 このカウンターは、割り当てられたプロセスメモリの量を表示し、Process / Private Bytesカウンターの値と非常に似ている必要があります。
• .NET CLR Memory＃Total Reserved Bytesは、プロセスの予約メモリの量を示します。 Process \ Virtual Bytesカウンターの値とほぼ等しく、Process \ Private Bytesの値よりも小さい必要があります。
• .NET CLR Memory \ Allocated Bytes / secは、管理ヒープの変動性を示します。 このカウンターの値は、アプリケーションがオブジェクトを作成するか破棄するかによって、正または負になります。 このカウンタは、各ガベージコレクションサイクルの後に更新されます。 このカウンタの一定の正の値は、メモリリークを示している可能性があります。
• すべてのヒープの.NET CLRメモリ＃バイトは、プロセスの管理ヒープの合計サイズを示します。
• .NET CLR Memory \％Time in GC最後のガベージコレクションサイクルの実行に費やされた時間の割合。 このカウンターの良い指標は、10％未満の値です。

WebサーバーでのWeb待ち時間



ネットワークパフォーマンスは、クラウドアプリケーションにとって特に重要です。 それはすべての情報が通過する指揮者です。 ネットワークの遅延はクエリの実行時間の増加につながるため、ネットワークの問題はパフォーマンスの低下につながり、ユーザーに不快感を与えます。 Windowsは現在、個々のアプリケーション要求の遅延を測定するためのパフォーマンスカウンターを提供していません。 ただし、ローカルコンピューター上のネットワークトラフィックを分析するための優れたツールであるリソースモニターがあります（クラウドサービスの展開中にリモートデスクトップを構成し、Webまたはワーカーロールのサーバーにログインできます）。 リソースモニターは、失われたパケットに関する情報、またはアクティブなTCP / IPセッションの合計遅延に関する情報を提供します。 パケット損失により、接続の品質がわかります。 遅延は、TCP / IPパケットがルートを完了するのにかかる時間を示します。 図は、リソースモニターの[ネットワーク]タブを示しています。





LANアクティビティを示すリソースモニター



Webサーバーでのネットワーク使用率



Perfomance MonitorからWebサーバーに直接接続することで（リアルタイム情報が必要な場合）、Azure Diagnosticsを構成してデータをAzure Storageに保存することにより、次のパフォーマンスカウンターを取得できます。

• Network Adapter \ Bytes Sent / secおよびNetwork Adapter \ Bytes Received / secは、ネットワークアダプターによるデータの送受信速度を示します
• ネットワークアダプター\現在の帯域幅は、ネットワークアダプターの許容帯域幅（バイト/秒）を推定するために使用されます
• 送信バイトのネットワーク使用率％=（（送信バイト/秒* 8）/現在の帯域幅）* 100
• 受信バイトのネットワーク使用率％=（（受信バイト/秒* 8）/現在の帯域幅）* 100

これらの値が約100％であることが判明した場合、これはネットワークの輻輳を示している可能性があります。 この場合、クラウドアプリケーションの複数のインスタンスにネットワークトラフィックを分散する必要がある場合があります。



Azureポータルは、クラウドサービスのすべてのインスタンスと、ロールの特定のインスタンスのネットワーク使用率を表示できます。 ポータルには、1秒あたりに送受信されるバイト数に関する情報を提供するNetwork InおよびNetwork Outカウンターがあります。





Azure管理ポータルでネットワークの使用状況を監視する



ネットワークの待ち時間が非常に長くても使用率が低い場合、ネットワークはほとんどボトルネックになりません。 アプリケーションインスタンスのCPU使用率が高い場合は、より多くの電力が必要であり、複数のインスタンス間で負荷を並列化する必要があることを意味します。 CPU使用率が低い場合、これは外部サービスの影響による可能性があります。 たとえば、Azure SQLデータベースに送信される複雑なクエリは、完了するまでに時間がかかる場合があります。 この状況では、インスタンス間のネットワークトラフィックの分散は、データベースサーバーの過負荷によるパフォーマンスの問題を悪化させる可能性があり、遅延の増加につながります。 外部サービスの使用を追跡する準備をする必要があります。



注：ネットワーク遅延とチャネル幅の詳細については、Windows SysinternalsのPsPingツールに慣れることをお勧めします。



ネットワークトラフィック量



遅延のもう1つの一般的な原因は、大量のネットワークトラフィックです。 外部サービスへのトラフィック量を調査する必要があります。 多くのAPMツールを使用すると、クラウドサービスおよびWebアプリケーションに向けられたトラフィックを追跡できます。 この図は、Web APIサービスの着信および発信ネットワークトラフィックを示すNew Relicからの例を示しています。 大量の総トラフィック（〜200 Mb /秒）により、顧客の待ち時間が長くなります。







Azure管理ポータルには、Azure SQLデータベースやAzure Storageなどの外部サービスの使用率を表示するためのツールも含まれています。



ネットワークのオーバーヘッドと顧客の場所



ネットワークの待ち時間が長いと、プロトコルのインターワーキング、パケット損失、ルーティングの影響などのオーバーヘッドが発生する可能性があります。 待機時間とスループットは、クライアントの場所とクライアントが連携するサービスに大きく依存します。 顧客が異なる地域にいる場合は、地域ごとにサービスインスタンスの分散を検討し、各地域に必要な負荷を処理するのに十分な容量があることを確認する必要があります。



以下のグラフは、ユーザーの地理的分布が帯域幅と遅延にどのように影響するかを示しています。 3分以内に一定のリクエストのストリームがサービスに送信されました。 このシナリオは2つのテストに使用されました。最初のテストでは、クライアントとサーバーは1つの地域にあり、2番目のテストでは異なる地域にありました。 両方のグラフで、左軸は1秒あたりの操作数でパフォーマンスを示し、右軸は秒で応答時間を示します。









最初のグラフでは、平均スループットは2番目のグラフよりも数倍高く、応答時間は2番目のグラフの応答時間の約1/4です。



ネットワークペイロードサイズ



要求と応答の本文のサイズは、スループットに大きな影響を与える可能性があります。 XMLクエリは、JSON形式の同等のものよりも大幅に大きくなる可能性があります。 バイナリシリアル化されたデータはよりコンパクトですが、柔軟性が低い場合があります。 帯域幅の消費に加えて、大規模な要求は、データの解析または逆シリアル化に追加のCPU負荷をもたらします。



次のグラフは、スループットと応答時間に対するさまざまな要求サイズの影響を示しています。 前と同じように、両方のチャートで同じテストサービスが使用されました。 顧客とサービスは同じ地域にあります。









ここで、メッセージサイズが10倍に増加すると、スループットが低下し、応答時間が増加することがわかります。 これは、ネットワークトラフィックの実証を目的とした人為的なテストであることに注意してください。 要求の処理に必要な追加のプロセスは考慮されず、他のクライアントまたはサービスによって生成されたサードパーティのネットワークトラフィックの影響はありません。



ネット上のおしゃべり



ネットワークの遅延のもう1つの一般的な原因は、「チャティネス」です。 おしゃべりとは、業務を完了するために必要なネットワークセッションの頻度です。



「おしゃべり」を検出するには、すべての操作にテレメトリ、呼び出しの頻度の記録、およびだれがいつ呼び出されたかを含める必要があります。 テレメトリには、操作の入力および出力でのネットワーク要求のサイズを含める必要があります。 同じクライアントから短期間で送信される比較的小さなリクエストが多数ある場合、これらのリクエストを1つ以上に結合してシステムを最適化する必要があることを示している可能性があります。 例として、図はテストWeb APIサービスのテレメトリーを示しています。 API呼び出しごとに、Azure SQLで1つ以上のクエリが発生します。 監視中、平均スループットは1分あたり13,900リクエストでした。 データベースのテレメトリも図に示されており、この期間中にサービスがデータベースに対して250,000を超えるクエリを行ったことを示しています。 これらの数値は、Web APIの呼び出しごとに、データベースへの呼び出しが平均18回あることを示しています。









アプリケーションの照会時に発生するDB呼び出し



CPUとサーバーの使用率

CPU使用率（使用率）は、マシンの作業量の尺度であり、CPUの「可用性」は、マシンが余分な負荷を処理するために必要なプロセッサーの予備容量の量を示します。 APMを使用すると、Webサービスまたはクラウドアプリケーションを実行している特定のサーバーに関するこの情報を取得できます。 この図は、New Relicの統計を示しています。







Azure Webポータルでは、各サービスインスタンスのCPUデータを表示できます。





AzureポータルのサービスインスタンスのCPU使用率



高いCPU使用率は、多数の例外が原因で発生する場合があり、例外の生成によりプロセッサが過負荷になります。



関連するセクションで前述したアプローチを使用して、例外の頻度を追跡できます。 過剰なプロセッサ使用率は、大きなオブジェクトのガベージコレクションが頻繁に発生するアプリケーションによって引き起こされる可能性があります。 「マネージメモリの使用」セクションの説明に従ってCLRガベージコレクションカウンタを調べて、プロセッサ負荷全体に対するガベージコレクタ（GC）の影響を評価する必要があります。 また、システムのガベージコレクションポリシーが正しく構成されていることも確認する必要があります（詳細については、ガベージコレクションの基礎を参照してください）。



低CPU使用率と高レイテンシは、さまざまなロックに関連付けられている可能性があります。これは、ロックの不適切な使用や同期I / O操作の完了の待機など、コードの問題を示している可能性があります（詳細については、同期I / Oのアンチパターンを参照してください）。



プロセッサプロパティアフィニティ（プロセスを特定のプロセッサにバインドする）により、プロセッサまたはプロセッサコアがボトルネックになる可能性があります。 この状況は、ワーカーロールを持つAzureのクラウドアプリケーションで発生する可能性があります。 Webロールからの要求は、ロードバランサーをバイパスして、常に特定のワーカーロールに送信できます。



特定のサーバーのCPU使用率



プロセッサは、ユーザーモードと特権モードの2つのモードで動作します。 ユーザーモードでは、プロセッサはアプリケーションのビジネスロジックを構成する命令を実行します。 特権モードでは、プロセッサはオペレーティングシステムのカーネルレベルの操作（ファイル操作、メモリ割り当て、スワッピング、スレッド制御、プロセス間のコンテキスト切り替えなど）を実行します。 プロセッサの負荷を追跡するには、次のパフォーマンスカウンターを監視する必要があります。

• プロセッサー\％特権時間プロセッサーが特権モードで費やす時間。 このカウンターの常に高い値は、システムがオペレーティングシステムの機能を実行するのにかなりの時間を費やし、大量のI / O操作、プロセスまたはスレッドの絶え間ないブロック、メモリ管理中の過度のスワッピングまたはオーバーヘッド（ガベージコレクションなど）によって引き起こされる可能性があることを示します。
• プロセッサ\％ユーザー時間。システム関数ではなく、プロセッサがアプリケーションコードの実行に費やす時間。
• プロセッサ\％Processor Timeプロセッサの合計負荷（ユーザーモードおよび特権モード）。 通常、プロセッサの負荷は高い値と低い値の間で変動しますが、常に高いレベル（80％を超える）は、プロセッサがボトルネックになっている可能性があることを意味します。 たとえば、 ビジーフロントエンドアンチパターンは、最初に1つのWebロールに負荷が集中する状況を示し、キューを使用してデータ処理を個々の作業ロールに転送する際の応答時間を改善する方法も示します。

CPUを集中的に使用するプロセス



ストレステスト中に、テスト環境でプロセス負荷が高くなる可能性のある原因を調査できます。 このようなアプローチは、外部要因の影響を排除するのに役立つはずです。 多くのAPMツールは、スレッドプロファイリングをサポートしており、プロセッサが処理のスタックを実行する方法を分析します。 図は、New Relicでのプロファイリングの例を示しています。







New Relicのプロファイリング



一定期間プロファイリングした後、New Relicではこの情報を分析し、CPU時間を最も多く消費する操作を調査できます。 受信した情報は、コード最適化のための信号である場合があります。

この手法は非常に強力なツールですが、実際のユーザーのパフォーマンスに大きな影響を与える可能性があります。 したがって、実際の環境でこのプロセスを実行する場合は、データを収集した後すぐにプロファイラーをオフにする必要があります。



ディスク使用量



I / Oレートが高いのは、通常、ビジネスインテリジェンスや画像処理などのタスクが原因です。 さらに、多くのストレージサービス（Azure SQL DB、Azure Storage、Azure DocumentDBなど）はディスクリソースを積極的に使用します。 サービスを実行する仮想マシンを作成している場合、ディスクアクセスの監視が必要になる場合があります。 これは、適切なディスク構成を選択してパフォーマンスを向上させるためです。



メモリを集中的に使用するアプリケーションは、大量のディスクアクティビティをトリガーすることもあります。 メモリを使いすぎると、サイズが大きくなり、結果としてパフォーマンスが低下する可能性があります。 この場合、いくつかのインスタンスに負荷を再分散するためにロールを水平にスケーリングする必要があるかもしれませんが、その前にアプリケーションで正しいメモリ使用量を分析する必要があります（理由は通常のリークです）。



Azureでは、仮想ディスク（仮想マシンで使用）はAzure Storageで作成されます。 現在、Azureストレージには、標準とプレミアムの2種類があります。 仮想ディスクのパフォーマンスは、1秒あたりのI / O操作数と1秒あたりのMB単位のスループットで測定されます。 IOPS（英語からの入力/出力操作の数。1秒あたりの入力/出力操作）は、さまざまなタイプのストレージのパフォーマンスの標準的な指標です。 標準ストレージを使用すると、1秒あたり最大500のI / O操作を処理でき、最大パフォーマンスは60 Mbpsです。 プレミアムストレージはSSDに基づいており、最大5,000 I / Oの速度で動作でき、200 Mb / sのスループットを提供します。



仮想マシン構成でRAIDディスクを使用するとスループットが向上しますが、この場合、I / O要求は仮想マシン自体のレベルで制御されます。 詳細については、仮想マシンのサイズを参照してください。



: IOPS I/O-. , , , IOPS . , , IOPS. I/O .



() SQLIO Disk Subsystem Benchmark Tool . , , :





I/O



, , , 500 . , RAID-, 4- ( Azure Storage) .





I/O striped-



1400 IOPS. Premium-, 80000 IOPS .

, () Azure. , IOPS Premium- (5000 IOPS) ( RAID) . , () I/O IOPS . . Premium Storage: High-Performance Storage for Azure Virtual Machine Workloads.



Azure I/O . APM- . , New Relic. I/O-, , . , , 100%, IOPS 1500. RAID` 4- ( ):







, ( Physical Disc):

• Avg. Disk sec/Read Avg. Disk sec/Write. ( ) . , . (payload) 64 15 . - I/O , , .
• Disk Transfers/sec. . , , , IOPS. I/O- . , . . , , 100 10 , 50 20 . (, ). .
• Disk Bytes/Sec, Disk Read Bytes/sec Disk Writes Bytes/sec. , . 1 MB 256 4 , . , 15 , I/O , Avg. Disk Bytes/Read Avg. Disk Bytes/Write
• Avg. Disk Queue Length, Avg. Disk Read Queue Length, and Avg. Disk Write Queue Length. I/O , ( ). :
• Avg. Disk Queue Length = (Disk Transfers/sec) * ( Disk sec/Transfer)
  
  , .. .
• % Idle Time. . . , . 1 , %idle time 0. , , , ( ).

Azure , , . , .



, , (backend pressure). , , , . . , .



?



Azure Azure (Storage, SQL DB, Service Bus ..). APM.



. . , , . , .



?



, -, SLA. . - Azure. , , .. .



Azure Storage



Azure Storage. , -. C (end-to-end) Azure Storage , .

Azure Azure Storage, -. , .





Azure



Azure Storage



. Azure Storage . (Premium ). , . , , .

Azure. , . .





, Azure



Azure SQL



, Azure SQL Database, , - . Azure .





Azure



Azure SQL Database Microsoft. Microsoft SLA, 99.9%. , ( ) .



, , , (, ). APM, . New Relic . , -.







New Relic



, . . , (, , ). Azure.



Azure SQL Database DTU



AZURE SQL database Database Throughput Units, DTU. DTU , , I/O . SQL Azure, . DTUs ( 5 DTU 1750 Premium/P11). DTU, , . , DTU , Azure. , .





DTU Azure



Azure SQL



, , , , . . CPU, Data I/O, Log I/O, , , , . , ( ).



Dynamic SQL , , . sys.dm_db_resource_stats, , ( , 80%).

(COUNT(end_time) - SUM(CASE WHEN avg_cpu_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'CPU Fit Percent' ,(COUNT(end_time) - SUM(CASE WHEN avg_log_write_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'Log Write Fit Percent' ,(COUNT(end_time) - SUM(CASE WHEN avg_data_io_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'Physical Data Read Fit Percent' FROM sys.dm_db_resource_stats```
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3つの要求されたメトリックのいずれかに対するこの要求が99.9％未満の値を返す場合、データベースパフォーマンスのより高いレベルへの移行を検討するか、データベースの負荷を減らすために最適化する必要があります。

この情報は、Azureポータルでも入手できます。





AzureポータルのAzure SQL統計



クエリパフォーマンス



効率の悪いデータベースクエリは、待ち時間とスループットに大きな影響を与える可能性があり、過剰なリソース消費を引き起こす可能性もあります。 クエリパフォーマンスページには、動的表現からクエリ情報を抽出し、Azure SQLポータルでこのデータを視覚化できます。





Azure SQL Portalのクエリパフォーマンス



実装計画を見て、最も難しい要求を掘り下げることができます。 このデータは、クエリの長​​時間実行の理由を判断し、それらを最適化するのに役立ちます。





Azure SQL Portalクエリ実行プラン



多数のデータベースクエリ



アプリケーションとデータベース間の大量のトラフィックは、キャッシュの不足を示している可能性があります。 抽出されたデータを分析する必要があります。たとえば、アプリケーションが絶えず同じデータを要求および更新する場合、アプリケーションまたは共有分散キャッシュにローカルにキャッシュします。 Azure SQLポータルの[クエリパフォーマンス]ページは、実行グラフの形式で有用な情報と、各クエリの実行数（実行カウント）を提供します。





Azure SQL Portalクエリ頻度の監視



非常に頻繁に実行される（実行カウントが高い）クエリは、必ずしも同じデータを返すとは限りません（一部のクエリは特別なオプティマイザーによってパラメーター化されます）が、キャッシュの候補を決定するための開始点として使用できます。



Azure SQLのデッドロック



最適でないトランザクションでは、デッドロックが発生する場合があります。 デッドロックが発生した場合は、トランザクションをロールバック（ロールバック）して、後で再実行する必要があります。 頻繁にデッドロックが発生すると、パフォーマンスが大幅に低下する可能性があります。 Azure SQLポータルでデッドロックを追跡し、デッドロックが発生したら、実行時にアプリケーショントレースを分析して原因を特定できます。



サービスバスの待ち時間



サービスバス（リッスンバス、以下SB）にアクセスする際の高レベルのレイテンシは、パフォーマンスの低下につながる可能性があります。 ネットワークの理由（クライアントからのSB名前空間のリモート性に関連するパケット損失など）、SB内の競合（トピック、キュー、サブスクリプション、イベントハブ、アクセスエラーなど、さまざまな理由により発生する可能性があります。キュー、トピック、およびイベントハブ用のSB。ただし、Microsoft Azカウンターのコレクションをアプリケーションコードに追加することにより、パフォーマンスに関する詳細な情報（送受信操作の待機時間、接続エラーなど）を取得できます。 ure Service Busクライアント側パフォーマンスカウンター（https://www.nuget.org/packages/WindowsAzure.ServiceBus.PerformanceCounters）



サービスバス接続の拒否と調整



キュー、トピック、およびSBサブスクリプションには、帯域幅を制限できるクォータがあります。 たとえば、最大キューまたはトピックサイズ、同時接続数および同時要求数が含まれます。 これらのクォータを超えると、SBはそれ以上の要求を拒否し始めます。 詳細については、 azure.microsoft.com / documentation / articles / service-bus-quotasをご覧ください。 ポータルポータルAzureのSBのキューとトピックを通過するトラフィックの量を制御できます。



イベントハブのボリュームはスループット単位で決定され、作成時に設定されます。 1つのスループットユニットは、着信トラフィック（入力）で1 MB /秒、発信トラフィック（出力）で2 MB /秒の速度に相当します。 アプリケーションがスループットユニットの設定数を超えると、データの送受信速度が低下します。 キューおよびトピックと同様に、Azureポータルでイベントハブの速度を制御できます。 着信トラフィックと発信トラフィックのクォータは別々に適用されることに注意してください。



サービスバスでの失敗したリクエストとポイズンメッセージ



メッセージ処理エラーの頻度と、許可された処理数を超えた有害メッセージの合計量を監視します。 アプリケーションの設計によっては、誤ったメッセージが1つでもシステム全体の速度が低下する場合があります。 失敗したリクエストとポイズンメッセージを分析します。



Event Hub Quotaの例外



クラウドアプリケーションは、Azure Event Hubをストレージとして使用して、クライアントから受信した大量のデータ（非同期イベントの形式）を集約できます。 イベントハブは、低レイテンシと高可用性を備えた着信イベントの高速を維持し、さらに処理するためにイベントを送信する他のサービスと組み合わせて使用​​されます。



イベントハブの容量は、購入時に設定される帯域幅ユニットの数によって制御されます。 1つのユニットがサポートするもの：



* 入力 ：1秒あたり最大1MBのデータ、または1秒あたり1000イベント。

* 出力 ：1秒あたり最大2MB。



着信トラフィックは、利用可能な帯域幅の単位の数によって規制されます。 超過した場合、「クォータ超過」例外がスローされます。 発信トラフィックを超えた場合、例外は発生しませんが、速度はスループットユニットの容量によって制限されます（基本バージョンでは1秒あたり2 MB）。



Azureポータルのダッシュボードを表示して、イベントハブの動作を制御できます。





Azure Portalでのイベントハブの監視



パブリケーションの数に関連する例外が表示される場合、または送信トラフィックの予想されるインジケーターが表示されない場合は、[スケール]ページのAzureポータルでプロジェクトに設定されているスループットユニットの数を確認します。





Event Hubの帯域幅割り当て



Event Hubリースのエラー



アプリケーションは__EventProcessorHost_オブジェクトを使用して、イベントのコンシューマーにワークロードを分散できます。 __EventProcessorHost_オブジェクトは、イベントコンセントレーターの各セクションにAzure Storage BLOBロックを作成し、これらのBLOBを使用してパーティションを管理します（イベントの受信と送信）。 _EventProcessorHost_の各インスタンスには2つの関数があります。



1.ロックの拡張：ロックは現在インスタンスによって所有されており、必要に応じて定期的に拡張されます

2.ロックの作成：各インスタンスは、既存のすべてのロックの有効期限を継続的にチェックし、ロックがある場合はブロックされます



メッセージの再処理とブロックBLOBの発生頻度を監視する必要があります。



依存サービスの使用



ストレージ、SQLデータベース、およびサービスバスに加えて、多数のAzureサービスがあり、その数は常に増加しています。 すべてのサービスをカバーすることはできませんが、使用する各サービスが提供する主要な側面を制御する準備をする必要があります。 例として、Azure Redis Cacheを使用して共有キャッシュを実装する場合、次の問題を分析することでその有効性を判断できます。



*毎秒キャッシュに入れられるデータと入れられないデータの量は？



この情報は、Azureポータルで入手できます。





Azure PortalでのAzure Redisキャッシュの監視



システムが完全な動作状態に達し、キャッシュ係数が低くなった後、キャッシュ戦略を調整する必要がある場合があります。



分散キャッシュに接続するクライアントの数は？



Azureポータルを使用して、接続されているクライアントの数を制御できます。

同時接続の制限は10000です。この制限に達すると、以降の接続試行は終了します。 アプリケーションが常にこの制限に達する場合は、ユーザー間でキャッシュを分散することを検討する必要があります。



キャッシュクラスターで毎秒何回の操作（受信および書き込み）が発生しますか？

AzureポータルでGets and Setsカウンターを表示できます。



キャッシュクラスターに保存されるデータの量

AzureポータルのUsed Memoryカウンターには、キャッシュのサイズが表示されます。 許可されるキャッシュサイズの合計は、作成時に設定されます。



キャッシュ遅延レベルとは何ですか？



Azureポータルでキャッシュ読み取りおよびキャッシュ書き込みカウントを追跡し、キャッシュの読み取りおよび書き込み速度（KB /秒で測定）を決定できます。



キャッシュサーバーはどれくらい忙しいですか？

Azureポータルのサーバー負荷カウンターを監視します。 このカウンターは、R​​edis Cacheサーバーがリクエストの処理でビジーである時間の割合を示します。 このカウンターが100％に達する場合、これはRedis Cacheサーバーのプロセッサー時間が最大値に達し、サーバーが高速で実行できないことを意味します。 サーバーで安定した高負荷が発生する場合、おそらくいくつかのリクエストがタイムアウトになります。 この場合、キャッシュリソースを増やすか、複数のキャッシュにデータを分割することを検討する必要があります。



要約する

• テレメトリを使用してパフォーマンスデータを取得します。
• 事業運営。 外部APIへのすべての呼び出しを制御します。 重要な事業運営には特に注意を払う必要があります。
• ブラウザのメトリック。 新規ユーザーとリピーターの情報、およびブラウザーの種類に関する情報を傍受する
• 着信および発信ネットワークトラフィックを監視する
• メモリ使用量と、それがビジネスワークロードにどのように関連するかを監視する
• CPU使用率とスレッド使用率
• キューの長さとキューのタイムアウト
• 外部サービス。 遅延と帯域幅、およびエラー。
• テレメトリを使用してアラートを作成し、ビジネス例外とSLA違反を監視します
• テレメトリの監視と収集は、パフォーマンスの問題を特定するためだけに使用しないでください（事後対応的アプローチ）。 現在のサーバー容量が将来のビジネス負荷の増加とどのように相関するか、または予期しないユーザーの行動がシステムの正常な機能にどのように影響するかを示すことができるため、この情報を積極的に使用してください
• パフォーマンス分析は、観察、測定、検証を含む周期的な研究プロセスです。 すべてのアプローチでプラスの結果が得られるわけではありません。 これは予算が必要です。 これは、システムのライフサイクル全体で継続する継続的なプロセスです。
• 低レベルの詳細にこだわらないでください。 特定のタスクのコンテキストでエンジニアリングスキルを評価します。 各パフォーマンスカウンターを詳細に理解する必要はありません。 代わりに、ユーザーがユーザーのビジネスアクティビティにどのように関係するかに焦点を当て、後者がユーザーに与える影響を分析する必要があります。
• システムの日々の運用に大きな影響を与える可能性があるため、テレメトリーのオン/オフの切り替え（およびその詳細レベルの変更）を検討してください。 たとえば、プロファイリングは常に機能する必要はありませんが、オペレーターがパフォーマンスの問題を特定しようとする場合にはプロファイリングを含める必要があります。 可能であれば、アプリケーションの設定を使用して、テレメトリーを選択的に有効にします。
• 外部APMではなくオペレーティングシステムツールを使用することをお勧めします。

ご清聴ありがとうございました！



記事の一部：

主要業績評価指標分析-パート1

主要業績評価指標分析-パート2、カスタム、ビジネス、およびアプリケーションメトリックの分析について

主要業績評価指標分析-パート3、システムとサービスに関する最後のメトリック。