Réduire le temps de démarrage d’EC2

• Il est possible de réduire le temps de démarrage d’une instance EC2 de 40 secondes à 5 secondes
• C’est particulièrement important lorsqu’une nouvelle instance EC2 est nécessaire pour traiter une tâche spécifique

Pourquoi le démarrage est long

• Lorsqu’une nouvelle instance EC2 est demandée, AWS effectue plusieurs opérations :
  • création du volume EBS racine à partir de l’AMI sélectionnée
  • attribution d’une adresse IP privée à l’instance
  • sélection d’un hôte pour l’instance
  • démarrage effectif de la machine
• Même après la mise sous tension du matériel, le chargeur d’amorçage, le noyau et les processus en espace utilisateur doivent encore démarrer.

Méthode de contournement du problème

• Exploiter un pool de calcul en attente afin de rediriger les requêtes de build vers des instances EC2 déjà en cours d’exécution.
• Cependant, ce n’est pas économiquement viable pour toutes les charges de travail.
• Dans le cas des runners GitHub Actions, chaque tâche est dirigée vers une instance EC2 dédiée.
• Maintenir 50 instances EC2 en ligne pour traiter 50 tâches parallèles n’est pas réaliste.

Des temps de démarrage plus rapides

• Pour certaines charges de travail, ne pas effectuer de travail inutile est toujours plus rapide.
• Chaque étape de la création de l’instance EC2, du démarrage et du lancement de l’application est optimisée de manière systématique.
• La méthode consiste à démarrer l’instance une fois, l’arrêter, puis la redémarrer lorsqu’elle est nécessaire.

Streaming du volume racine EBS

• La préparation du volume racine EBS a un impact important sur le temps de démarrage de l’instance EC2 et sur les performances de l’application.
• Lorsqu’un volume EBS est créé à partir d’une AMI, les blocs de données doivent être récupérés depuis S3 au moment de leur premier accès.
• AWS recommande de précharger tous les blocs de données.

Démarrer l’instance une seule fois

• Une instance basée sur EBS peut être arrêtée puis redémarrée.
• Une instance arrêtée ne conserve que sa configuration, et seuls les coûts du volume EBS racine sont facturés.
• En démarrant l’instance une fois pour exécuter les tâches d’initialisation puis en l’arrêtant, on crée un volume racine EBS « préchauffé ».

Warm pool d’Auto Scaling

• AWS fournit des warm pools pour l’Auto Scaling EC2.
• Cependant, les groupes Auto Scaling mettent du temps à réagir aux requêtes.
• Pour obtenir les meilleures performances, les appels API LaunchInstances et StartInstances sont utilisés afin de démarrer directement les instances EC2.

Redimensionnement de l’instance

• Le temps de démarrage est optimisé en changeant le type des instances préchauffées.
• Un type d’instance peu coûteux est utilisé pour les tâches d’initialisation, puis il est remplacé par un type d’instance plus performant lors de l’exécution réelle de la tâche.

Flux complet

• Les instances runner GitHub Actions suivent le flux suivant :
  • création sur une instance t3.large
  • attribution d’une adresse IP privée dans le VPC cible
  • démarrage unique du noyau et des processus en espace utilisateur
  • arrêt de l’instance
  • à l’arrivée d’une requête de tâche, mise à jour du type d’instance vers m7a puis démarrage
  • en l’absence de capacité disponible pour m7a, mise à jour vers un type de secours puis nouveau démarrage
• Avec ce flux, le temps de préparation d’une instance pour une tâche passe de 40 secondes à 5 secondes.

[GN⁺]

Commentaires Hacker News

Résumé

• Temps de démarrage : élément clé du succès de l’auto-scaling ; plus le temps de démarrage est court, plus la fenêtre de prédiction est réduite, ce qui améliore la précision des prévisions. Il peut être rationnel de préprovisionner des volumes EBS pour réduire les coûts.
• Optimisations d’Amazon : Amazon a mis en place des démarrages ultra-rapides avec des technologies comme Firecracker, et pourrait proposer des capacités similaires sur EC2.
• Configuration immuable : grâce à une configuration immuable/atomique, il est possible de partager des volumes EBS et d’optimiser avec une AMI de démarrage minimale.
• Mesure du temps de démarrage : le temps de démarrage des instances EC2 présente une distribution bimodale, autour de 15 à 20 secondes ou de 80 secondes. Il faut en identifier la cause.
• Actions GitHub : malgré l’optimisation du démarrage des runners GitHub Actions, le temps de distribution des tâches reste long et nécessite des optimisations.
• Comparaison avec AWS : comparaison des temps de démarrage entre AWS et d’autres fournisseurs cloud. Hetzner crée des instances en quelques secondes.
• Auto-scaler EC2 : mention des limites de l’auto-scaler EC2 et de la nécessité de l’améliorer. L’auto-scaler fourni par AWS est lent et restrictif.
• Pourquoi utiliser EBS : EBS sacrifie coût et performance au profit de la durabilité. En tant que volume réseau, il est lent. Une installation Linux minimale avec un stockage local rapide serait plus adaptée.
• Absence de prise en charge du Copy-On-Write dans EBS : EBS ne prend pas en charge le Copy-On-Write, et les snapshots sont stockés sur S3, ce qui retarde l’allocation des IOPS.
• Passage à du matériel on-premise : Depot pourrait migrer vers du matériel on-premise pour optimiser les performances et réduire les coûts. Démarrer directement les tâches CI des clients sur l’hyperviseur pourrait être une meilleure approche.