Docker for Apple Siliconの仮想化基盤が変わるかもな話

2 min read読了の目安(約2200字

Apple Silicon向けのDocker Desktop RC 2で、バックエンドを切り替えられるオプションが追加されました。

https://docs.docker.com/docker-for-mac/apple-m1/

今までのqemuベースのバックエンド以外に、virtualization.frameworkを使ったバックエンドも追加されて、オプションのexperimentalのチェックボックスで有効化できます。

といっても、qemuも裏ではHypervisor.frameworkを利用していたので、Appleの提供する仕組みには乗っています。Virtualization.frameworkは高水準なAPIでLinuxに特化してます。VZLinuxBootLoaderというAPIが提供されています。

Virtualization.Frameworkも現在はおそらくはHypervisor.frameworkの上に構築されていると思います。実際、このオプションのON/OFFを切り替えてpyperformanceでベンチを測ってみたところ、ARM版のイメージではほとんどのテストで0.01%以内の速度差しかありませんでした。x86版のイメージ(--platform linux/amd64をつけて実行)では1%程度、新しい方が早いぐらいで今のところ誤差。CPUを酷使する場面では大きく変わらなそうです。

ただ、パフォーマンスはまだワークロードとか次第でネガポジがいろいろありそうです。実際、このDockerの記事でも、内部のテストでカバーしきれない領域があるので、ユーザー環境で試したフィードバックが欲しいということでした。中の人の説明では、mountではない場合の書き込みパフォーマンスは大幅に向上する見込みとのことでしたが、10倍以上遅くなったというDockerユーザーslackのコメントもありました(実際、known issueにflushが遅いというのはあった)。一方で、アイドル状態でCPU使用率が30%オーバーから4.5%に改善されたというコメントもありました。M1 macはスの状態ではバッテリーパフォーマンスが良いのですが、Dockerを走らせまくると結構消費が大きいな、という体感がありましたが、それも改善されそうです(といってもintel版よりもだいぶ良い)。

Virtualization.Frameworkの説明を見ると、詳細はわからないけどWSL2みたいな感じでよりOSに深く組み込まれていくのを想定していそうです。mac版Dockerは固定メモリのLinux仮想マシンをあらかじめ起動しておいて、その中でコンテナを起動する方式でしたが、このフレームワークではMemory Ballooningに対応しているとのことです。これはWSL2が実現している、ホストOSとゲストOSのメモリの共有の仕組みのようです。ホストのメモリの50%(以前は80%)がLinuxから利用可能なメモリとして見えており、Linux内のアプリがメモリを要求するとLinuxカーネル経由でWindowsカーネルがメモリを割り当てます。Linux内でメモリを開放すると、Windowsにメモリが帰るみこみです。ただ現時点ではバグがあってメモリを食い尽くしてしまうのですが、このWSL2が夢見ている世界がmacでも得られそうです。

3/28追記

今後、Memory Ballooningは入るのかDockerのベータテスターチャンネルで質問したところ、Stephen Turner氏から回答がありました。ロードマップにはあるものの、現在はまだqemuバックエンドと、virtualization.frameworkバックエンドのどちらがデフォルトになるか、検討中の段階であり、それが決定するまではまだvirtualization.frameworkに対して開発リソースを100%割り当ててはないとのことでした。

ぜひ、みなさんも両方使ってみて何かあればフィードバックしましょう。

Docker起動しただけのアイドル状態ではCPU使用率が低くなっているのを確認しました。Memory Ballooningがないのでメモリ消費量は今のところあんまり変わらない感じ。

QEMU

virtualization.framework