2026 Macクラウド iOS CIの可観測性：キュー深さ・失敗クラスタリング・ディスクWebhook閾値
Xcode 26パイプラインをSSH可能なMacクラウドへ載せたあとも、末尾ログだけでは「午後遅い」「再実行で緑」といった不信を消せません。本稿はキュー待ち・APFS空き容量・SwiftPM再試行を束ねる4信号、ログ/メトリクス/Webhookの判断表、7ステップの実装順、SLOレビュー用の閾値、そしてDerivedDataとキュー運用との役割分担FAQまでをまとめます。
目次
1. 末尾ログだけでは足りない理由
Linux Runner文化では最終200行で判断しがちですが、AppleシリコンMacクラウドでは統合メモリ・リンカ作業領域・肥大化DerivedDataが絡み、スタックトレースは署名やCDN問題に見せかけます。観測設計の前に、次の3つの失敗モードをRunbookに明文化してください。
- キュー深さが壁時計に埋もれる：GitLab RunnerやJenkinsがMacラベルで詰まると、
xcodebuild時間だけ見ると待ち行列を過小評価し、ビジネス側の「午後遅い」を説明できません。 - 失敗クラスタが無いと非ゼロ終了が均一に見える：コード署名、プロビジョニング、ディスク満杯、SwiftPM、ロック競合は似た終了コードになります。
failure_clusterとノードID、スキーム名を揃えないとインシデント橋が手作業になります。 - ディスクと並列の連動アラートが無いとWebhookが逆効果：DerivedData分離と12%未満fail-fastを済ませていないと、自動再試行や並列増幅がIO嵐を招き、分課金Runner予算を焼きます。
2026年の最低ラインは「待ち・実行・失敗署名・ディスク/並列スナップショット」の4分類です。次表でログのみで足りる規模と、Prometheus系＋Webhookが必要な規模を切り分けます。
2. ログ・メトリクス・Webhookの判断表
数値は出発点です。p95待ち時間、最速テストジョブの中央値、Xcodeマイナー更新後のディスク減衰を四半期で見直してください。
| 段階 | Mac台数 | ベースライン | Webhook用途 | 欠けると起きること |
|---|---|---|---|---|
| 小規模 | 1〜2 | 構造化ログ、ヘッダ3点、dfサンプル | 空き12%未満で新規archive停止 | ディスク事故をネットワーク誤認 |
| 成長期 | 3〜8 | キュー深さ・待ち・成功率をノード別 | 同一クラスタ3回/10分で再試行抑制 | アラート疲労と課金爆増 |
| プラットフォーム | 8+ | スケジューラから成果物倉庫までトレースID | Webhookは並列削減やメンテ窓のみ | 設定ドリフトを自動化が隠蔽 |
ラベル標準化はAPI接続ガイドと併せ、SKU・マウント点・プール名を各ビルドイベントへ載せます。
3. 7ステップ：ヘッダ3点セットからサイレンスまで
Jenkins共有ライブラリやGitLabテンプレに順に埋め込みます。失敗ごとに「どのマシンで」「どれだけ待ち」「ディスク何%」「どのクラスタか」を必ず返します。
sw_vers・xcodebuild -version・xcode-select -pを先頭固定：週次比較とXcodeドリフト検知に必須です。queue_wait_msを記録：シェル開始時刻とキュー投入時刻の差で近似します。failure_clusterを安定キーワードで生成：Code SignやNo space leftなど全文ハッシュは避けます。- ビルド前後で
df -g /とDerivedDataルートdu -sh：キュー長文の12%方針と連動します。 - Webhook JSON最小セット：
node_id、job_url、failure_cluster、disk_avail_pct、queue_depth、queue_wait_ms。 - サイレンスとバックオフ：同一クラスタは10分に1回まで「並列削減」、ディスク10%未満連続2回のみ自動停止。
- 自動操作の監査ログ：実行者・理由・ロールバックURLを残し、手動hotfixと競合させません。
DERIVED_DATA_PATHのジョブ分離が済むまで破壊的Webhookを有効化しないでください。並列archiveが参照中のディレクトリを掃除すると稀なロック障害が増えます。
4. レビューに貼れる閾値
財務・プロダクトとSLOを握るための箇条書きです。①並列スロットの4倍を30分超えて維持するキュー深さは容量事故とみなし、弾性Macクラウド拡張かマージ抑制を選びます。②空き約12%未満では新規archiveを止め軽量テストのみ許可し、APFS一桁台の長尾I/Oを避けます。③同一failure_clusterが1時間に5回以上なら直近3回分のヘッダ差分を添付しxcode-selectドリフトを疑います。④queue_wait_msのp95が最速テスト中央値の3倍を超えたらラベル枯渇やarchive独占を先に調べます。⑤Webhookの並列削減は1スロットずつ、20分のディスク回復曲線を見てから次判断です。加えてderived_data_gbのヒストグラムをジョブ種別で匿名化し、Webhookを冪等化するdedupキー（node_id＋分バケット）を文書化します。人手確認なしに全並列を戻すポリシーはプロビジョニング不具合を隠すので禁止リストに入れます。
5. FAQ
DerivedData自動クリーニングがあってもWebhookは必要？
必要です。クリーニングは空きを作り、Webhookは悪化中に新ジョブ投入を止めます。
クラスタは誤結合しうる？
はい。ヘッダ3点と併記し、人間のRCAは生ログへ戻します。
マルチXcode記事との違いは？
マルチXcodeはDEVELOPER_DIR選択。本稿はキューとディスク閾値。アップグレード時は両方を同時監視します。
6. 説明可能なMac CIへ
ノートPCや小さなMacに無理やりキューを載せると、観測フィールドが無いまま属人化し、ディスク・並列問題が「Appleのせい」に見え、分課金と無サイレンス再試行で予算を焼きます。高価なAPMだけでは「当時何GB空いていたか」に答えられません。ディスクとメモリが読みやすく、SSHとAPIで伸縮できるMacクラウドに観測を載せれば、Linuxビルドファームと同じ辞書でiOSを運べます。説明責任とWebhookによる一時停止を両立したいチームには、VPSMACの専用Macクラウドが現実的です。基線が明確なら「キュー停止」が開発者ノートPCではなく本番Runnerにだけ当たります。