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

  • [アーティクル]

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

パフォーマンスの監視

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

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

  • エグレスとイングレスのメトリックは、ストレージ サービスまたは特定の API 操作の種類を介して送受信されるデータの合計量 (バイト単位) を示します。

  • [トランザクション] メトリックには、API 操作のストレージ サービスが受信している要求の合計数が表示されます。 トランザクション は、ストレージ サービスが受け取る要求の合計数です。

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

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

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

アプリケーションのパフォーマンスは、特にユーザーの観点から主観的な場合があります。 そのため、パフォーマンスの問題が発生する可能性がある場所を特定するために、ベースライン メトリックを使用できるようにする必要があります。 多くの要因が、クライアント アプリケーションの観点から Azure ストレージ サービスのパフォーマンスに影響を与える可能性があります。 これらの要因は、ストレージ サービス、クライアント、またはネットワーク インフラストラクチャで動作する可能性があります。 そのため、パフォーマンスの問題の発生元を特定するための戦略を持つことが重要です。

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

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

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

注:

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

クライアントのパフォーマンスの問題の調査

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

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

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

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

ネットワーク待機時間の問題の調査

通常、ネットワークによって発生するエンド ツー エンドの待機時間が長い場合は、一時的な状態が原因です。 Wiresharkなどのツールを使用して、パケットの破棄など、一時的なネットワークの問題と永続的なネットワークの問題の両方を調査できます。

メトリックは低い SuccessE2ELatency と低い SuccessServerLatency を示しますが、クライアントで待機時間が長くなっています

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

クライアントが要求の送信を遅らせる理由の 1 つは、使用可能な接続またはスレッドの数が限られているということです。

また、クライアントが複数の再試行を実行しているかどうかをチェックし、その理由を調査します。 クライアントが複数の再試行を実行しているかどうかを判断するには、次の操作を行います。

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

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

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

クライアントに問題がない場合は、パケット損失などの潜在的なネットワークの問題を調査する必要があります。 Wiresharkなどのツールを使用して、ネットワークの問題を調査できます。

メトリックは高い SuccessServerLatency を示します

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

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

SuccessServerLatency の値が高いと、スキャン操作が発生したり、append/prepend アンチパターンに従ったりする、設計が不十分なテーブルやクエリの症状になる場合もあります。

注:

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

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

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

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

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

  • キューからメッセージを読み取るワーカー ロールが失敗しているかどうかを確認します。 キュー クライアントが メソッドを GetMessage 呼び出しても受信確認の応答に失敗した場合、メッセージは期限切れになるまで invisibilityTimeout キューに表示されなくなります。 この時点で、メッセージはもう一度処理できるようになります。

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

  • 通常よりも長い期間にわたって、予想以上の E2ELatency 値と ServerLatency 値を持つキュー操作がないか、ストレージ ログを調べます。

関連項目

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

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