2026 Mac クラウド CI：コールドスタート vs ウォームノード、キュー退避・DerivedData アフィニティ・常駐ベースラインの実装指針
GitHub Actions の YAML は書けるのに「一回目が遅い、二回目は速い、三回目また遅い」という揺らぎに悩むのは、Xcode 以前にコールドキャッシュと DerivedData の奪い合いが原因であることが多いです。本稿は 2026 年に Mac クラウドを VPS のように SSH／launchd で扱うチーム向けに、四つの痛み、三形態の比較表、アフィニティとバックオフの具体値、財務にも説明できる三指標、五ステップ導入と FAQ をまとめます。エラスティックプールと常駐ベースラインのルーティング記事と併読すると二層設計が腑に落ちます。
目次
1. 痛み：分散、アフィニティ欠如、バックオフ欠如、観測の偏り
Mac クラウドを CI に載せるとき、多くのチームは Linux VPS と同じ発想で SSH・launchd・ディスク・出口を握ります。しかし Swift の大規模モジュールは NVMe の局所性に敏感で、全 runner が同一 DerivedData を共有していると、コールドスタート由来の揺らぎが「謎のコンパイラ劣化」に見えてしまいます。
- コールドスタート尾部：初回 checkout 後の依存解決、索引ウォームアップ、リンク段で P95 が伸びます。財務が総分数だけを見るとコード肥大と誤認しがちですが、実際はキャッシュミス率です。
- アフィニティ欠如によるドリフト：同一ブランチの連続ビルドが別物理ボリュームに落ちると増分利益が消えます。ツールチェーン更新のせいにしがちですが、パスドリフトが本体です。
- バックオフ欠如：Archive を複数同時に走らせ max parallel と指数バックオフが無いと、NVMe キュー深度が飽和しリンクタイムアウトに見える失敗が増えます。
- CPU 偏重ダッシュボード：macOS CI は IO とメタデータが主役です。空き容量やリンクヒストグラムを無視すると会議は永遠に「コアを足そう」で終わります。
2. 意思決定表：コールドプール、ウォームホスト、常駐ベースライン
本表は エラスティック＋ベースライン と補完し、Mac 内部のディレクトリ／並列を決めます。課金マトリクス も参照。
| 観点 | コールド優先（短時間バースト） | ウォーム（半常駐キャッシュ） | 常駐ベースライン（専用スロット） |
|---|---|---|---|
| 典型負荷 | lint、単体、軽い行列 | 中規模の増分 PR | Archive、公証、長時間 UI |
| 尾部感度 | 弾力と引き換えに分課金 | P95 を安定化、稀な移行は許容 | リンク分散を極小化 |
| ディスク戦略 | ジョブ別サブディレクトリ＋夜間 gc | sticky パスか短期ゴールデンスナップショット | ビルド／成果物の二分割 |
| キュー戦略 | 高並列＋厳格な再試行上限 | 中並列＋深さ閾値 | 低並列＋変更ウィンドウ |
3. DerivedData アフィニティとスタンピード対策
アフィニティは「永遠に同一マシン ID」ではなく「統計的に再利用できるモジュールキャッシュ」です。各並列スロットに DERIVED_DATA_PATH を分け、Archive と PR 増分を分離し、空き容量が約 15% を切る前に新規 Archive を止めるのが実務的な三本柱です。
export DERIVED_DATA_PATH=/Volumes/ci/d12/$JOB_SLOT/dd
export COCOAPODS_CACHE_PATH=/Volumes/ci/d12/$JOB_SLOT/cocoapods
xcodebuild -scheme App -destination 'platform=iOS Simulator,name=iPhone 16' build
リンク段の再試行は「無料のリカバリノブ」ではなく予算です。再試行は新規ジョブと同じ NVMe 帯域を奪うため、並列を下げずに間隔だけ広げるとオンデュティの痛みが増えます。PR 増分はキャッシュヒット時に短い間隔で数回まで許容し、Archive は 1〜2 回に指数バックオフを載せるのが現実的です。
4. 五ステップ導入
- ジョブ分類：コールド／ウォーム／常駐に分け、キュー・コンパイル・リンク・アップロード比率を測る。リンク比率が跳ねたら CPU 購入前に DerivedData 競合を疑う。
- パス契約：JOB_SLOT と self-hosted ラベルとディレクトリの対応表を公開し、実験ブランチの共有ルート直書きを禁止する。
- 並列ゲート：Archive 全体で max parallel 1〜2。PR 側は高めでもバックオフ曲線を添える。
- アラート配線：空き容量・キュー深さ・再試行分数を 可観測性記事 と同じダッシュに載せ、ユーザー可視フラッキーの前に検知する。
- 三回ビルド検証：同一コミットを三回、P95 と失敗クラスタを比較。分散が残るなら並列増より第二ベースラインを優先する。
5. 三つの引用指標
- キュー比率：端到端の約 15% を超えてコミット率と相関するならプール混在が主因のサイン。
- リンク P95 の差：三回の同一ビルドで約 25% 以上開くなら共有 DerivedData か空き容量を疑う。
- 再試行分数比：全体の約四分の一を再試行が食うならバックオフ欠如かゲート過大。スケールアウト前に並列を下げる。
6. エラスティック記事との関係
一段目の runner 振り分けに続く二段目として、Mac 内部のコールド／ウォーム／常駐パラメータを揃えると財務とプラットフォームが同じグラフを共有できます。
7. FAQ
1 台の Mac クラウドでウォームは再現できる？ ディレクトリスロットとキュー深さで論理ウォームは可能ですが移行窓は残ります。Archive は低並列専用キューを推奨します。
アフィニティとセキュリティは両立する？ 盲目 sticky よりマルチテナント分離を優先し、Unix ユーザーとマウントを分けて秘密とキャッシュを混ぜない。
すぐ分散リモートキャッシュが要る？ 多くの場合、NVMe 分割とジョブ単位パスを正す方が分散より先に分散を減らせます。
バックオフをプロダクトにどう説明？ 相関失敗への保険として、短い意図的遅延が NVMe キューを空け総壁時計を短縮する、と伝える。
8. まとめ
コールド自体は悪者ではなく、無制限な同居が問題です。ウォームと常駐は尾部をランダム過程からチューニング可能なパラメータへ変えます。キューとディスク曲線を直視できれば、Mac クラウドはもう一台の謎の遅い共有 Mac ではなくプログラマブルな計算資源です。
ホストプールはレイアウト自由度が低く、小ディスク単体コールドは Archive と PR が衝突します。重いリンクを低並列ベースラインへ逃がすなら、VPSMAC の Apple Silicon Mac クラウドで Linux VPS 流の SSH／launchd を継ぐのが現実的です。