前バージョンから大幅に性能向上した新Linux環境「WSL 2」の実力を探る：Windows 10 The Latest
Windows 10 May 2020 Updateの目玉機能であるWindows Subsystem for Linux（WSL）の新バージョン「WSL 2」のインストールから性能評価までを取り上げる。WSL 2になってどのような変更が行われたのかを明らかにする。
新型コロナウイルスのまん延で不透明なところはあるものの、「Windows 10 May 2020 Update（バージョン2004）」の開発は順調に進んでいるようで、正式配布が近づいている。既に、Windows Insider Programによるプレビュー版の配布は、正式リリース版を試す「Release Preview」リングで行われており、近いうちに一般向け配布開始のアナウンスがあると思われる。
さて、今回はMay 2020 Updateの目玉ともいえる「Windows Subsystem for Linux（WSL） 2」に関して、Release Previewバージョンでのまとめを行い、併せて従来の「WSL」と機能や性能を比較してみることにする。
なお、本記事では、従来のWSLを「WSL 1」、May 2020 Updateに搭載される機能やその実行環境などを「WSL 2」と区別して表記し、両者をあわせて扱う場合に「WSL」と数字を付けずに表記する。
またLinuxは、Windows OSと違ってカーネルや関連ソフトウェアが個別のプロジェクトとして開発されている。これらをOSとしてインストールできるようにまとめたものを「Linuxディストリビューション」と呼ぶ。Linuxディストリビューションは一般的な用語であるが、本記事ではWSL用にMicrosoft Storeで配布されているLinuxディストリビューションのみを指すものとする。
WSL 2はWSL 1と何が違うのか？
WSL 2に関しては、これまでも幾つか本連載で取り上げてきた。開発途中のバージョンを扱った記事ではあるが、基本的な部分は変わっていない。
- Windows 10 The Latest「『WSL 2』へのバージョンアップでLinux互換環境はどう変わるのか？」
- Windows 10 The Latest「完全なLinuxがWindows 10上で稼働する？ 『WSL 2』とは」
- Windows 10 The Latest「Linuxがほぼそのまま動くようになった『WSL2』のネットワーク機能」
- Windows 10 The Latest「【WSL 2互換性チェック】NTFSのシンボリックリンクやジャンクションは使い物になるのか？」
WSL 1と同様、WSL 2はWindows OS内でLinuxソフトウェアを実行可能にするものだ。ただし、WSL 1とは内部構成などが異なる。簡単に違いをまとめたのが下表だ。
| 項目 | WSL 1 | WSL 2 |
|---|---|---|
| Linuxカーネル | エミュレーション | ネイティブ |
| 実行環境 | picoプロセス | 軽量ユーティリティー仮想マシン（VM） |
| 対応Windowsバージョン | Windows 10 Fall Creators Update（バージョン1709）〜 | Windows 10 May 2020 Update（バージョン2004）〜 |
| Windows 10 Home対応 | ○ | ○ |
| 仮想マシン支援機能 | 不要 | 必須 |
| WSL 1とWSL 2の違い | ||
WSL 1は、Windows 10 Fall Creators Update（バージョン1709）に最初に搭載された。Windows 10環境の中でLinuxアプリケーションが動作する環境を提供していたが、Linuxカーネルを使わず、カーネルが提供する機能（システムコール）は、エミュレーションを使い、Windows OSのカーネル機能などで実現していた。
これに対してWSL 2は、仮想マシンでLinuxを動作させる。このときに使われるのは、Hyper-Vを使った仮想マシン環境ではなく、「軽量ユーティリティー仮想マシン」と呼ばれるものだ。
基本的には仮想マシンだが、仮想マシンを管理するハイパーバイザー「Hyper-V」の管理外にある。ただし、Hyper-Vと共存することは可能で、仮想ネットワークスイッチや仮想ネットワークアダプターなどの基本的な仕組みは共用している。また、Hyper-Vではないことから、Hyper-Vが動作しない「Windows 10 Home」でもWSL 2の利用が可能だ。
WSL 2は、WSL 1の仕組みを使うため、インストールはWSL 1のインストールに追加して行うものとなっている。このため、既にWSL 1を利用している場合、追加手順のみでWSL 2を動作させることができる。
また、WSL 2をインストールしても、Linuxディストリビューションを既存のWSL 1で動作させ続けることも可能だ。ユーザー側から見ると、Linuxディストリビューションごとの動作バージョンが「1（本記事でいうWSL 1）」または「2（同WSL 2）」という違いでしかない。しかし、WSLでは、同一のLinuxディストリビューションを複数インストールすることはできず、かつ1つのLinuxディストリビューションは、WSL 1かWSL 2のどちらか一方でしか動作させられない。
WSL 2を利用するためには、CPUに「仮想マシン支援機能」（Intel VTもしくはAMD-V）が必要になる。ハードウェアによっては、出荷時にこれらをBIOS設定（UEFI設定）で無効にしてある場合があるため、インストール前に有効にしておく必要がある。
変更になったWSL 2のファイルシステム
WSL 1とWSL 2のもう1つの違いは、Linuxがインストールされる「ローカルファイルシステム」やWindows 10側（WSLではWin32側と表記することが多い）のファイルアクセスのためのファイルシステムにある。もともとLinuxはWindows OSのNTFSとは違うファイルシステムを持ち、ファイルのアクセス管理や属性などに違いがある。
| 項目 | WSL 1 | WSL 2 |
|---|---|---|
| Linuxローカルファイルシステム | ボリュームファイルシステム（VolFs／NTFS上） | Ext4ファイルシステム（VHDX内） |
| ローカルファイルシステムのWin32からのアクセス | 可（9PFs経由） | 可（9PFs経由） |
| WSLからWin32（NTFS）側へのアクセス | ドライブファイルシステム（DrvFs／NTFS上） | 9PFs（ネットワーク共有） |
| WSL 1とWSL 2のファイルシステムの違い | ||
WSL 1は、Windows 10側でLinuxカーネルをエミュレーションしていた関係から、NTFSの上に特別な領域を設け、そこにLinuxをインストールしていた。これを「ボリュームファイルシステム（Volume File System。以下VolFsと表記する）」と呼ぶ。
VolFsは、WSL 1がLinuxのファイルアクセスAPIをエミュレーションしてLinuxのファイルシステムのように見せかけているが、実際にはNTFS上のフォルダでしかない。ただし、Windows 10側からこれを直接アクセスすることは、Linux側の状態に矛盾を引き起こす（本来カーネルだけしか操作できないはずファイルがWindows 10側から変更されるなど）ことがあるため、アクセスが禁止されている。
その代わり、「9P」というプロトコルを使ったネットワークファイル共有の仕組みが提供されており、ネットワーク共有として「\\wsl$」という仮想的なサーバ名でアクセスが可能になる（これを本記事では仮に9Pファイルシステム、9PFsと表記する）。
WSL 1のLinuxからWin32側のNTFSをアクセスする仕組みは「ドライブファイルシステム（Drive File System。同DrvFs）」と呼ばれ、Linux側からは「/mnt/c」（設定で変更が可能）以下のパスでアクセスが可能になっている。こちらも、WSL 1がLinuxをエミュレーションしているため、NTFSへ直接アクセスができる。
これに対してWSL 2は、Linuxカーネルが動作しているため、そのインストールは、Linuxで標準的な「ext4」というファイルシステムに対して行われる。WSL 2では、仮想ハードディスクファイルを使い、このext4を実現している。WSL 2からNTFS側へのアクセスは、9PFsを使い、ネットワークアクセス経由で行う。このため、WSL 2では、Win32側のファイルアクセスはあまり速くない。
なお、WSLでは、DrvFs、9PFsともに、NTFSのシンボリックリンク、ジャンクションに対応している（Windows 10 The Latest「【WSL 2互換性チェック】NTFSのシンボリックリンクやジャンクションは使い物になるのか？」参照のこと）。
異なるIPアドレスが割り当てられるWSL 2
WSL 2のネットワークに関しては、Windows 10 The Latest「Linuxがほぼそのまま動くようになった『WSL2』のネットワーク機能」を参考にしてほしい。ここでは簡単にWSLのネットワークについてまとめておく。
WSL 1では、Windows 10側でエミュレーションを行うため、Linux側ではTCP/IPなどのプロトコルは処理せず、Windows 10側のネットワーク機能を利用する。このため、LinuxのIPアドレスもWindows 10側と同一になる。
| 項目 | WSL 1 | WSL 2 |
|---|---|---|
| WSL側IPアドレス | Win32と同じ | Win32とは別ネットワーク |
| Win32側 IPアドレス | Win32と同じ | 仮想ネットワーク側アドレス |
| WSL 1とWSL 2のネットワーク機能の違い | ||
これに対して、WSL 2では仮想マシン内でLinuxカーネルが動作し、ネットワークスタックも動作するため、IPアドレスはWin32側とは別のものを使う。このとき、仮想ネットワーク（仮想ネットワークスイッチ）が作られ、独自の内部ネットワークにWSL 2とWin32側の仮想ネットワークアダプターが接続した構造となる。現時点では、このIPアドレスの割り当ては、WSL 2の仮想ネットワークが立ち上がるときに行われるため、必ずしも一定のIPアドレスになるわけではない。
しかし、Windows 10側からは、常にWSL 2側は、Localhostとしてアクセスが可能になるような仕組みがある（詳細はWindows 10 The Latest「Linuxがほぼそのまま動くようになった『WSL2』のネットワーク機能」参照のこと）。これは、WSL 2側での待ち受けポート（Listenポート）をWin32側のソフトウェアが中継することで行われる。
また、WSL 2内では、「/etc/resolv.conf」に記載されているDNSサーバが常にWin32側の仮想ネットワーク側IPアドレスを示すようになっている（このファイルはWSL 2の起動時に自動的に生成される）。この仕組みを利用すれば、Linux側でも一定の手順でWin32側のIPアドレスを得ることが可能だ。
WSL 2のインストール手順
WSL 2を動かすためには、事前にWSL 1を動作させる必要がある。まとめてインストールすることも可能だが、WSL 1を動かした後にWSL 2をインストールするという、2段階で行う方が分かりやすい。WSL 1のインストールに関しては、ITの教室「【WSL入門】第1回 Windows 10標準Linux環境WSLを始めよう」を参考にしていただきたい。
まず、必要なWindows 10の機能をインストールする。それには、［コントロールパネル］−［プログラムと機能］を開き、左ペインで［Windowsの機能の有効化または無効化］を選択し、［Windowsの機能］で表示されるリストから「Linux用Windowsサブシステム」を有効にする。
WSL 2を使うなら、このリストの一番下にある「仮想マシンプラットフォーム」も有効にする（Windows 10 Homeでもサポートされている）。その後、システムを再起動してインストールした機能を有効化する。GUI操作が面倒という場合には、cmd.exeまたはPowerShellで以下のコマンドを実行後、手動で再起動させてもよい。
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
再起動後、Microsoft StoreからWSL用のLinuxディストリビューションをインストールする。Linuxディストリビューションを探すには、Microsoft Storeアプリの検索欄に「WSL」と入力する。どのディストリビューションを選んでも構わない。
Microsoft StoreでLinuxディストリビューションをインストールする
Microsoft Storeを開き、検索で「WSL」と入力する。結果にLinuxディストリビューションが表示されるので、好みのものをクリックしてインストールする。
Linuxディストリビューションをインストールすると、［スタート］メニューに登録されるのでこれをクリックしてWSL 1としてLinuxディストリビューションの実行環境を作らせる。このとき、「ユーザー名」と「パスワード」を聞いてくるので、これを設定する。特に制限もないので、適当なユーザー名、パスワードで構わない。
パスワードは、Linuxディストリビューションによっては、管理者権限でプログラムを実行させるsudoコマンドなどで要求されることがあるため、無理に難しいものにする必要はなく、覚えやすく入力しやすいものでよい。WSLでは、起動時にパスワードを要求されることはない。
WSL 1でLinuxディストリビューションが動作したら、これをWSL 2で起動できるように変更する。それには、コマンドプロンプトまたはPowerShellを開き、以下のコマンドを実行する。いまのところWSL 2への変更はGUIでは行えず、コマンドを使う必要がある。
wsl.exe --set-version ＜ディストリビューション名＞ 2
LinuxディストリビューションをWSL 2用に変換する
WSL 1を有効にすると、wsl.exeコマンドが利用できるようになる。Windows 10 May 2020 Update（バージョン2004）では、オプションが増えており、「-l -v」オプションで動作バージョンが表示できる。WSL 1でインストールしたLinuxディストリビューションに対して、「--set-version」オプションを使い、WSL 2で動作するようにLinuxディストリビューションを変換できる。
これで指定したLinuxディストリビューションがWSL 2で起動するようになる。
上記のコマンドを実行して、LinuxディストリビューションをWSL 2用に変換する際、「WSL 2を実行するには、カーネルコンポーネントの更新が必要です」というメッセージが表示された場合、Microsoftの「WSL 2 Linuxカーネルの更新」ページを開き、「wsl_update_x64.msi」をダウンロードして実行するとよい。
なお、Linuxディストリビューション名は、以下のコマンドで表示させることができる。「-l」オプションだけでLinuxディストリビューション名を表示するが、「-v」を付けると、LinuxディストリビューションがWSL 1なのかWSL 2なのかといったバージョンも表示するようになる。
wsl.exe -l -v
また、今後インストールするLinuxディストリビューションは、全てWSL 2としたい場合、以下のコマンドでデフォルトの動作バージョンをWSL 2に指定できる。
wsl.exe --set-default-version 2
WSL 2の性能をベンチマークテストで調べてみる
さて、WSL 2は、WSL 1より性能が高いのかどうかが気になるところだ。そこで、ベンチマークソフトウェアを使い、その実行速度などを測定してみた。利用したのは、「byte-unixbench」と呼ばれるもので、米Byte誌が作成したプログラムをベースに現在もメンテナンスが続けられているものだ。
インストール手順などについては、省略させていただく。評価には、Lenovo Yoga 13（Intel Core i7-3517U、クロック2GHz、2コア／4スレッド、メモリ8GB、128GB-SSD）に、Windows 10はビルド19041.208（Insider Preview版）をインストールして利用した。Linuxディストリビューションには、Ubuntu-18.04を使い、事前に最新状態にしてあるが、ディストリビューション自体は18.04LTSのままである。テストでは、wsl.exeを使いWSL 1とWSL 2を切り替えて行った。
下のグラフがベンチマークの結果となる。今回は、「oldsystem」と呼ばれる一連のシステム性能を測定するベンチマークを行った。測定したのは、下表の8項目である。
| テスト名 | テスト内容 |
|---|---|
| System Call Overhead | 一連のシステムコールを繰り返し、一定時間内に何回呼び出せ方かを測定 |
| Process Creation | 自分と同じプロセスを生成させ、すぐに終了させるというプログラムを繰り返して、1秒間に何回プロセスを生成できるのか測定 |
| Execl Throughput | 実行ファイルを指定してプログラムを起動させるシステムコールの性能を測定 |
| Pipe-based Context Switching | Pipeを使って、親子関係にあるプロセス間でpipeによるデータの受け渡しを行う処理が1秒間に何回実行できるかを測定 |
| Pipe Throughput | pipeによるデータ転送をどれだけ行えるかを測定 |
| File Copy 256 bufsize 500 maxblocks | ブロックサイズを変えて、ファイルのコピー性能を測定 |
| File Copy 1024 bufsize 2000 maxblocks | |
| File Copy 4096 bufsize 8000 maxblocks | |
| byte-unixbenchのテスト項目 | |
byte-unixbenchの結果
WSL 2がWSL 1に対してどれだけ高速になったかを示す倍率をグラフ化した（WSL 1の性能は1倍）。唯一、Pipe-based Context Switchingのシングルプロセス処理のみWSL 1よりも遅かった。
最初の4つは、システムコール関連のもので、アプリケーションからシステムコールを行い、WSL 1とWSL 2でその速度を比較した。後半の4つは、ファイルシステムのアクセスに関するものだ。なお、ファイルシステムとしては、Linuxがインストールされているローカルファイルシステム側で行った。
グラフは、WSL 1を「1」にした場合のWSL 2の性能がどれだけ向上しているかを示す「倍率」である。ベンチマークは、1プロセスと4プロセスで行ったが、「Pipe-based Context Switching」を除き、全てWSL2 の方が速かった。
なお、「Pipe-based Context Switching」だが、ベンチマークを繰り返したとき、エラーになることがあった。byte-unixbench自体は、かなり前から使われてきたものであり、既に多くのシステムで動作している。そのため、テスト側に問題がある可能性よりも、WSL側に何らかの問題がある可能性の方が高い。
WSL 2はWin32側のファイルアクセスが遅い
全体としてWSL 2の性能の方が高いが、WSL 2にも欠点がある。Linux側からのWin32側のNTFSへのアクセスが遅いことだ。これを調べるために、ddと呼ばれるLinuxコマンド（UNIX時代からあるコマンド）を使い、ファイルの読み書きを行わせてみた。ddコマンドは、ファイルの読み書きを行わせるものだが、実行後にアクセス速度を表示できる。これを使い、ローカルファイルシステムとNTFS側でファイルの読み書きの速度を測定した。
WSL 2のファイルシステムのアクセス速度
ddコマンドを使って、WSL 2のファイルシステムのアクセス速度を調べて見た。WSL 2は、ローカルファイルシステム（ext4）のアクセスは高速だが、Win32側のファイルアクセスが遅く、1.6MB/sとWSL 1の1/24程度しかなかった。
WSL 1では、VolFsもDrvFsもNTFS上にあるため、ほとんど速度が変わらない。これに対して、WSL 2のext4でのファイルアクセスは高速になっている。
しかし、WSL2からWin32側のファイルをアクセスする9PFsでは、かなり速度が遅く、特に読み出しの速度に関しては1.6MB/sとWSL1のDrvFsに比べると1/24にまで落ちている。WSL 2では、Win32側の大きなファイルをLinuxで直接処理することは避けた方が無難だ。なお、この件は、Microsoftも認識しており、Blogなどに記載があるため、今後改善される可能性もある。
全体として、WSL 2の方が実行性能が高く、可能ならWSL 1よりもWSL 2を利用した方がいい。ただし、現時点では、Win32側ファイルアクセスが遅いため、できるだけWSL 2のローカルファイルシステム側で作業し、大きなファイルを処理するような場合には、ext4側へファイルをコピーしてから処理するといった方法を考える必要があるだろう。
Copyright© Digital Advantage Corp. All Rights Reserved.