次の方法で共有

Azure ストレージ アカウントのパフォーマンスのトラブルシューティング

  • [アーティクル]

この記事は、予期しない動作の変化 (通常よりも遅い応答時間など) を調査するのに役立ちます。 これらの動作の変化は、多くの場合、Azure Monitor でストレージ メトリックを監視することによって特定できます。 Azure Monitor でのメトリックとログの使用に関する一般的な情報については、次の記事を参照してください。

パフォーマンス監視

ストレージ サービスのパフォーマンスを監視するには、次のメトリックを使用できます。

  • SuccessE2ELatency と SuccessServerLatency の値は、Storage サービスまたは API 操作タイプが要求の処理に要した時間の平均を示します。 SuccessE2ELatency は、要求の読み取りと応答の送信に要した時間に加えて、要求の処理にかかる時間を含むエンドツーエンドの待機時間の測定値です (したがって、要求がストレージ サービスに到達した後のネットワーク待機時間も含まれます)。 SuccessServerLatency は処理時間のみを測定するため、クライアントとの通信に関連するネットワーク待機時間は除外されます。

  • Egress と Ingress メトリックの値は、Storage サービスまたは特定の API 操作タイプの送受信データの総量 (バイト単位) を示します。

  • Transactions メトリックは、API 操作の Storage サービスが受信した要求の総数を示します。 トランザクション は、ストレージ サービスが受信した要求の合計数です。

これらの値の予期しない変更を監視できます。 これらの変更は、詳細な調査が必要な問題を示している可能性があります。

Azure ポータルでは、このサービスのパフォーマンス メトリックのいずれかが指定したしきい値を下回るか超えたときに通知するアラート ルールを追加できます。

パフォーマンスの問題を診断する

アプリケーションのパフォーマンスは主観的であり、特にユーザーの見方によって変わることがあります。 そのため、パフォーマンスに問題がある可能性のある場所を特定できるように、メトリックの基準値を設けておくことが重要です。 クライアント アプリケーションの観点から見ると、Azure Storage サービスのパフォーマンスはさまざまな要因によって影響を受ける可能性があります。 これらの要因は、ストレージ サービス、クライアント、またはネットワーク インフラストラクチャで動作する可能性があります。 そのため、パフォーマンスの問題の原因を特定するための戦略を立つことが重要です。

メトリックを使用してパフォーマンスの問題の原因と考えられる場所を特定したら、ログ ファイルを使用して詳細な情報を見つけ、問題をさらに診断してトラブルシューティングすることができます。

メトリックは、SuccessE2ELatency が高く、SuccessServerLatency が低いことを示します

場合によっては、 SuccessE2ELatency が SuccessServerLatency よりも高いことがわかります。 Storage サービスは、正常な要求に対するメトリック SuccessE2ELatency のみを計算します。SuccessServerLatency と違い、クライアントでデータを送信し、Storage サービスから確認応答を受け取るまでにかかる時間が含まれます。 そのため、 SuccessE2ELatency と SuccessServerLatency の違いは、クライアント アプリケーションの応答が遅いか、ネットワーク上の状態が原因である可能性があります。

Note

Storage Logging ログ データの個々のストレージ操作に関して、E2ELatency と ServerLatency を表示することもできます。

クライアントのパフォーマンス上の問題に関する調査

クライアントが応答が遅くなる原因としては、使用可能な接続やスレッドが限られているか、CPU、メモリ、ネットワーク帯域幅などのリソースが不足している可能性があります。 より効率的にクライアント コードを変更するか (たとえば、ストレージ サービスへの非同期呼び出しを使用して)、またはより多くのコアとより多くのメモリを持つ大規模な仮想マシンを使用して、問題を解決できる場合があります。

テーブル サービスとキュー サービスの場合、Nagle アルゴリズムは、SuccessServerLatencyと比較してSuccessE2ELatency が高くなる可能性もあります。 詳細については、「 Nagle のアルゴリズムは小さな要求に対してフレンドリではありません投稿を参照してください。 System.Net名前空間の ServicePointManager クラスを使用して、コード内の Nagle アルゴリズムを無効にすることができます。 この操作は、既に開かれている接続には影響を与えないため、アプリケーションで Table サービスまたは Queue サービスを呼び出す前に実行する必要があります。 次の例は、worker ロールの Application_Start メソッドに由来します。

var connectionString = Constants.connectionString;
QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

クライアント側のログを調べて、クライアント アプリケーションが送信している要求の数を確認し、CPU、.NET ガベージ コレクション、ネットワーク使用率、メモリなど、クライアント内の一般的な .NET 関連のパフォーマンスボトルネックを確認する必要があります。 .NET クライアント アプリケーションのトラブルシューティングの開始点として、「 Debugging, Tracing, and Profiling (デバッグ、トレース、およびプロファイリング)」を参照してください。

