‍

Introduction

Dans le monde en constante évolution de l'informatique en nuage, l'optimisation des coûts et l'amélioration des performances sont des priorités absolues. L'architecture ARM, avec ses processeurs AWS Graviton, offre une alternative puissante et rentable aux architectures x86 traditionnelles.

Cet article présente notre expertise et notre expérience en matière de migration des charges de travail vers des instances ARM, en mettant l'accent sur les avantages, les défis et les meilleures pratiques.

‍

Pourquoi choisir l'architecture ARM (Graviton) ?

Les processeurs Graviton d'AWS, basés sur l'architecture ARM, offrent plusieurs avantages significatifs :

• Réduction des coûts: Les instances Graviton sont souvent plus économiques que leurs équivalents x86, ce qui permet de réaliser des économies substantielles sur les dépenses d'infrastructure.
• Amélioration des performances: Pour de nombreuses charges de travail, les processeurs Graviton peuvent offrir de meilleures performances par watt, ce qui se traduit par une exécution plus rapide et plus efficace.
• Efficacité énergétique: Les processeurs ARM sont connus pour leur faible consommation d'énergie, ce qui réduit à la fois l'empreinte carbone et les coûts d'exploitation.
• Polyvalence: Les processeurs Graviton conviennent à un large éventail de charges de travail, depuis les serveurs web et les bases de données jusqu'à l'analyse de données et l'informatique à haute performance.
  
  

Comparaison des coûts : Avant et après la migration ARM

La migration vers l'architecture ARM, en particulier avec les instances Graviton, offre des avantages financiers substantiels. Vous trouverez ci-dessous une comparaison des coûts pour des cas d'utilisation courants :

‍

x86 vs ARM (région parisienne)

‍Remarque : Les coûts horaires sont indicatifs et peuvent varier en fonction de la région AWS, des options de tarification (Reserved, Spot) et des charges de travail spécifiques.

Pour les fonctions AWS Lambda, l'exécution sur l'architecture ARM (Graviton2) permet généralement de réduire les coûts de 20 % tout en offrant des performances améliorées par rapport à l'architecture x86. Cette optimisation est particulièrement bénéfique pour les applications sans serveur à grande échelle, où les économies peuvent rapidement s'accumuler.

‍

Comment migrer vos charges de travail AWS vers ARM ?

Nos équipes ont développé une forte expertise dans la migration de charges de travail conteneurisées vers des instances ARM sur AWS. Notre approche comprend :

• Évaluation et planification: Nous effectuons une analyse approfondie des applications existantes afin d'identifier la compatibilité, les dépendances et les optimisations nécessaires.
• Compatibilité des logiciels: Nous travaillons avec les équipes de développement pour nous assurer que le code source, les bibliothèques et les outils sont compatibles avec l'architecture ARM, ou pour identifier les changements nécessaires.
• Tests de performance et d'intégration: Nous effectuons des tests rigoureux pour nous assurer que les niveaux de performance attendus sont atteints et que l'intégration avec les services AWS est transparente.

Optimisation continue: Même après la migration, nous continuons à surveiller et à optimiser les charges de travail pour exploiter pleinement les capacités de l'architecture ARM.

Expérience des services AWS

Trois services principaux permettent d'exécuter des conteneurs sur AWS :

• AWS Lambda
• Amazon Elastic Container Service (ECS)avec deux modes d'exécution :
  
  • sur Fargate (sans serveur)
  • sur EC2
• Service Amazon Elastic Kubernetes (EKS)
  
  

Avant d'aborder les aspects spécifiques de la migration de chacun de ces services, examinons l'exigence commune à tous ces services : la nécessité de créer des images de conteneurs pour la nouvelle architecture cible.

Construction d'images (Build)

Constructions natives (Construire ARM sur un hôte ARM)

L'objectif est de construire l'image directement sur une architecture ARM64 : une instance Graviton, une instance AWS CodeBuild Arm64, ou un Mac avec une puce Apple Silicon (M1 ou ultérieure).

Constructions émulées (Construire ARM sur un hôte x86)

L'objectif est de construire une image Arm64 à partir d'une machine x86 (émulation) :

• Utiliser BuildKit via docker buildx‍
• QEMU émule le processeur Arm64

Notes supplémentaires sur les constructions

Les constructions natives sont souvent plus rapides et plus fiables puisqu'il n'y a pas d'émulation - c'est la meilleure option si vous avez accès à un environnement ARM64 (Graviton EC2, Mac M1, CodeBuild Arm64).

