macOS Big Surのパブリック・ベータ版リリースされたが、肝心の「アレ」は手に入らない。アレとはもちろん「A12Z」を搭載したMacであり、その上で動くmacOSのこと。もちろん、現行のIntel MacでもBig Surは動くが、肝心のARM環境が実際どうなのかは想像の域を出ない。ああ、開発者向けに提供されるA12Z搭載Mac miniさえあれば(NDAがあるからどのみち原稿には書けないけれど)……。
さて、今回のテーマはズバリ「MacがARMアーキテクチャになるということ」。前回、前々回とIntelからARMへのアーキテクチャ移行がスムーズに行えるか、どのような支援ツールが用意されているかを紹介してきたが、今回はARMアーキテクチャへの移行で一変するはずの「仮想化」について考えてみたい。
そもそも「仮想化」とは
Intel Macの登場以降に普及したソフトウェアの新ジャンルのひとつに「仮想化ソフト」を挙げることができる。コンシューマ向けでいえば、macOS向けにはParallels DesktopやVMWare Fusion、Virtual Boxといったプロダクトが存在し、Mac上でWindowsやLinuxをシームレスに動作させる目的で活用されている。
ARM Macの話へ進む前に、この仮想化ソフトについてざっくりと整理しておきたい。Macに留まらない、クラウドなどコンピューティング全般に広がる話になってしまうが、混乱を避けるためだ。
PC向けの仮想化ソフトは、「ホスト型」と「ハイパーバイザ型」に大別できる。前者はハードウェアをソフトウェアとして抽象化し、その上でLinuxやWindowsといったOS(ゲストOS)を動作させるもので、登場以来の典型的な仮想化ソフトの実装形態だ。しかし、ハードウェアへのアクセスは必ずホストOS(Macの場合macOS)を経由するためオーバーヘッドが避けられず、利用するマシンで実現できるはずのゲストOSのパフォーマンスは数段低下してしまう。
後者のハイパーバイザー型は、ハードウェアを直接制御する。その結果オーバーヘッドが減り、ゲストOSのパフォーマンス低下を最小限に抑えることができる。そのためにはCPUやカーネルに追加された機能を利用したり、ハードウェアに近い(低いレイヤーの)APIを整備する必要が出てくるため、macOSではIntel Coreシリーズでサポートされている仮想化支援機能(VT-xやEPT)を活用、フレームワーク(Hypervisor.framework)も提供している。
最近ではもうひとつ、「コンテナ型」も加わった。コンテナ型とは、ホストOS上に独立したマシン同様に機能する独立空間(コンテナ)を複数設け、それぞれにアプリ/サービスを割り当て稼働させるというもの。1つのOSに1つのユーザ空間しか存在しない従来型の仮想化とは異なり、1つのOS上で仮想的なユーザ空間を複数稼働できるコンテナ型は個別にCPUやメモリを割り当てる必要がないため、オーバーヘッドを減らせるメリットがあるのだ。ちなみに、WWDC 2020の基調講演でARM Macの仮想化環境が紹介されたとき、Parallels DesktopでLinuxを動かす様子がちらりと紹介されたが、そこで画面に現れた「Docker」はコンテナ型の仮想化ソフトだ。
ARM Macでの「仮想化」
Macに関していうかぎり、現在における仮想化ソフトの主流はハイパーバイザー型で、macOSに用意されたHypervisor.frameworkを活用している。しかし、このフレームワークはIntel CPU向けに設計され、VT-xやEPTといった仮想化支援機能もx86_64に依存している。
WWDC 2020では、ARM MacでHypervisor.frameworkをアップデートする計画が明らかにされた。ということは、Apple Siliconにも仮想化支援機能があり、それを活用したハイパーバイザー型仮想化ソフトが登場するということなのだろう。具体的な言及はなかったが、デモで紹介されたParallels Desktopがすでにそうなのかもしれない。
そもそもの話だが、仮想化ソフトは命令セット(ISA/機械語)の変換は行わないので、ARM Macの仮想化ソフトで動作するのはARMネイティブのOS/アプリということになる。前述したWWDCのデモも、実行しているのは「ARM version of Debian Linux」としっかり紹介していた。
気になるのはWindowsが動くかどうかだが、MicrosoftはARM版Windowsを提供しているので、最適化はともかく動くには動きそうだ。しかし、現在のところARM版Windowsは単品販売/ライセンスされていないため、実際に利用できるかどうかはMicrosoftの判断ということになる。
一方、目線を変えるとARM Macの仮想化ソフトには大きな可能性が出てくる。ARM向けのOS/アプリをネイティブ環境に近いパフォーマンスで実行できるということは、ARMベースが多い組み込み系/IoTデバイスの開発に活用しやすくなるからだ。個人的には、Raspberry Pi向けに準備しているオーディオ再生用Linuxディストリビューションの開発に使おうと考えているが、実機で開発するより快適かどうかはApple Siliconの性能次第、ARM Macの出来次第となりそうだ。