ネットワーク待ち時間に関する問題の調査

一般的に、エンド ツー エンドの待ち時間が長くなるのは、ネットワークの一時的な状態に起因します。 Wireshark などのツールを使用して、破棄されたパケットなどの一時的なネットワークの問題と永続的なネットワークの問題の両方を調査できます。

メトリックでは SuccessE2ELatency も SuccessServerLatency も低いのにクライアントで大きな遅延が発生している

このシナリオの場合、最も可能性が高い原因は、Storage サービスに到達するストレージ要求の遅延です。 クライアントからの要求が BLOB サービスに送信されない理由を調査する必要があります。

要求送信でクライアントに遅延が生じる理由の 1 つとして、使用可能な接続またはスレッドの数が制限されていることが考えられます。

また、クライアントが複数回再試行を実行しているかどうかを確認し、その理由を調査します。 クライアントが複数回再試行しているかどうかを確認するには、以下を実行できます。

  • ログを調べます。 複数回再試行が行われている場合は、同じクライアント要求 ID を持つ複数の操作が表示されます。

  • クライアントのログを調べます。 詳細ログに、再試行が発生したことが示されます。

  • コードをデバッグし、要求に関連付けられている OperationContext オブジェクトのプロパティを確認します。 操作が再試行された場合、 RequestResults プロパティには複数の一意の要求が含まれます。 各要求の開始時刻と終了時刻をチェックすることもできます。

クライアントに問題がない場合、パケット損失などの考えられるネットワーク問題について調査してください。 Wireshark などのツールを使用して、ネットワーク問題を調査できます。

メトリックが高い SuccessServerLatency を示す

BLOB ダウンロード要求の SuccessServerLatency が高い場合、Storage ログを使用して、同じ BLOB (または BLOB セット) に対して反復されている要求がないかどうかを確かめます。 BLOB アップロード要求の場合は、クライアントが使用しているブロック サイズを調査する必要があります (たとえば、サイズが 64 K 未満のブロックは、読み取りも 64 K 未満のチャンクに含まれている場合を除き、オーバーヘッドが発生する可能性があります)。また、複数のクライアントがブロックを同じ BLOB に並列にアップロードしている場合などです。 また、1 秒あたりのスケーラビリティ ターゲットを超える要求数の急増がないか、分単位のメトリックを確認する必要があります。

同じ BLOB または BLOB のセットに対して要求が繰り返し発生したときに blob ダウンロード要求の SuccessServerLatency が高い場合は、Azure Cache または Azure Content Delivery Network (CDN) を使用してこれらの BLOB をキャッシュすることを検討してください。 アップロード要求に関しては、ブロック サイズを大きくすることによってスループットを改善できます。 テーブルに対するクエリの場合、同じクエリ操作を実行し、データが頻繁に変更されないクライアントにクライアント側のキャッシュを実装することもできます。

また SuccessServerLatency 値が高いという症状は、テーブルやクエリがうまく設計されていないために、スキャン操作が生じたり、前後にアンチ パターンが存在したりする場合に起こり得ます。

Note

包括的なパフォーマンス チェックリストは、 Microsoft Azure Storage のパフォーマンスとスケーラビリティのチェックリストから確認できます。

キューのメッセージ配信で予期しない遅延が発生する

アプリケーションがキューにメッセージを追加してからキューから読み取れるまでの間に遅延が発生している場合は、次の手順を実行して問題を診断します。

  • アプリケーションがキューにメッセージを正常に追加していることを確認します。 成功する前に、アプリケーションが AddMessage メソッドを複数回再試行していないかどうかを確認します。

  • キューにメッセージを追加する worker ロールと、キューからメッセージを読み取る worker ロールの間にクロック スキューがないことを確認します。 クロック スキューにより、処理に遅延があるかのように表示されます。

  • キューからのメッセージを読み取る worker ロールに障害がないことを確かめます。 キュー クライアントが GetMessage メソッドを呼び出したが、受信確認で応答できない場合、メッセージは、 invisibilityTimeout 期間が経過するまでキューに表示されなくなります。 有効期限が切れた時点で、メッセージは再び処理可能になります。

  • キューの長さが時間の経過とともに大きくなっているかどうかを確認してください。 これは、他のワーカーがキューに配置しているすべてのメッセージを処理するのに十分なワーカーがない場合に発生する可能性があります。 また、メトリックを調べて、削除要求が失敗しているかどうかを確認し、メッセージのデキュー数を確認します。これは、メッセージの削除試行が繰り返し失敗したことを示している可能性があります。

  • 通常よりも長期間に渡り、予想された E2ELatency 値および ServerLatency 値よりも高くなっているキュー操作がないかどうか、Storage ログを調べます。

関連項目

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。