SQL Server Dockerコンテナを運用しているチームが、2026年4月更新でまず確認すべきポイントは cgroup v2によるCPU・メモリ制御、データ永続化、バックアップの置き場所、MSSQL_SA_PASSWORDへの移行 です。今回のMicrosoft公式ドキュメント更新は、単にDockerコマンド例を眺めるだけでは不十分です。Kubernetes、AKS、OpenShift、Docker上でSQL Serverを動かしているdata engineer、DBA、analytics leaderは、リソース制限が実際のSQL Serverの動作にどう反映されるかまで確認する必要があります。Microsoft Learnの該当ページは2026年4月21日に更新されており、対象はAzure SQL Databaseそのものではなく、SQL Server on LinuxのDockerコンテナ構成です。(Microsoft Learn)
SQL Server / Azure SQLの最新動向: 2026年4月更新で何が変わったか
Microsoft Learnの「Configure and customize SQL Server Linux containers」は、SQL Server LinuxコンテナをDockerで構成・カスタマイズするための公式記事です。扱っている範囲は、データ永続化、コンテナ内外のファイルコピー、タイムゾーン、tempdb、既定のデータ配置、mssql-conf、cgroup v2などです。(Microsoft Learn)
GitHubの履歴を見ると、2026年4月21日のコミットは「Linux向けSQL Serverアップグレード考慮事項」に関する更新の一部で、該当Docker記事ではcgroup関連セクション名が「Configure memory limits with control group (cgroup) v2」から、より広い意味を持つ「Control group (cgroup) v2 support」に変更されています。つまり、今回の注目点は「メモリ制限の設定」だけではなく、コンテナ環境でSQL Serverがcgroup v2の制約をどう扱うかに広がったことです。(GitHub)
| 更新ポイント | 実務での意味 | 確認すべき読者 |
|---|---|---|
| cgroup v2サポートの説明が重要化 | CPU・メモリ制限がSQL Serverの実行計画、スケジューラ、OOM対策に関係する | DBA、SRE、platform engineer |
| SQL Server 2025とSQL Server 2022 CU20以降への言及 | 新しいSQL Serverコンテナではcgroup v2前提の設計を検討しやすくなる | DB基盤担当、analytics platform担当 |
| AKS v1.25+などKubernetes環境でのOOM問題に言及 | コンテナ仕様で指定したメモリ制限がSQL Serverに反映されるかを検証すべき | Kubernetes運用チーム |
| CPU制限時のエラーログ表示に注意 | エラーログがホスト全体のCPU数を表示しても、実際の制御とは別問題 | DBA、性能検証担当 |
永続化、バックアップ、MSSQL_SA_PASSWORDの再確認 | コンテナ削除時のデータ消失や古い環境変数の使用を避ける | すべての運用担当者 |
cgroup v2対応は、コンテナ版SQL Serverの運用判断を変える
cgroupは、Linux上でCPUやメモリなどのリソース使用量を制御する仕組みです。DockerやKubernetesで「このSQL Serverコンテナはメモリ8GBまで」「CPUは4コア相当まで」といった制限をかける場合、その裏側でcgroupが関係します。
公式ドキュメントでは、SQL Server 2025とSQL Server 2022 CU20以降で、SQL Serverがcgroup v2の制約を検出し、Docker、Kubernetes、OpenShift環境でのリソース分離を改善すると説明されています。また、以前のバージョンではAKS v1.25+などのKubernetesクラスターで、コンテナ仕様のメモリ制限がSQL Server側で十分に反映されず、OOMが発生する可能性があったとされています。(Microsoft Learn)
まずcgroupのバージョンを確認する
対象ホストやノードで、次のコマンドを実行します。
stat -fc %T /sys/fs/cgroup| 結果 | 意味 |
|---|---|
cgroup2fs | cgroup v2を使用している |
cgroup | cgroup v1を使用している |
KubernetesやOpenShiftでSQL Serverコンテナを運用している場合は、アプリケーションのPodマニフェストだけでなく、ノードOS側のcgroupバージョンも確認してください。マニフェストにCPU・メモリ制限を書いていても、SQL ServerのバージョンやCU、ノード側のcgroup構成が合っていなければ、期待した挙動にならない可能性があります。
CPU制限時はエラーログだけで判断しない
cgroup v2でCPU制限を設定している場合でも、SQL Serverのエラーログには構成したCPU数ではなく、ホスト全体のCPU数が表示されることがあります。公式ドキュメントでは、この表示は実際のCPU使用、スケジューラ作成、cgroup v2やprocessor affinityによる制御に影響しないと説明されています。(Microsoft Learn)
たとえば8コアのホスト上で、SQL Serverコンテナに4CPU相当の実行枠を与える場合、SQL Server側のスケジューラや並列処理判断を意図したCPU数に合わせるには、processor affinityの設定を検討します。
ALTER SERVER CONFIGURATION
SET PROCESS AFFINITY CPU = 0 TO 3;さらに、公式ドキュメントではtrace flag 8002を有効化し、SQLPALレイヤーでsoft affinityを使う構成が推奨されています。設定後はSQL Serverの再起動が必要です。(Microsoft Learn)
sudo /opt/mssql/bin/mssql-conf traceflag 8002 on実務では、設定を入れて終わりではありません。クエリの並列度、待機統計、CPU使用率、スループットを検証し、「制限したCPU数に合わせて安定しているか」を確認してください。特にanalytics workloadでは、並列クエリが多いため、CPU制限とSQL Server側のスケジューラ数がずれると、性能が不安定に見えることがあります。
Dockerコンテナ運用で必ず見直す設定
データ永続化は「コンテナを消しても残る」前提で設計する
SQL Serverコンテナでは、docker stopとdocker startで再起動するだけなら、コンテナ内の構成変更やデータベースファイルは残ります。しかし、docker rmでコンテナを削除すると、コンテナ内のSQL Serverやデータベースも削除されます。公式ドキュメントでも、SQL ServerではDockerのデータ永続化を理解することが重要だと強調されています。(Microsoft Learn)
検証環境でも本番相当の設計をするなら、最低限、データ領域はボリュームに分離します。
docker volume create sqlvolume
docker run -e 'ACCEPT_EULA=Y' \
-e 'MSSQL_SA_PASSWORD=<strong-password>' \
-p 1433:1433 \
-v sqlvolume:/var/opt/mssql \
--name sql1 \
-d mcr.microsoft.com/mssql/server:2022-latest本番運用に近づけるなら、data、log、secrets、backupを分ける設計が扱いやすくなります。障害調査、バックアップ取得、権限管理、ストレージ性能の切り分けがしやすくなるためです。
docker run -e 'ACCEPT_EULA=Y' \
-e 'MSSQL_SA_PASSWORD=<strong-password>' \
-p 1433:1433 \
-v /srv/sql/data:/var/opt/mssql/data \
-v /srv/sql/log:/var/opt/mssql/log \
-v /srv/sql/secrets:/var/opt/mssql/secrets \
-v /srv/sql/backup:/var/opt/mssql/backup \
--name sql1 \
-d mcr.microsoft.com/mssql/server:2022-latestここで注意したいのは、古い環境変数SA_PASSWORDです。公式ドキュメントではSA_PASSWORDは非推奨で、代わりにMSSQL_SA_PASSWORDを使うよう示されています。(Microsoft Learn)
バックアップファイルはコンテナ外に出す
SQL Serverのバックアップを取得しても、バックアップファイルをコンテナ内だけに置いていると、コンテナ削除時に一緒に消える可能性があります。公式ドキュメントでも、バックアップファイルはコンテナ外に作成またはコピーする必要があると説明されています。(Microsoft Learn)
実務では、次のようにホスト側のバックアップディレクトリをマウントしておくと運用しやすくなります。
-v /srv/sql/backup:/var/opt/mssql/backupバックアップ先は、SQL Serverから見えるコンテナ内パスを指定します。
BACKUP DATABASE [sales]
TO DISK = '/var/opt/mssql/backup/sales_full.bak'
WITH INIT;そのうえで、ホスト側の/srv/sql/backupを別ストレージ、オブジェクトストレージ、バックアップ製品などに連携します。DBAの観点では、バックアップ取得よりもリストア検証のほうが重要です。月次やリリース前だけでなく、イメージ更新やCU適用の前にも、別コンテナで復元できるか確認してください。
VDIバックアップを使う環境は共有メモリ設定を確認する
バックアップ製品がVirtual Device Interface、つまりVDIベースのバックアップ・リストアを使う場合は追加確認が必要です。公式ドキュメントでは、SQL Server 2019 CU15以降、SQL Server 2017 CU28以降のコンテナデプロイでVDIバックアップ・リストアがサポートされ、--shm-sizeを使って共有メモリを少なくとも1GBから設定することが推奨されています。また、mssql.confでmemory.enablecontainersharedmemoryをtrueにする手順も示されています。(Microsoft Learn)
docker run -e "ACCEPT_EULA=Y" \
-e "MSSQL_SA_PASSWORD=<strong-password>" \
--shm-size 1g \
-p 1433:1433 \
--name sql19 \
-d mcr.microsoft.com/mssql/server:2019-latestmssql.confの例は次のとおりです。
[memory]
enablecontainersharedmemory = true標準のBACKUP DATABASEだけを使う環境と、VDI対応のバックアップ製品を使う環境では、必要な設定が異なります。バックアップ製品を導入しているDBAは、製品側の要件とSQL Serverコンテナ側の共有メモリ設定をセットで確認してください。
tempdb、既定データ配置、タイムゾーンも見落としやすい
tempdbはユーザーデータベースと分ける
公式ドキュメントでは、tempdbをユーザーデータベースとは別の場所に置くことがよいプラクティスとして示されています。変更にはT-SQLでのファイルパス変更と、SQL Serverコンテナの再起動が必要です。(Microsoft Learn)
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = '/var/opt/mssql/tempdb/tempdb.mdf');
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = '/var/opt/mssql/tempdb/templog.ldf');
GO変更後はコンテナを再起動します。
docker stop sql1
docker start sql1analytics workloadでは、集計、ソート、一時テーブル、ハッシュ処理でtempdbのI/Oが増えやすくなります。データファイル、ログ、tempdbを同じ低速ディスクに置くと、SQL Server本体の設定よりもストレージI/Oがボトルネックになることがあります。
既定のデータ配置はMSSQL_DATA_DIRで変更できる
既定のデータディレクトリを変えたい場合は、MSSQL_DATA_DIR環境変数を使います。公式ドキュメントでは、コンテナ内の変更先パスに、コンテナユーザーがアクセスできるボリュームをマウントする必要があると説明されています。(Microsoft Learn)
docker run -e 'ACCEPT_EULA=Y' \
-e 'MSSQL_SA_PASSWORD=<strong-password>' \
-e 'MSSQL_DATA_DIR=/my/file/path' \
-v /my/host/path:/my/file/path \
-p 1433:1433 \
-d mcr.microsoft.com/mssql/server:2022-latestここで失敗しやすいのは、ホスト側ディレクトリの所有者と権限です。SQL Server 2019以降のコンテナは既定でnon-rootとして起動するため、マウント先に書き込めないと、起動失敗やデータベース作成失敗につながります。公式ドキュメントでも、SQL Server 2019以降のコンテナは自動的にnon-rootで起動し、SQL Server 2017は既定でrootとして起動すると説明されています。(Microsoft Learn)
グローバル運用ではタイムゾーンを明示する
ログ、監査、バッチ、BIレポート、データ連携で時刻の解釈を揃えるには、コンテナのタイムゾーンを明示します。公式ドキュメントでは、Linuxコンテナ上のSQL Serverで特定のタイムゾーンを使う場合、TZ環境変数を設定する方法が示されています。(Microsoft Learn)
日本時間で運用する例です。
docker run -e 'ACCEPT_EULA=Y' \
-e 'MSSQL_SA_PASSWORD=<strong-password>' \
-e 'TZ=Asia/Tokyo' \
-p 1433:1433 \
--name sql1 \
-d mcr.microsoft.com/mssql/server:2022-latestただし、グローバル読者向けのデータ基盤では、アプリケーション、ETL、BI、監査ログでUTCを使うか、ローカルタイムを使うかを先に決めてください。SQL Serverコンテナだけを日本時間にしても、周辺システムがUTCのままだと、障害調査や集計の境界時刻で混乱します。
役割別に見る、今すぐ確認すべきポイント
| 役割 | 確認すべきこと | 実務アクション |
|---|---|---|
| data engineer | 開発・検証用SQL Serverコンテナの再現性 | Dockerfile、Compose、CI設定でボリュームと環境変数を固定する |
| DBA | バックアップ、リストア、tempdb、権限、ログ | コンテナ削除後も復旧できる手順をステージングで検証する |
| platform engineer / SRE | cgroup v2、CPU・メモリ制限、Kubernetesノード設定 | stat -fc %T /sys/fs/cgroup、Pod制限、SQL Serverバージョン/CUを照合する |
| analytics leader | 分析基盤の可用性、性能、アップグレードリスク | SQL Server 2022 CU20以降またはSQL Server 2025採用時の検証計画を作る |
| security担当 | SAパスワード、シークレット、non-root実行 | MSSQL_SA_PASSWORD、Docker secrets、Kubernetes Secret、権限設計を見直す |
Azure SQLとの関係は「直接適用」と「参考情報」を分けて考える
今回の公式記事は、Azure SQL DatabaseやAzure SQL Managed Instanceの設定手順ではありません。Applies toはSQL Server on Linuxであり、DockerでSQL Serverコンテナを構成・カスタマイズする内容です。(Microsoft Learn)
そのため、次のように分けて考えると誤解を避けられます。
| 環境 | 今回の記事の適用度 | 判断 |
|---|---|---|
| ローカルDocker上のSQL Server | 高い | ほぼ直接使える |
| Azure VM上のDockerで動くSQL Server | 高い | ホストOS、ストレージ、バックアップ設計も含めて確認する |
| AKS上のSQL Serverコンテナ | 高い | cgroup v2、CPU・メモリ制限、永続ボリュームを重点確認する |
| OpenShift上のSQL Serverコンテナ | 高い | cgroup v2とセキュリティコンテキストを確認する |
| Azure SQL Database | 低い | Dockerコンテナ設定としては適用しない |
| Azure SQL Managed Instance | 低い | 自前コンテナ運用の設定としては適用しない |
Azure SQLを使っているチームでも、開発環境やCI、分析検証環境ではSQL Serverコンテナを使うことがあります。その場合、本番のAzure SQLとは別物として、コンテナ固有のデータ永続化、バックアップ、リソース制限を設計してください。
失敗しやすいポイントと回避策
| 失敗例 | 起きる問題 | 回避策 |
|---|---|---|
docker rmしてからデータ消失に気づく | データベース、バックアップ、ログが消える | /var/opt/mssqlやbackup領域をボリュームに分離する |
SA_PASSWORDを使い続ける | 非推奨の環境変数に依存する | MSSQL_SA_PASSWORDへ移行する |
| バックアップをコンテナ内だけに保存する | コンテナ削除時にバックアップも消える | ホスト側または外部ストレージに出す |
| Kubernetesのlimit設定だけで安心する | SQL Server側の挙動とずれる可能性がある | cgroup v2、SQL Serverバージョン/CU、負荷試験を確認する |
| エラーログのCPU数だけを見て誤判断する | ホストCPU数表示を実効CPU数と混同する | processor affinity、スケジューラ数、実CPU使用率を見る |
latestタグを本番で無計画に使う | イメージ更新時に予期しない差分が入る | 検証済みのタグと更新手順を管理する |
| マウント先権限を確認しない | 起動失敗、DB作成失敗、バックアップ失敗が起きる | non-root実行を前提にホスト側権限を設定する |
今日やるべきチェックリスト
まず、利用中のSQL Serverコンテナのバージョン、CU、イメージタグ、DockerまたはKubernetesのリソース制限を一覧化してください。次に、ホストまたはノードでcgroupのバージョンを確認します。
stat -fc %T /sys/fs/cgroupそのうえで、次の順に見直すと効率的です。
- SQL Server 2022 CU20以降またはSQL Server 2025を使っているか確認する
- Docker、Compose、KubernetesマニフェストのCPU・メモリ制限を確認する
- CPU制限を使う場合、processor affinityとtrace flag 8002の要否を検証する
/var/opt/mssql/data、log、secrets、backupの永続化設計を確認するMSSQL_SA_PASSWORDを使っているか確認する- バックアップファイルがコンテナ外に残るか確認する
tempdbとユーザーデータベースの配置を確認する- タイムゾーン設定がアプリケーション、ETL、BIと矛盾していないか確認する
- ステージング環境でコンテナ削除後の復旧をテストする
- 本番更新前に、負荷試験とリストア試験をセットで実施する
2026年4月更新のポイントは、「SQL Serverコンテナの起動コマンドを少し直す」ことではありません。DockerやKubernetesでSQL Serverを動かす場合に、リソース制御、永続化、バックアップ、権限、タイムゾーンを運用品質で見直すタイミングだと捉えるべきです。特にAKSやOpenShiftで分析基盤を運用しているチームは、cgroup v2とSQL Server側のCPU・メモリ認識を検証し、コンテナを消しても復旧できる状態まで確認してから本番適用に進めてください。
コメント