Comment déplacer l'infrastructure des machines virtuelles classiques vers des conteneurs orchestrés par Kubernetes

Ce billet de blog explique comment GraphiqueMogul a retiré ses derniers éléments d'infrastructure sur DigitalOcean, marquant sa migration vers AWS comme terminée.

Le voyage n'était pas votre migration AWS habituelle car il impliquait de déplacer notre infrastructure de machines virtuelles classiques vers des conteneurs orchestrés par Kubernetes.

Dans une série d'articles, nous partagerons nos expériences sur :

• Notre parcours vers AWS EKS (service géré Kubernetes).
• Certains des obstacles les plus critiques que nous avons rencontrés.
• Notre pile et nos outils actuels.
• Nos plans d'infrastructure vont de l'avant, en espérant qu'ils pourront être utiles à l'ensemble de la communauté.

La vie avec DigitalOcean

Depuis notre création en 2014 et jusqu'à la mi-2021, l'ensemble de notre infrastructure a fonctionné sur des droplets DigitalOcean (machines virtuelles cloud autogérées). Nous avions besoin d'un fournisseur de cloud pour démarrer rapidement, de manière fiable et rentable.

DigitalOcean avait beaucoup de sens et était un excellent choix. Nous sommes là où nous sommes grâce à eux. Ce choix nous a donné la liberté de nous concentrer sur la création de produits sans nous soucier de l'évolutivité et de la complexité de l'infrastructure, des aspects qui interviennent généralement à un stade ultérieur.

Chaque aspect de notre infrastructure a été provisionné, configuré et géré en interne. Nous avons utilisé la gestion de la configuration et les outils Infrastructure as Code (Saltstack et Terraform) pour gérer les choses.

Nous n'avons cessé de croître au fil des ans et, en 2019, nous nous sommes retrouvés face à une flotte d'environ 50 machines nécessitant constamment une gestion, des mises à jour logicielles, des correctifs de sécurité, etc. Et avec de nouveaux projets dans notre pipeline, nous nous attendions à ce que nos besoins en puissance de calcul doublent d'ici la fin de 2020.

Pourquoi déménager et pourquoi maintenant ?

Aussi formidable que soit le choix de DigitalOcean, notre croissance organique a repoussé les limites de notre configuration au fil des ans. Nous avons fait face à des défis dans plusieurs domaines, certains réparables et évitables, d'autres non.

Échecs divers

• Fenêtres de maintenance ad hoc inopinées qui ont soudainement interrompu la production.

  
  

• Défaillances matérielles à plusieurs reprises, affectant la configuration de notre base de données principale - réplique (par exemple, les gouttelettes entrant dans un «état de migration en direct vers d'autres machines matérielles» sans préavis, ce qui signifie 1 à 2 heures d'indisponibilité pour cette gouttelette.)

  
  

• Problèmes de réseau inexpliqués avec la latence entre nos machines que l'équipe d'assistance de DigitalOcean n'a jamais résolus (c'était critique pour notre retard de lecture des réplicas Postgres, les instances Redis et HA en général).

Abandon de la région AMS2

Notre région DigitalOcean (AMS2) a été annoncée comme "bientôt à la retraite", ce qui signifie un support limité. Nous ne pouvions pas obtenir de ressources supplémentaires à la demande, et l'exécution de tâches simples signifiait généralement une longue planification et un gaspillage de ressources.

Des choses simples telles que la mise à niveau d'une version de Postgres et le provisionnement d'une nouvelle machine pour effectuer une tâche devenaient impossibles à faire.

Choix matériels limités

Être dans l'espace d'analyse des abonnements signifie des opérations gourmandes en données, de gros volumes et la possibilité d'évoluer souvent en conséquence.

Les machines modernes dotées de ressources matérielles plus étendues n'étaient disponibles que dans d'autres régions. La dégradation des performances du réseau était un phénomène fréquent, et nous nous sommes vite rendu compte que migrer vers une autre région était notre meilleur pari.

Manque de fonctionnalités cloud modernes et de services gérés

Le volume de travail opérationnel pour entretenir notre infrastructure afin de suivre le taux de croissance (et de gérer simultanément la dette technologique) a augmenté.

Nous avons dû examiner attentivement notre configuration et comprendre si déménager dans une autre région DigitalOcean ou un nouveau fournisseur de cloud était le meilleur choix.

Devrions-nous rester ou devrions-nous partir ?

Nous avons commencé à examiner les avantages de rester avec DigitalOcean et de simplement déménager dans une nouvelle région - une option plus tranquille, plus rapide, moins chère et moins douloureuse.

