Google a franchi une étape majeure dans sa stratégie multi-architecture. Suite à l’annonce d’Axion, ses premiers processeurs ARM® conçus sur mesure, la société a expliqué comment elle a réussi à faire compiler et faire fonctionner des dizaines de milliers d’applications internes simultanément en x86 et en ARM au sein de ses clusters de production. Ce n’est pas une expérience : YouTube, Gmail ou BigQuery traitent déjà du trafic sur les deux ISA en parallèle, avec un hardware ARM saturé en utilisation et de plus en plus de serveurs déployés chaque mois.
Le raisonnement est clair. Selon les données de Google, les instances basées sur Axion offrent jusqu’à 65 % de meilleur rapport prix/performance et sont jusqu’à 60 % plus économes en énergie comparées à des instances équivalentes dans Google Cloud. À l’échelle d’un centre de données, cette amélioration multiplie l’impact : facture énergétique réduite et plus de capacité utilisable par watt pour les clients et services internes.
Migration vers la « multiarch » à l’échelle du data center : ce qui n’était pas le problème
Le récit technique démystifie certaines idées reçues. Avant de commencer, tant l’équipe multiarch que celle des applications pensaient que les principaux obstacles seraient liés aux différences d’architecture : dérives en faible précision flottante, concurrence, intrinsics vectoriels, opérateurs spécifiques, ou écarts de performance difficiles à combler. Ce n’a pas été le cas — ou, du moins, pas dans l’ampleur attendue.
Lors des premières migrations de services « phares » (comme F1, Spanner ou Bigtable), les ingénieurs ont rencontré des cas concrets liés à ces différences, mais en beaucoup moindre quantité que prévu. Les outils modernes —compilateurs et sanitizers— ont permis d’éclaircir une grande partie des inquiétudes au fil des années. La principale difficulté était ailleurs :
- Tests surajustés à x86 reposant sur des timings ou des détails de plateforme spécifiques.
- Systèmes de build et de déploiement très anciens ne prenant pas en compte les variantes ARM.
- Configurations de déploiement ne comprenant pas qu’un même service puisse fonctionner sur deux ISAs différentes.
- Risque opérationnel lié à la modification de systèmes critiques en production.
Un ingénieur résumait ainsi : « Tout le monde s’est concentré sur la toolchain totalement différente, en pensant que ‘tout allait casser’. La plupart des difficultés venaient en réalité des configurations et d’aspects ennuyeux ».
Le vrai défi : le long tail
Migration d’une dizaine de jobs critiques avec des équipes dédiées et des réunions hebdomadaires fonctionne, mais ne suffit pas pour une migration à grande échelle. Bien que près de 60 % du calcul actif se trouve dans les 50 plus grandes applications, dans un monorepo comportant plus de 100 000 applications, le reste constitue une longue traîne plate. Si l’objectif est que Borg (le orchestrateur interne) répartisse efficacement les tâches entre x86 et ARM, plus de jobs multiarch est synonyme de meilleure robotisation. La seule solution viable : automatiser.
Google aborde cela avec un ensemble d’outils — certains déjà en usage bien avant le projet — et un agent IA de nouvelle génération pour combler le gap.
Automatisation : commits massifs, validation et déploiements sans intervention humaine
- Rosie : produit des commit massifs et pastore dans le flux de revue, par exemple en activant le mode ARM dans le blueprint d’un job avec une simple ligne de configuration.
- Sanitizers et fuzzers : détectent des différences d’exécution entre x86 et ARM avant déploiement (ex. data races cachés par le modèle mémoire TSO de x86), évitant comportements non-déterministes à la recompilation.
- CHAMP (Continuous Health Monitoring Platform) : plateforme automatisée pour déployer et surveiller des jobs multiarch. Si un job plante en ARM ou baisse l’throughput, il est évacué automatiquement pour une optimisation hors ligne, sans mettre en danger la santé du cluster.
Avec ces outils, l’équipe a commencé à industrialiser la migration.
38 156 commits en trois phases : outils, code, configuration
Pour comprendre quels changements étaient nécessaires pour une migration à grande échelle, Google a analysé 38 156 commits dans son monorepo Google3 —totalisant environ 700 000 lignes modifiées. Avec Gemini Flash et une fenêtre de 1 million de tokens, les changements ont été classés en 16 catégories regroupées en quatre grands blocs, et leur évolution a été tracée :
- Outils et adaptation des tests : lors de la mise en place de la toolchain multiarch, la majorité des commits portaient sur l’ajustement des outils et des tests.
- Adaptation du code : lors de la migration des premières applications majeures, la part de modifications de code a augmenté (corrections dans dépendances partagées, ifdefs par plateforme, représenation des données, etc.).
- Configuration et processus : dans la dernière phase, presque tout concernait des fichiers de configuration et procédures support. Le nombre de commits a également fortement augmenté, indiquant la montée en charge vers le reste du dépôt.
Un point clé : la majorité des commits liés à la migration étaient de petite taille. Les plus volumineux étaient surtout des listes ou configurations importantes, et non des changements complexes dans un seul fichier.
L’IA en renfort : CogniPort, un agent pour “réparer” builds et tests
Pour traiter le reste —c’est-à-dire le long tail des applications encore incapable de compiler ou de passer ses tests en ARM— Google a développé CogniPort, un agent basé sur une IA générative visant à automatiser le reste de la migration.
Fonctionnement : CogniPort intervient lors de importantes erreurs de build ou de test. Si une bibliothèque, un binaire ou un test ne compile pas ou échoue, l’agent intervient pour corriger sans intervention humaine. Il implémente trois boucles» empilées :
- Un orchestrateur qui commande les deux autres agents.
- Build-fixer : compile une cible, modifie les fichiers jusqu’à réussite ou abandon.
- Test-fixer : exécute un test, modifie les fichiers jusqu’à ce qu’il passe et, si nécessaire, sollicite le build-fixer.
Testé avec des commits historiques (245 cas de Code & Test Adaptation annulés volontairement), sans prompting spécifique, l’agent a réussi à résoudre 30 % des échecs de tests. Ses forces : tests, conditions propres à chaque plateforme et ajustements de représentation de données. C’est un premier pas : Google prévoit de l’améliorer avec des optimisations supplémentaires.
Axion + multiarch : implications pour Google… et pour le secteur
- Elasticité à une nouvelle échelle : si le scheduler peut distribuer la même charge en x86 ou ARM en fonction de la disponibilité et du coût, l’occupation moyenne des clusters augmente et le coût effectif par service diminue.
- Soutien à la durabilité : avec jusqu’à 60 % d’amélioration en efficacité énergétique, l’impact global en consommation et en émissions devient significatif.
- Moins de dépendance à l’ISA-fournisseur : le fait de concevoir des applications multiarch par défaut diminue le risque technologique et ouvre le champ des possibles en matière de hardware (Axion aujourd’hui, autres ARM à venir), sans réécrire le logiciel.
- Changements culturels : cette migration a montré que la véritable friction se trouve dans les tests, builds et pipelines. Cette couche, souvent invisible, doit être conçue pour la portabilité.
Que signifie cela pour les clients de Google Cloud ?
Bien que l’article porte principalement sur l’infrastructure interne, les enseignements ont aussi des répercussions pour le client :
- Plus d’options d’instances avec un meilleur rapport prix/performance et une efficience accrue (Axion), sans compromis sur la compatibilité si le logiciel est multiarch-ready.
- Amélioration du TCO pour les charges élastiques, microservices et data plane exploitant la flexibilité du scheduler entre ISAs.
- Une guide pour aborder des migrations réalistes dans les grandes organisations: commencer par tests/outils, automatiser les builds et les rollouts, et utiliser l’IA comme un multiplicateur, non comme un substitut à l’ingénierie.
Et maintenant : « multiarch par défaut »
Google prévoit d’utiliser l’automatisation pour traiter des dizaines de milliers d’applications encore en attente, et a adopté la politique de « multiarch par défaut » pour les nouvelles applications. Les composants structurants —monorepo visible, tooling multiarch, automatismes comme Rosie et CHAMP— sont en place. Avec CogniPort qui assurera la dernière étape, l’objectif déclaré est d’amener tous les services en production vers une neutralité d’architecture plus stricte.
La leçon fondamentale pour le secteur est claire : la migration d’ISA n’est plus de la science-fiction, c’est une opération industrielle. Le véritable enjeu —du moins dans cette expérience— ne concerne pas la traduction de vecteurs ou l’ajustement d’assembleur, mais la domestication de la périphérie: tests, builds, configs, pipelines. Là où l’IA générative peut jouer un rôle clé, c’est dans la main-d’œuvre infatigable qu’elle représente.
Foire aux questions
Que sont les processeurs Axion de Google et quels avantages apportent par rapport à des instances comparables ?
Les Axion sont des CPU Arm conçues par Google pour ses centres de données. Selon la société, elles offrent jusqu’à 65 % de meilleur rapport prix/performance et jusqu’à 60 % de meilleure efficacité énergétique comparé à des instances similaires dans Google Cloud, tout en maintenant une parfaite compatibilité logicielle pour des applications multiarch.
Comment fonctionne CogniPort, l’agent IA dédié à la migration ISA ?
CogniPort se déclenche lors d’échecs de compilation ou de tests sur ARM. Via des boucles agiles (orchestrateur, build-fixer et test-fixer), il modifie le code, les scripts de build ou les configs jusqu’à réussite. Lors de tests avec des commits historiques, l’agent a réussi à résoudre 30 % des erreurs de tests sans interventions additionnelles.
Combien d’applications Google a-t-il migré et celles déjà en service multiarch ?
Google affirme avoir migré plus de 30 000 applications vers ARM, avec des services tels que YouTube, Gmail ou BigQuery opérant simultanément en x86 et ARM. Le hardware ARM est pleinement exploité et une capacité supplémentaire est déployée chaque mois.
Quels ont été les principaux obstacles à la migration multiarch ?
Contrairement aux attentes, ce ne sont pas les différences profondes entre ISA, mais plutôt les tests surajustés à x86, systèmes de build anciens et configurations ne tenant pas compte des variantes architecturales. L’automatisation —Rosie, sanitizers/fuzzers, CHAMP— et l’IA ont été clés pour industrialiser le processus.
Sources : Analyse technique de Google Cloud (“Using AI and automation to migrate between instruction sets”) et prépublication « Instruction Set Migration at Warehouse Scale » ; couverture explicative dans El Chapuzas Informático sur la migration vers Axion/Arm et l’utilisation de l’IA.
via : cloud.google
