あらゆるスケールのMac

あらゆるスケールのMac

おそらくX（旧Twitter）で私の投稿を見たことがあるでしょう。数百台のMacBook Proを開封してデータセンターに展開する様子です。この動画は多くの人の関心を呼びました。一見すると狂気の沙汰ですが、私たちが今知っていることを踏まえれば、ある種の合理性があります。

［画像］

Namespace

@

namespacelabs

新しいサーバーラックのためにMacを大量に開梱しています。

午後4時27分

·

2026年8月24日

·

2500万回再生

1K9645K1.8K

今日は、カスタムMacラックを構築するために何が必要か、macOSインスタンスを数秒でゼロから起動し、Appleがリリースしてからわずか数時間で新しいXcodeバージョンを配信する方法について、背景を説明したいと思います。

なぜMacBookなのか？

お客様がMacを必要としているからです。そして、Appleが私たちに他の選択肢を与えなかったからです。

多くのお客様はiOSアプリを開発・テストしています。MacなしではiOSアプリをビルドできません。iOSシミュレータはMac上でしか実行されません。さらに、App Storeにアプリをリリースするには、Appleは最新のXcodeバージョンを使用することを要求します。xtoolxtoolは素晴らしいですが、まだ本格的な代替手段ではありません。したがって、コーディングエージェントにはMacが必要です。

しかし、それでもなぜラップトップなのでしょうか？画面のピクセル、キーボードのボタン、バッテリーのイオンの無駄遣いではないでしょうか？はい、Mac Miniの方がデータセンターには適しています。確かに、リモート管理機能は非常に基本的で、冗長電源もなく、どちらの面に置いても冷却が困難になる美しいケースを備えています。しかし、これらはすべて私たちが管理方法を学んだ既知の課題です。

しかし、実際に数百台のMiniを注文しようとしたことはありますか？私たちは試しました。1月に注文し、7月に納品されました。2026年のサプライチェーンが混乱している世界へようこそ。Appleがすべてのデバイスに一度に更新されたCPUモデルをリリースしないことも忘れないでください。そのため、Mac Miniは10ヶ月間M5コアを入手できず（その後、他のどのデバイスモデルよりも先に突然M6を入手しました！）。私たちは顧客に最高の最新情報を提供することを約束しているので、独創的になる必要がありました。こうしてMacBook-in-Datacenterプロジェクトが誕生しました。

私たちの美しいMacラック

良いデザインには繰り返しが必要です。そして、私たちは間違いなく最初からすべてを正しくできたわけではありません。しかし、私たちはシステムを完璧に仕上げたと信じています。

［画像: Namespaceラック内のMacBook］

各MacBookは、リモート管理のためにIP KVMに接続されています。ラップトップを扱う上で不可欠です。Mac Miniとは異なり、ラップトップのファームウェアは画面を念頭に置いて設計されています。一部のメンテナンスアクションは、美しいGUIのボタンをクリックすることによってのみ実行できます。

もちろん、各MacBookには外部10GイーサネットNICが接続されています。Namespaceの多くのスタッフはネットワークオタクであり、顧客に提供する接続速度と信頼性に誇りを持っています。

そして電源です。合計で、ラップトップあたり4本のケーブル、棚あたり48本、さらにイーサネット用12本、KVM配線が含まれます。ケーブル管理が非常に重要だと言っておきましょう。

熱管理も同様です。現在、ホットスポットからの熱を吸い取り、近くの機械に熱風を吹き付けないように導くカスタムメイドのホルダーを展開しています。

予期せぬ問題：HDMI、FileVault、USB NIC

当然ながら、私たちは問題や課題を予想していました。ただ、それが現れた場所が予想外でした。

おそらく、上の写真を見て、MagSafeケーブルが接続されているのを見て、「MagSafeは安全ではなく、誤って切断される可能性がある」と皮肉なツイートを書き始めた人もいるでしょう。

