Azure Storageを使う管理者・開発者がまず押さえるべき結論は、2026年5月19日更新の「Scalability and performance targets for Azure Blob Storage」は、Azure Blob Storageの上限値と性能目標を確認するための基準資料であり、単独で強制移行や設定変更を求める告知ではない、という点です。
ただし、Blobの最大サイズ、単一Blobあたりのリクエスト目標、サービスバージョン別のアップロード上限、503や500発生時のリトライ設計は、実運用の性能トラブルに直結します。特に大容量アップロード、ログ収集、動画配信、データレイク、IaCによる大量展開を行っている環境では、今回の更新をきっかけに「設計値」と「実測値」を見直すべきです。Microsoft Learnの該当ページは、Azure Blob Storageのスケーラビリティとパフォーマンス目標を整理する公式リファレンスとして、2026年5月19日に更新されています。(Microsoft Learn)
Azure Blob Storageの「Scalability and performance targets」は何を示す資料か
Azure Blob Storageの「Scalability and performance targets」は、ストレージアカウントやBlobがどの程度の容量・リクエスト・スループットを目標値として扱えるかを確認するための公式資料です。
ここで重要なのは、記載されている値が「どの環境でも必ず出る保証値」ではないことです。Microsoftは、これらを高い性能目標として示しつつ、実際に達成できるリクエストレートや帯域は、オブジェクトサイズ、アクセスパターン、ワークロードの種類に依存すると説明しています。急激なトラフィック増加を避け、パーティションに負荷を分散し、要件を満たすか事前にテストすることが前提です。(Microsoft Learn)
実務では、この資料を次のように使います。
| 確認したいこと | 見るべきポイント | 実務上の判断 |
|---|---|---|
| 大容量ファイルを保存できるか | Block Blobの最大サイズ、ブロック数、サービスバージョン | 古いSDKやREST APIバージョンを使っていないか確認する |
| 高頻度アクセスに耐えられるか | 単一Block Blobのリクエスト目標、アカウント側の上限 | 1つのBlobにアクセスを集中させず、分散・キャッシュ・CDNを検討する |
| ログや追記データを扱えるか | Append Blobの最大サイズ、ブロックサイズ | 1本のAppend Blobに書き込みを集中させない |
| Data Lake Gen2と併用できるか | 階層型名前空間とPage Blobの制約 | Page Blobを前提にした設計を避ける |
| 障害なのかスロットリングなのか | 503、500、ServerBusy、Operation Timeout | Azure Monitorとリトライポリシーを確認する |
2026年5月19日更新で何が変わったのか
今回の更新で押さえるべき点は、「サービスの新機能追加」や「大規模な制限値変更」よりも、公式リファレンスとしての表記整理と内容の明確化です。
GitHub上の差分を見ると、該当記事ではタイトルが「Blob storage」から「Azure Blob Storage」を含む表現に改められ、説明文も「サービス制限を理解し、最適なパフォーマンスのためにアプリケーションを設計する」という意図がより明確になっています。また、スケール目標のincludeファイルでは更新日が2026年5月18日に変更され、4000 MiBが4,000 MiBのように桁区切り付きの表記へ整理されています。数値自体の意味が変わったというより、読みやすさと表現の整合性を高めた更新と見るのが妥当です。(GitHub)
管理者や開発者にとっての影響は、次の3点です。
| 影響範囲 | 今回の見方 | 対応の優先度 |
|---|---|---|
| 既存のBlob Storage運用 | 更新だけで直ちに設定変更が必要とは限らない | 中 |
| 大容量アップロード処理 | サービスバージョン別の最大サイズを再確認すべき | 高 |
| 高トラフィックアプリ | 単一Blob、パーティション、アカウント上限を再評価すべき | 高 |
| GPv1や古いBlob Storageアカウント | GPv2移行計画と合わせて確認すべき | 高 |
| IaCや大量デプロイ | Storage Resource Providerの管理操作上限も確認すべき | 中 |
Azure Blob Storageで押さえるべき主要なスケーラビリティ目標
Azure Blob Storageのスケーラビリティ目標では、単一Blob、コンテナー、Blob種別ごとの上限を分けて考える必要があります。よくある誤解は、「1つのBlobの目標値」と「ストレージアカウント全体の目標値」を混同することです。
公式ページに記載されている主な値は次のとおりです。(Microsoft Learn)
| 項目 | 目標・上限 | 実務上の注意点 |
|---|---|---|
| 単一Blobコンテナーの最大サイズ | ストレージアカウントの最大容量と同じ | アカウント全体の容量制限も合わせて確認する |
| Block BlobまたはAppend Blobの最大ブロック数 | 50,000ブロック | 大容量Blobではブロックサイズ設計が重要 |
| Block Blobの最大ブロックサイズ | 4,000 MiB | 古いサービスバージョンでは小さくなる |
| Block Blobの最大サイズ | 約190.7 TiB | 4,000 MiB × 50,000ブロックが前提 |
| Append Blobの最大ブロックサイズ | 4 MiB | 高頻度ログを1本に集約しすぎない |
| Append Blobの最大サイズ | 約195 GiB | 長期ログはローテーション設計が必要 |
| Page Blobの最大サイズ | 8 TiB | 階層型名前空間が有効なアカウントでは未対応 |
| Blobコンテナーごとの保存済みアクセスポリシー | 5個 | SAS運用でポリシーを増やしすぎない |
| 単一Block Blobの目標リクエストレート | 最大3,000 request/sec | 1つのBlobに集中する配信・読み取りは分散を検討 |
| 単一Page Blobの目標リクエストレート | 最大500 request/sec | VMディスク系ワークロードでは別の設計観点も必要 |
| 単一Page Blobの目標スループット | 最大60 MiB/sec | 階層型名前空間との併用不可に注意 |
| 単一Block Blobの目標スループット | ストレージアカウントのingress/egress上限まで | アカウント全体の帯域制限がボトルネックになる |
ここで特に重要なのは、Block Blobの「最大190.7 TiB」という値だけを見て設計しないことです。実際のアップロードでは、REST APIのサービスバージョン、SDK、ブロックサイズ、並列度、クライアント側ネットワーク、アカウント側のingress制限が絡みます。
サービスバージョン別の最大サイズに注意する
大容量Blobのアップロードで見落とされやすいのが、Azure Storage REST APIのサービスバージョンです。現在の上限値を前提にしていても、アプリケーションやSDKが古いサービスバージョンを明示している場合、利用できる最大ブロックサイズや単一書き込みサイズが小さくなる可能性があります。
公式資料では、サービスバージョン別に次の上限が整理されています。(Microsoft Learn)
| サービスバージョン | Put Blockの最大ブロックサイズ | Put Block Listによる最大Blobサイズ | Put Blobの単一書き込み最大サイズ |
|---|---|---|---|
| 2019-12-12以降 | 4,000 MiB | 約190.7 TiB | 5,000 MiB |
| 2016-05-31〜2019-07-07 | 100 MiB | 約4.75 TiB | 256 MiB |
| 2016-05-31より前 | 4 MiB | 約195 GiB | 64 MiB |
開発チームは、次の項目を確認してください。
- Azure Storage SDKのバージョン
- REST APIで
x-ms-versionを明示しているか - 独自実装のアップロード処理でブロックサイズを固定していないか
- AzCopyやバッチ処理ツールが古いままになっていないか
- 大容量ファイルでPut Blob単体送信に依存していないか
たとえば、数百GiBの動画ファイルやバックアップファイルを扱う場合、単一のPut Blobで送るのではなく、ブロック分割とPut Block Listを前提に設計するのが基本です。古いAPIバージョンのままでは、最大サイズに達する前にクライアント側の処理が失敗することがあります。
管理者が確認すべき設定と運用ポイント
ストレージアカウント全体の上限を単一Blobの上限と分けて見る
単一Blobの上限を満たしていても、ストレージアカウント全体の要求レート、ingress、egressがボトルネックになることがあります。
標準ストレージアカウントのスケーラビリティ目標では、GPv2、GPv1、Blob Storageアカウントの既定容量や要求レート、ingress、egressが整理されています。たとえばGPv2やBlob Storageアカウントの既定最大容量は5 PiBで、リージョンによって既定の最大要求レートや帯域目標が異なります。また、一部の容量やingress上限はサポートリクエストで引き上げを依頼できるとされています。(Microsoft Learn)
管理者は、次の順序で確認すると実務的です。
| 確認順 | 確認項目 | 判断基準 |
|---|---|---|
| 1 | ストレージアカウントの種類 | GPv2か、Premium Block Blobか、古い種類か |
| 2 | リージョン | ワークロードとクライアントに近い場所か |
| 3 | 容量 | 5 PiBに近づいていないか、増加傾向はどうか |
| 4 | ingress/egress | バックアップ、配信、ETLのピーク時に余裕があるか |
| 5 | 要求レート | Transactions、Response type、ServerBusyが増えていないか |
| 6 | 冗長性 | LRS、ZRS、GRS、RA-GRSなどの要件とコストが合っているか |
GPv1や古いBlob StorageアカウントはGPv2移行も合わせて確認する
性能目標の確認と同時に、アカウント種別の見直しも重要です。MicrosoftはGPv1ストレージアカウントの廃止を案内しており、2026年10月13日までにGPv2へアップグレードする必要があると説明しています。未移行の場合は自動移行や課金影響の可能性にも触れられています。(Microsoft Learn)
GPv2へのアップグレード自体は、Azure portal、PowerShell、Azure CLIから実行でき、データコピーを伴わないAzure Resource Manager操作として説明されています。ただし、GPv2へのアップグレードは元に戻せず、アクセス層やトランザクション課金の違いによってコストが変わる可能性があります。(Microsoft Learn)
移行前に見るべきポイントは次のとおりです。
| 項目 | 確認内容 |
|---|---|
| アカウント種別 | Storage、BlobStorage、StorageV2のどれか |
| アクセス層 | Hot、Cool、Cold、Archiveの使い分けが妥当か |
| 操作回数 | 読み取り、書き込み、一覧取得が多いワークロードか |
| ライフサイクル管理 | 長期保存データを自動で低コスト層へ移せるか |
| 料金影響 | 移行前後の容量単価、トランザクション単価、取り出しコスト |
| アプリ互換性 | 古いSDK、古いAPIバージョン、ハードコードされた設定がないか |
Premium Block Blobを使うべきケースを見極める
Premium Block Blob Storageは、小さなKB単位のオブジェクトを大量に扱い、高いトランザクションレートや低レイテンシを必要とするアプリケーション向けです。一方で、Block Blobのみをサポートし、Append BlobやPage Blobはサポートされません。また、利用できるリージョンも限定されるため、展開前にリージョン対応を確認する必要があります。(Microsoft Learn)
次のような場合は、Premium Block Blobの検討価値があります。
| ワークロード | Premium検討の目安 |
|---|---|
| 小さな画像・JSON・設定ファイルを大量に読む | レイテンシと要求回数がボトルネックになっている |
| AI・分析基盤で細かいオブジェクトを頻繁に参照 | 標準アカウントでServerBusyや遅延が目立つ |
| 配信系アプリで低レイテンシが重要 | CDNやキャッシュと併用してもストレージ側が遅い |
| ログ追記やPage Blob中心 | Premium Block Blobではなく別設計を検討する |
開発者が確認すべき実装上のポイント
ブロックサイズと並列度を見直す
Azure Blob Storageの性能を引き出すには、ブロックサイズと並列度のバランスが重要です。Microsoftの開発者向けチェックリストでは、並列転送を最適化しつつ、標準アカウントでは4 MiB超、Premiumでは256 KiB超のブロックサイズを目安にすること、ただし並列度を上げすぎるとデバイスやストレージ目標を超えてスロットリングを招くことが説明されています。(Microsoft Learn)
実装では、次のような設定を見直してください。
| 設定 | 悪い例 | 改善例 |
|---|---|---|
| ブロックサイズ | 64 KiBなど小さすぎる固定値 | ワークロードに応じて数MiB以上を検証 |
| 並列度 | 無制限に同時アップロード | CPU、回線、Storage目標に合わせて上限を設定 |
| リトライ | 即時リトライを連打 | 指数バックオフを設定 |
| 大容量ファイル | Put Blob一発で送信 | Put BlockとPut Block Listを使う |
| 小さなログ | 1行ごとにBlob書き込み | ローカル集約後にまとめてアップロード |
503や500が出たら指数バックオフを使う
Azure Storageでは、アプリケーションがパーティションで処理できる限界に近づくと、503 Server Busyや500 Operation Timeoutが返る可能性があります。Microsoftは、503が発生する場合は指数バックオフによるリトライを検討するよう説明しています。(Microsoft Learn)
開発者向けチェックリストでは、例として2秒、4秒、10秒、30秒のように待機時間を伸ばすリトライ方針が示されています。重要なのは、エラー発生直後に全クライアントが同時再試行して、さらに負荷を高めないことです。(Microsoft Learn)
実装方針は次のように考えます。
| エラー状況 | 推奨対応 |
|---|---|
| 一時的な503 | 指数バックオフで再試行 |
| ServerBusyが継続 | リクエスト集中、Blob名、パーティション、アカウント上限を確認 |
| Operation Timeout | クライアント側タイムアウト、ネットワーク、サーバーレイテンシを切り分け |
| 認可エラーや存在しないBlob | 無闇にリトライせず、原因を修正 |
| ピーク時だけ遅い | キューイング、キャッシュ、処理分散を検討 |
Blob名の付け方でホットパーティションを避ける
小さなブロックサイズで大量アップロードする場合、Blob名の付け方も性能に影響します。Microsoftは、log20160101、log20160102のような連番・日付順の名前は特定範囲にトラフィックが集中しやすく、パーティション分散の観点で避けるべきと説明しています。代わりに、Blob名の早い位置にハッシュや秒単位の値を入れることが推奨されています。(Microsoft Learn)
たとえば、次のように設計します。
| 避けたいBlob名 | 改善例 |
|---|---|
logs/2026/05/19/app-000001.json | 7fa/logs/2026/05/19/app-000001.json |
backup/customer-000001.bak | 032/backup/customer-000001.bak |
events/20260519090000.json | 09/events/20260519090000.json |
ただし、現在のAzure Storageでは大きなブロックを使う場合、パーティション名の影響は小さくなるケースもあります。重要なのは、実測でServerBusyやレイテンシ悪化が出ているかを確認し、必要なワークロードにだけ命名改善を適用することです。
サーバー間コピーではダウンロードして再アップロードしない
ストレージアカウント間、またはコンテナー間でデータをコピーする場合、クライアント端末に一度ダウンロードして再アップロードすると、ネットワーク帯域、処理時間、失敗リスクが増えます。Microsoftの開発者向けチェックリストでは、サーバー間コピーにPut Block From URLなどを使うことで、帯域の無駄を減らせると説明されています。(Microsoft Learn)
移行や展開作業では、次の順に検討してください。
| 作業 | 優先したい方法 |
|---|---|
| 大量Blobのコピー | AzCopyやサーバー間コピーAPI |
| アカウント間コピー | Put Block From URL、Copy Blob系API |
| オンプレミスからの大量移行 | AzCopy、必要に応じてData Box |
| アプリ内部の小規模コピー | SDKの非同期コピー機能 |
| 緊急時の手動移動 | 一時的な対処に限定し、恒久運用にしない |
展開・移行時に見落としやすい注意点
IaCや自動化ではResource Providerの上限も見る
Blobの読み書き性能だけでなく、Azure Resource Manager経由の管理操作にもスケーラビリティ目標があります。Storage Resource Providerでは、管理操作の読み取りが5分あたり800回、書き込みが1秒あたり10回または1時間あたり1,200回、一覧操作が5分あたり100回という目標が示されています。(Microsoft Learn)
Terraform、Bicep、ARM Template、Azure CLIで大量のストレージアカウントやネットワークルールを一括更新する場合、データプレーンではなく管理プレーン側で制限に近づくことがあります。
対策としては、次のような運用が有効です。
- 大量デプロイをサブスクリプション・リージョン単位で分割する
- リトライを即時連打ではなくバックオフ付きにする
- 同じストレージアカウントへの頻繁な設定変更をまとめる
- ネットワークルールやPrivate Endpointの大量更新は事前に検証する
- CI/CDの並列実行数を制限する
階層型名前空間とPage Blobの組み合わせに注意する
Azure Data Lake Storage Gen2で使われる階層型名前空間を有効にしているアカウントでは、Page Blobがまだサポートされていないと公式ページに記載されています。(Microsoft Learn)
そのため、次のようなケースでは注意が必要です。
| ケース | 注意点 |
|---|---|
| Data Lake Gen2として利用 | Page Blob前提のワークロードを載せない |
| 既存アプリがPage Blobを利用 | HNS有効化前に互換性を確認する |
| 分析基盤とディスク系用途を同居 | 同じアカウントにまとめず分離を検討する |
| 移行後にPage Blobを作成予定 | 事前検証なしで本番移行しない |
保存済みアクセスポリシーは5個まで
Blobコンテナーごとの保存済みアクセスポリシーは5個までです。SASを部署別、アプリ別、用途別に細かく分けすぎると、すぐに上限に達します。(Microsoft Learn)
SAS運用では、ポリシーを増やす前に次を検討してください。
| 見直し項目 | 実務上の考え方 |
|---|---|
| ポリシー粒度 | アプリ単位ではなく権限パターン単位にまとめる |
| 有効期限 | 短期SASは保存済みポリシーではなく都度発行も検討 |
| 権限 | 読み取り専用、書き込み専用、削除可を分ける |
| ローテーション | 既存ポリシー削除の影響範囲を事前確認する |
| 監査 | SAS発行元と利用ログを追えるようにする |
監視で確認すべきメトリックとログ
性能目標は、設計時に読むだけでは不十分です。本番環境では、Azure Monitorで実際のリクエスト数、レイテンシ、エラー、スロットリングを確認する必要があります。
Azure Blob Storageの監視では、プラットフォームメトリックは自動収集されます。一方、リソースログは診断設定を作成してAzure Monitor Logsなどへルーティングするまで保存・クエリできません。ログを分析したい場合は、まず診断設定の有効化を確認してください。(Microsoft Learn)
特に見るべき項目は次のとおりです。
| 目的 | 見る項目 | 確認内容 |
|---|---|---|
| スロットリング確認 | Transactions + Response type | ServerBusyや失敗応答が増えていないか |
| 可用性確認 | Availability | 成功率が低下していないか |
| 帯域確認 | Ingress、Egress | バックアップや配信で上限に近づいていないか |
| 容量確認 | UsedCapacity、BlobCapacity | 容量増加が想定内か |
| 遅延確認 | DurationMs、ServerLatencyMs | クライアント側遅延かサーバー側遅延か |
| 操作別分析 | API Name、OperationName | GetBlob、PutBlock、ListBlobsなど何が多いか |
Azure Blob Storageの推奨アラート例として、Blob StorageのスロットリングはTransactionsのResponse type、リクエスト成功率はAvailability、1日あたり500 GiB超のegressはEgressで監視する例が示されています。(Microsoft Learn)
Log Analyticsを使ってServerBusyを確認する場合は、次のようなKQLが実務で使いやすいです。
StorageBlobLogs
| where TimeGenerated > ago(3d)
| where StatusText contains "ServerBusy"
| project TimeGenerated, OperationName, StatusCode, StatusText, DurationMs, ServerLatencyMs, Uri
| order by TimeGenerated desc遅延が大きい操作を確認する場合は、次のようにします。
StorageBlobLogs
| where TimeGenerated > ago(3d)
| top 20 by DurationMs desc
| project TimeGenerated, OperationName, DurationMs, ServerLatencyMs, ClientLatencyMs = DurationMs - ServerLatencyMs, StatusTextServerLatencyMsが小さく、ClientLatencyMs相当の差分が大きい場合は、アプリケーション、クライアント端末、ネットワーク、プロキシ、オンプレミス回線側に原因がある可能性があります。逆にServerBusyが増えている場合は、リクエスト集中、並列度過多、Blob名設計、ストレージアカウント上限を優先して確認します。
よくある失敗パターンと対策
Azure Blob Storageの性能問題は、上限値を知らないことよりも、「上限値の読み方」を誤ることで起きます。
| 失敗パターン | 起きる問題 | 対策 |
|---|---|---|
| 単一Blobにアクセスを集中させる | 3,000 request/sec付近で遅延や503が出る | 複数Blobへ分散、CDN、キャッシュを使う |
| 小さすぎるブロックで大量アップロード | リクエスト数が増え、効率が悪化する | ブロックサイズを見直し、並列度を調整する |
| 日付連番のBlob名にする | 特定パーティションに集中しやすい | 早い位置にハッシュや秒値を入れる |
| 古いAPIバージョンを使い続ける | 大容量Blobの上限を活用できない | SDKとx-ms-versionを確認する |
| 503を即時リトライする | 負荷がさらに増える | 指数バックオフを使う |
| GPv2移行でコストを見ない | トランザクション費用が増える可能性 | 読み書き回数、アクセス層、ライフサイクルを試算する |
| HNS有効アカウントでPage Blobを想定 | 移行後に互換性問題が起きる | アカウント分離やBlob種別の見直しを行う |
| IaCを過度に並列実行する | 管理プレーン側で制限に近づく | デプロイを分割し、バックオフを入れる |
管理者・開発者向けの確認チェックリスト
今回の更新を受けて、まずは次のチェックから始めるのがおすすめです。
| 担当 | 確認すること | 完了の目安 |
|---|---|---|
| 管理者 | 対象ストレージアカウントがGPv2か確認 | GPv1やBlobStorageが残っていない |
| 管理者 | 容量、ingress、egress、Transactionsを確認 | ピーク時の余裕が分かっている |
| 管理者 | 診断設定とAzure Monitorアラートを確認 | ServerBusyやAvailability低下を検知できる |
| 開発者 | SDKとREST APIサービスバージョンを確認 | 2019-12-12以降の上限を使える状態 |
| 開発者 | ブロックサイズと並列度を確認 | 小さすぎるブロックや無制限並列がない |
| 開発者 | 503/500時のリトライを確認 | 指数バックオフが実装されている |
| SRE | Blob名、パーティション、アクセス集中を確認 | ホットスポットが特定されている |
| FinOps | GPv2移行やアクセス層変更の費用を確認 | 移行前後の料金差を試算済み |
| DevOps | IaCの並列展開を確認 | Storage Resource Provider上限を考慮している |
まとめ：今回の更新は「制限値の再確認」と「設計点検」のきっかけにする
2026年5月19日更新の「Scalability and performance targets for Azure Blob Storage」は、Azure Blob Storageの制限値や性能目標を整理する重要な公式リファレンスです。今回確認できる更新内容は、数値上限の大幅変更というより、タイトル・説明・表記の整理が中心です。
ただし、この記事を単なるドキュメント更新として流すのは危険です。単一Block Blobの最大3,000 request/sec、Block Blobの最大約190.7 TiB、サービスバージョン別のアップロード上限、503発生時の指数バックオフ、GPv2移行、監視設定は、実際の性能・可用性・コストに直結します。
次に取るべき行動は明確です。まず対象のストレージアカウントを棚卸しし、GPv2移行状況、SDKとサービスバージョン、ブロックサイズ、リトライ設定、Azure Monitorのアラートを確認してください。大容量転送や高頻度アクセスがある環境では、設計値だけでなく本番に近い負荷テストを行い、Transactions、Ingress、Egress、Availability、ServerBusyを見ながら改善することが重要です。
コメント