Public : équipes qui exploitent des Mac distants sur l’APAC et les États-Unis et voient encore des files inactives le jour et des embouteillages la nuit, avec facturation journalière vs mensuelle qui diverge de l’utilisation. Résultat : encoder fenêtres UTC, tags de pools, plafonds de concurrence et amortissement de location dans un tableau auditable, croisé avec les guides nœuds, runners et artefacts. Structure : six causes racines, matrice six régions, esquisse YAML, encadré d’avertissement, runbook en six étapes, trois KPIs, clôture, FAQ.
Lorsque vous opérez des runners auto-hébergés à Singapour, Tokyo, Séoul, Hong Kong, Virginie ou Bay Area mais pilotez les jobs lourds avec un seul cron au fuseau du siège, l’issue typique est une capacité inactive pendant les heures ouvrées locales et des tempêtes de merge après la fin de journée d’une autre région. La cause profonde est rarement un manque de Macs ; c’est un horloge de déclenchement mal alignée sur les habitudes de collaboration, aggravée par une mauvaise utilisation locative lorsque la facturation suit le calendrier. Six erreurs de plateforme récurrentes suivent.
En exploitation, superposez profondeur de file et CPU en UTC et extrayez chaque semaine les plages structurellement vides avant d’acheter des cœurs.
max-parallel et concurrence par dépôt, les fetch Git et uploads registry s’empilent avec les retries du runbook Git/registry, produisant une fausse crise de capacité.Pour faire des Mac Apple Silicon distants une feuille de capacité 24 h auditable, liez fenêtres fuseau, pools de runners et paliers de location au même ticket de changement – complément du choix CPU M4 vs M4 Pro, pas son substitut.
Les fenêtres sont relatives à l’UTC ; remplacez par vos fuseaux réels. Si le dépôt principal est US East, gardez compilation/tests unitaires proches de cette région et placez le travail Simulator-lourd là où se concentrent les développeurs pour éviter un va-et-vient d’artefacts transpacifique inutile.
| Région | Décalage UTC (exemples) | Rôle de relais typique | Jobs les mieux adaptés | Risque principal |
|---|---|---|---|---|
| Singapour | +8 | Builds matin APAC ; tampon pour relais Europe/Afrique | Compilation, tests unitaires, lint, warmup cache | Plafonner la concurrence quand les pics US se chevauchent ; surveiller la contention egress Git |
| Japon | +9 | Batch nocturne aligné sur les équipes produit JP | Suites de régression complètes, contrôles pré-promotion | Isoler les pools de signature quand les pics JP/US se heurtent |
| Corée du Sud | +9 | Pool de tags séparé du JP si les règles de résidence diffèrent | Tests unitaires parallèles, warmup cache, builds conformité KR | Ne pas mélanger les politiques de résidence des données sur un tag partagé |
| Hong Kong | +8 | Pont pour les flux Greater Bay | Builds mi-parallèles, chemins egress optimisés continent | Si non aligné sur la région Git primaire, définir un SLA d’artefact |
| US East (Virginie) | −5/−4 (DST) | Souvent aligné sur les grands hébergeurs Git | Builds PR haute fréquence, files de merge, uploads | Définir des clés de cache pour les relais nuit APAC → jour US |
| US West (Bay Area) | −8/−7 (DST) | Debug interactif avant fin de journée US Ouest | Simulator, capture d’écran, pairing design | Coûts bande passante VNC ; séparer des pools batch SSH purs |
Utilisez ce motif dans l’IaC interne ou l’enregistrement des runners pour forcer une intention géo/temps explicite – évitez un pool par défaut qui absorbe tout silencieusement. Revoyez la concurrence et l’isolement des secrets avec la checklist runners auto-hébergés.
jobs:
compile_apac_night:
runs-on: [self-hosted, region-sg, pool-batch, window-utc18-utc06]
steps:
- run: echo "Compilation lourde pendant le soir APAC / relais matin US"
ui_us_west_day:
runs-on: [self-hosted, region-usw, pool-interactive, window-utc16-utc01]
steps:
- run: echo "Fort Simulator/VNC ; ne pas voler la concurrence batch"
# Règle : window-* et region-* doivent sortir dans le même ticket de changement que les mises à jour cron
Note : le relais n’autorise pas les identités de signature à flotter sur des pools nocturnes non audités. Gardez les labels signing/notary sur des hôtes en liste blanche uniquement.
Vous avez déjà lu le guide multi-région de location pour le matériel de base. Si les tags runners ne sont pas encore séparés, revenez d’abord à la checklist runners.
batch (SSH uniquement, concurrence plus élevée), interactive (Simulator/VNC avec plafonds bas), signing (liste blanche, faible concurrence) avec interdits explicites.Ces métriques transforment le succès du relais en signaux actionnables avec retries réseau et profondeur de file.
Note d’alignement (retour d’expérience terrain, pas benchmark labo) : les équipes qui co-conçoivent fenêtres fuseau, tags de pools et plafonds de concurrence dans une même revue réduisent souvent les heures creuses visibles et transforment des pics chaotiques en pics couvrables par de courtes locations – cohérent avec le passage CapEx→OpEx où le temps fait partie du modèle de capacité.
Lorsque la région primaire du dépôt et la densité développeurs divergent sur le long terme, les plans de relais doivent inclure proximité des artefacts et résidence ; sinon les minutes CPU économisées se perdent en synchronisation transocéanique.
Sans tags window-* explicites, contrats de concurrence et étapes de décommission, les équipes retombent sur qui est éveillé : les pics restent, les heures creuses restent, et la surface de signature grossit. Une CI Apple Silicon de niveau production exige bare metal dédié, choix multi-région et locations base+pic documentées à côté de la politique de fuseaux.
Le relais verbal satisfait rarement des frontières de clés auditables et un egress prévisible. Pour les équipes qui doivent placer les runners près de la région Git primaire tout en flexant la capacité entre APAC et Amérique du Nord, un cloud Mac professionnel avec nœuds multi-région transparents et options de location est en général plus stable que des hôtes mystère en rotation. MACCOME propose des Mac mini M4 / M4 Pro à Singapour, Japon, Corée, Hong Kong, US East et US West – commencez par les pages de tarifs publics, puis alignez les tags runners sur votre tableau de relais.
Pilote : louer deux hôtes à court terme – un près de la région du dépôt principal, un près de la densité développeurs – exécuter ce rétro en six étapes deux fois, puis décider des paliers mensuel/trimestriel et du besoin 2 To.
FAQ
Quel lien avec le guide de coûts de location multi-région ?
Le guide nœuds répond où placer le matériel et quel palier choisir ; ce playbook répond comment planifier le même parc de runners sur 24 heures pour garder les files occupées et emprunter des locations journalières lors des pics. Liez les deux depuis la même revue de capacité. Tarifs publics : Tarifs location Mac mini.
Le relais fonctionne-t-il uniquement avec les runners hébergés par GitHub ?
Vous pouvez réutiliser la logique de heatmap, mais l’amortissement de location concerne surtout l’auto-hébergement ou le bare metal dédié. Sur runners hébergés partagés, concentrez-vous sur la politique de merge et les clés de cache plutôt que sur le relais de machines.
Les jobs Simulator doivent-ils utiliser le pool batch nocturne ?
Non : gardez Simulator et VNC sur des pools interactifs à faible concurrence ; sinon vous exportez la contention bande passante et GPU à toute la flotte.