2026年4月28日のMicrosoftDocs系更新として確認したいポイントは、Azure Storageの新機能そのものではなく、SQL Server系ワークロードでストレージI/Oをどう安全に扱うかというサポート要件の明確化です。特に、Azure VM上のSQL Server、Azure Managed Disks、Azure FilesやBlob Storageを絡めた構成、オンプレミスからAzureへの移行を検討している場合は、キャッシュ設定、書き込み保証、I/O障害時の責任分界を見直す必要があります。
今回の「Storage guide: Add info for I/O support」は、MicrosoftDocs/sql-docsリポジトリ内の sql-server-storage-guide.md に対する更新で、Microsoft Learn上では「SQL Server I/O fundamentals」として公開されています。対象はSQL Server、Azure SQL Managed Instance、SQL Server on Azure Virtual Machinesであり、Azure Storageを使う設計者にとっては「どのストレージを選ぶか」だけでなく、「そのI/OがSQL Serverの耐久性要件を満たしているか」を確認するための更新と捉えるのが実務的です。(GitHub)
Azure Storageの公式ドキュメント更新「Storage guide: Add info for I/O support」で何が変わったか
今回の更新で最も重要なのは、SQL Serverが求めるI/Oサブシステムの前提が、より運用目線で読み取りやすくなった点です。コミットでは1ファイルが変更され、I/Oサポート、ファイルシステム構成、キャッシュや安定媒体への書き込み保証に関する説明が追加・整理されています。差分上では Support for I/O issues セクションや File system configuration セクションが追加され、Microsoft Learnのページ上でも同内容が反映されています。(GitHub)
確認すべき変更点は、次の4つです。
| 確認ポイント | 実務上の意味 | 主に確認すべき人 |
|---|---|---|
| 安定媒体への書き込み保証 | SQL Serverのトランザクション整合性を守るには、書き込み順序、キャッシュの安定性、データ再書き換えの有無などを満たす必要がある | クラウド管理者、DBA、インフラ担当 |
| 書き込みキャッシュの扱い | パフォーマンス向上のためのキャッシュ設定が、ログ書き込みやACID保証を壊す可能性がある | Azure VM運用担当、SQL Server管理者 |
| I/O問題時のサポート境界 | SQL Server自体はMicrosoftがサポートするが、I/Oソリューション起因の問題はデバイス・ストレージ提供元の責任になる | 技術責任者、運用設計者 |
| ファイルシステム構成の整理 | 圧縮ボリューム、NAS、tempdb、Always On、診断など、構成別の確認先が明確になった | ソリューションアーキテクト、移行担当 |
Microsoft Learnでは、SQL Serverが「guaranteed delivery to stable media」を必要とし、その条件としてWindows Hardware Compatibility Program、書き込み順序、キャッシュ安定性、データ再書き換えがないことなどを挙げています。また、該当要件を満たすシステムであればSQL Serverデータベースストレージをサポートできる一方、要件を保証する必要があることも明記されています。(Microsoft Learn)
今回の更新はAzure Storageの機能追加ではなく、I/O要件の再確認として読む
「Azure Storageの更新」と聞くと、Blob Storage、Azure Files、Managed Disksなどに新しい機能が追加されたと受け取りがちです。しかし、今回のソースはAzure Storageの製品ページではなく、SQL ServerのI/O基礎ドキュメントです。
つまり、見るべきポイントは「Azure Storageで何ができるようになったか」ではなく、次のような設計判断です。
| 判断したいこと | 確認すべき観点 |
|---|---|
| Azure VM上のSQL ServerでManaged Disksを使う | データ、ログ、tempdbをどのディスクに置くか。ホストキャッシュ設定は適切か |
| オンプレミスSQL ServerをAzureへ移行する | 既存SAN/NASのI/O保証とAzure側の構成差分を洗い出せているか |
| Azure FilesやBlob StorageをSQL Serverで利用する | 利便性だけでなく、性能、信頼性、機能可用性の観点でManaged Disksと比較したか |
| 障害調査を設計する | SQL Server、OS、ドライバー、ストレージ、ネットワークのどこまでを誰が調査するか |
SQL Server on Azure VMsの公式ベストプラクティスでは、データファイルとログファイルをデータディスクに配置し、最高のパフォーマンス・信頼性・機能可用性を求める場合はAzure Managed Disksを使うことが推奨されています。一方で、SQL ServerデータベースファイルをBlob StorageやSMBストレージ上に直接ホストできるケースもありますが、構成要件と性能面の検証を省略してよいという意味ではありません。(Microsoft Learn)
最優先で確認すべきI/Oサポート要件
Azure StorageをSQL Server系ワークロードで使う場合、まず確認すべきなのは「そのストレージは速いか」ではなく、「コミット済みトランザクションを失わない構成か」です。
SQL Serverでは、トランザクションログへの書き込みが安定媒体へ到達したことを前提に、復旧処理やACID特性を維持します。今回の更新でも、WAL、ACID、安定媒体への保証、キャッシュコントローラーの安全性が改めて整理されています。(Microsoft Learn)
書き込み順序と安定媒体への保証を確認する
SQL ServerのI/Oで特に重要なのは、書き込みが「完了した」と返された時点で、本当に耐久性のある媒体に保存されているかです。ストレージやキャッシュが書き込みを受け取っただけで完了扱いにし、その後に障害でデータが失われると、ログとデータページの整合性が崩れる可能性があります。
確認時は、次の項目を構成管理表に入れてください。
| 項目 | 確認内容 |
|---|---|
| ストレージ種別 | Managed Disk、Azure Files、Blob Storage、Elastic SAN、オンプレNASなど |
| ディスク用途 | OS、データ、ログ、tempdb、バックアップ |
| 書き込み保証 | write-through、write ordering、stable mediaの要件を満たすか |
| キャッシュ方式 | None、Read-only、Read/write、ストレージ側キャッシュの有無 |
| 障害時の保護 | 電源断、ホスト障害、コントローラー障害、ファームウェア障害時の保護範囲 |
| サポート責任 | Microsoft、ストレージベンダー、SIer、社内運用のどこが一次対応するか |
この表を作る理由は、I/O問題が起きた後では責任範囲の切り分けに時間がかかるためです。設計段階で「誰が何を保証しているのか」を明文化しておくと、移行判定や障害対応が速くなります。
データディスクとログディスクのキャッシュ設定を分ける
Azure VM上のSQL Serverでは、ディスク用途ごとにホストキャッシュ設定を分けるのが基本です。SQL Server on Azure VMsの公式ベストプラクティスでは、データファイル用ディスクは Read-only、トランザクションログ用ディスクは None が推奨されています。ログディスクで Read-only や Read/write キャッシュを有効にすると、ACIDの耐久性保証に影響する可能性があるためです。(Microsoft Learn)
| ディスク用途 | 推奨される考え方 | 避けたい設定 |
|---|---|---|
| データファイル | 読み取り性能向上のため Read-only を検討 | Read/write キャッシュ |
| トランザクションログ | 書き込みの耐久性を優先し None | Read-only、Read/write |
| OSディスク | 既定の設定を維持 | 理由なく変更すること |
| tempdb | 一時ディスクまたは専用ディスクを用途に応じて設計 | 消失して困るデータの配置 |
特にログディスクの設定は、単なるパフォーマンスチューニングではありません。ログ書き込みはトランザクションの確定に直結するため、「速く見える設定」より「失敗時にも正しく復旧できる設定」を優先します。
Azure環境で影響を受けやすい構成
今回の更新は、すべてのAzure Storage利用者が即座に設定変更すべき内容ではありません。ただし、次の構成に該当する場合は、棚卸しを優先してください。
| 構成 | 確認すべき理由 | 対応の優先度 |
|---|---|---|
| SQL Server on Azure VMで本番DBを運用している | ディスクキャッシュ、VMサイズ、ディスクIOPSの組み合わせが性能と耐久性に直結する | 高 |
| オンプレSAN/NASからAzureへ移行中 | 既存のI/O保証をAzure側でどう再現するか確認が必要 | 高 |
| ログディスクでRead/writeキャッシュを使っている | 耐久性保証を壊す可能性がある | 高 |
| Azure FilesやBlob StorageにDBファイルを置く設計を検討している | 公式に扱えるケースがあっても、要件確認と性能検証が必要 | 中〜高 |
| tempdbを一時ディスクに配置している | 一時ディスクは永続ストレージではないため、用途を誤ると危険 | 中 |
| Standard HDD/SSDを本番DBで使っている | 本番SQL Serverワークロードには性能面で不向きな場合がある | 中 |
SQL Server on Azure VMsの公式ドキュメントでは、VMとディスクの両方にIOPS・スループット上限があり、どちらか一方だけを増やしても性能が頭打ちになる可能性があると説明されています。Premium SSD v2やUltra Diskのように性能を調整しやすい選択肢もありますが、VM側の上限、キャッシュポリシー、ファイル配置を合わせて設計する必要があります。(Microsoft Learn)
移行前に実施したいチェック手順
Azure StorageやManaged DisksへSQL Serverワークロードを移行する場合は、移行直前に設定を眺めるだけでは不十分です。以下の順で、設計・検証・運用を分けて確認します。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 現行構成を棚卸しする | データ、ログ、tempdb、バックアップの配置を一覧化する | ドライブ文字だけを見て、実体のストレージ種別を確認しない |
| 要件を数値化する | ピーク時のIOPS、スループット、遅延、容量増加率を取得する | 平常時だけを測って、締め処理やバッチ時間帯を見落とす |
| Azure側の候補を選ぶ | Managed Disks、Premium SSD v2、Ultra Diskなどを比較する | ディスク性能だけ見てVM上限を見ない |
| キャッシュ設定を決める | データ、ログ、tempdbごとに設定を分ける | すべてのディスクを同じ設定にする |
| SQLIOSimなどで検証する | 本番投入前にI/Oサブシステムをテストする | 実DBファイルをテスト対象にしてしまう |
| 障害対応を決める | Microsoft、ベンダー、社内の切り分け手順を作る | 障害発生後に責任分界を確認する |
SQLIOSimは、SQL ServerのようなI/Oパターンを模擬してサブシステムを検証するためのツールです。Microsoft Learnでは、SQL Serverをインストールする前のコンピューターでも、データファイルやログファイルを配置する予定のI/Oサブシステムをテストできると説明されています。ただし、SQLIOSimはランダムなテストパターンでデータを書き込むため、実際のSQL Serverデータベースファイルを指定してはいけません。(Microsoft Learn)
Azure CLIでキャッシュ設定を確認する例
Azure VMのデータディスクに設定されたキャッシュを確認する場合は、次のようなコマンドで棚卸しできます。
az vm show \
--resource-group <resource-group-name> \
--name <vm-name> \
--query "storageProfile.dataDisks[].{name:name,lun:lun,caching:caching,managedDisk:managedDisk.id}" \
--output table確認した結果は、次のように用途と紐づけて記録します。
| LUN | 用途 | 現在のキャッシュ | あるべき設定 | 対応 |
|---|---|---|---|---|
| 0 | データファイル | ReadOnly | ReadOnly | 維持 |
| 1 | トランザクションログ | ReadWrite | None | 変更計画を作成 |
| 2 | tempdb | ReadOnly | 構成に応じて判断 | 容量とI/Oを再確認 |
キャッシュ設定の変更は軽い作業に見えますが、Azureの公式ドキュメントでは、SQL Serverのデータ、ログ、アプリケーションファイルをホストするディスクのキャッシュ設定を変更する場合、データ破損を避けるためSQL Serverサービスなどを停止するよう案内されています。(Microsoft Learn)
SQL Server側でI/O遅延を確認する例
SQL Server側では、sys.dm_io_virtual_file_stats を使ってデータファイルやログファイルごとのI/O待ち時間を確認できます。
SELECT
DB_NAME(vfs.database_id) AS database_name,
mf.type_desc,
mf.physical_name,
vfs.num_of_reads,
vfs.num_of_writes,
vfs.io_stall_read_ms,
vfs.io_stall_write_ms,
CASE
WHEN vfs.num_of_reads = 0 THEN 0
ELSE vfs.io_stall_read_ms * 1.0 / vfs.num_of_reads
END AS avg_read_ms,
CASE
WHEN vfs.num_of_writes = 0 THEN 0
ELSE vfs.io_stall_write_ms * 1.0 / vfs.num_of_writes
END AS avg_write_ms
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS vfs
JOIN sys.master_files AS mf
ON mf.database_id = vfs.database_id
AND mf.file_id = vfs.file_id
ORDER BY avg_write_ms DESC;この結果だけで「ストレージが悪い」と断定しないことが重要です。クエリ設計、インデックス、統計情報、ウイルス対策ソフト、バックアップ処理、VM上限、ディスク上限、ネットワーク経路など、I/O遅延の原因は複数あります。Microsoft Learnでも、長時間I/Oや非効率なクエリ、フィルタードライバー、セキュリティソフトなどがI/O遅延に影響する可能性を説明しています。(Microsoft Learn)
I/O問題が起きたときのサポート境界を決めておく
今回の更新で実務上見落とせないのが、I/O問題時のサポート境界です。Microsoft Learnでは、MicrosoftはSQL ServerおよびSQL Serverベースのアプリケーションをサポートする一方、I/Oソリューションが問題の原因である場合はデバイスメーカーが責任を持つと説明しています。症状の例として、データベース破損、バックアップ破損、予期しないデータ損失、トランザクション欠落、I/O性能の予期しない変動などが挙げられています。(Microsoft Learn)
また、Microsoftは第三者のハードウェアやソフトウェア製品がSQL Serverと動作することを認証・検証するわけではなく、問題調査時には第三者製品なしで再現を求められる可能性があります。これは、Azure上の構成でも「公式サービスだから何でもMicrosoftが一括で調査してくれる」と単純化しない方がよい、という実務上の注意点です。(Microsoft Learn)
障害対応手順には、少なくとも次の切り分けを入れておきます。
| 切り分け対象 | 確認例 |
|---|---|
| SQL Server | エラーログ、823/824/833、DBCC CHECKDB、待機統計 |
| OS | システムイベントログ、ディスク関連イベント、フィルタードライバー |
| Azure VM | VMサイズ、ディスク上限、ホストキャッシュ、メトリック |
| Azure Storage | ディスク種別、冗長性、リージョン、性能設定 |
| ネットワーク | SMB、iSCSI、NAS相当構成、遅延、パケットロス |
| ベンダー製品 | バックアップ、ウイルス対策、暗号化、レプリケーション |
NASやネットワークストレージ利用時の注意点
Azure Filesやネットワーク接続ストレージを使う場合は、「ファイル共有として見えているからDBファイルを置ける」と考えるのは危険です。
MicrosoftのSQL Serverネットワークデータベースファイルに関するドキュメントでは、SQL Serverデータベースファイルの保存先としては一般にSANまたはローカル接続ディスクが推奨され、ネットワークサーバーやNASを使う場合はデータ書き込み順序とwrite-through保証を満たす必要があるとされています。要件を満たさないNASやネットワークストレージ上のSQL Serverデータベースファイルはサポートされません。(Microsoft Learn)
実務では、次のようなケースで注意が必要です。
| ケース | リスク |
|---|---|
| 共有フォルダーにDBファイルを置く | 書き込み保証や遅延の問題で破損・性能劣化が起きる可能性 |
| バックアップ先とDBファイル配置先を混同する | バックアップ保存には適していても、DBファイル常用に適しているとは限らない |
| ファイル共有の冗長性だけで判断する | SQL Serverが必要とする書き込み順序や完了保証とは別の観点 |
| ベンダー資料を確認しない | 障害時にサポート対象外または再現要求で対応が遅れる |
よくある誤解と判断基準
「Azure上のストレージならSQL Serverで安全に使える」は正しくない
Azureのストレージサービスは高い可用性やスケーラビリティを持ちますが、SQL Serverのデータファイルやログファイルに適した構成かどうかは別問題です。特にログディスクのキャッシュ設定、VMのI/O上限、ディスクの種類、ネットワーク経路は個別に確認する必要があります。
「IOPSが高いディスクを選べば十分」ではない
IOPSだけでは判断できません。SQL Serverでは、IOPS、スループット、レイテンシ、書き込み保証、キャッシュ、VM上限、ファイル配置を合わせて見る必要があります。たとえば高性能ディスクを選んでも、VM側のuncached throughputが低ければ性能は頭打ちになります。
「UPSがあるから書き込みキャッシュは安全」とは限らない
公式ドキュメントでは、外部UPSだけでは十分でないと説明されています。電源断以外にも、ファームウェア障害、ハードウェア障害、コントローラー障害など、キャッシュデータを失う要因があるためです。(Microsoft Learn)
「tempdbなら何でも一時ディスクでよい」ではない
Azure VMの一時ディスクはエフェメラルであり、VMの再起動やホスト移動時に再作成される可能性があります。SQL Server on Azure VMsの公式ドキュメントでは、ユーザーデータベースファイルやトランザクションログなど永続性が必要なものを一時ディスクに保存しないよう説明しています。(Microsoft Learn)
開発者・クラウド管理者・アーキテクト別の確認ポイント
| 役割 | 具体的にやること |
|---|---|
| 開発者 | I/O負荷の高い処理、バッチ、インデックス再構築、バックアップ時間帯を共有する |
| DBA | データ、ログ、tempdbの配置とI/O待ちを確認し、SQLIOSimやDBCC CHECKDBの計画を作る |
| クラウド管理者 | VMサイズ、ディスク種別、キャッシュ設定、Azure Monitorメトリックを棚卸しする |
| ソリューションアーキテクト | Managed Disks、Azure Files、Blob Storage、Elastic SANなどの採用理由を文書化する |
| 技術意思決定者 | 性能、コスト、サポート責任、移行リスクのトレードオフを承認する |
今回の更新は、単なるドキュメント差分として流すよりも、移行判定や本番運用レビューのチェックリストに落とし込む価値があります。特にグローバル展開しているシステムでは、リージョン、ディスク種別、VM SKU、運用ベンダーが環境ごとに異なるため、標準構成との差分を見える化しておくと監査や障害対応にも役立ちます。
まず実施すべきアクション
最初に行うべきことは、Azure上のSQL Server系ワークロードについて、データディスク、ログディスク、tempdb、バックアップ先の一覧を作ることです。そのうえで、ログディスクのキャッシュが None になっているか、データディスクで Read/write キャッシュを使っていないか、VMとディスクのIOPS・スループット上限に余裕があるかを確認します。
移行前の環境では、SQLIOSimなどでI/Oサブシステムを検証し、実DBファイルを使わずにテスト結果を保存しておきます。既存環境からAzureへ移行する場合は、「現在のストレージが何を保証しているか」と「Azure側でその保証をどの構成で満たすか」を1枚の設計資料にまとめると、レビューと承認が進めやすくなります。
今回の「Storage guide: Add info for I/O support」は、Azure Storageの派手な新機能ではありません。しかし、SQL ServerをAzureで安全に動かすうえでは、性能チューニングより前に確認すべき土台を整理した重要な更新です。まずはキャッシュ設定、I/O保証、サポート境界の3点を棚卸しし、移行計画や運用手順に反映してください。
コメント