Mais en même temps, nous avons traité cette décision comme une opportunité de moderniser certaines parties de notre pile au service de la croissance attendue des utilisateurs et d'un rythme de progression accru.

À la fin de notre évaluation, nous avons réalisé que des exigences spécifiques incontournables seraient difficiles à atteindre en restant et en changeant simplement de région. Les plus importants étaient :

• Flexibilité dans les ressources de calcul à mise à l'échelle automatique.

• Bases de données gérées.

• Provisionnement des ressources en fonction de l'utilisation temporaire.

• Latence (plus) faible.

• Interopérabilité des services.

• Infrastructure basée sur des conteneurs avec orchestration Kubernetes.

  
  

Cette liste d'exigences ainsi que les défis énumérés dans la section précédente ont fait pencher la balance en faveur du changement de fournisseur.

Pourquoi AWS ?

Le choix d'un nouveau fournisseur de cloud pour alimenter l'infrastructure ChartMogul a été un long voyage. Nous avons étudié le marché et découvert de nombreux compromis et avantages qu'un nouveau fournisseur pourrait apporter à la table.

Nos options étaient Amazon Web Services (AWS), Google Cloud (GCP) et Azure. Finalement, nous avons décidé d'aller avec AWS. Nous énumérons ci-dessous quelques-unes des principales raisons.

Expertise d'équipe

Nous utilisions déjà certains services AWS en production (par exemple, S3 pour stocker des sauvegardes Postgres incrémentielles). Plus important encore, quelques-uns de nos ingénieurs avaient une expérience professionnelle préalable dans l'utilisation intensive de divers services AWS dans les systèmes de production.

Évolutivité

• Nous pouvons augmenter ou réduire les instances AWS d'une simple pression sur un bouton.

  
  

• Nous pouvons provisionner instantanément des ressources telles que des bases de données RDS et des ressources de calcul temporairement.

  
  

• Nous pouvons parcourir rapidement les expériences et les preuves de concepts.

  
  

• La flexibilité et l'évolutivité des pools de nœuds Kubernetes sauvegardés par la mise à l'échelle automatique EC2 sont difficiles à battre.

Sécurité et conformité des données

La sécurité des données a toujours été une priorité. Au fil des ans, les capacités de sécurité d'AWS ont considérablement augmenté.

Le nombre de nouveaux services développés par AWS autour de la sécurité des données couvre la plupart de nos besoins dans l'espace conteneur/Kubernetes.

Ils fonctionnent bien avec des services bien établis tels que l'isolement de VPC privé, le contrôle précis des politiques et les rôles IAM.

En ce qui concerne la conformité, nous prévoyons d'obtenir la certification SOC II dès que possible, et nous avons constaté que les programmes de conformité AWS étaient un avantage qui peut aider à accélérer ce parcours.

Services gérés

Postgres est au cœur de ce que nous faisons chez ChartMogul, et nous avons généralement passé beaucoup de temps à gérer activement notre flotte de bases de données de machines pour soutenir notre croissance.

La haute disponibilité et la fiabilité des bases de données devenaient des préoccupations croissantes, nous avons donc décidé d'évaluer plusieurs offres des principaux fournisseurs de cloud avec PostgreSQL géré. AWS RDS a été le grand gagnant.

Kubernetes géré était un autre facteur majeur à prendre en compte, et c'était en tête-à-tête avec Google Cloud (GCP). Le Kubernetes géré par Google (GKE) se sentait mieux que ce qu'AWS avait à l'époque, mais comparer RDS à CloudSQL n'était pas proche en termes de fonctionnalités.

De nos jours, il semble cependant qu'AWS rattrape EKS ; Nous bénéficions d'excellentes fonctionnalités RDS telles que la flexibilité des instantanés, la durabilité des sauvegardes (avec SLA), les répliques en lecture pour Postgres, les mises à niveau indolores, les IOPS dédiées, les métriques Cloudwatch, Performance Insights, et la liste continue.

Le nombre insensé de services AWS

Au moment de la rédaction, AWS propose plus de 200 services. La plupart d'entre eux vous permettent d'accéder instantanément à des services gérés dans de nombreux domaines tels que le calcul, les bases de données, l'analyse de données, l'entreposage de données, le sans serveur et le stockage.

Nos équipes d'ingénieurs peuvent désormais tirer parti d'intégrations de premier ordre pour résoudre rapidement les problèmes de base et donner la priorité à l'achat par rapport à la construction là où cela a du sens.

reprise après sinistre

Le cloud AWS est un élément essentiel de notre plan de reprise après sinistre. C'est parce que les instances sont faciles à lancer, nous pouvons promouvoir les réplicas en lecture RDS en tant que primaires en un clic, les instantanés sont un jeu d'enfant, nous pouvons héberger dans plusieurs régions et nous avons une intégration de premier ordre avec notre outil IaC de choix.

