Thunderbolt 5 クラスター実測：複数台 Mac mini のネットワーク化でどれだけ速くなる？

1 台で足りるのに、なぜ複数台を並列するのか

Mac mini M4（10 コア、16 GB ユニファイドメモリ）で中規模 SwiftUI プロジェクトをフル Archive すると、おおよそ 4 分前後—— 個人開発者や「1 日数回 push」程度の小チームには十分なことが多いです。本当に「足りない」と感じるのは、次の 3 パターンです。

第一に複数 scheme / 複数 App マトリクス：同一 monorepo でメイン App、Watch、Widget、Debug/Release バリアントを同時に回す必要があり、 1 台では直列待ちになり、実時間が target 数に比例して伸びます。 第二に共有コンパイルキャッシュ：1 台の DerivedData や SPM キャッシュを他の Runner に配りたいが、 公網 1 Gbps 専用回線だと数 GB の同期だけで 1 分級かかる。 第三に分散推論やレンダリングのシャーディング：複数台が中間成果物を頻繁にやり取りし、 イーサネットの遅延と帯域が CPU より先に上限になる。

本記事は「クラウド Mac を借りるべきか」（料金・注文ページの話）ではなく、一点に絞ります： 同一ノード上の Mac mini を Thunderbolt 5 で並列接続したとき、機間のデータ経路はどこまで速くなり、並列ビルドの実時間に何を意味するか。

Thunderbolt 5 並列が実際につなぐもの

よくある誤解を先に解きます：TB5 並列は3 台の CPU を 1 台の「スーパー Mac」に融合するものではありません。 透明な分散コンパイラが自動起動するわけでもありません。提供されるのは同一ノード内マシン間の高速物理相互接続—— 公称 80 Gbps で、各ホストの 1 Gbps 専用公網口を大きく上回ります。

ZovCloud では並列は同一データセンターノード内のインスタンスに限られます。 シンガポールと東京のマシンを TB5 でつなぐことはできません。 開通後、データセンター側で Thunderbolt ケーブルとブリッジ設定が行われ、macOS に Thunderbolt Bridge / 高速ブリッジインターフェースが現れ、 その上で TCP、SMB/NFS マウント、オブジェクトキャッシュを構築します。

価値モデルは明快です： CPU は台ごとに独立スケジュールされ、機間データ搬送コストだけが大幅に下がる。 パイプラインが大容量成果物の相互同期をそもそも要さないなら、直列 1 台や「各自ビルドして公網に上げるだけ」で足り——並列オプションは不要です。

トポロジとレディネス：リンクが本当に立っているか確認

構成は「コントローラ + Worker 2 台」の三角：node-a がスケジュールと成果物集約、node-b / node-c が並列ビルド。 TB5 オプション支払い後（稼働中インスタンスのコンソールから追加も可）、数分以内に 3 台すべてで Thunderbolt ブリッジが表示されました。 スループット計測の前に次の 3 ステップを固定で実施し、普通のイーサネットだけ計っている事故を防ぎます。

1. 01
   ブリッジインターフェースの存在確認

   各ホストで ifconfig または「システム設定 → ネットワーク」。Thunderbolt Bridge（または DC 側の高速ブリッジ名）と同一サブネットのプライベート IP があること。

2. 02
   双方向 ping と MTU 確認

   3 台相互に ping -c 20。RTT はサブミリ秒〜約 1 ms が目安。数 ms でジッタが大きい場合は公網経由の可能性——ルーティング表を確認。

3. 03
   同期先 IP を TB セグメントに固定

   ビルドスクリプトの同期先を公網 IPv4 ではなく TB 網の IP に。rsync / SMB が 1 Gbps 出口に戻らないようにする。

スループット実測：TB5 と 1 Gbps 公網の比較

第 1 弾は iperf3 による TCP 一方向スループット。ベースラインは各マシンの公網 IPv4 相互（ラック内スイッチ経由だが 1 Gbps 専用口で頭打ち）。 テスト経路は Thunderbolt Bridge のプライベートセグメント。各 60 秒 × 3 回の中央値を採用。

ユーザ空間 TCP で理論 80 Gbps を満たすのは難しく、プロトコルオーバーヘッドと単一ストリームのスケジューリングが要因——今回はメモリ間でディスク非依存。 実務では「1 Gbps より 1〜2 桁速い」だけで同期戦略を変えられます： 差分圧縮していた数 GB キャッシュも、そのまま丸ごと送れるようになり、スクリプトはむしろ単純に。

大容量ファイルと共有キャッシュ：実時間の差はどこか

スループットがきれいでも、パイプラインが必ず速くなるわけではありません——大きなブロブを本当に運んでいるかが鍵です。 8.4 GB の DerivedData スナップショット（Module Cache と中間生成物）を SMB で同期し、 2.1 GB の .xcarchive をコントローラへ戻しました。

結論は率直です：「機間で GB 級成果物を運ぶ」工程は、TB5 で同期時間がほぼ無視できるレベルまで短縮される。 各マシンが git clone、依存取得、オブジェクトストレージへのアップロードを独立に行い、相互アクセスがほぼないなら、 体感の高速化はゼロに近く、並列オプションは無駄になります。

並列 Archive：3 台で実時間はどこまで圧縮できるか