そして、私もそれを心配していました。しかし、現実はMagSafeの切断は非常に少ないケースしか見ていないということです。

最も信頼性の低いケーブルは？HDMIです！しばしば太くて柔軟性がありません。棚に触れるたびに外れてしまいます。

幸いなことに、今ではほとんど完璧なケーブルを見つけ、希望通りに曲がるものを見つけました。そして、それらの供給をすべて買い占めました。Amazonではもう注文できません。

もう一つの苦痛の原因：FileVaultディスク暗号化。あるいはむしろ復号化。MacBookが再起動すると（予期せず）、ローカルディスクのロックを解除するためのパスワードを求められます。プロンプトは画面に表示されます（ラックのどこかにある閉じられたラップトップの画面に、ドヒ！）。問題ない、と思ったのですが、それほど簡単ではありませんでした。パスワードプロンプトは、5分間非アクティブ状態が続くと外部画面から消えます。そこで、macOS Tahoeが便利な機能をもたらしたことを思い出しました。SSHプロトコルを使用してFileVaultをリモートでロック解除できるのです。それでもうまくいきません。ラップトップでは5分で期限切れになります。この状態から抜け出す唯一の方法は、物理的にボタンを押して時間内にロック解除を急ぐことのようです。Macの再起動このトピックに関連して、ちょっとしたヒントです。ディスクのロックを解除したままにしておきたい場合に、Macを再起動する方法があります：fdesetup authrestart。

そして、単純なバグもあります。特定の条件下では、外部USB NICが機能しなくなり、電源が入っていないように見え、リンクが表示されなくなります。別のケーブル、別のNIC、別のスイッチポートを試しても、うまくいきません。しかし、ネットワーク設定を素早く確認し、macOSの設定で「ネットワークサービス」を削除して再作成すると、元に戻ります。

Mac MiniとStudioはどうですか？

現時点では、私たちは非常に順調です。M5およびM6 Mac MiniとStudioがまもなく私たちのフリートに加わります。データセンターでの管理ははるかに簡単です。10Gbのネットワークカードが内蔵されており、電源投入後に自動的に起動し、MDMを介してOSを完全に自動構成できます。

しかし、NamespaceにはMini向けの特別な工夫もあります。効率的な冷却に重点を置いたカスタムメイドの棚を設計しています。展開中の設計に到達するために、空気の流れシミュレーションを使用していくつかの設計をテストしました。

最終的にMac Miniの設置は簡単です。開封し、10台をホルダーに入れ、電源とネットワークを接続し、一度電源ボタンを押します（非常に不便な場所にあることで有名です）。そこからは自動化がそれらを処理します。

Macの仮想化

舞台裏では、Namespaceインスタンスは仮想マシンによってバックアップされています。Linux、Windows、Macインスタンスを最も効率的な方法で実行するために、複数の仮想マシンエンジンを統合されたプラットフォームに組み込んでいます。これにより、キャッシュボリューム、テレメトリ、VPC接続など、Namespaceを特別なものにしているのと同じ機能を提供できます。

驚くことではありませんが、私たちのMacソリューションは、Appleの優れたVirtualizationフレームワークに基づいています。これは組み込み可能で柔軟な仮想マシンエンジンです。システムアーキテクチャにおける位置づけは、Firecrackerと比較するのが最も簡単です。エンドツーエンドの汎用VM操作と一般的な周辺機器を実装しています。

完全を期すために、Appleはより低レベルのHypervisorフレームワークも提供しています。これはLinuxのKVM APIに相当します。例えばQEMUはmacOSで内部的にこれを使用しています。Hypervisorはコードを隔離された状態で実行する方法を提供しますが、アプリケーション開発者はマシンアーキテクチャと周辺機器の大部分を実装する必要があります。これにより多くの制御が可能になりますが、残念ながらmacOSを実行することはできません（サードパーティが再現できない、または再現すべきではないApple独自の環境が必要です）。