Les constructions émulées (via buildx + QEMU) sont très pratiques pour générer des images multiplateformes sur des machines x86, mais elles peuvent être beaucoup plus lentes et plus complexes.

Manifeste multi-architecture

Un manifeste multi-architecture vous permet de regrouper plusieurs images Docker construites pour différentes architectures (telles que x86_64, ARM64, etc.) sous une seule étiquette unifiée. Lorsque vous exécutez un docker pull, le moteur détecte automatiquement votre architecture et récupère la version correspondante.

1. Construction d'images spécifiques : Des images Docker distinctes, chacune spécifique à une architecture donnée (par exemple, amd64, arm64), sont générées puis poussées vers un registre d'images de conteneurs (par exemple, Docker Hub, Amazon ECR).
2. Création du fichier manifeste : Un fichier manifeste (ou liste manifeste), qui est un fichier index, est créé. Il référence les images spécifiques à l'architecture, en associant chaque image à l'architecture correspondante. Ce manifeste est ensuite poussé vers le registre avec une étiquette unifiée (par exemple, my-app:latest).‍
3. Exécution des conteneurs : Lorsqu'il est exécuté (par exemple, docker run my-app:latest), le client Docker interroge le registre des conteneurs pour obtenir le fichier manifeste. Il identifie sa propre architecture, télécharge l'image appropriée et instancie le conteneur de manière transparente.

‍

‍Cesmanifestes multi-architectures sont très utiles car:

• Ils simplifient le flux de travail CI/CD : une étiquette pour toutes les architectures, pas besoin de gérer des variantes séparées.
• Grande flexibilité : une seule image peut être utilisée sur EC2 Graviton (ARM) comme sur des serveurs x86 sans changer la configuration.
  
  

Construire des manifestes multi-architectures avec l'émulation

La méthode la plus simple en une étape avec buildx :

‍

‍

Construire des manifestes multi-architectures de manière native 

‍

‍

Flux de travail CI/CD recommandé

‍

Ce diagramme illustre un pipeline d'intégration et de déploiement continus (CI/CD) optimisé pour la création d'applications multi-architectures (Arm et x86). À partir d'un dépôt de code unique, le processus se divise en deux flux parallèles, chacun utilisant un runner natif pour compiler, tester et publier une image de conteneur spécifique à son architecture. Une fois ces deux images validées, une étape de consolidation les fusionne en un manifeste unique. Ce manifeste permet ensuite aux environnements de déploiement de télécharger automatiquement la version de l'image appropriée (Arm ou x86) pour leur architecture, garantissant ainsi un processus de déploiement final simple et transparent sur les deux plateformes.

‍

AWS Lambda : Migration vers ARM

Une particularité de Lambda : pour l'instant, le service ne prend pas en charge les images multi-architectures.

Pour exécuter une fonction Lambda sur une architecture ARM64 (via les processeurs AWS Graviton2), il suffit de modifier un seul paramètre dans sa configuration. Dans les paramètres de Runtime de votre fonction, vous devez :

• Changez le champ Architecture de x86_64 à arm64.
• Fournir une image Docker correspondant à l'architecture ARM64 (pas de manifeste !).

‍

ECS Fargate : Migration vers ARM

Pour migrer une charge de travail Fargate vers ARM, vous devez spécifier explicitement l'architecture dans la configuration de la définition de la tâche. Pour ce faire, ajoutez ou modifiez le champ runtimePlatform dans le JSON de la définition de la tâche, en lui attribuant la valeur ARM64 pour indiquer que la tâche doit s'exécuter sur une architecture ARM. Cette modification garantit que Fargate alloue des ressources basées sur ARM pour votre application.

‍

ECS (mode EC2) : Migration vers ARM

La migration d'une charge de travail ECS en mode EC2 vers une architecture ARM nécessite deux étapes clés.

Créer un fournisseur de capacité ARM

Associez un nouveau fournisseur de capacité ECS à un groupe de mise à l'échelle automatique (ASG) EC2. Cet ASG doit être configuré pour lancer des instances ARM (par exemple, t4g, m6g, c6g) avec une AMI ARM64 optimisée par ECS. Intégrez ce fournisseur de capacité dans votre stratégie de cluster ECS pour permettre une migration progressive ou des charges de travail mixtes.

Contraindre les tâches à l'ARM

Configurez vos services ou vos tâches pour qu'ils utilisent spécifiquement ce fournisseur de capacité ARM. Pour plus de sécurité, incluez une contrainte de placement dans la définition de la tâche afin d'imposer l'exécution sur une architecture ARM64.

Voici un exemple de contrainte de placement à ajouter dans la définition de la tâche :

