2026 Mac クラウドの「Spot 的」低価格算力は常駐ノードに代わるか：iOS 署名・公証・長寿命セッションの意思決定表（FAQ）
Linux で Spot やプリエンプト可能インスタンスに慣れたチームほど、「Mac クラウドでも同じ発想で安く回せるのでは」と問いが出ます。本稿は iOS パイプラインを macOS クラウドへ載せ替えるプラットフォーム／リリース担当向けに、Linux Spot 前提と Apple 署名チェーン・キーチェーンセッション・notarytool の長時間ポーリング・App Store Connect のレート窓との構造的差分を整理し、タスク分類表と五段階の分割手順、三つの測定可能シグナルと FAQ を提示します。公証実装記事およびエラスティックプールと専用 Mac ベースラインへリンクし、「安さ」と「リリース安定性」を同じ設計書に書ける状態を目指します。
目次
1. 痛み：Linux Spot 習慣が macOS で外れる三パターン
iOS 出荷チェーンはキーチェーンと長寿命セッションに強く結びつきます。プリエンプトで Mac ノードが途中消失したコストは、単なる xcodebuild 再実行ではなく、人手トリアージとリリースウィンドウリスクとして現れます。
- セッションとキーチェーン結合：アーカイブと codesign は同一 SSH セッション内で同一キーチェーン項目へ繰り返しアクセスできる前提があります。notarytool ポーリング中にノードが回収されると、承認プロンプトの残留や中途半端なキーチェーン状態が発生し、平均復旧時間が跳ね上がります。
- 公証と staple の長尾：サーバ側キューとネットワークジッターで数十分以上伸びるのが常態です。「プリエンプト可能ライフサイクル」に縛るとチケットとローカル staple 状態がズレやすく、詳細は公証記事を参照。
- キュー経済の読み違い：分課金だけを最適化対象にすると、PR が署名チェーンで詰まる機会損失を見落とします。コールド／ウォームノードの議論と同様、高いのは予測不能な尾遅延です。
2. 比較表：中断可能計算と署名チェーンの硬い制約
左列は Linux Spot で検証済みの前提、右列は macOS クラウド構築へ載せる際に追加で課される制約です。
| 観点 | Linux Spot の典型前提 | Mac クラウド iOS 出荷の現実 |
|---|---|---|
| 状態面 | キャッシュは捨てて再構築でよい | キーチェーン項目、ASC Cookie、ローカル公証チケットがマシン文脈と相関し、単純再実行では戻せない |
| ジョブ時間 | 数分単位でリトライ完結しがち | 公証とアップロードは長時間窓とバンドル単位レートが共存 |
| 失敗形状 | 非ゼロ終了コードなら再スケジュール | 部分成功があり、サーバ受理とローカル未 staple が併存し冪等設計が要る |
| 並列性 | ワーカー水平展開 | 同一証明書並列には上限が要り、キーチェーン競合とプロファイル競走を避ける |
3. タスク分類：プリエンプト可否と推奨ノード種別
パイプラインを「捨ててよいコンパイル」と「捨てられない署名」に分けます。エラスティック＋専用ベースラインと整合し、プリエンプト可否を明示します。
| タスク | プリエンプト向き | 推奨ノード | メモ |
|---|---|---|---|
| Swift ユニットテスト／静的解析 | 多くの場合可 | 中断可能プールまたは低優先キュー | 署名鍵を同じマウント空間に置かない |
| 増分コンパイル成果物 | キャッシュ方針次第 | ウォーム優先 | DerivedData アフィニティはコールド／ウォーム記事参照 |
| Archive＋codesign | 非推奨 | 常駐 Mac ベースライン | キーチェーンとプロファイル版に強結合 |
| notarytool＋staple | 非推奨 | 常駐＋安定 egress | 長時間ポーリングは観測指標が必要 |
| ASC メタデータとアップロード | 非推奨 | 常駐 | レート制限と人的承認ゲートが共存 |
MAC_CI_TIER=interruptible # 署名鍵なしテストのみ
MAC_CI_TIER=durable-signing # 署名＋公証＋アップロード
# durable ジョブを interruptible プールへ流さないガードをオーケストレータに実装
4. 五段階ロールアウト：キュー・成果物・プローブ
- 信頼境界の凍結：キーチェーン・API キー・プロビジョニングプロファイルに触れるステップを非プリエンプト白名簿化し、GitHub Actions や Jenkins でラベル強制する。
- 成果物の外部化と検証：中断可能層は SHA256 マニフェスト付き tarball のみを出し、署名層は検証済みバンドルのみ取得する。
- 同時実行とディスク閾値：常駐プールで xcodebuild アーカイブ同時数と空き容量アラートを設定し、構築プール記事の三指標パターンを流用する。
- 公証プローブ：同一 nightly で staple 成功を三連続取得し p95 を記録する。プリエンプト以前に尾が伸びるならネットワークや Apple 側を疑う。
- ロールバックスイッチ：リリース週は全ジョブを常駐へ戻す feature flag を用意する。
5. 三つのシグナル
- 公証チェーン p95：三連続 nightly がリリース余裕を超えるなら単価削減より常駐キャパシティ増を優先する。
- 署名失敗リトライ率：キーチェーンやプロファイル起因が全失敗のおよそ一割五分を超えるなら、誤って中断可能プールへ流れていないか先に確認する。
- ディスク水位と並列：システムボリューム空きがおよそ一八パーセント未満でアーカイブ並列が二以上なら IO 尾が肥大化し、プリエンプト議論の前に並列とキャッシュ整理を下げる。
6. FAQ
Q：同一 Mac で中断可能コンパイルと署名を共存させられるか A：ボリューム分離は可能だがラベル誤設定が多い。プール分離か少なくともプロセス分離と分割キュー深さメトリクスを推奨する。
Q：ホスト macOS Runner は Spot か A：共有プール上の分課金に近く、リスクはランダム回収よりキュー深さ。専用 Mac クラウドとの比較はエラスティック記事を参照。
Q：公証失敗の再試行は A：リモートチケット状態を確認してから再 submit と staple のどちらかを選ぶ。盲再試行はレート制限に当たりやすい。
7. まとめ
中断可能 Mac 容量を採用する前に、署名を白名簿化し、チェックサム付き成果物でコンパイルと出荷を切り離し、三シグナルで尾遅延をゲートする。キューラベルと失敗理由コードを変更テンプレへ埋め込み、リリース週に全常駐ロールバックを演習する。
キュー分割なしに Spot 的安さだけを追うと、Linux での「失ったら安く再実行」という習慣が macOS のキーチェーン・公証長尾・ASC セッションと衝突し、分散がリリース週の消防に変わりがちです。署名チェーンを専用 Apple Silicon Mac クラウドの常駐ベースラインに固定し、プリエンプトは鍵のないコンパイルに限定するのが安定側の工学回答です。VPS のように Mac 容量をコントロールしたいチームには、VPSMAC の Mac クラウドで常駐サイズとリージョンを証跡に揃える道が現実的です。