2026 PR パイプラインで iOS Simulator を Mac クラウド上で並列実行：同時数、destination 行列、ディスクとキュー
静的解析を Linux に寄せた後も、マージ頻度を止めるのは macOS 上の Simulator テストであることが多い。オフィスの Mac mini 群では Simulator 競合・DerivedData の肥大・キュー可視性の欠如が最初に限界になる。本稿は PR テストをインフラとして扱うチーム向けに、(1) 三つの誤解、(2) オンプレプールと Mac クラウド Runner の比較表、(3) 七ステップ、(4) レビュー用の数値目安、(5) FAQ、(6) まとめ、を順に示す。90 秒 API と CI 接続および ビルドキューと DerivedDataの長編と役割分担する。
目次
1. 誤解三つ：Simulator を軽いコンテナだと思う
多くのチームはすでに Lint と軽量ユニットを Linux に移した。残る壁は Simulator を伴うゲートである。SSH でサーバ管理に慣れたエンジニアほど、PR シナリオで次の三つを過小評価しがちだ。
- ワーカーを線形増やせる誤解：同一ホストで並列を乱立させると CPU と I/O が重なり尾が伸びる。コアあたり Simulator 上限のベースラインが無い限り SLA はスローガン。
- リリース用の全 destination を毎 PR にコピーすること：全行列は提出直前には意味があるが、各コミットではコストが高すぎる。「ブロックする目的地」と「情報取得用」を分けないと、ピーク時にキュー深度が直線的に膨らむ。
- DerivedData と添付をソフト予算にすること：録画・失敗スクリーンショット・トレースを既定 ON にすると、単一 PR が数時間で数十 GB を消費する。週末だけ掃除では水曜の午後にディスクが先に落ちる。ビルド側の水位は別記事で扱うが、本稿は高頻度の短い PR Job に焦点を絞る。
先に同時上限・destination 階層・ゴミ回収をパラメータ化し、その後で Xcode マイナー議論へ。
2. 比較表：Mac mini プールと Mac クラウド
レビュー初版に貼れる比較表。要求・オフィスプール・形状固定の Mac クラウド・注意点の四列。
| 要求 | オフィス Mac mini | Mac クラウド PR Runner | 備考 |
|---|---|---|---|
| ピーク同時性の予測 | デスクトップ利用や OS アップデートで乱れる | インスタンス種別を固定しコード化できる | ホスト型と自前 Runnerの比較も参照 |
| ディスク水位 | 共有ボリュームで「誰も消していない」が起きやすい | ジョブ単位のボリュームか強制 prune | ジョブ末尾で DerivedData サブツリーを必ず削除 |
| キュー可視性 | 口頭調整になりがち | CI ラベルと API スケールと整合 | 可観測性チェックリストを併読 |
| ネットワーク RTT | LAN は低遅延だが経路が複雑 | Git や成果物倉庫に近いリージョンを選べる | Linux 前処理とのハイブリッドとも相性が良い |
3. 七ステップ：同時数・destination・掃除
- ベースライン表を作る：代表プロファイルで PR 相当のジョブを二十回走らせ、P95 時間と RSS ピークから「物理コアあたりの Simulator 上限」の初期値を得る。
- destination をブロッキング集合と拡張集合に分ける：ブロッキングは直近二世代の iOS と主要画面サイズに限定。拡張はナイトリーかリリースブランチのみ。
- ハードタイムアウトと段階的リトライ：インフラ起因とアサーション失敗を分離。フレーク UI は同一コミット一回まで再実行し、ラベルで可視化する。
- クリーンフックを必ず付ける：成否に関わらず
xcrun simctl shutdown allと DerivedData サブツリー削除。巨大添付はアップロード前に切り詰める。 - キュー深度をメトリクス化：macOS Executor 待ち時間の分布を計測し、閾値超えで自動スケールか destination 降格を行う。
- Linux 前処理との成果物境界：コンパイル成果と索引だけを渡し、倉庫全体のキャッシュは署名付きヒットがある場合のみ。
- ワンページ Runbook：「空き容量 12% 未満なら拡張集合を止める」など、当番が暗記不要な文面にする。
4. 数値目安：CPU・ディスク・キュー深度
以下はレビュー合意用の出発点であり、必ず自社トレースで校正すること。第一に、M4 級で性能コア約十～十二本・メモリ三十二 GB のプロファイルでは、ブロッキング集合を「並列ワーカー三到四・同時 Simulator 四台以下」から評価し、UI が CPU 律速の間だけ段階的に上げる。第二に、単一 PR は直近成功の DerivedData の約一点八～二点四倍をディスクピークに確保し、空き十二パーセント未満でブロッキングのみへ降格。第三に、Executor 数の四倍を三十分超えるキューは、増設より拡張集合停止を先に。第四に、録画・トレースは PR 既定 OFF で添付を数百 MB 帯へ。第五に、マージごとにフル行列 JSON を二十四～七十二時間残し狭広差分の退行を説明可能にする。
5. FAQ
毎 PR で iPad とマイナ OS の全組合せが必要か
不要。高トラフィック端末をブロッキングに残し、組合せ爆発はナイトリーかリリース列へ回す。
並列がランダムに固まる
ワーカーを半分にし録画を止める。複数ジョブが同一対話ユーザを共有して Simulator ロックを奪い合っていないか確認する。
九十秒記事との違いは
あちらは Runner を立ち上げる話。こちらは SSH が通ったあと Simulator とディスクを運用品質にする話である。
6. まとめ：安定した Mac 実行面へ
少数の Mac mini は初期には足りるが、PR が増えると手動掃除と口頭調整が単一障害点になる。尾遅延は説明不能、キューは見えず、深夜マージは空き容量頼みになる。ノート環境は電源と帯域と隔離で CI に不向きだ。測定・降格・弾力を揃えるなら、VPSMAC の M4 Mac クラウドを PR 専用プールにする方が静かだ。SSH はそのまま、種別固定で掃除と同時上限を同一 Runbook に載せられる。九十秒 API・DerivedData キュー・Runner 比較の各記事と一直線だ。