Azure Blob Storageはデータをパーティション間で分散させ、スケーラブルなパフォーマンスを提供します。 トラフィックが単一のパーティションに集中すると、そのパーティションがボトルネックとなることがあり、ホット パーティションと呼ばれる状態になります。 この記事では、ホットパーティションとは何か、Azure Monitorのメトリクスやリソースログを通じてそれらを認識する方法、そして負荷をより均等に分散させてスロットリングエラーを減らすための対策について説明します。
ホットパーティションを理解する
Azure Blob Storageはパフォーマンスとスループットをスケールさせるために、自動的にデータをパーティション間で分散させます。 単一のパーティションが他のパーティションよりも著しく多くのトラフィックを受け取ると、そのパーティションは ホットパーティションとなります。 ホットパーティションとは、多数の読み書き、更新リクエストが同じパーティションに集まる場合に発生し、サービスのワークロードを効果的に分散させる能力を制限します。 その結果、リクエストはワークロードの再分配やアクセスパターンの最適化が行われるまで、遅延の増加、スロットリング、タイムアウトエラーが発生することがあります。 複数のパーティションにリクエストを分散させるのではなく、トラフィックを一部のデータに集中させるパーティショニングやネーミングスキームは、ホットパーティションを引き起こすことがよくあります。
ホットパーティションの症状と影響
ストレージパーティションがホットになると、リクエストの処理効率が低下します。 パーティションのスケーラビリティ制限に近づくと、Azure Storageはサービスを保護し、他のワークロードの信頼性を維持するためにリクエストを制限し始めます。 クライアントアプリケーションは遅延の増加、スループットの低下、一時的なリクエスト失敗を経験します。
ホットパーティションの一般的な症状には以下のようなものがあります:
- パーティションが一時的に追加のリクエストを処理できなくなったことを示すHTTP 503(サーバー忙し)応答。
- パーティションが重負荷でリクエストが完了するのに時間がかかりすぎる場合、HTTP 500(オペレーションタイムアウト)の応答があります。
- 最終的に成功するリクエストであっても、リクエストの遅延が増加します。
- 自動クライアント再トライは、複数のクライアントが同時に再試行するとトラフィックを増加させ、パフォーマンスの問題を長引かせることがあります。
- スループットの低下。これは、ストレージ アカウント全体の容量は十分であるにもかかわらず、アプリケーションが 1 秒あたりに処理する操作数が予想より少ない状態を指します。
ホットパーティションは、トラフィックが単一のパーティションに集中するアクセスパターンによって引き起こされることが多いです。 一般的な例としては、連続したブロブ名、追加専用ワークロード、そして単一のパーティションに不釣り合いなトラフィックを送るパーティションキー設計などがあります。 ワークロードが均等に分散されていないと、影響を受けたパーティションがストレージアカウントの他の部分より先に限界に達し、アプリケーションのパフォーマンスに影響を及ぼすボトルネックを生み出します。
多くのアプリケーションにおいて、ホットパーティションの最初の兆候は、遅延の増加、再試行率の増加、そして需要が高い期間中の503または500エラーの増加の組み合わせです。
Azure Monitorのメトリクスとリソースログを使ってスロットリングエラーを検出します
Azure Storageは、ワークロードがストレージアカウントやパーティションのスケーラビリティ目標を超えるとリクエストをスロットルします。 スロットリングはHTTP 503(サーバー忙しい) または 500(操作タイムアウト) の応答としてよく見られます。 Azure Storage クライアント ライブラリでは、スロットリングされた要求を自動的に再試行することがよくあるため、アプリケーションのパフォーマンスに大きな影響が及ぶ前にスロットリングを検出するには、監視が不可欠です。
Azure Monitorのメトリクスを使ってスロットリングエラーを特定しましょう
スロットリングを検出するには、ストレージアカウントのAzure Monitorのメトリクスを分析してください。 トランザクション指標とResponseType次元を組み合わせることで、ストレージリクエストの結果を可視化し、スロットリングに関連する障害を特定するのに役立ちます。
スロットリングを特定する指標
スロットリングの調査に役立つ以下のAzure Monitor指標があります:
| Metric | Purpose |
|---|---|
| トランザクション | ストレージサービスが処理したリクエスト数を測定します。 ResponseType次元を使って、制限されたリクエストを特定してください。 |
| 可用性 | 成功したリクエストの割合を示します。 可用性の低下はスロットリングやその他のリクエスト失敗を示す可能性があります。 |
| 成功時の E2E レイテンシー | ネットワークおよびクライアント側の処理を含むエンドツーエンドのリクエスト遅延を測定します。 増加している場合は、スロットリングが原因の再試行を示している可能性があります。 |
| 成功サーバーの待機時間 | ストレージサービスがリクエストを処理するのに必要な時間を測定します。 この指標とE2Eレイテンシを比較することで、サービス側の遅延とクライアントの再送信を区別するのに役立ちます。 |
一般的なスロットリングパターンは、遅延の増加とそれに伴うスロットリング関連の応答タイプの増加、そして利用可能性の低下です。
ResponseType ディメンションを使用してスロットリングを特定します
ResponseType次元は、Azure Monitorのメトリクスにおけるスロットリング条件を特定する主要なツールです。 関連する価値観には以下が含まれます:
| ResponseTypeの値 | Description |
|---|---|
| ServerBusyError | ストレージサービスはスケーラビリティ目標を超えたためHTTP 503を返しました。 |
| ClientThrottlingError | リクエストはストレージサービスに届く前に制限されました。 |
| ClientAccountRequestThrottlingError | アカウントレベルのリクエストレート上限が超えていました。 |
| クライアント アカウントの帯域幅調整エラー | アカウントの帯域幅制限がオーバーしていました。 |
| スロットリングでの成功 | 当初はリクエストが制限されましたが、リトライの後に最終的に成功しました。 |
これらの値を長期的に追跡することで、一時的なスロットリングの急増や持続的なスケーラビリティの問題を特定するのに役立ちます。
寸法を使ってスロットリングの原因を特定しましょう
Azure Monitorのメトリクス寸法は、スロットリングに関与するワークロードを特定するのに役立ちます:
| ディメンション | Purpose |
|---|---|
| ResponseType | 特定のスロットリングやエラー条件を特定します。 |
| ApiName | スロットリングが発生している操作( PutBlob、 GetBlob、 ListBlobsなど)を特定します。 |
| GeoType | 地理的冗長ストレージアカウントにおけるプライマリエンドポイントとセカンダリエンドポイントへのトラフィックを区別します。 |
| 認証 | スロットリングが特定の認証方法に関連しているかどうかを判断するのに役立ちます。 |
例えば、スロットリングが主に PutBlob 操作で発生する場合、作業負荷は書き込み集約的になることがあります。 特定のAPI操作でスロットリングレートが高まった場合、最適化はアプリケーション全体ではなくその操作に集中できます。
Azure Monitor リソース ログを分析する
メトリクスはスロットリングの有無を特定させますが、Azure Monitorのリソースログはリクエストレベルの詳細を提供し、根本原因の診断に役立ちます。 リソースログは、スロットリング、タイムアウト、認可、ネットワーク関連エラーなど、成功・失敗したリクエストの両方を記録します。
Azure Blob Storageの場合、リソースログがLog Analyticsワークスペースに送信された後、StorageBlobLogsテーブルでレコードが利用可能になります。
スロットリングイベントのリソースログをクエリする
これらのクエリを実行する前に、リソースログがLog Analyticsワークスペースに送信されていることを確認してください。
Kustoクエリ言語(KQL)を使って、一般的なスロットリング関連のステータスコードを返すリクエストを特定します:
StorageBlobLogs
| where StatusCode in (500, 503)
| summarize RequestCount = count() by OperationName, StatusCode, bin(TimeGenerated, 15m)
| order by TimeGenerated desc
このクエリを拡張し、操作、認証タイプ、発信者のIPアドレス、またはアプリケーション識別で結果をグループ化し、制限されたリクエストを生成しているワークロードを特定します。 リソースログは、スロットリングが特定のアプリケーション、運用、または期間内に集中しているかどうかを判別するのに特に有用です。
スロットリングに関するアラート条件
次に関する Azure Monitor アラートを作成します。
- ServerBusyErrorトランザクションの継続的な発生。
- スロットリングに関連する ResponseType 値の増加。
- 可用性指標が許容範囲を下回る。
- 遅延の増加はスロットリングイベントと相関しています。
- ストレージのスケーラビリティ制限に近づく要求ボリュームの急増。
推奨されるモニタリングワークフロー
- トランザクション指標を監視し、結果をResponseTypeで分割してください。
- ServerBusyErrorやClientThrottlingErrorのようなスロットリング関連のレスポンスタイプの増加に注目してください。
- ApiName次元を使って影響を受けた操作を特定します。
- スロットリングイベントと可用性、成功E2E遅延、成功サーバー遅延の変化を関連付けます。
- Azure Monitorのリソースログを使って、どのリクエスト、操作、アプリケーションがトラフィックを制限しているかを特定しましょう。
- ユーザーに影響が出る前にスロットリングの問題を検出できるようアラートを設定しましょう。
Azure Monitorの指標、寸法、リソースログを組み合わせることで、スロットリングの状況を迅速に検出し、過剰な需要の原因を特定し、アプリケーションのパフォーマンス低下前に是正措置を講じることができます。
ホットパーティションの軽減
ホットパーティションを防ぐために、リクエストをパーティション間で均等に分散させ、スロットリングが発生した場合にアプリケーションが適切に応答するようにしましょう。
効率的な分割および命名方式を活用しましょう
パーティションキー、ブロブ名、その他の識別子を設計し、リクエストが複数のパーティションに分散されるようにしましょう。 ほとんどのリクエストを同じパーティションに誘導する逐次または付加のみの命名パターンは避けてください。 詳細は「 Optimize Blob Partitions and naming scheme(最適化ブロブ分割と命名スキーム)」を参照してください。
再試行には指数的バックオフを使います
リクエストがスロットルされ、 503(サーバー忙しい) または 500(操作タイムアウト) エラーが返された場合は、指数的バックオフ戦略を用いてリクエストをやり直します。 この方法は影響を受けたパーティションへの負担を軽減し、Azure Storageが負荷を再調整したり、一時的な需要急増から回復する時間を与えます。
指数的バックオフ再試行動作は、Azure Storageクライアントライブラリ、SDK、REST APIを使ってAzure Storageにアクセスするカスタムアプリケーションに最も関連性があります。 多くのMicrosoft サービス、マネージドアプリケーション、サードパーティクライアントはすでに適切なリトライロジックを実装しているため、追加の設定は不要かもしれません。 カスタムアプリケーションを開発する場合は、リトライポリシーが有効化され、Azure Storageのベストプラクティスに従って設定されていることを確認してください。 次の記事のいずれかを参照してください。
- .NETのリトライポリシーを実装してください
- Javaのリトライポリシーを実装する
- JavaScriptの再試行ポリシーを実装してください
- Pythonのリトライポリシーを実装してください
- Goのリトライポリシーを導入してください
リクエスト量の急増を避ける
新しいワークロードを導入したり、パフォーマンステストを実行したり、大量のデータを処理する際には、ピークトラフィックを即座に発生させるのではなく、リクエスト率を徐々に上げましょう。 Azure Storageは需要の変化に応じて自動的にパーティションのロードバランスを調整しますが、急激なトラフィックの急増は一時的にパーティションを圧倒し、サービスが調整するまでのスロットリングを引き起こすことがあります。
次のステップ
詳細な実装ガイダンスについては、以下をご覧ください:
