cgroup v2への段階移行を本番環境で実施する｜v1並行動作の確認とリソース制御設計の判断軸

なぜ今、cgroup v2への移行が現場課題になっているか

cgroup（Control Groups）はLinuxカーネルがプロセスへのCPU・メモリ・I/Oなどのリソース割り当てを制御するための仕組みです。v1は2008年頃から広く使われてきた実績ある実装ですが、コントローラーごとに独立したhierarchyが存在するため、設定の整合性を保つのが難しいという根本的な構造上の問題を抱えていました。

cgroup v2はLinuxカーネル4.5（2016年）で正式マージされ、単一のunified hierarchyにすべてのコントローラーを集約するアーキテクチャに刷新されました。2026年時点では、RHEL 9・Ubuntu 22.04 LTS・Debian 12以降がデフォルトでcgroup v2を採用しており、Kubernetes 1.25以降もv2を推奨構成として明示しています。containerd・runcといったコンテナランタイムもv2対応が標準となっており、現場で新規に構築される本番環境ではv2が事実上の標準となっています。

問題が生じるのは、既存の本番環境がv1で稼働したまま、周辺ツールがv2を前提とした機能を要求し始めるタイミングです。たとえばKubernetes 1.28以降でPSI（Pressure Stall Information）を活用したスケジューリング機能を利用しようとすると、cgroup v2が必須となります。このような依存関係が積み重なってから急いで移行を試みると、サービスへの影響が読み切れず、ロールバック手順も不明確なままになりがちです。段階的な移行とその前後の検証が重要になる理由はここにあります。

v1・v2・ハイブリッドモードの現状確認：移行前に把握すべき環境情報

移行を始める前に、対象ホストが現在どのモードで動作しているかを正確に把握する必要があります。Linuxカーネルはv1・v2・hybrid（v1とv2の共存）の3つのモードをサポートしており、ディストリビューションのバージョンや初期設定によって状態が異なります。

現在のモードを確認する最も確実な方法は、/sys/fs/cgroup のマウント情報を参照することです。mount | grep cgroup を実行して cgroup2 のみが表示されればv2、cgroup（v1）と cgroup2 が混在していればhybridモード、cgroupのみであればv1です。また stat -fc %T /sys/fs/cgroup/ コマンドでファイルシステムタイプを直接確認する方法もあり、cgroup2fs が返ればv2専用モードです。

hybridモードはRHEL 8などで採用されていた過渡的な形態で、v1の一部コントローラー（特にmemoryやcpuset）をv2と並行稼働させます。このモードは後方互換性を確保しつつv2への移行を促すためのものですが、運用上の複雑さが増すため、新規構築では選ばないことが推奨されます。既存環境でhybridモードが確認された場合は、移行先のターゲットをfull v2とするのか、まずhybridのまま安定させるのかを事前に決めておくことが重要です。

あわせて確認すべき情報として、コンテナランタイムのバージョン、systemdのバージョン（v2サポートはsystemd 248以降で本格化）、そして現在稼働しているサービスがcgroupサブシステムを直接参照していないかが挙げられます。特にJavaアプリケーションやPythonの一部フレームワークはcgroup v1のパスを直接参照する実装が残っていることがあるため、アプリケーション依存性の棚卸しは移行計画の前提作業として外せません。

リソース制御設計の判断軸：v2で変わること・できるようになること

cgroup v2への移行を単なる「設定変更」と捉えると、移行後のリソース制御が意図と異なる動作をするリスクがあります。v2ではリソース制御モデルそのものが変わっているため、設計段階での判断が重要です。

最も大きな変更点のひとつがmemory.oom_groupの導入です。v1ではOOM killer（メモリ枯渇時のプロセス強制終了）の対象選定がカーネルの判断に委ねられていましたが、v2では同一cgroupのプロセス群をひとつの単位としてOOM killerに扱わせる設定が可能になりました。これはコンテナ環境でサイドカーコンテナが巻き込まれないよう保護するケースや、逆にアプリケーションコンテナとそのヘルパープロセスをまとめて終了させたいケースに有効です。

もうひとつの重要な機能がPSI（Pressure Stall Information）です。PSIはCPU・メモリ・I/Oそれぞれについて、リソース待ちにより処理が停滞している時間の割合をパーセンテージで可視化します。v1では外部ツールや独自実装でしか得られなかったこの情報が、v2ではカーネル組み込みで利用できます。Kubernetesのリソース管理機能であるIn-Place Pod Vertical ScalingやQoS改善も、このPSI情報を活用する設計になっています。

一方で注意が必要なのがcpusetコントローラーの挙動変化です。v1ではcpusetを任意の階層に独立して適用できましたが、v2では親から子へのcpuset継承ルールが厳格化されました。NUMAアーキテクチャを持つサーバーでcpusetを使ったCPUピニングを行っている場合、v2への移行後に意図したコアへの割り当てが機能しなくなることがあります。HPC系ワークロードやリアルタイム処理が混在する環境では、この点の事前検証が欠かせません。

段階移行の実施手順：ブートパラメータからサービス検証まで

本番環境での移行は、ステージング環境での十分な検証を経たうえで、ローリング方式またはブルーグリーン方式を選択して実施するのが現場での定石です。以下は移行の大まかな流れです。