実際、ほとんどの競合プラットフォームは同じ基盤上に構築されています。しかし、詳細は重要です。Appleは、高速かつ安全に動作するように、適切な方法で配置する必要があるいくつかのプリミティブを提供しています。異なる制約で同様の問題を異なる人々がどのように解決するかを見るのは、より興味深いことです。

Apple Virtualizationの制限

よく知られた制限として、Appleは物理Macあたり2つのmacOS VMしか許可していません。24コアと192GBのメモリを持つMac Proであっても、2つのゲストVMしか実行できません。この制限は私たちの製品提供にも影響します。14コアのMac Miniでは6または12コアのインスタンス、18コアのMacBookでは8/16コアのインスタンスを実行しています（管理オーバーヘッドのために数コアを予約しています）。

Virtualization VMの重要な考慮事項は、仮想CPUが、Virtualizationを統合するソフトウェア（ここではNamespace VMホスト）とは別のOSプロセス（図のVMMプロセス）によって実行されることです。VMの動作をフックしたり、カスタム仮想デバイスを実装したりしたい場合、それらとのすべてのやり取りには、VMプロセスと「ホスト」プロセス間のIPCラウンドトリップが必要です。このようなコンテキストスイッチは避けられず、システムを設計する際に考慮する必要があります。

仮想ネットワーク

Virtualizationフレームワークは、仮想マシンをネットワークに接続するためのいくつかの方法を提供します。例えば、ブリッジモードとNATモードでは、VMMプロセスからホストのネットワークインターフェイスに直接トラフィックがルーティングされます。これらは、ワークロードが信頼できるローカルコンピュータで実行されるVMに適しています。

Namespaceインスタンスは信頼されていないコードを実行するため、VMが何にアクセスできるか、またはできないかについてポリシーを強制する必要があります（これらのポリシーは顧客定義も可能です！）。また、インスタンスに、ゲストシステムにとってあたかもローカルネットワーク上にあるかのように見える追加サービスをいくつか提供しています。

これには、ソフトウェアでVMへの出入りを処理するモードで、ゲストネットワークを完全に制御する必要があります。私たちは、Google gVisorプロジェクトのユーザー空間TCP/IPスタックに基づいてゲストネットワークを構築し、インスタンスのIPゲートウェイ/ファイアウォールとして使用しています。これにより、ゲストによって制御される未処理パケットに対するホストOSの露出を最小限に抑えます。

ネットワークパケット処理は非常に効率的である必要がありますが、前述のようにパスにはIPCが含まれます。VMMプロセスはまずパケットを「VMホスト」プロセスに渡す必要があり、次にVMホストプロセスがそれを処理してネットワークインターフェイスに渡します。IPCラウンドトリップの数を最小限に抑えるには、慎重な実装と可能な限りのバッチ処理が必要です。

上記の方式により、NamespaceのmacOSインスタンスは最大4Gbpsの上り帯域幅（Fast.comによる）に達します。残念ながら、これは回線速度よりは低いです。私たちは代替アプローチを模索しており、ネットワーク処理のためにIPCを完全に回避する方法のアイデアも含まれています。しかし、新しいセットアップの本番稼働はまだ将来に残されています。結局のところ、4Gbpsでも十分に立派な速度です。

VMイメージ

Apple Virtualizationを使用して最初のVMを作成するのは非常に簡単です。macOSインストーラーXIPをダウンロードし、UTM/Tart/数十のオープンソースVirtualizationラッパーのいずれかを使用してマシンを起動し、セットアップアシスタントを進め、Xcodeをインストールすれば準備完了です。これで、ローカルで任意のワークロードを実行するためにフォークできるVMイメージが手に入ります。

しかし、複数のiOSバージョンでテストする必要があるため、いくつかのiOSランタイムをインストールします。そして、今後のXcodeベータ版（および新しいランタイムも）をインストールします。あっという間にVMイメージは500GBに成長します（iOSランタイムパッケージは巨大です）。

