Choisir la plateforme de calcul AWS pour votre charge de travail en termes de coût n'est pas une tâche facile. J'ai fait le calcul pour l'un des projets sur lesquels je travaille et j'ai décidé de partager mes découvertes. Dans cet article, je ferai une comparaison de très haut niveau et simplifiée pour décrire une façon de faire la comparaison.

N'étant pas un expert dans l'utilisation de toutes les options de calcul, je vous encourage à utiliser la section des commentaires pour corriger mes hypothèses erronées ou suggérer des améliorations et des idées à intégrer dans l'effort de comparaison.

Paramétrage de la configuration

À l' aide d' AWS Pricing Calculator , nous pouvons comparer le coût mensuel des services de configurations à peu près équivalentes en puissance de calcul. J'ai déjà trouvé que c'était une tâche délicate à faire. Chaque service a son propre type de configuration à choisir, ayant des spécifications différentes non seulement pour les vCPU et la mémoire, mais aussi pour les limitations de la bande passante du réseau, ayant des restrictions pour utiliser les GPU ou les volumes EBS, etc.

Pour garder les choses simples, comparons les services avec les exigences juste pour avoir 1 vCPU disponible et environ 2 Go de mémoire. Pour Lambda, vCPU évolue avec la taille de mémoire configurable. Lambda obtient 1 vCPU pour 1,769 Go de mémoire , ce sera donc notre choix pour Lambda. Fargate a configurable à la fois le nombre de vCPU et la taille de la mémoire, nous pouvons donc choisir exactement 1 vCPU et 2 Go de mémoire disponibles. Pour EC2, pour une valeur aussi faible de vCPU et de mémoire dans la génération actuelle des types d'instances EC2, notre seule option est d'opter pour la famille T qui a des performances extensibles. Cela apporte un autre niveau de complexité car le prix de l'instance est basé sur une utilisation inférieure ou égale aux performances de référence du processeur, et des frais supplémentaires se produisent lorsque la consommation dépasse la référence. Cependant, dans les types d'instance de la génération précédente , le type d'instance m1.small répond assez bien aux exigences avec 1 vCPU et 1,7 Go de mémoire, nous l'utiliserons donc plutôt que le type d'instance de la famille T. De plus, les options suivantes n'ont pas été prises en compte dans la comparaison par souci de simplicité :

• Processeurs à architecture ARM
• Système d'exploitation non Linux
• Instances ponctuelles et tâches Fargate ponctuelles
• Transfert et stockage des données
• Instances réservées et plans d'économies de calcul

Intuitivement, EC2 devrait être le service le moins cher, suivi de Fargate et Lambda. Le raisonnement est que chaque service suivant nécessite moins d'administration d'infrastructure que le précédent, laissant les tâches de gestion d'infrastructure à AWS. Le graphique suivant montre le prix mensuel de chaque service en fonction d'un pourcentage d'utilisation du temps.

Le prix EC2 est en effet le plus bas, suivi d'assez près par Fargate, tandis que le prix Lambda est environ le double de Fargate. La tarification EC2 pourrait être encore réduite en utilisant le type d'instance extensible de la famille T, en fonction des besoins réels de votre charge de travail.

Facteurs de facturation et de démarrage

Comme nous l'avons vu ci-dessus, le coût d'exécution de Lambda est assez élevé par rapport à Fargate et EC2. Examinons maintenant les facteurs qui peuvent expliquer pourquoi nous pouvons toujours choisir Lambda pour l'informatique malgré son prix plus élevé.

La première chose à considérer est l'intervalle de facturation des services. EC2 est facturé à la seconde, avec une durée minimale de 60 secondes. La facturation commence lorsque l'instance est lancée et s'arrête lorsque l'instance est résiliée ou arrêtée. Fargate est facturé à la seconde, ainsi qu'avec une durée minimale de 60 secondes. La facturation commence lorsque l'image est extraite et s'arrête lorsque la tâche se termine. Lambda, quant à elle, est facturée à la milliseconde sans seuil minimum. La facturation commence lorsque votre code d'initialisation ou de gestionnaire commence à s'exécuter et s'arrête lorsque votre code revient ou se termine autrement.

C'est l'une des raisons pour lesquelles Lambda est un bon choix pour les charges de travail exécutées peu fréquemment et de courte durée.

