MENU

SQL Server Dockerコンテナ設定の2026年4月更新ポイント｜cgroup v2と運用チェック

Linux

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
結果意味
cgroup2fscgroup v2を使用している
cgroupcgroup 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-latest

mssql.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 sql1

analytics 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 / SREcgroup 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

そのうえで、次の順に見直すと効率的です。

  1. SQL Server 2022 CU20以降またはSQL Server 2025を使っているか確認する
  2. Docker、Compose、KubernetesマニフェストのCPU・メモリ制限を確認する
  3. CPU制限を使う場合、processor affinityとtrace flag 8002の要否を検証する
  4. /var/opt/mssql/data、log、secrets、backupの永続化設計を確認する
  5. MSSQL_SA_PASSWORDを使っているか確認する
  6. バックアップファイルがコンテナ外に残るか確認する
  7. tempdbとユーザーデータベースの配置を確認する
  8. タイムゾーン設定がアプリケーション、ETL、BIと矛盾していないか確認する
  9. ステージング環境でコンテナ削除後の復旧をテストする
  10. 本番更新前に、負荷試験とリストア試験をセットで実施する

2026年4月更新のポイントは、「SQL Serverコンテナの起動コマンドを少し直す」ことではありません。DockerやKubernetesでSQL Serverを動かす場合に、リソース制御、永続化、バックアップ、権限、タイムゾーンを運用品質で見直すタイミングだと捉えるべきです。特にAKSやOpenShiftで分析基盤を運用しているチームは、cgroup v2とSQL Server側のCPU・メモリ認識を検証し、コンテナを消しても復旧できる状態まで確認してから本番適用に進めてください。

Linux
SQL Server Docker Kubernetes Azure SQL cgroup v2

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次