また、その小さなものをテストするために、前のバージョンのmacOSも必要になります。ここでさらに500GBです。Appleが新しいmacOS開発者プレビューをリリースすると、さらに1つのイメージが必要です。

そして、Xcodeベータ版が同じシステム上の非ベータ版Xcodeを微妙に壊してしまうことに気づきます（実話です！）。結局のところ、Xcodeのインストールは「グローバル」なCoreDeviceとCoreSimulatorのバージョンを更新します。したがって、ベータ版Xcodeシミュレータのバグは、表向きは安定版のXcodeバージョンを使用している場合でも表示されます。そのため、現在ではプレリリースXcodeの有無でイメージバージョンを管理しています。

そして、2TBのVMイメージができました。それは何に？2TBのMacBookハードドライブに？

これが私たちが直面した課題でした。数百台のマシン全体にわたって、巨大なイメージを構築、配布、保存する必要がありました。

ビルドプロセス

ビルドプロセスは再現可能であるため、Appleが新しいソフトウェアバージョンをリリースしたときに確実に新しいイメージを生成できます。ビルドは、人間がユーザーとして行うインストールと構成を再現するスクリプトによって駆動されます（例：ビルドスクリプトはシェルコマンドを実行したり、UIボタンをクリックしたり、VMを再起動したりできます）。可能な限り、Appleが設計したコントロールを使用してVMを構成し、典型的なローカルユーザーが見るものと矛盾する予期しない動作を避けるようにしています。当然ながら、イメージのビルドは自動化され、再現可能なプロセスです。これは、YAMLファイル内の操作シーケンスとして表現されたワークフローによって駆動されます。操作は、VM制御（例：再起動）、シェルスクリプトの実行、またはVNCを介したシステムまたはセットアップUIとのプログラム的な対話である可能性があります。

生成されたVMイメージは、Namespace内部イメージレジストリに引き渡されます。これは、LinuxおよびWindowsイメージのストレージ、レプリケーション、配布を処理するのと同じレジストリです（Matteoによる素晴らしい記事でカバーされています）。ディスクイメージは、通常のコンテナイメージとは大きく異なります。OCIレイヤーは単純なファイルのtarballですが、ディスクは一般的にバイトのフラットな配列です。実際には非常に大きな配列です。そして、かなりの部分が空のスペースを含んでいます。これは、ユーザーが空きスペースとして利用できるディスクスペースです。

当然、レジストリに保存する際に「空の」データを転送および保存するのは非常に無駄になります。そのため、レジストリに保存する際にイメージの「スパース性」を維持できるシンプルな形式を開発しました。割り当てられていないイメージの範囲は、わずか数バイトしかかかりません。

さらに別の重要な最適化があります。VMイメージセクションで言及した例のシナリオを思い出してください。同じシステムのイメージがあり、追加のXcodeインストールのみが異なります。明らかに、後者のイメージは前者を使用して構築され、ほとんどのバイトは変更されていません。

私たちのストレージ形式は「シャローコピー」の関係を維持し、そのようなイメージを複数のレイヤーとして格納します。ベースレイヤーはそれらの間で共有され、後続のレイヤーには変更されたブロックのみが含まれます。

配布

この時点で、イメージはOCIレジストリにあります。しかし、もちろんVirtualizationフレームワークは、レジストリにあるディスクを直接使用してVMを開始することはできません。ノード自体に何かが必要です。VMディスクは、ローカルホストSSD上のイメージファイルでバックアップされるか、ネットワークブロックデバイス（NBD）プロトコルを使用してサーバーにディスクI/O要求をルーティングできます。後者は、ローカルキャッシュから需要の高いデータをインテリジェントに提供できるようにする一方で、不要なブロックを保存しないことでオンデバイススペースを節約できます。