Crédits AWS

Nous avons obtenu 100 000 $ de crédits grâce au programme AWS Startup. Nous avons pu planifier, tester et terminer notre migration sans dépenses considérables.

Migration vers AWS

Notre migration de DigitalOcean vers AWS a duré dix mois. L'ensemble de l'effort a été soutenu par des bénévoles de toutes nos équipes d'ingénierie et dirigé par un ingénieur DevOps, un ingénieur backend et notre responsable de l'ingénierie.

Certaines choses impliquaient des essais et des erreurs. Nous avons essayé plusieurs façons de :

• Déplacement des données de Postgres vers RDS avec un temps d'arrêt quasi nul.

  
  

• Déplacement de notre application et de nos services d'une architecture basée sur des machines virtuelles vers des architectures conteneurisées dans Kubernetes.

  
  

• Changer fondamentalement la façon dont nous nous déployons.

Un plan parfait était en place et tout semblait bon sur le papier, mais nous avons appris à nos dépens que les choses ne se dérouleraient pas toujours comme prévu.

Parfois, notre objectif de migration de temps d'arrêt proche de zéro était sérieusement menacé, et nous sommes retournés à la planche à dessin.

La persévérance, le dynamisme et un travail d'équipe fantastique nous ont aidés à surmonter les défis auxquels nous étions confrontés.

Une planification minutieuse a également fait des merveilles; Compte tenu de notre capacité, nous avons établi très tôt que la décomposition de la migration réelle en trois étapes (ou jours) fonctionnerait mieux.

Semaine précédant le jour J

• Démarrez la réplication Postgres de DigitalOcean vers les instances RDS.
• Passez en revue notre future infrastructure de production AWS.
• Configuration des secrets (AWS Parameter Store).
• Assurez-vous que les pipelines CI/CD sont prêts à être déployés sur nos nouveaux clusters Kubernetes.

La veille du jour J

• Préparez notre infrastructure d'enregistrement de webhooks temporaires AWS (la perte d'événements lors de notre migration n'était pas une option).

  
  

• Déplacez certaines données à l'avance (par exemple, DigitalOcean Spaces vers S3).

  
  

• Mettez à jour tous les secrets du magasin de paramètres sur les valeurs de production.

  
  

• Préparez les modifications DNS.

  
  

• Définissez tous les déploiements Kubernetes sur zéro pod pour empêcher les services d'accéder aux données de production pendant la migration.

Jour J : appuie sur l'interrupteur

• Redirigez tous les webhooks vers l'enregistreur temporaire AWS.

  
  

• Arrêtez tous les services sur DigitalOcean.

  
  

• Attendez que la réplication Postgres rattrape les dernières mises à jour.

  
  

• Comparez les données DigitalOcean et RDS Postgres (pour garantir l'intégrité et le rattrapage de la réplication).

  
  

• Supprimez l'abonnement de RDS à Postgres exécuté dans DigitalOcean.

  
  

• Créez des répliques en lecture RDS.

  
  

• Mettez à jour nos secrets de magasin de paramètres avec de nouveaux points de terminaison et secrets RDS.

  
  

• Déployez sur Kubernetes et redémarrez PgBouncer pour charger de nouvelles configurations.

  
  

• Basculez les enregistrements DNS pour app.chartmogul.com vers AWS.

  
  

À ce stade, nous exécutions notre charge de travail de production sur la toute nouvelle infrastructure ! Nous avons terminé le tout en 10 heures (nous avions initialement estimé 8 heures – pas trop mal).

Défis avec AWS

Le plus gros problème concernait le service DMS (service géré AWS pour déplacer les bases de données vers RDS).

Ce n'était pas aussi facile à utiliser qu'annoncé. Dans notre cas avec Postgres, cela n'a pas été utile. Finalement, nous avons développé une méthode personnalisée de transfert de données vers AWS.

Nous avons également réalisé qu'il était compliqué de déplacer des bases de données sans temps d'arrêt vers AWS avec la prise en charge de webhook. Nous avons développé une approche personnalisée pour prendre en charge cette configuration.

Plus d'informations sur ces approches personnalisées dans les prochains articles.

Futurs articles de la série

Ne manquez pas les prochains articles documentant notre parcours de migration de DigitalOcean vers AWS. Nous aborderons des sujets tels que :

• Pourquoi nous avons choisi Kubernetes pour propulser ChartMogul.
• Comment nous avons migré PostgreSQL vers RDS.
• Comment nous avons migré notre application Rails vers Kubernetes.
• Comment nous configurons un tunnel IPSEC vers AWS VPC.