クラウド Mac mini マルチノードビルド編成実践

リリース前夜、プロジェクト内のメインApp、今日ウィジェット、Apple Watch連携Appという3つのターゲットを一斉にフルビルドすると、1台のマシンでは38分かかっていた。チームには自前のCIクラスタを年中維持する予算はないが、リリース日にはその待ち時間は許容できない。そこで折衷案として、リリース当日だけ云端(クラウド)Mac mini を3台一時的にレンタルし、「一日限りのビルドファーム」を組んでSSHマトリクスでタスクを分配、ビルド完了後に署名とアーティファクトの集約を一括で行う運用に落ち着いた。全工程15分未満で、アップロード可能な3つのパッケージが手に入る。本稿ではこの編成の具体的な手順を記録する。

マルチノード化が必要になるタイミング

すべてのプロジェクトがこれほどの手間をかける必要はない。判断基準はシンプルだ——1回のフルビルドが20分を超える、あるいは1回のリリースで複数ターゲット・複数アーキテクチャのパッケージを同時に作る必要がある場合にのみ、一時的にノードを増設する価値がある。日常のコーディングや単体テストだけであれば、Mini Standard(24GBメモリ)1台で十分であり、常時3台稼働させるのはむしろ無駄なコストになる。

マルチノードファームの核心は「日単位で借り、必要なくなれば即解散する」という考え方だ。リリースウィンドウの前夜に注文し、リリース完了後は即座に解放する。コストが発生するのは、実際に並列演算力が必要となるその日だけである。

ファームのトポロジーとノードの役割分担

役割分担は各ノードのネットワーク経路とリソース条件に基づいて決めている。役割を割り振る前にコンソールで各ノードで現在選択できるプランを確認し、負荷の高いビルド役はネットワーク経路とリソースの両方が適したノードに割り当てる。

3台合計で$139.5/日。比較として、全台をMini Proに揃えると$177.9/日になる——ウィジェットとWatch Appのビルド負荷自体は大きくないため、Standardクラスで十分であり、その分の予算をメモリを多く消費するメインAppのビルドに回すべきだ。

教訓:当初、我々は3台すべてを東京に配置していた。メインビルドノードと署名ノードを1台に統合した結果、rsyncによる内部ネットワーク転送は速かったものの、その後のApp Store Connectへのアップロードを担うのはアメリカ西部のノードであり、実際にはアップロード出口に近いことのほうが重要だった——署名ノードのロケーションは、開発者に近い場所より、アップロード出口に近い地域を選ぶべきである。

分配スクリプトと実行

コーディネーター役は通常メインビルドノード自身が担う。シンプルなBashスクリプトで各ターゲットを従属ノードに分配し、バックグラウンドで並列実行させ、最後に一括で待機する:

#!/bin/bash
set -e

NODES=("node-a.internal" "node-b.internal")
TARGETS=("WidgetExtension" "WatchApp")

for i in "${!NODES[@]}"; do
  ssh "build@${NODES[$i]}" \
    "cd ~/repo && xcodebuild -scheme ${TARGETS[$i]} \
     -configuration Release -archivePath build/${TARGETS[$i]}.xcarchive \
     archive CODE_SIGNING_ALLOWED=NO" &
done

xcodebuild -scheme MainApp -configuration Release \
  -archivePath build/MainApp.xcarchive archive

wait
echo "all targets archived"

ポイントは、従属ノード側で CODE_SIGNING_ALLOWED=NO を付けて実行することだ。これにより未署名の .xcarchive のみが生成され、証明書をそれら2台のマシンに同期する必要が一切なくなる。メインビルドノード自身は証明書を保持し、MainAppの署名付きビルドを担当しながら、他ノードからのアーティファクトを待機する。

アーティファクトの集約と一括署名

従属ノードでのビルドが完了したら、rsyncで .xcarchive をメインノードに送り返す:

rsync -avz build@node-a.internal:~/repo/build/WidgetExtension.xcarchive ./build/
rsync -avz build@node-b.internal:~/repo/build/WatchApp.xcarchive ./build/

3つのアーカイブが揃ったら、メインノード上で同一のプロビジョニングプロファイルと証明書を使い xcodebuild -exportArchive を一括実行し、続いてfastlaneの pilot upload で3つのパッケージを一度にTestFlightへアップロードする。署名工程はすべて1台のマシン上でのみ発生し、秘密鍵は従属ノードには一切配置されない。この点はセキュリティ基準の確認時に繰り返しチェックされる項目だ。

注文前に一度チェックリストを確認しておくとよい:

• [ ] 3台のノードでmacOSとXcodeのバージョンが一致しているか(アーティファクトのアーキテクチャ差異を防ぐため)
• [ ] 従属ノードのSSH公開鍵が事前に authorized_keys に登録済みか
• [ ] 署名ノードはApp Store Connectのアップロード出口に近い地域を選んでいるか
• [ ] 各ノードの無料再インストール回数が十分残っているか(リリース直前に再インストールしないこと)

よくある落とし穴と限界

マルチノード編成が割に合わない場面もある。プロジェクトにターゲットが1つしかない場合や、フルビルド自体が10分以内で終わる場合は、複数ノードに分割するとSSHのスケジューリングやrsync転送のオーバーヘッドで待ち時間がむしろ増える。そうした場合は1台のノードで素直にビルドしたほうがよい。また、ソウルには現時点でPro/Maxクラスが存在しない点にも注意が必要だ。3つのターゲットのうち1つが特にメモリを多く消費する場合(たとえば機械学習モデルの推論を含むターゲットなど)は、事前に東京またはアメリカ西部のPro/Maxノードに割り当てるべきであり、無理にソウルのStandardノードに詰め込んではならない。

よくある質問