AWS

Opérations

Décoder un authorization message :

aws sts decode-authorization-message --encoded-message "<encoded message>"

Architecture

Cloudwatch Agent

  • Créer un rôle embarquant une policy permettant d’accéder à l’API de Cloudwatch
  • Le rôle sera ensuite utilisé dans un instance_profile qui sera attaché à la VM
  • Dans la VM, on installera le paquet amazon-cloudwatch-agent
  • Lancement de l’agent :
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/etc/cloudwatch_agent.json -s

Fichiers de configuration :

Inspiration : cloudposse/terraform-aws-cloudwatch-agent

Autoscaling : utiliser des favors de type « burst » (t2/t3)

Note : ce texte a été écrit dans le cas de l’autoscaling d’une CI/CD où on souhaitait utiliser la flavor t2.medium.

Sur AWS, la consommation renvoyée par la métrique CPUUtilization ne renvoi pas toujours l’utilisation réelle du CPU de la machine. Les instances de type t2/t3 fonctionnent en mode burst, elles sont prévues pour absorber des pics d’utilisation temporaire mais elles ne peuvent pas être utilisées à 100 % en continue.

Les VM avec ce type de flavor vont recevoir un certain nombre de crédit CPU chaque heure déterminé en fonction du type de flavor. Quand le processeur est utilisé, il vient consommer des crédits jusqu’à arriver à 0. Quand la machine n’a plus de crédit, le CPU de la machine est bridé à 20 % d’utilisation pour la flavor t2.medium (la limitation varie en fonction de la taille de la flavor).

Le bridage est reporté différemment en fonction de la métrique regardée :

  • Sur htop (en activant la feature) ou sur Grafana, on peut observer la métrique “CPU steal” qui permet de voir que l’hyperviseur garde une partie du processeur pour lui-même.
  • La métrique CPUUtilization renvoyée par AWS ne montrera pas ce phénomène et se contentera de montrer un usage de 20% de la machine. La métrique nous laisse penser que le CPU a encore de la capacité de libre alors qu’en fait, le reste du CPU est “volé” par l’hyperviseur.

Les cycles CPU volés par l’hyperviseur ne peuvent pas être utilisé par les jobs de CI, on se retrouve donc à avoir des machines très limitées lorsqu’elles n’ont plus de crédit. Ce phénomène est particulièrement problématique dans le cadre de l’autoscaling car on s’appuie sur la métrique CPUUtilization pour gérer le nombre d’instances.

La métrique CPUCreditBalance permet de surveiller le nombre de crédits restant pour une machine virtuelle. Il faut éviter que ce nombre tombe à zéro.

Il existe plusieurs solutions à ce problème :

  • Si la CI/CD reçoit une charge de travail intensive, peut-être que le mieux est d’utiliser une autre flavor que les T2/T3 car une machine sans crédit CPU va faire exploser le temps d’exécution des jobs de CI/CD. Exemple de flavors : c5.large ou m5.large (non disponible en medium) (prix)
  • Continuer à utiliser les instances t2.medium mais en les autorisant à utiliser le CPU même après avoir dépasser leurs crédit en passant en mode unlimited. Si la machine est utilisée au delà de sa limite, Amazon va facturer l’utilisation du CPU. L’avantage serait que le client paierait ce qu’il consomme et il ne serait pas impacté par le choix d’une petite flavor pour commencer (surcoût de “$0.05 per vCPU-Hour”). Il faut cependant prendre en compte le fait que la flavor t2.medium pourrait coûter plus cher qu’une flavor fixe (calcul des coûts à faire)

Je ne pense pas que ce soit une bonne idée d’ignorer le problème car cela pourrait nous coûter plus cher de démarrer 5 instances qui fonctionnent à 20% de leur capacité plutôt que d’avoir une seule machine capable de fonctionner à 100 %.

Impacts sur l’US et l’autoscaling :

  • Utiliser une t2.medium en mode normal en conjonction avec l’autoscaling peut poser problème dans le cas où la CI est très utilisée (le seul restant à déterminer).
  • Prendre la métrique CPU renvoyée par linux pour régler l’autoscaling nous ferait entrer dans le cas de figure évoqué précédemment : on ajoute des machines car on voit que tous les CPU sont à 100 % mais en réalité on va se retrouver avec beaucoup de machines bridées.
  • Si on utilise la métrique fournie par AWS (CPUUtilization), on ne sera pas capable de faire fonctionner l’autoscaling si on utilise pas une flavor fixe ou une flavor burstable en mode unlimited.

Note sur la métrique CPUUtilization : il me semble que l’utilisation CPU remonté n’inclus pas les I/O wait non plus (à vérifier).

On retrouve également ce conseil dans les Best practices sur les autoscaling groups:

Check which instance type your Auto Scaling group uses. Amazon EC2 instances with burstable performance, which are T3 and T2 instances, are designed to provide a baseline level of CPU performance with the ability to burst to a higher level when required by your workload. Depending on the target utilization specified by the scaling plan, you could run the risk of exceeding the baseline and then running out of CPU credits, which limits performance. For more information, see CPU credits and baseline performance for burstable performance instances. To configure these instances as unlimited, see Using an Auto Scaling group to launch a burstable performance instance as Unlimited in the Amazon EC2 User Guide for Linux Instances.

Sources :

Liens