Deuxièmement, la création d'une nouvelle instance EC2 prend environ une minute ou plus, comme le démarrage d'une nouvelle tâche Fargate. En comparaison, la création d'une nouvelle instance Lambda prend généralement quelques centaines de millisecondes pour les runtimes avec des langages interprétés et jusqu'à quelques secondes pour les runtimes avec des langages compilés.

En fonction de votre charge de travail, il se peut que vous ne puissiez pas attendre une minute pour démarrer une instance EC2 ou une tâche Fargate, et que vous ayez donc besoin de maintenir l'exécution de l'instance ou de la tâche. Ce n'est pas le cas pour Lambda, car vous attendez généralement quelques secondes pour démarrer une nouvelle instance. Vous pouvez également garder l'instance Lambda au chaud pour le petit prix en lui envoyant un ping toutes les quelques minutes par événement CloudWatch.

Pour souligner les deux facteurs décrits ci-dessus, nous pouvons maintenant comparer la facturation des services pour un traitement de type gestionnaire d'API Web, où nous voulons n'avoir aucun délai de démarrage et être prêts à servir le trafic à tout moment.

L'instance EC2 et la tâche Fargate doivent être utilisées à 100 % du temps pour ne pas souffrir de problèmes de démarrage. La facturation Lambda, quant à elle, dépend de l'heure réelle à laquelle votre code de gestionnaire s'exécute pour acheminer le trafic vers l'API Web. Ainsi, l'utilisation de Lambda est préférable jusqu'à ce que Lambda soit utilisé environ 40 à 50 % du temps, malgré son prix plus élevé pour la même puissance de calcul. Cela rend Lambda adapté aux tâches de traitement rapides, par exemple, les tâches d'E/S telles que la lecture de données à partir de DynamoDB, etc.

Exemple du monde réel

Nous utilisons la fonction Lambda sur l'un de nos projets pour gérer les demandes d'API. Il a une configuration de mémoire de 2 Go principalement pour minimiser les délais de démarrage à froid, sinon, il pourrait avoir une configuration inférieure. Il utilise une bibliothèque .NET qui a plus de 4 Mo, donc les différences de démarrage à froid entre par exemple 512 Mo de mémoire et 2 Go sont perceptibles.

Le trafic vers Lambda a augmenté régulièrement au cours des derniers mois, et nous voulons savoir s'il est temps d'envisager une migration vers un autre service.

Selon les métriques d'utilisation quotidiennes, la fonction est invoquée en moyenne environ 250 000 fois par jour, soit 2,89 requêtes par seconde. La durée d'exécution moyenne est d'environ 250 ms. 2,89 fois 250 est environ 723. Cela signifie que la fonction est utilisée environ 70 % du temps.

Des métriques d'intervalle d'une minute plus granulaires montrent que les modèles d'appel sont hérissés, mais en général, la charge est gérée par un peu moins de 10 instances simultanées de la fonction.

Les métriques collectées indiquent que nous avons dépassé le seuil où la facturation Lambda était optimale. Potentiellement, pour gérer le trafic avec la même puissance de calcul et avoir une marge de croissance, nous pourrions utiliser par exemple 2 tâches Fargate multi-AZ, chacune ayant 0,5 vCPU et 1 Go de mémoire. Sur la base des graphiques ci-dessus, cela réduirait les coûts de facturation mensuels de 53,50 $ à 36,04 $. Nous pourrions tenter de réduire davantage les coûts en utilisant des instances EC2 extensibles de taille appropriée et en y hébergeant le conteneur ou l'application. Ceci n'est bien sûr qu'une idée théorique approximative qui nécessiterait une vérification sur l'application réelle.

En guise de conclusion, je voudrais mentionner que les coûts de facturation bruts doivent être étendus en tenant compte de la complexité et des coûts de gestion de l'infrastructure. Pour des scénarios spécifiques, cela peut signifier que même si, par exemple, les coûts de facturation EC2 peuvent être inférieurs de quelques pour cent à ceux de Fargate ou Lambda, la différence ne compense pas la complexité supplémentaire de la solution.

Nous sommes ACTUM Digital et cet article a été écrit par Milan Gatyas , responsable technique .NET de la division Apollo. N'hésitez pas à nous contacter.