しかし、NBDは上記のユーザー空間ネットワーキングと同じ欠点があります。すべてのI/O操作は、最低でもIPCラウンドトリップを伴い、バッファコピーとコンテキストスイッチが含まれます。ネットワーキングと同じパターンが見られます。非常に直接的でハードワイヤードで高速なオプションと、間接的な「ソフトウェア定義」だが残念ながら遅いオプションです。

Namespaceではパフォーマンスを非常に重視しているため、選択は明確です。ローカルディスクからイメージを提供します。レジストリ内のOCIイメージから、フリート内の各ノードのSSDにマテリアライズする必要があります。500ギガのイメージを数百、数千のノードに。そして、それを高速に行う必要があります。

当然ながら、各ノードが中央レジストリからナイーブにダウンロードするだけではうまくいきません。例の数字で言えば、保守的に見て数十分以内に500テラバイトのトラフィックが転送されることになります。レジストリ（およびネットワークファブリック）は毎秒テラビットをサービスする必要があります！

配布しているバイトはすべてのノードで同じなので、明白な解決策は、これらのブロブのピアツーピア配信を組織することです。各ブロックは、一部のノードによってレジストリから一度だけダウンロードされればよいのです。次に、近くにある別のノード（特定のメトリックによる）がブロックをピアから直接ダウンロードでき、コピーが2つになります。そして、さらに2つのノードがこれらのバイトをプルでき、それ以降も同様です。フリートは指数関数的にフラッディングされます。BitTorrentこの設計にはBitTorrentが大きな影響を与えたことは間違いありません。しかし、信頼できないピアの公開ネットワークで動作するBitTorrentとは異なり、効率と予測可能性を向上させるための異なるトレードオフを行うことができました。しかし、それは別の投稿のトピックです。

ストレージ

これでバイトはノードディスク上にあります。しかし、ビルドプロセスで行ったストレージの最適化を覚えていますか？ナイーブなアプローチでイメージをディスクに保存すると、無駄なバイトがたくさんあります。それらは穴であるか、他のイメージと共有できるものです。

おそらくご存知の方もいると思いますが、これらはまさに、現代のファイルシステム、すなわちAPFSで可能なストレージ最適化技術の種類です。ZFSLinuxユーザーはZFSでも同様の機能を見てきました。

これらのクールな機能を使用するのは非常に簡単です。書き込み用に新しいファイルを開き、オフセット100Gにシークしてブロックを書き込みます。これで、大きな穴のあるファイルが作成されます。書き込んだブロックのみがディスクに割り当てられ、残りは100GBの仮想的なゼロです。ファイルを読み取る際に、穴に気づくことはありません。OSは実際のゼロを返します。

ブロックの共有も同様に透過的です。cp -cモードまたはclonefileシステムコールを使用するだけです。新しいファイルは同じディスクブロックを共有し、実質的にスペースを取りません。

クローンされたファイルへの書き込みも透過的です。ブロックのいずれかを上書きしようとすると、その特定のブロックがディスクに割り当てられ、共有部分は共有されたままになります。

次は何？

フリートの拡大ペースは加速しており、上記のすべての経験が再現可能なプロセスに変換されました。MacBookラックを本番稼働させるのにどれくらいの時間がかかるかを正確に把握しています。ラックの組み立てラインは調整されています。DCOps担当者は訓練されています。ディスクイメージは構築され、配布されています。必要に応じて、顧客が必要とする数のマシンをフリートに投入できます（もちろん、購入できる限り）。

それでも改善の余地はあります！1本のUSB-Cケーブルで電源、イーサネット、KVM接続を提供する「聖杯」のようなデバイスがあればどうでしょうか？それは可能であるはずですが、現在、私たちの要件を満たすオープン市場のハードウェアは存在しません。そのため、非常にカスタムなものを開発中です。

あるいは、またクレイジーなことをするかもしれません？データセンターにスマートフォンを展開したらどうなるでしょう？Xで今後の展開にご期待ください！