En résumé, les fournisseurs de capacité optimisent la migration en automatisant la gestion et l'ajustement des instances Graviton. Il vous suffit de spécifier le type de capacité requis pour vos tâches (ARM ou x86), et ECS, par l'intermédiaire du fournisseur de capacité, s'assure que l'infrastructure appropriée est provisionnée.

‍

EKS (Kubernetes) : Migration vers ARM

Pour migrer un cluster Amazon EKS (Elastic Kubernetes Service) vers une architecture ARM, la démarche est similaire à ECS en mode EC2. Elle consiste à provisionner des nœuds de calcul (worker nodes) basés sur l'architecture ARM et à s'assurer que vos applications (pods) s'exécutent sur ces nouveaux nœuds.

Ajout de nœuds de calcul ARM

Pour intégrer des instances AWS Graviton (ARM64) dans votre cluster EKS, l'approche recommandée consiste à utiliser des groupes de nœuds gérés.

Les principales étapes de la création d'un groupe de nœuds sont les suivantes :

• Sélectionnez le type d'instance ARM: Choisissez les familles d'instances Graviton telles que m6g, c6g ou r6g.
• Utiliser une AMI optimisée pour ARM: EKS fournit des AMI officielles spécifiquement optimisées pour Kubernetes et compatibles avec l'architecture ARM64. Il est tout à fait possible et même recommandé de fonctionner avec un cluster hétérogène, combinant des groupes de nœuds x86_64 et arm64. Cette configuration favorise une migration progressive et contrôlée.
  
  

Karpenter

Une alternative efficace pour l'autoscaling est Karpenter, un outil open-source recommandé par AWS pour EKS. Il permet le provisionnement dynamique des nœuds (Graviton/x86), optimise les coûts grâce aux instances Spot et simplifie la configuration pour une gestion des ressources flexible et rentable.

Ordonnancement de pods sur des nœuds ARM

Une fois que les nœuds ARM sont disponibles, vous devez configurer Kubernetes pour déployer vos applications compatibles ARM sur ces nœuds. Pour ce faire, utilisez les mécanismes de planification intégrés de Kubernetes.

Kubernetes attribue automatiquement des étiquettes aux nœuds, comme kubernetes.io/arch=arm64. Ce label peut être utilisé pour s'assurer que vos pods s'exécutent exclusivement sur les nœuds appropriés.

La méthode la plus courante consiste à spécifier un nodeSelector ou une affinité de nœud(nodeAffinity) dans votre définition de déploiement ou de pod.

‍

Voici un exemple simple utilisant nodeSelector:

‍

‍

Cas d'utilisation client : Saut - Migration ARM et mise à niveau de version intégrée

‍

Contexte de la clientèle

Jump est une plateforme française qui permet aux freelances de conserver leur indépendance tout en bénéficiant des droits des salariés (fiche de paie, assurance, congés payés, etc.) grâce au portage salarial. Jump souhaitait optimiser ses coûts d'infrastructure et améliorer les performances de ses applications conteneurisées. Leur architecture existante à base de x86 était stable mais ne permettait plus les gains d'efficacité souhaités. En outre, il était nécessaire de mettre à niveau plusieurs clusters Kubernetes parallèlement à la migration ARM.

Objectifs du projet

• Migrer des charges de travail conteneurisées vers des instances AWS Graviton (ARM64).
• Réduire considérablement les coûts d'infrastructure.
• Améliorer les performances globales de l'application.
• Intégrer la migration ARM avec une mise à jour de plusieurs composants logiciels majeurs.
• Mettre en œuvre un pipeline CI/CD robuste et moderne.
• Adopter Karpenter pour la gestion de la mise à l'échelle automatique des nœuds EKS.

Défis rencontrés et solutions apportées

Le projet avec Jump a présenté des défis complexes en raison de la nature combinée de la migration ARM et de la mise à jour de la version de l'écosystème d'applications. Les points les plus critiques étaient les suivants :

