Comment Figma a migré vers K8s en moins de 12 mois

Paramètres des cookies et abonnement à la newsletter

• Ce site web utilise des cookies, des balises pixel et le stockage local à des fins de performance, de personnalisation et de marketing.
• Seuls les cookies essentiels sont activés par défaut.
• Il est possible de s’abonner à la newsletter.

Migration de Figma vers Kubernetes

• Auteur : Ian VonSeggern, Engineering Manager chez Figma
• Sujet : le processus et les raisons qui ont conduit Figma à migrer vers Kubernetes en moins de 12 mois

La plateforme de calcul de Figma

• Début 2023, l’entreprise a achevé le travail consistant à exécuter tous ses services dans des conteneurs.
• Des tâches conteneurisées ont été lancées rapidement avec Elastic Container Service (ECS) d’AWS.
• Dans une perspective de long terme, l’équipe a commencé à envisager la prochaine génération de sa plateforme de calcul.

Manques fonctionnels de Kubernetes

• Certaines limitations d’ECS ont consommé beaucoup de temps d’ingénierie.
• Comme ECS ne disposait pas de la fonctionnalité StatefulSets de Kubernetes, il était difficile d’exécuter un cluster etcd.
• Absence de prise en charge de la définition des services via des charts Helm.
• Difficulté à arrêter une seule machine EC2 lors de l’exécution d’EC2 sur ECS.

Accès à l’écosystème de la Cloud Native Computing Foundation

• Avec ECS, il n’était pas possible de tirer parti des technologies open source de l’écosystème CNCF.
• L’écosystème Kubernetes offre d’excellentes capacités d’auto-scaling.
• La possibilité d’introduire un service mesh a aussi été envisagée.

Les avantages d’une plateforme populaire

• Kubernetes est utilisé par de nombreuses grandes entreprises, ce qui a fait ses preuves en matière de stabilité.
• Cela permet d’éviter le vendor lock-in.
• Il est plus facile de recruter des ingénieurs ayant de l’expérience avec Kubernetes.

Définition du périmètre de migration

• Afin de garantir une migration sûre, les changements apportés aux systèmes critiques ont été réduits au minimum.
• L’objectif était de passer à EKS.
• Certaines améliorations ont été incluses dans le périmètre de migration.

Améliorations incluses dans la migration

• Expérience développeur : simplification de la définition des services et du processus de déploiement.
• Amélioration de la fiabilité : utilisation de trois clusters EKS pour renforcer la fiabilité des services.
• Efficacité des coûts : prise en charge de l’auto-scaling des nœuds afin de réduire les coûts.

Travaux exclus du périmètre

• Les travaux visant à résoudre la complexité du pipeline de logs ont été exclus.
• Les travaux sur l’auto-scaling au niveau des pods ont été exclus.

Réaliser une migration sûre

• Tests de charge : des tests de charge ont été effectués pour comprendre les performances des clusters.
• Mécanisme de déploiement progressif : le trafic a été déplacé progressivement à l’aide d’entrées DNS pondérées.
• Exécution de services réels : des services réels ont été exécutés dans l’environnement de staging afin de détecter les problèmes en amont.
• Réduction du YAML personnalisé : les définitions YAML susceptibles de perturber les utilisateurs ont été réduites au minimum.
• Collaboration étroite avec les responsables de services : les équipes ont travaillé avec les responsables de services pour mettre à jour le monitoring et les alertes.
• Affectation des bonnes ressources humaines : une équipe capable de résoudre les problèmes imprévus a été mise en place.

Résultats de la migration

• D’ici janvier 2024, les principaux services avaient été migrés vers les clusters EKS.
• La migration a apporté des bénéfices tels que la réduction des coûts, l’amélioration de la fiabilité et une meilleure expérience développeur.

Période post-lancement

• Les outils d’accès utilisateur ont été améliorés grâce à l’inférence automatique des clusters et des rôles.
• Des travaux sont prévus pour simplifier le pipeline de logs, prendre en charge l’Horizontal Pod Autoscaler et migrer vers les processeurs Graviton.

Récapitulatif de GN⁺

• Grâce à sa migration d’ECS vers Kubernetes, Figma a obtenu une réduction des coûts, une meilleure fiabilité et une amélioration de l’expérience développeur.
• En s’appuyant sur les technologies open source de l’écosystème CNCF, l’entreprise a renforcé ses possibilités d’auto-scaling et d’introduction d’un service mesh.
• Pendant la migration, des méthodes sûres ont été utilisées, comme les tests de charge, le déploiement progressif et l’exécution de services réels.
• Après le lancement, Figma a amélioré ses outils d’accès utilisateur et prévoit des travaux d’optimisation supplémentaires.

[GN⁺]

Avis sur Hacker News

• Un utilisateur apprécie k8s

  • Il gère plusieurs petites boutiques e-commerce complexes et très personnalisées
  • Il s’occupe aussi bien du marketing que des finances et du service client
  • Auparavant, il utilisait des serveurs dédiés, mais les déploiements étaient un cauchemar
  • La migration vers k8s lui a pris un mois
  • Il exploite 25 services différents
  • Le fait d’avoir la configuration du cluster centralisée en un seul endroit lui permet de connaître précisément l’état des services
  • Il est désormais possible de faire des déploiements progressifs sans interruption de service
  • C’est complexe, mais en tant que programmeur il est habitué à la complexité
  • Comprendre l’architecture de k8s permet d’en apprendre davantage
  • La haute disponibilité (HA) est très utile
  • Les frais d’hébergement sont d’environ 400 dollars par mois

• Une migration pour améliorer l’infrastructure est une bonne chose

  • Il est surprenant de ne pas convertir en Terraform pour utiliser des charts Helm
  • Utiliser des charts Helm sans les modifier manque de cohérence
  • Helm est un outil difficile à maintenir
  • Il vaut mieux tout réécrire en Terraform
  • On se demande si les problèmes de Helm ont été résolus

• Le grand nombre d’avis anti-k8s sur HN est surprenant

  • Beaucoup de commentateurs utilisent probablement des services comme Heroku, Fly.io, Render.com, ou exécutent leurs applications sur des VM

• La gestion des déploiements avec Terraform et ECS est excessivement complexe

  • Ajouter ne serait-ce qu’une variable d’environnement est compliqué
  • La partie génération de templates se comprend, mais dans l’ensemble c’est complexe

• Certains doutent qu’une migration vers Kubernetes puisse prendre plusieurs années

  • Ils ne comprennent pas pourquoi les entreprises essaient ce type de migration
  • Ils s’interrogent sur les bénéfices concrets pour les clients
  • Ils se demandent si des décisions motivées par une envie technique ont vraiment du sens pour les utilisateurs

• Dans les grandes organisations, les décisions ne semblent pas fondées sur les besoins des utilisateurs ou de l’entreprise

  • Le même ressenti est apparu dans un précédent billet de Figma sur sa base de données
  • On se demande si des décisions motivées par une envie technique ont vraiment du sens pour les utilisateurs

• Certains se demandent s’il existe aujourd’hui des systèmes ou services modernes dont une migration en moins d’un an serait vraiment digne d’être mise en avant

• Certains aiment lire des retours de terrain

  • Ils apprennent toujours quelque chose de nouveau
  • Merci d’avoir partagé

• Cet article explique clairement les avantages de Kubernetes

  • Beaucoup passent à Kubernetes sans vraiment en connaître les bénéfices
  • Les raisons présentées ici sont bonnes

• Certains se demandent combien de temps il faudra pour abandonner cette migration