Microsoftは、Windows Subsystem for Linux（WSL）の内部アーキテクチャを刷新し、Linuxカーネルのリソース管理機構であるcgroupのバージョンをv1からv2に切り替えた。この変更によりWSLの安定性は向上する見込みだが、一部のワークロードでは後方互換性が失われることも明らかになっている。
cgroup v2移行の技術的な意味
WSL2は、Hyper-Vベースの軽量な仮想マシン上で実際のLinuxカーネルを動かす仕組みだ。複数のディストリビューションを同時に起動できるのは、カーネルのcgroup機能でプロセスグループごとにCPU・メモリ・I/Oを分離管理しているからにほかならない。
これまでWSLが使ってきたcgroup v1は、リソースの種類ごとに別々の階層（コントローラー）を持つ複雑な構造で、ディストリビューションの起動・終了処理で競合やハング、メモリの解放漏れが起きやすいという課題を抱えていた。cgroup v2は単一階層に統合されたシンプルな設計で、こうした不安定要因を構造的に減らせる。Microsoftが安定性向上を優先してこの移行に踏み切ったのは筋が通っている。
一方でcgroup v2は、v1前提で書かれた古いsystemdやコンテナランタイムと相性が悪い。具体的には、cgroup v2への対応が入る前のsystemdや、対応が不十分なDocker Engineを使っている環境では、コンテナやサービスの起動に失敗する可能性がある。
実務への影響
WSL2を開発環境やDocker Desktopのバックエンドとして使っているエンジニア、それを管理するIT部門にとっては見過ごせない変更だ。
- 更新前にディストリビューション内のsystemdバージョン（
systemctl --version）とDocker Engineのバージョンを確認する - Docker Desktopを使っている場合は最新版へのアップデートを済ませてからWSLの更新を反映する
- 複数の開発者PCを抱えるチームでは、一斉更新ではなく数台での動作確認を挟んでから展開する
Windows Update全般に言えることだが、「当てたら壊れた」という報告が出てから数日様子を見るのも、立派なセキュリティ・安定性判断だ。特に開発環境が止まると業務影響が大きいWSLのような基盤コンポーネントほど、この判断が効いてくる。
筆者の見解
個人的には、この手の「地味だが本質的な」改善こそもっと評価されるべきだと思っている。WSLは日本のエンジニアの間でもLinux開発環境の定番になっており、cgroup v1由来の不安定さに悩まされてきた人は少なくないはずだ。
派手な新機能よりも足回りの安定性を優先する判断は、正面から評価したい。ただし移行に伴う互換性リスクの周知はもう一段丁寧であってほしい——Docker DesktopやsystemdのバージョンとWSLの対応関係を、公式ドキュメントでもっと明示してもらえると、現場での更新判断がずっと楽になる。Windowsの基盤技術としてWSLが正面から評価される機会が増えることを期待している。
出典: この記事は Microsoft makes Windows Subsystem for Linux more stable with architecture tweak の内容をもとに、筆者の見解を加えて独自に執筆したものです。