Azure ストレージ アカウントの可用性に関する問題のトラブルシューティング

  • [アーティクル]

この記事は、可用性の変更 (失敗した要求の数など) を調査するのに役立ちます。 これらの可用性の変更は、多くの場合、Azure Monitor でストレージ メトリックを監視することによって識別できます。 Azure Monitor でのメトリックとログの使用に関する一般的な情報については、次の記事を参照してください。

可用性の監視

可用性メトリックの値を監視することで、ストレージ アカウント内のストレージ サービスの 可用性 を監視する必要があります。 可用性メトリックには、パーセンテージ値が含まれています。 これは、請求可能な要求の合計値を取得し、予期しないエラーを発生させた要求を含む、該当する要求の数で割ることによって計算されます。

100% 未満の値は、一部のストレージ要求が失敗していることを示します。 エラーの種類 (ServerTimeoutError など) の ResponseType ディメンションを調べることで、エラーが失敗する理由を確認できます。 サービスがパーティションをより適切な負荷分散要求に移動している間に、一時的なサーバー タイムアウトなどの理由により 、可用性 が一時的に 100% を下回ると予想されます。クライアント アプリケーションの再試行ロジックは、このような断続的な条件を処理する必要があります。

Azure Monitor の機能を使用して、サービスの 可用性 が指定したしきい値を下回ったかどうかを警告できます。

メトリックは、調整エラーの増加を示します

調整エラーは、ストレージ サービスのスケーラビリティ ターゲットを超えると発生します。 ストレージ サービスは、1 つのクライアントまたはテナントが他のユーザーを犠牲にしてサービスを使用できないように調整します。 詳細については、 ストレージ アカウントのスケーラビリティ ターゲットとストレージ アカウント内のパーティションのパフォーマンス ターゲット の詳細については、「標準ストレージ アカウントのスケーラビリティとパフォーマンスのターゲット」を参照してください。

ResponseType ディメンションの ClientThrottlingError または ServerBusyError の値が、調整エラーで失敗している要求の割合の増加を示している場合は、次の 2 つのシナリオのいずれかを調査する必要があります。

  • PercentThrottlingError の一時的な増加
  • PercentThrottlingError エラーの永続的な増加

スロットル エラーの増加は、多くの場合、ストレージ要求の数の増加と同時に、またはアプリケーションを最初にロード テストするときに発生します。 これは、クライアント内で"503 Server Busy" または "500 操作タイムアウト" の HTTP 状態メッセージとして表示される場合もあります。

調整エラーの一時的な増加

アプリケーションの高いアクティビティ期間と一致する調整エラーの急増が発生する場合は、クライアントで再試行のための指数関数 (線形ではない) バックオフ戦略を実装します。 バックオフ再試行は、パーティションの即時負荷を軽減し、アプリケーションがトラフィックの急増をスムーズにするのに役立ちます。 ストレージ クライアント ライブラリを使用して再試行ポリシーを実装する方法の詳細については、 RetryOptions.MaxRetries プロパティを参照してください。

注:

また、アプリケーションのアクティビティが高い期間と一致しない調整エラーが急増する場合もあります。 最も可能性の高い原因は、負荷分散を向上させるためにパーティションを移動するストレージ サービスです。

調整エラーの永続的な増加

トランザクション ボリュームが永続的に増加した後、またはアプリケーションで初期ロード テストを実行しているときに、調整エラーの値が一貫して高い場合は、アプリケーションがストレージ パーティションをどのように使用しているか、ストレージ アカウントのスケーラビリティ ターゲットに近づいているかどうかを評価する必要があります。 たとえば、キューで調整エラー (1 つのパーティションとしてカウントされます) が表示される場合は、追加のキューを使用してトランザクションを複数のパーティションに分散することを検討してください。 テーブルで調整エラーが発生する場合は、別のパーティション分割スキームを使用して、より広い範囲のパーティション キー値を使用してトランザクションを複数のパーティションに分散することを検討してください。 この問題の一般的な原因の 1 つは、パーティション キーとして日付を選択し、特定の日のすべてのデータが 1 つのパーティションに書き込まれる (読み込み中に書き込みのボトルネックが発生する可能性がある) アンチパターンの追加/追加です。 別のパーティション分割設計を検討するか、BLOB ストレージを使用することがより優れたソリューションであるかどうかを評価します。 また、トラフィックの急増によって調整が発生しているかどうかをチェックし、要求のパターンをスムージングする方法を調査します。