第 2 弾は CI に近い構成：同一 commit で 3 scheme（メイン App Release、Widget Release、Watch Release）を 3 Worker で並列 xcodebuild archive；対照は 1 台で 3 Archive を直列実行。 コントローラはソーススナップショット配布（TB5 経由）、成果物回収、簡易検証。各 3 回の中央値。

並列の実時間 4 分 18 秒は、最も遅い scheme の単機時間（メイン App Archive 約 4 分 05 秒）に近く、 ソース/キャッシュ配布と成果物戻しで約 9 秒追加——1 Gbps だと同期だけで 1 分以上増え、 3 台並列の恩恵の大半がネットワークに食われます。

強調しておきます：短縮比は線形の「3 台で 3 倍」ではありません。 scheme ごとの時間差、証明書アンロック、SPM 解決の競合で、実時間は最遅の脚で止まります。 TB5 の役割は「配布と集約」を分単位から秒単位に圧縮し、並列スケジュール自体を意味あるものにすること； CPU 側の加速は複数ベアメタルが同時に計算することによるもので、ケーブルが単一コア Swift コンパイルを魔法のように速くするわけではありません。

ハマりどころ：実際に止まった 4 つ

1. 同期スクリプトの NIC 指定ミス。 初回 iperf が「900 Mbps しか出ない」——調査すると公網 IP を使用。ブリッジセグメントに切り替えた瞬間 50 Gbps 超え。 CI 環境変数で CLUSTER_IFACE と PEER_TB_IP を明示推奨。

2. SMB デフォルト署名がスループットを抑える。 macOS 標準 SMB は高速リンクで CPU が先に飽和。短時間ベンチなら署名ポリシー調整；本番はセキュリティと速度のトレードオフ、 または TB IP にバインドした rsync over SSH でキャッシュディレクトリ同期。

3. キーチェーンと署名は台ごとに準備。 並列は証明書問題を解決しません。3 Worker すべてに Distribution 証明書と unlock が必要。 自動化スクリプトは共通化しつつ、鍵はマシンごとに分離——共有キーチェインディレクトリの同時書き込み破損を避ける。

4. ディスクがネットより先にボトルネック。 256 GB システムディスクで 3 台同時 DerivedData 書き込み時、I/O wait が時々上昇。 巨大 monorepo と夜間バッチが多いなら、まず SSD +1TB / +2TB 拡張を検討してから並列ノード追加—— TB5 が速くてもローカルディスクが追いつかなければ意味がありません。

TB5 を付けるべきとき、付けなくていいとき

実測を意思決定表にまとめ、「80 Gbps を見たから開通」事故を防ぎます：

料金：ZovCloud 基本ノードは日額 $19.8、週 $53.5、月 $99.1、四半期 $269.6； Thunderbolt 5 並列オプションは日額 $1.8、週 $4.9、月 $9.1、四半期 $24.8。 3 台月額常駐 + 並列は、同期と直列待ちが明確にキューを塞いでいるチーム向き； リリース週だけ日額で並列を有効化し、検証後オフ——データセンターの銅線やスイッチを自前調達する必要はありません。

「速く測れた」から「日常運用へ」：クラウド専用クラスターの立ち上げ

オフィスで Mac mini 3 台を自前並列すれば似たスループットは出せますが、ラック、ケーブル、停電、 固定公網 IP、証明書ローテーション、夜間無人運用を自分で抱えます。多くのモバイルチームにとって、その運用コストが本当の壁—— 「iperf3 が叩けるか」ではありません。

Linux VM のメッシュがどれだけ速くても Apple ツールチェーンの関門は越えられません：完全な macOS がなければ正当な xcodebuild / codesign / TestFlight 経路はありません。 共有 macOS クラウドでオーバーセルがあれば、並列ビルド時のメモリ・ディスクジッターが「理論上の並列」を台無しにします。

ZovCloud の方針は、各ホストを専用物理 Mac mini M4（10 コア、16 GB、1 Gbps 専用帯域、フル管理者権限）のまま維持し、 機間高速経路が必要なとき同一ノードで Thunderbolt 5 並列を有効化、80 Gbps 物理チャネルを利用。 支払い後 1–5 分で開通、リージョンはシンガポール、日本（東京）、韓国（ソウル）、中国香港、米国東部。 ブラウザ VNC、SSH、サードパーティ VNC クライアントすべて利用可；Runner の載せ方は単機と同じで、同期用 Bridge IP が増えるだけです。

1. 01
   並列分割戦略を先に決める

   App / scheme / プラットフォームでタスクを切り、各マシンに独立した Archive ターゲットがあることを確認してから台数を決める。

2. 02
   同一ノードで複数台注文し TB5 を選択

   注文ページで同一リージョンの複数インスタンスを選び、オプションで Thunderbolt 5 並列にチェック。明細は料金ページ参照。

3. 03
   Bridge IP をバインドしてから Runner をマウント

   レディネス確認後、キャッシュ同期と成果物戻しを TB セグメントへ。公網口は git、オブジェクトストレージ、リリース用に残す。

Thunderbolt 5 並列が解くのは「複数の実 Mac 間で、データをどう十分速く運ぶか」であり、 「1 台を 3 台に見せかける」話ではありません。マトリクスビルドとキャッシュ同期がすでに実時間を支配しているなら、 同一ノード専用クラスター + 80 Gbps 相互接続は、単機キューを延ばすより合理的なことが多い； 単一 App で低頻度リリースの段階なら、安定した M4 専用ノード 1 台に予算を置く方が冷静な選択です。