2026 Pools de build Mac distants multi-région et Thunderbolt 5 : quand ajouter une 2e machine, topologie, FinOps

Pourquoi ajouter de la RAM ou du disque ne règle pas toujours la file

Sur Apple Silicon distant, les clusters de build heurtent encore trois « faux local » :

1. La parallélisation structurelle bute sur la bande passante mémoire unifiée : cibles parallèles, simulateurs, piles média lourdes se disputent la ressource. Un disque plus gros n’en fait pas une file ordonnée.
2. Les gros chemins réseau vers Git et les registries dominent le mur d’horloge quand le builder est séparé du registry par un océan. Plus de CPU sur la mauvaise topologie, c’est seulement un idle plus rapide.
3. Les interférences entre jobs sur un hôte partagé viennent souvent de caches partagés, pas des VM voisines. L’isolation et la file d’attente peuvent battre un achat de puce supplémentaire.

Table de décision : quatre coups avant d’acheter deux boîtiers

Indicateurs à tracer séparément : CPU, GPU/média, disque, réseau

Planifiez au moins une fenêtre de deux semaines alignée sur le release. Sur une même ligne de temps, tracez CPU, pression mémoire, débit d’écriture et trafic vers les gros points de terminaison. Des pointes courtes vers le linker ou l’indexeur ne valent pas « des cœurs chauds ensemble longtemps » : c’est le second schéma qui justifie un palier supérieur ou un second nœud.

Quand le Thunderbolt 5 (ou un lien de proximité) compte vraiment

Les chiffres marketing en Gbit/s ne servent à rien si le cas d’usage ne colle pas. Si les deux machines sont alimentées par l’object storage et ne partagent pas d’état local mutable, un second hôte et un bon cache suffisent souvent. Si l’équipe passe des heures en rsync de dizaines de Go de cache parce que la politique de stockage n’est pas colocalisée, un chemin physique haut débit peut enfin dépasser la bande passante VPN. Considérez le TB comme le remède d’une topologie d’artefacts brisée, pas comme un substitut à un registry au bon endroit.

Colocaliser d’abord le chemin le plus lourd : six régions et FinOps

Cartographiez personnes, dépôts, registries et consommateurs de tests. Le lien vers notre matrice de sélection assistée par IA aide à pondérer ; le guide de coûts par région aligne le vocabulaire avant d’ajouter du matériel.

Baselines et pics de location : un grand livre honnête

Réservez des sièges de base en mensuel ou trimestriel pour la file qui ne doit jamais mourir de faim, et des compléments journaliers ou hebdomadaires pour les pointes de release. Attachez l’approbation de pic à un déclencheur chiffré (par ex. P95 d’attente), pas à l’intuition. Comparez les tarifs publics sur une seule feuille : même RAM, même stockage, bare metal dédié vs partagé, hypothèses d’egress.

Six étapes vers un déploiement de pool réversible

1. Geler le dossier de preuves avec des percentiles et le récit « pourquoi ce n’est pas seulement le disque ».
2. Ramener registries et caches dans la région du builder si la finance l’autorise.
3. Fragmenter les files (interactif, CI, release) par labels de runner pour qu’un gros job ne bloque pas les petites PR.
4. Définir le cold start du nœud 2 : source des images, durée du premier build, retour arrière sur un nœud.
5. Noter l’option de lien avec de vrais octets hebdo entre hôtes contre heures d’ingénierie perdues en sync.
6. Revoir en semaine 1, 2 et 4 l’inactivité et retourner les machines de pic quand les signaux repassent au vert.

# pool-baseline: mois/trimestre ; pool-peak: jour/semaine + id de ticket
# label = region + role + xcode_major
# coloc du chemin lourd avant 2e nic / budget câble
# rollback: vider pool-b, desactiver en 15m, retour un noeud

Trois faits citables (avec contexte)

• Le RTT intercontinental entre de nombreux points APAC et la côte ouest US se situe souvent autour de 150–220 ms : pour les contrats, c’est votre trace, pas ce paragraphe, mais c’est l’ordre de grandeur pour lequel un registry dans le même métro compte encore en 2026.
• Le seuil d’indifférence entre courtes et longues locations sur les grilles publiques se situe souvent près de quelques jours d’utilisation continue élevée par mois : recalculez avec votre tarif journalier et mensuel réellement payé.
• Le débit d’écriture disque sur des paires Xcode + simulateur chargés peut atteindre des centaines de Go par jour sans politique de nettoyage : la planification de capacité doit nommer un responsable, pas seulement une ligne de budget.

M4 vs M4 Pro quand on fragmente les files plutôt que les machines

Avant d’acheter un second hôte, vérifiez qu’un M4 Pro avec plus de mémoire unifiée ne règle pas votre pire tranche parallèle. Pro ne signifie pas « un peu plus de MHz » : c’est souvent le bon pari quand le même hôte doit faire tourner plusieurs simulateurs, de l’encodage media lourd et de gros graphes Swift sans swap. Si les traces montrent que vous avez déjà isolé CI et travail interactif (comptes distincts) et que collision disque / cache continue, deux machines plus petites peuvent battre un seul gros cœur — à condition que l’histoire des artefacts et du registry tienne. La mauvaise séquence : acheter deux M4, puis constater des heures de pull des mêmes couches de conteneur de 5 Go parce que le registry est resté outre-mer.

Pourquoi le bricolage matériel et les tunnels informels échouent ici

Partage 4G, box résidentielle et CGNAT sont des sols instables pour un train de release multi-file. Des « petites VM pas chères » sur des hôtes bruyants exportent la variance en heures d’ingénieurs. Un pool géré avec six emplacements régionaux explicites et un modèle locatif présentable en finance se tient en général mieux qu’une étagère de Mac isolés. Pour les équipes qui traitent les pools de build comme des services de production, les Mac cloud MACCOME s’alignent typiquement sur ce modèle d’exploitation : régions claires, Apple Silicon dédié, conditions auditable. Ainsi, Thunderbolt contre Ethernet se décide sur la donnée, pas sur l’espoir.

Règles d’exploitation : première semaine avec deux builders dédiés

Ne doublez pas la capacité sans avoir d’abord fragmenté les files, sinon vous dupliquez les mêmes chemins de cache en concurrence. N’ajoutez pas d’interconnexion tant que des octets par jour ne prouvent pas l’Ethernet + stockage objet comme goulot. Enfin, nommez une astreinte et un retour arrière : couper le second groupe de runners doit ramener un état stable à un nœud en moins d’une heure ouvrée. Ces garde-fous transforment le pool en service, pas en expérience de labo.