進むWindowsのLinux化 - WSL1

MicrosoftがWindowsにLinuxを取り込む直接のきっかけになったのが、WSLだ。WSLは「Windows Subsystem for Linux」の略称で、WindowsでLinuxバイナリを実行する機能である。WSLは現在、まったく仕組みの異なる新しいバージョンの開発が進められており、この最初のバージョンのWSLは開発中のバージョンと区別するために「WSL1」と呼ばれることも増えている。

コマンドやアプリケーション、またはライブラリは内部のどこかで「システムコール」と呼ばれる機能を利用する。これはカーネルと呼ばれるOSの中核のソフトウェアに機能を依頼するもので、WindowsであればWindowsカーネルが、LinuxであればLinuxカーネルが依頼された内容を処理してくれる。

WSL1はこのシステムコールを差し替える機能で、LinuxアプリケーションやLinuxコマンドが要求するLinuxカーネルのシステムコールをWindowsカーネルのシステムコールに差し替えるという動きをする。LinuxアプリケーションやLinuxコマンドを実行するのに、実はLinuxカーネルは必須ではない。要求されるシステムコールさえ提供していれば、カーネルはWindowsカーネルでもFreeBSDカーネルでも構わない。

例えば、FreeBSDにはLinuxアプリケーションやLinuxコマンドを実行する機能が備わっている。これはLinuxカーネルのシステムコールをFreeBSDカーネルのシステムコールに置き換える機能によるもので、WSL1とよく似ている……と言うか、原理は同じだ。そして、この技術は別段新しいものではなく、古くから使われている技術でもある。FreeBSDにおけるLinuxバイナリ実行機能は、ほかのUNIX系OSの多くがすでに似たような機能を提供している。

システムコールを差し替えるこの技術は、処理速度が遅くならないという利点がある。場合によっては元のカーネルで動作させるよりも、システムコールを差し替えて別のカーネルで動作させたときのほうが、処理が高速になることもあるくらいだ。

ともかく、Microsoftがこの機能をWindows 10のデフォルト機能として導入したことで、Windows 10はLinuxを利用するための手軽なプラットフォームとして利用できるようになった。WSL1はWindows 10を大きくLinuxに近づけることになった直接の原因と言える。

WindowsとLinuxの融合

MicrosoftはWSL1の実現にあたって、WindowsとLinuxの垣根をできるだけ曖昧にすることに努力した。これは一定の成果を挙げている。仮想化アプリケーションでLinuxと実行する場合、WindowsとLinuxの間には明確な区別が発生する。WSL1ではこれが曖昧になるようになっており、Windows 10でLinuxコマンドが直接使えるようになったような印象のある仕組みになっている。

たとえば次の画面は、Windows 10で動作しているWindows Terminalだ。インタラクティブシェルとしてはPowerShell Coreが使われている。

しかし、スクリーンショットからわかるように、PowerShell CoreからLinux側のコマンドであるneofetchコマンドが実行されている。一見しただけでは、Windows側でneofetchコマンドが動作しているように見える。実際にはWSL1を経由してコマンドが実行されているのだが、ユーザーがそうしたことを気にしなくてもよいように工夫されているのだ。これも、Windows 10にシームレスにLinuxを取り込むことに寄与している。

CanonicalがサポートするWSL向けのUbuntuという存在

さらに重要なのは、CanonicalがMicrosoftと協力してこのWSL1で利用できるUbuntuを公式にサポートしているということだ。Ubuntuはデスクトップ向けのLinuxディストリビューションとしてもWebサーバ向けのLinuxディストリビューションとしても最も多いシェアを持つと言われている。このディストリビューションをWindows 10で公式に利用できるようになった意義は大きい。

現在ではMicrosoft Store経由でUbuntu以外のLinuxディストリビューションも選択できる。しかし、Canonicalが公式にサポートしており、さらに最も早くMicrosoftと協力関係を結んだCanonicalのUbuntuは、Windows 10で利用するLinuxディストリビューションのデファクトスタンダードのような立場になった。このUbuntuの存在は大きい。

一方、エンタープライズでの採用が大きいと考えられているRed Hat Enterprise LinuxはMicrosoft Storeには登録されていない。Red Hat Enterprise Linuxから作成されるCentOSも登録されていない。この2つのディストリビューションもそれなりにユーザーを抱えていると考えられているが、プライベートクラウドやハイブリッドクラウドを推すRed Hatにとっては、Microsoft Storeに対してRed Hat Enterprise LinuxやCetnOSを公式提供する利点は薄い。Red HatがIBMに買収されたことでその点はさらに強まったと言える。戦略の転換やユーザーからの強い要望がない限り、これらディストリビューションがMicrosoft Storeに登録されることはなさそうだ。

現状を考えると、Windows 10におけるLinuxディストリビューションはUbuntuという図式はしばらくの間続くことになるだろう。Ubuntuはユーザーも多く、ドキュメントやティップスも豊富に存在している。ユーザーにとっては扱いやすい状況だ。

WSL2を開発している理由は「ファイルシステム」

それでは、なぜ今WSL1の次のバージョンの開発に取り組んでいるのかということになるが、それはファイルシステムに原因がある。WSL1はシステムコールを差し替える技術だが、Windowsの場合にはそれだけでは済まなかった。LinuxのファイルシステムとWindowsのファイルシステムに概念の隔たりがありすぎるためだ。

たとえば、FreeBSDとLinuxはどちらもUNIX系のOSであり、ファイルシステムが提供している機能やインタフェースはよく似ている。しかし、LinuxとWindowsはその部分に大きな隔たりがある。Microsoftはドライバを導入してLinux側からWindowsのファイルシステムを利用できるようにすることでこの問題を解決した。しかし、完全には概念変換ができない部分があり、さらにパフォーマンスが発揮できなくなったという問題も存在していた。

特に問題になったのは、パフォーマンスだ。ファイルシステムのパフォーマンスはOS全体のパフォーマンスとして体感されやすい。要するに、WSL1は遅いという感じが出てしまう。ほかにもWSL1にはLinuxカーネルのシステムコールに100%対応し続けることが困難という理由もあるのだが、最大の理由はファイルシステムのパフォーマンスにあったように思う。

詳しいことは次回取り上げるが、現在開発が進められているWSL2は現在のWSL1とはまったく異なる技術で開発が進められている。Microsoftは「WSL1で提供していた機能はWSL2でも提供する」としているが、それでもいくつかの機能はWSL2では消えることになるだろう。利用している技術が異なりすぎるため、全て同じというわけにはいかないはずだ。

それでも消えないWSL1

WSL2の導入は早くても2020年5月ごろに配信されるWindows 10のフィーチャーアップデートからとなる見通しだ。それまではWSL1がデフォルトの機能として利用され、さらにWSL2導入後もWSL1は使い続けることが可能だと言われている（WSL1とWSL2は共存が可能だとされている）。

Windows 10とLinuxのシームレスな統合が重要であり、ファイルシステムのパフォーマンスや互換性にも問題がないということであれば、このままWSL1を使い続けて問題ないだろう。なお、WSL1からWSL2へマイグレートする手段も提供されるだろうから、すべてWSL2に置き換えるということもできると見られている。