トランザクションを複数のパーティションに分散する場合でも、ストレージ アカウントに設定されているスケーラビリティの制限に注意する必要があります。 たとえば、10 個のキューを使用し、1 秒あたり最大 2,000 1 KB のメッセージを処理する場合、ストレージ アカウントの 1 秒あたり 20,000 メッセージの全体的な制限になります。 1 秒あたり 20,000 を超えるエンティティを処理する必要がある場合は、複数のストレージ アカウントを使用することを検討してください。 また、ストレージ サービスがクライアントを調整すると、要求とエンティティのサイズが影響を受けます。 より大きな要求とエンティティがある場合は、より早く調整される可能性があります。

クエリの設計が非効率的な場合、テーブル パーティションのスケーラビリティの制限に達する可能性もあります。 たとえば、パーティション内のエンティティの 1% のみを選択するが、パーティション内のすべてのエンティティをスキャンするフィルターを含むクエリは、各エンティティにアクセスする必要があります。 読み取られたすべてのエンティティは、そのパーティション内のトランザクションの合計数にカウントされます。 そのため、スケーラビリティ ターゲットに簡単に到達できます。

注:

パフォーマンス テストでは、アプリケーション内の非効率的なクエリ設計が明らかになるはずです。

メトリックは、タイムアウト エラーの増加を示します

タイムアウト エラーは、 ResponseType ディメンションが ServerTimeoutError または ClientTimeout と等しい場合に発生します。

メトリックは、いずれかのストレージ サービスのタイムアウト エラーの増加を示します。 同時に、クライアントはストレージ操作から大量の "500 操作タイムアウト" HTTP 状態メッセージを受信します。

注:

ストレージ サービスが新しいサーバーにパーティションを移動することで要求を負荷分散するため、タイムアウト エラーが一時的に発生する可能性があります。

サーバーのタイムアウト (ServerTimeOutError) は、サーバー上のエラーによって発生します。 クライアントのタイムアウト (ClientTimeout) は、サーバー上の操作がクライアントによって指定されたタイムアウトを超えたために発生します。 たとえば、ストレージ クライアント ライブラリを使用するクライアントは、操作のタイムアウトを設定できます。

サーバーのタイムアウトは、ストレージ サービスに関する問題を示し、さらに調査する必要があります。 メトリックを使用して、サービスのスケーラビリティの制限に達しているかどうかを確認し、この問題の原因となっている可能性のあるトラフィックの急増を特定できます。 問題が断続的な場合は、サービスの負荷分散アクティビティが原因である可能性があります。 問題が永続的であり、アプリケーションがサービスのスケーラビリティの制限に達したために発生しない場合は、サポートの問題を発生させる必要があります。 クライアントのタイムアウトの場合は、タイムアウトがクライアントで適切な値に設定されているかどうかを判断し、クライアントで設定されたタイムアウト値を変更するか、テーブル クエリの最適化やメッセージのサイズの縮小など、ストレージ サービスの操作のパフォーマンスを向上させる方法を調査する必要があります。

メトリックは、ネットワーク エラーの増加を示します

ResponseType ディメンションが NetworkError と等しい場合、ネットワーク エラーが発生します。 これは、クライアントがストレージ要求を行ったときにストレージ サービスがネットワーク エラーを検出したときに発生します。

このエラーの最も一般的な原因は、ストレージ サービスでタイムアウトが切れる前のクライアントの切断です。 クライアントのコードを調査して、クライアントがストレージ サービスから切断される理由とタイミングを理解します。 サードパーティのネットワーク分析ツールを使用して、クライアントからのネットワーク接続の問題を調査することもできます。

関連項目

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

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