本連載ではこれまで、Windowsのユーザーという視点からWindowとLinuxの使い方の違いなどを取り上げてきた。前々回と前回は、WindowsとLinuxに関係があるということで、「Windows Terminal」と「Visual Studio Code with WSL」という最近のアプリケーションを紹介した。
今回は前回の説明にも出てきたWSL(Windows Subsystem for Linux)について説明する。Microsoftは現在、WSLの次のバージョンとなるWSL 2の開発を進めている。WSL 2は名前こそWSLを引き継いでいるものの、利用されている技術はまったくの別物になっている。このタイミングで、WSL 1とWSL 2についてまとめておこう。
WSL 1 - 最初のWSL実装系
この連載を始めるきっかけともなった技術がWindows 10に搭載されるようになったWSLだ。これは、WindowsでLinuxバイナリを実行可能にする技術。
WSLのリリースによって、Microsoft Storeに複数のLinuxディストリビューションが登録され、手軽にWindowsでLinuxを実行できるようになった。最近のWindowsにおけるLinux利用の新しい流れを生み出すきっかけとなった技術と言える。
Microsoft Storeには複数のLinuxディストリビューションが登録されているが、今のところ公式的な扱いになっているのはUbuntuだ。これは、Ubuntuの開発を後押ししているCanonicalがWindows向けUbuntuの開発を表明しているためで、今のところこの態度が変わる理由は見られず、今後も提供が続けられると見られる。
つまり、Windowsで最新のUbuntu LTS版を使うというのが、今後数年の間はWindowsで当たり前のことになっていくような状況にある。
-
Ubuntu 18.04 LTS on Microsoft Store
それでは、この状況を生み出すきっかけとなったWSLどのような技術であるかというと、いわゆる互換レイヤ技術というものが表現としては近い。FreeBSDでLinuxバイナリを実行するためのLinuxバイナリ互換技術などがこの技術に近く、FreeBSDに限らず類似の技術はUNIX系オペレーティングシステムの多くがすでに利用している。
具体的には、Linuxのシステムコールを解釈してWindowsカーネルのシステムコールに置き換えるレイヤを実装したものであり、LinuxバイナリをWindowsカーネルで実行することを可能にする技術である。LinuxとWindowsはファイルシステムが提供している機能がかなり異なるため、WSLにはさらにファイルシステム変換を実現するためのドライバも導入されている。
レイヤ技術の特徴はその軽量さにある。PCをエミュレートするタイプの技術と比較すると、プロセッサ性能が高くなりやすい。場合によってはほとんどネイティブと同じ速度で動作するという特徴がある。UNIX系オペレーティングシステム同士の互換レイヤであればファイルシステムもほとんどネイティブに動作するのだが、WSLはファイルシステムに関しては性能が低い。WindowsとLinuxの違いを補うために入れたドライバを経由するため、どうしても性能を発揮できない。
また、常に開発を続けなければならず、100%の互換を実現するのが難しいという課題もある。Linuxカーネルが新しいシステムコールを提供すれば、互換レイヤ側もそれに対応しなければならない。さらに、100%の互換性を維持するには常に調整やデバッグを続けなければならない。プロセッサ性能は発揮しやすいものの、カーネルシステムコール100%互換やファイルシステム性能の実現が難しい、これが一番最初に導入されたWSLということになる。
そして、Microsoftは次のバージョンとなるWSL 2の開発を発表した。これを受けて、これまでのWSLはWSL 2と比較するためにWSL 1と呼ばれるようになった。
WSL 2 - 現在開発中の仮想環境ベースWSL
MicrosoftはWSL 1のシステムコール互換性の向上やファイルシステム性能改善に取り組んでいた。少なくとも、WSL 1がリリースされてから最初の数カ月はその方向で開発を進めていた様子がうかがえる。
しかし、どうやらMicrosoftはその方向での開発を断念したようだ。内部でどのような意思決定があったのかはわからないが、WSL 1の手法ではファイルシステム性能の劇的な改善が困難であることが判明したか、経営判断的に別の技術を使う方向で指示が出たか、または複合的な理由から総合的に判断したか。いずれにせよ、この辺りが、WSL 1の開発断念の根拠になっているのではないかと思う。
次にMicrosoftが取り組んだことは、Hyper-Vの技術を使って仮想環境でLinuxを実行することだ。MicrosoftはPCをエミュレートする仮想化技術であるHyper-Vを保持しているので、流れとしては順当といえる。むしろ、なぜWSL 2のアプローチではなく、互換レイヤ技術であるWSL 1になぜ最初に取り組んだのか、こちらのほうが突拍子もない取り組みのように見える。
WSL 2はいわばPCをエミュレートするため、Linuxカーネルがそのまま動作する。このため、当然のことだが、Linuxカーネルシステムコール互換は100%だ。なにせ、Linuxカーネルそのものが動作している。
さらに、ファイルシステムの性能の低さも解消できる。仮想環境で動作する以上、ネイティブに動作するファイルシステムと比べればパフォーマンスは低くなるが、それでもWSL 1よりもファイルシステム性能が優れている。
一方、WSL 2のプロセッサ性能は、互換レイヤ技術と仮想化技術の特徴がそのまま出ており、WSL 1よりも低くなっている。CPUバウンダリな処理はWSL 2で実行すると遅くなってしまうわけだ。MicrosoftはWSL 1もそのまま提供するとしていることから、基本的にはWSL 2を使いつつ、プロセッサ性能が必要な場合はWSL 1を利用する、そんな状況になっていくのではないかと考えられる。
WSL 1とWSL 2の互換性は？
Microsoftは開発者向けに開発中のWSL 2の機能を提供している。MicrosoftはWSL 1と同じ状況になるようにWSL 2を調整するとしている。WSL 2は見た目としてはWSL 1と同じものを目指しているものの、技術的には仮想化アプリケーションでLinuxをエミュレートしているので、ネットワーク設定やファイルシステムの見え方などがまだWSL 1と同じになっていないのだ。
さらに、問題であるのは、WSL 2は仮想化アプリケーションであるため、プロセッサの提供している仮想化支援技術を使っている点だ。このため、現状のままではWSL 2を使っている状態ではほかの仮想化アプリケーションを使うことができない。WSL 2を使たらVMware Workstationが使えないということになると、困る人も多いだろう。
この点に関しては、サードパーティ側で対応を入れる必要がある。Virtual Boxは既にWSL 2に対応しており、Virtual Box 6.0.0以降のバージョンであれば、WSL 2と同時に利用することが可能だ。VMware Workstationも人気の高い仮想化アプリケーションであり、WSL 2の正式リリースに合わせて対応してくることが予想されるが、ユーザーのニーズの高さにかかってくるのではないかと見られる。
Linux開発環境としてのWSL
MicrosoftはVisual StudioやVisual Studio Codeといった人気の高い開発環境を有している。さらに、ここ数年でこうした統合開発環境でLinuxアプリケーションを開発するための機能を強化している。WSL 1やWSL 2はこうした取り組みの要となるものだ。
加えて、MicrosoftはWindows以外のプラットフォーム、特にLinux向けのアプリケーションを開発する統合開発環境として、Visual StudioやVisual Studio Codeの機能強化に取り組んでおり、WSL 1やWSL 2はLinuxネイティブなビルドを実施するために欠かすことができないと考えられる。
Windows Terminalはまだ荒削りだが、そのまま開発が進めば日常的に利用できる多機能高性能なターミナルアプリケーションになりそうだ。そうなれば、WindowsでLinuxを利用する障壁も下がる。WSLはデフォルトでは有効化されていない機能だが、ニーズが高まればデフォルトで有効化される可能性もある。Visual StudioやVisual Studio Codeから利用する設定も、現在よりも簡単になっていくかもしれない。
MicrosoftはAzureを展開する関係もあって、Windows以外のプラットフォームサポートに積極的に取り組んでいる。主な対象はLinuxだが、この流れは今後強化されることはあっても消極的になっていくことはないように見える。WindowsとLinuxは今後ますますおもしろい状況になっていくだろう。しばらくは目を離せない状況が続きそうだ。