• Gestion de la complexité des versions et des architectures: La coexistence de différentes versions logicielles et la nécessité de prendre en charge à la fois x86 et ARM ont rendu les phases de planification et de test particulièrement exigeantes. Nous avons mis en œuvre des stratégies de test exhaustives et des environnements de pré-production dédiés pour valider chaque étape de la migration et de la mise à niveau des versions.
• Mise en œuvre d'un pipeline CI/CD multi-architecture: Le plus grand défi a été de moderniser et d'adapter le pipeline CI/CD de Jump afin qu'il puisse construire et déployer des images de conteneurs pour les architectures x86 et ARM64 de manière transparente. Nous avons mis en œuvre des constructions multi-architectures en utilisant Docker buildx et Docker manifests, permettant à une seule balise image de servir toutes les architectures. Cela a nécessité une refonte des pipelines de construction et de déploiement existants.
• Migration et adoption de Karpenter sur EKS: L'intégration de Karpenter a été un autre point clé. Initialement, Jump utilisait des groupes de nœuds gérés plus traditionnels. La transition vers Karpenter a permis une gestion plus dynamique et plus rentable des nœuds EKS, en tirant pleinement parti des instances Spot et des capacités d'autoscaling rapide des instances Graviton. Nous avons aidé les équipes de Jump à configurer les provisionneurs Karpenter, en définissant des règles pour l'architecture et la sélection des types d'instances (y compris Graviton) afin d'optimiser l'utilisation des ressources.
• Compatibilité: Le manque de disponibilité de certains composants ou outils souvent obsolètes et non maintenus a été l'occasion de rationaliser les ressources et de nettoyer les clusters Kubernetes.
  

Résultats et avantages

La migration réussie et la mise en œuvre de nouvelles pratiques ont permis à Jump de.. :

• Réaliser des économies substantielles sur les coûts de l'infrastructure en nuage grâce à l'adoption généralisée des instances Graviton.
• Bénéficier d'une amélioration significative des performances de leurs applications critiques.
• Disposer d'un pipeline CI/CD modernisé et flexible, capable de gérer les déploiements sur différentes architectures avec une seule source de vérité.
• Optimiser l'utilisation des ressources Kubernetes via Karpenter, rendant leur infrastructure plus élastique et résiliente.
• Assurer une transition en douceur et contrôlée (sans interruption de service) malgré la complexité d'une migration combinée à une mise à jour majeure de la version.
  
  

Ce cas d'usage illustre notre capacité à gérer des projets de migration complexes, intégrant non seulement des changements architecturaux mais aussi des évolutions technologiques profondes et l'optimisation des pratiques DevOps.

Limites et défis de la migration vers l'ARM

Si la migration vers l'architecture ARM offre des avantages substantiels, elle peut également présenter des défis et des limites qu'il est important de prendre en compte :

• Effort de migration important pour certains projets: Pour les applications complexes ou monolithiques, le passage à l'ARM peut nécessiter des efforts de développement et de test considérables. Les dépendances logicielles x86 spécifiques à l'architecture, les compilations natives ou les outils incompatibles peuvent nécessiter des ajustements profonds.
• Compatibilité logicielle: Bien que l'écosystème ARM s'améliore rapidement, il se peut que certains logiciels ou bibliothèques moins courants ne soient pas encore totalement optimisés ou disponibles pour cette architecture. Cela peut nécessiter l'exploration de solutions alternatives ou la mise en œuvre d'adaptations.
• Plateformes interprétées: Pour les projets basés sur des langages tels que PHP, Python, NodeJS ou Java, la couche d'abstraction fournie par les machines virtuelles ou les interprètes rend généralement l'application indifférente à l'architecture sous-jacente. Cependant, les dépendances natives (extensions, bibliothèques C/C++) utilisées par ces applications peuvent nécessiter une recompilation ou des versions spécifiques à ARM.
• Outils CI/CD et intégrations: Les chaînes d'outils CI/CD peuvent nécessiter des mises à jour pour prendre en charge les constructions multi-architectures ou les environnements de test ARM, ce qui ajoute une complexité initiale à la configuration.
  
  

Il est essentiel d'évaluer soigneusement ces points lors de la planification de la migration afin de s'assurer que les avantages escomptés justifient l'investissement. Une approche progressive et bien structurée est essentielle pour minimiser les perturbations et maximiser le succès de la transition.

‍

Conclusion

La migration vers l'architecture ARM, notamment avec les processeurs Graviton d'AWS, offre une opportunité significative d'optimiser les infrastructures cloud. Notre expertise nous permet d'accompagner nos clients dans cette transition, en gérant les défis et en exploitant pleinement les avantages de cette technologie.

Nous accompagnons nos clients dans la modernisation de leurs applications, leur conteneurisation et la mise en place de pipelines CI/CD. La plupart de ces évolutions devraient être gérées par les meilleures pratiques d'Infrastructure as Code (IaC) et de GitOps. Nous sommes prêts à vous accompagner dans l'adoption de ces pratiques si elles ne sont pas encore en place au sein de votre organisation.

‍

Prêt à transformer vos opérations ? Contactez-nous pour une migration ARM efficace et en douceur.

‍