• ステップ1：ステージング環境での全量テスト　本番と同等の構成でcgroup v2を有効化し、全サービスの起動・負荷試験・OOMシナリオを確認します。
• ステップ2：ブートパラメータの変更　GRUBの設定ファイル（通常 /etc/default/grub）に GRUB_CMDLINE_LINUX として systemd.unified_cgroup_hierarchy=1 を追記し、update-grub または grub2-mkconfig を実行します。v1への戻しは systemd.unified_cgroup_hierarchy=0 で即座に可能です。
• ステップ3：再起動と初期確認　再起動後に mount | grep cgroup でv2専用マウントになっていることを確認し、systemdのcgroup関連ログ（journalctl -b | grep cgroup）にエラーがないかを照合します。
• ステップ4：コンテナランタイムの再起動と確認　containerdやdockerdはcgroup v2を自動検出しますが、設定ファイルで明示的に SystemdCgroup = true（containerd）を指定することで、systemdとのcgroup管理一元化が確実になります。
• ステップ5：アプリケーション動作の段階確認　メモリ上限・CPU制限・I Oスロットリングがそれぞれ意図どおりに機能しているかを、実際の負荷をかけながら確認します。

Kubernetesクラスターの場合は、ノード単位での移行がローリングアップデートと相性がよい方法です。ノードをcordon・drainして隔離したうえでv2に移行し、ワークロードを再スケジュールして問題がないことを確認してから次のノードに進む流れが、サービスへの影響を最小化します。

移行後の検証とロールバック手順

移行後の検証で最初に確認すべきは、各サービスのリソース制限が実際に機能しているかどうかです。/sys/fs/cgroup/system.slice/ 以下にsystemdが管理するサービスのcgroupエントリが存在することを確認し、memory.current・cpu.stat・io.stat の各ファイルが値を返していることを確認します。これらのファイルが存在しない、または空の場合は、コントローラーが正しく有効化されていない可能性があります。

PSIの活用も移行後の検証に有効です。/proc/pressure/ 配下のファイルに加え、v2対応のcgroupでは各cgroupのディレクトリ内にも cpu.pressure・memory.pressure・io.pressure が生成されます。通常運用時のベースラインとなる数値を記録しておくと、その後の性能劣化や異常の早期検知に役立ちます。

ロールバックはGRUBパラメータの変更と再起動で対応できます。systemd.unified_cgroup_hierarchy=0 を設定してv1に戻す手順はシンプルですが、v2稼働中にv2固有の機能（memory.oom_groupの設定など）を利用していた場合、v1に戻した後にその設定が無効化されることに注意が必要です。ロールバック手順書には「v2固有設定の無効化→GRUBパラメータ変更→再起動→v1コントローラー設定の再適用」という順序を明記しておくことが重要です。

また、移行後しばらくは dmesg | grep -i cgroup を定期的に確認し、カーネルからの警告やエラーが出ていないかを監視することが推奨されます。特にカーネル5.x系列ではcgroup v2の一部機能に軽微なバグが混入していた経緯があり、使用中のカーネルバージョン固有の既知問題をリリースノートで事前に確認しておく習慣が現場では重要です。

2026年時点の主要ディストリビューション対応状況と注意点

2026年8月時点での主要ディストリビューションの対応状況を整理すると、以下のような状況です。

• RHEL 9 / AlmaLinux 9 / Rocky Linux 9　デフォルトでcgroup v2専用モード。RHEL 8はhybridモードがデフォルトであり、grubby コマンド経由でのパラメータ変更が推奨手順となっています。RHEL 9以降でv1に戻すことはRed Hatとしてサポート対象外となっているため、本番環境でのv1ロールバックは自己責任での対応となります。
• Ubuntu 22.04 LTS / 24.04 LTS　いずれもcgroup v2専用モードがデフォルト。Canonicalは22.04 LTSのサポート期間（2027年）まで継続サポートを提供しており、v2への移行が事実上完了している状況です。
• Debian 12（Bookworm）　cgroup v2がデフォルト。Debian 11（Bullseye）はv1がデフォルトのまま2026年6月でLTS終了となり、現役の本番環境はDebian 12への移行が急がれる状況にあります。
• Amazon Linux 2023　cgroup v2がデフォルト。Amazon Linux 2はv1ベースのまま2025年6月でサポート終了となったため、AL2から移行中の環境ではcgroup設定の差分確認が必須です。

Kubernetes環境では、EKS・GKE・AKSいずれのマネージドサービスも2024年以降はcgroup v2がデフォルトノード構成となっており、セルフマネージドの場合に限りv1環境が残存している状況です。特にEKS最適化AMIはv2対応済みですが、カスタムAMIを使用している環境では移行前の確認が必要です。

Javaアプリケーションについては、JDK 15以降でcgroup v2のメモリ制限を正しく認識する実装が取り込まれています。JDK 11以前のバージョンをコンテナで動かしている場合は、-XX:+UseContainerSupport フラグが有効でも、v2環境下でヒープサイズの自動計算が期待どおりに機能しないケースが報告されています。JDKのバージョンとcgroupの組み合わせは、移行前の検証リストに必ず含めるべき項目です。

cgroup v2への移行は一度完了すればほとんどの場面で恩恵を受けられる変更ですが、その過程で既存設定の動作差異を見落とすと本番障害に直結します。ディストリビューションとランタイムの現状確認、設計上の差分の把握、段階的な適用と検証という3つの柱を守ることで、移行リスクを大幅に低減できます。