症状：Git LFSを含むiOS CIのチェックアウトが遅く、Macの増設を検討している。
最短解法：まずGit、LFSオブジェクト、ワークスペース、依存関係、Xcodeビルドを個別に計測し、コンパイル段階が飽和している場合だけMacを増設します。
この判断は、大型リポジトリを管理する開発生産性責任者、Macビルド基盤の拡張を決めるIT責任者、資格情報とキャッシュ分離を担うセキュリティ・プラットフォームチーム向けです。
最初に分けるべき処理時間
同じジョブ全体の時間が伸びても、Macのコンパイル性能が低下したとは限りません。ネットワーク待機が大半なら、CPUの高いMacへ替えても取得時間はほとんど変わらないためです。
Git LFS iOS CI 高速化では、次の2つの基線を同じコミット、同じRunner設定で記録します。初回の冷起動と、オブジェクトや依存関係が残った状態での反復実行です。
| 計測区間 | 記録する値 | 主な判断 |
|---|---|---|
| Gitデータ取得 | Gitオブジェクトの転送時間とバイト数 | ブランチ範囲や履歴深度を見直す |
| LFS取得 | LFSオブジェクトの転送時間とバイト数 | パスフィルター、経路、キャッシュを確認する |
| ワークスペース復元 | ポインターから実体を配置する時間 | fetch成功とファイル利用可能を区別する |
| 依存関係復元 | Swift Package Managerなどの待機時間 | 依存キャッシュの再利用を確認する |
| Xcode処理 | コンパイル、リンク、署名の時間 | MacのCPU、メモリ、ディスクI/Oを評価する |
Git LFSでは、ポインターが管理対象の実体を参照し、実体は別のLFSストレージに置かれます。fetchが成功しても、作業ツリーに必要なファイルが展開済みとは限りません。仕組みとコマンドの挙動は、Git LFS公式マニュアルとfetchの公式説明で確認できます。
取得範囲と転送量
全履歴、全ブランチ、全アセットを毎回取得する構成は、PR検証とリリースビルドを同じ負荷にします。まずジョブが実際に参照するディレクトリを洗い出し、画像、動画、テスト用アセットなどをタスク単位で分けます。
| 方式 | 適する状況 | 注意点 |
|---|---|---|
| 全量取得 | リリース工程で広い資産を確実に検証する | PRごとの転送量が増えやすい |
| パス単位の取得 | テスト対象が明確なPR検証 | 間接参照する資産の漏れを検証する |
| ジョブ別の資産分割 | 単体テスト、UIテスト、配布工程で必要資産が異なる | ジョブ間の成果物受け渡しを設計する |
| 浅いクローンとの併用 | 履歴を必要としない検証 | checkoutコンポーネントのLFS挙動を確認する |
git lfs fetch --includeや--excludeによる対象制御は、Git LFS fetchの引数説明に沿って隔離リポジトリで再現してください。CI製品のcheckout処理がLFSを自動取得するか、稀疎チェックアウトとどの順序で適用されるかは、利用中のバージョンのcheckoutドキュメントで確認する必要があります。
実務では、次のように診断用の最小コマンドだけを使います。
git lfs env
git lfs fetch --include="Assets/Required/**"
git lfs checkout
これだけで高速化が完了するわけではありません。ビルド前に対象ファイルがポインターではなく実体として存在するか、必要なアセットのハッシュやサイズが期待値と一致するかを検証してください。
キャッシュ再利用とワークスペース分離
一時的なMacでは毎回LFSオブジェクトを取り直すため、転送がボトルネックになりやすくなります。一方、長期稼働ノードはオブジェクトを再利用できますが、キャッシュがあることと、キャッシュが有効に使われることは別です。
記録すべき指標は、LFSダウンロード量、再利用されたオブジェクトの割合、キャッシュ後の取得時間、ディスク増加量です。企業の実測値やCIキャッシュの安全性に関する公式説明がない状態で、改善率を固定値として見積もってはいけません。
固定ノード
専用Macを同じ信頼境界のジョブに割り当てる方式です。
利点
- LFSオブジェクトを継続的に再利用しやすい
- Xcodeや依存関係の準備時間を管理しやすい
- ピーク時の待ち行列を継続的に観測できる
欠点
- 遊休時間にもMacの占用費用が発生する
- キャッシュと作業ツリーの肥大化を運用する必要がある
- プロジェクト間の汚染を防ぐ隔離設計が必要になる
弾性のあるリモートMac
ピーク時だけ追加のMacを使う方式です。冷起動時のLFS転送を抑えるには、ジョブ開始前の対象オブジェクトのプレウォーム、または取得範囲を限定したタスク分割が必要です。
固定ノード、弾性ノード、混合構成の判断は、開発者数ではなく、実際の到着率、平均ビルド時間、待ち行列、障害時の代替容量で行います。Mac購入を検討する場合も、Mac miniの調達条件を確認し、ハードウェア費用だけでなく保守、設置、交換、遊休時間を含めて比較してください。
資格情報と成果物の正しさ
Git LFS高速化では、キャッシュを共有しすぎる設計が性能より大きなリスクになります。読み取り用のリポジトリ資格情報と、コード署名や配布に使う資格情報は、同じノードや同じ環境変数に置かないでください。
非信頼ブランチが、本番リリース用Macに残った長期資格情報を継承する構成は避けます。自社管理Runnerでは、ジョブ実行後のワークスペース削除、ログへのトークン出力防止、プロジェクト単位のキャッシュ分離を受け入れ条件にします。自社管理Runnerのリスクは、公式のセキュリティガイドにも整理されています。
次の検証を、キャッシュヒット時と冷起動時の両方で実施します。
- LFSポインターが残っていないか確認する
- 必須アセットの存在とハッシュを検査する
- 署名処理に使う資格情報がログやキャッシュに残らないことを確認する
- ジョブ終了後に作業ツリーと一時資格情報を削除する
- 同じコミットから同じ成果物を再生成できるか比較する
容量判断とTCO
LFS取得を改善した後も待ち時間が長い場合、処理区間をもう一度見ます。コンパイル、リンク、署名でCPUやメモリが継続的に高止まりし、同時にキュー待ちが増えているなら、ネットワーク改善ではなくMac容量が制約です。
判断は次の式に分けると、購入とレンタルを同じ土俵で比較できます。
月間TCO =
ネットワーク転送費
+ ストレージ費
+ Mac占用時間
+ 運用工数
+ 障害による影響
ネットワーク待機が主因なら経路や取得範囲を改善します。LFSオブジェクトの再利用が有効なら、信頼境界を分けた固定ノードを検討します。コンパイルとキューが主因なら、固定Macの増設、弾性のあるリモートMac、または両者の混合を実際のiOSパイプラインで比較します。
受け入れマトリクス
| 判定項目 | 証拠として残すもの | 不合格時の処置 |
|---|---|---|
| 冷起動 | LFS転送量、取得時間、ビルド時間 | パス範囲とデータ経路を見直す |
| キャッシュ再利用 | 再利用オブジェクト、再実行時間 | キャッシュ構造と容量上限を見直す |
| 完全性 | アセット検査、成果物比較 | ジョブを停止し取得手順を修正する |
| 資格情報分離 | ログ、環境変数、削除記録 | 本番資格情報を別ノードへ隔離する |
| ディスク回収 | 使用量の推移、削除結果 | 保持期間と削除条件を設定する |
| 待ち行列 | 到着数、待機時間、同時実行数 | 固定または弾性ノードを追加する |
| 障害復旧 | ノード停止後の再実行記録 | 代替ノードと再取得手順を用意する |
最終結論は3種類です。転送とワークスペースだけが遅いなら、Git LFSの最適化だけで止めます。Xcode処理が継続的に飽和するなら、Mac容量を増やします。信頼性が必要なリリース工程を固定ノードに残し、PRやピーク時だけ弾性のあるリモートMacへ逃がす方法もあります。
リモートMacの利用方法を試す場合は、同じリポジトリ、同じLFS対象、同じXcodeジョブで比較してください。冷起動、キャッシュ再利用、実コンパイル時間、ピーク時の待ち行列を記録してから、固定容量か弾性容量かを決めるべきです。
現在のMac構成をそのまま増設すると、LFS転送の待機、キャッシュの重複、保守対象の増加、遊休時間という問題が残ります。逆に、取得範囲と資格情報を整理したうえでKVMNODEのリモートMacを短期検証に使えば、実際のパイプラインで容量を測り、購入前にピーク時の必要台数を確認できます。
まずは診断用ジョブで段階別の記録を取り、同一条件の試験環境で比較してください。長期的な高負荷処理や物理ポートが必須の業務には自社保有Macが適しますが、繁忙期のiOS CI、移行期間、容量検証には、KVMNODEのレンタルによる弾性運用が判断材料を増やします。