このリファレンスでは、Azure Storageのスケーラビリティとパフォーマンスのターゲットについて詳しく説明します。 ここで示すスケーラビリティとパフォーマンスのターゲットは、ハイエンドのターゲットですが、達成可能です。 いずれの場合も、ストレージ アカウントで実現される要求レートと帯域幅は、格納されているオブジェクトのサイズ、使用されるアクセス パターン、アプリケーションが実行するワークロードの種類によって異なります。
サービスをテストして、そのパフォーマンスが要件を満たしているかどうかを判断します。 可能であれば、トラフィック量の急増を回避し、トラフィックがパーティション間でうまく分散されるようにしてください。
アプリケーションがワークロードに対してパーティションで処理できる制限に達すると、Azure Storageはエラー コード 503 (サーバービジー) またはエラー コード 500 (操作タイムアウト) の応答を返し始めます。 503 エラーが発生した場合は、再試行に指数バックオフ ポリシーを使用するようにアプリケーションを変更することを検討してください。 指数バックオフにより、パーティションの負荷が減少し、そのパーティションへのトラフィックの急増が容易になります。
Azure Storageアカウントのサービスレベル契約(SLA)については、「SLA for Storage Accounts」をご覧ください。
Blob Storage のターゲットをスケーリングする
| リソース | 目標 |
|---|---|
| 単一の BLOB コンテナーの最大サイズ | ストレージ アカウントの最大容量と同じ |
| ブロック BLOB 内または追加 BLOB 内の最大ブロック数 | 50,000 ブロック |
| ブロック BLOB 内の最大ブロック サイズ | 4,000 MiB |
| ブロック BLOB の最大サイズ | 50,000 x 4,000 MiB (約 190.7 TiB) |
| 追加 BLOB のブロックの最大サイズ | 4 MiB |
| 追加 BLOB の最大サイズ | 50,000 x 4 MiB (約 195 GiB) |
| ページ BLOB の最大サイズ | 8 TiB2 |
| BLOB コンテナーごとの保存されるアクセス ポリシーの最大数 | 5 |
| 単一のブロック BLOB の目標リクエストレート | 1 秒あたり最大 3,000 要求 |
| 単一ページ BLOB のターゲットリクエストレート | 最大 500 要求/秒 |
| 1 つのページ BLOB のターゲット スループット | 最大 60 MiB/秒2 |
| 1 つのブロック BLOB のターゲット スループット | ストレージ アカウントイングレス/エグレスの上限まで1 |
1 1 つの BLOB のスループットは、いくつかの要因によって異なります。 これらの要因には、コンカレンシー、要求サイズ、パフォーマンスレベル、アップロードのソースの速度、ダウンロード先が含まれますが、これらに限定されません。 高スループット ブロック BLOB のパフォーマンス機能強化を活用するには、もっと大きな BLOB またはブロックをアップロードします。 具体的には、256 KiB を超える Blob またはブロック サイズで Put Blob または Put Block 操作を呼び出します。
2 階層型名前空間が有効になっているアカウントでは、ページ BLOB はまだサポートされていません。
次の表では、サービス バージョンで許可される最大ブロック サイズと BLOB サイズについて説明します。
| サービスのバージョン | 最大ブロック サイズ (Put Block 使用) | 最大 BLOB サイズ (Put Block List 使用) | 1 回の書き込み操作での最大 BLOB サイズ (Put Blob 使用) |
|---|---|---|---|
| バージョン 2019-12-12 以降 | 4,000 MiB | 約 190.7 TiB (4,000 MiB x 50,000 ブロック) | 5,000 MiB |
| バージョン 2016-05-31 からバージョン 2019-07-07 | 100 MiB | 約 4.75 TiB (100 MiB x 50,000 ブロック) | 256 MiB |
| 2016-05-31 よりも前のバージョン | 4 MiB | 約 195 GiB (4 MiB x 50,000 ブロック) | 64 MiB |
ホットパーティション:検出、監視、緩和
Azure Blob Storageはデータやリクエストをパーティション間で分散させ、ワークロードのスケールを支援します。 ストレージアカウントは利用可能な容量とスループットを持つ一方で、狭いパーティションキー範囲にトラフィックを集中させるワークロードはパーティションレベルのスループット制約を受けます。
単一のパーティションが他のパーティションよりも著しく多くのトラフィックを受け取ると、そのパーティションは ホットパーティションとなります。 ブロブのパーティションキーはストレージアカウント名、コンテナ名、ブロブ名を組み合わせるため、逐次またはアペンドオンリーの命名方式でトラフィックを単一のパーティションに集中させることができます。
パーティションがホットになると、アプリケーションは遅延の増加を観察し、ストレージアカウントが文書化されたスケーラビリティ制限に近づく前にHTTP 503(サーバー忙しい)またはHTTP 500(操作タイムアウト)の応答を受け取ることがあります。
ホットパーティションを軽減するために:
トラフィックを単一のパーティションに集中させる逐次的または追加のみのブロブ命名方式は避けましょう。
スロットリングエラーが発生した場合は指数関数的なバックオフ再試行戦略を用いましょう。
新しいワークロードを導入する際には、リクエスト率を徐々に上げましょう。
スロットリングを検出し、過剰な需要の原因を特定するには、Azure Monitorの指標とリソースログを活用してください。
詳細については、Azure Blob StorageのMitigate hot partitionsをご覧ください。
