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

  • [アーティクル]

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

可用性の監視

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

100% より低い値は、一部のストレージ要求が失敗したことを示します。 エラーの種類 (ServerTimeoutError など) のResponseType ディメンションを調べることで、エラーが失敗する理由を確認できます。 一時的なサーバー タイムアウトなどの理由から、 Availability が一時的に 100% を下回り、サービスがパーティションを移動して要求の負荷分散を向上させる必要があります。クライアント アプリケーションの再試行ロジックでは、このような断続的な条件を処理する必要があります。 Availability メトリックは、アカウントでもトランザクションが発生した期間のみ使用できます。

Azure Monitor の機能を使用すると、サービスの可用性が指定のしきい値を下回った場合にアラートを生成できます。

メトリックが調整エラーの増加を示す

Storage サービスのスケーラビリティ ターゲットを超えると、調整エラーが生じます。 Storage サービスは、1 つのクライアントやテナントがサービスを占有してしまうことがないよう、調整を行います。 詳細については、「Standard Storage アカウントのスケーラビリティとパフォーマンスのターゲット」を参照し、ストレージ アカウントのスケーラビリティ ターゲットと、ストレージ アカウントのパーティション用のパフォーマンス ターゲットの詳細を確認してください。

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

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

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

調整エラーの一時的増加

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

注意

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

調整エラーの永続的増加

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

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

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

Note

パフォーマンス テストを実行すると、アプリケーションにおける非効率的なクエリ設計が明らかになります。

メトリックがタイムアウト エラーの増加を示す

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

メトリックが、いずれかの Storage サービスのタイムアウト エラーが増加していることを示しています。 同時に、クライアントは、ストレージ操作により「500 操作タイムアウト」HTTP ステータス メッセージを大量に受け取ります。

Note

パーティションを新しいサーバーに移動するときに、Storage サービスの負荷分散要求としてタイムアウト エラーが一時的に表示される場合もあります。

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

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

メトリックがネットワーク エラーの増加を示す

ネットワーク エラーは、ResponseType ディメンションが NetworkError と等しい場合に発生します。 このエラーは、クライアントがストレージ要求を出す際に Storage サービスによりネットワーク エラーが検出されると生じます。

多くの場合、このエラーの原因は、Storage サービスでタイムアウト期間が切れる前にクライアントが切断することです。 クライアントのコードを調べて、Storage サービスからクライアントが切断した理由とタイミングを把握してください。 また、サードパーティ製のネットワーク分析ツールを使用して、クライアントからネットワーク接続の問題を調査することもできます。

関連項目

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

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