Le Blog Amazon Web Services
Approche théorique de l’optimisation des coûts des types de lancements d’Amazon ECS : AWS Fargate vs Amazon EC2
Nos clients nous demandent souvent quelles sont les meilleures pratiques lorsque l’on utilise Amazon Elastic Container Service (Amazon ECS), en particulier autour du pilier optimisation des coûts du Well Architected Framework. Dans ce cadre, choisir entre les deux types de lancements, Amazon EC2 et AWS Fargate, peut être un facteur différenciant. Avec une réduction des prix allant jusqu’à 50% avec le type de lancement Fargate en 2019 et l’introduction des Saving Plans et de Spot pour Fargate, vous pouvez faire des économies substantielles. Ces considérations à l’esprit, cela peut être important de comprendre les modèles de rapport coût-efficacité pour ces deux types de lancements.
Cet article de blog explore les deux types de lancements disponibles pour Amazon ECS et compare le coût de l’exécution d’une flotte de conteneurs sur ECS en fonction des prix d’EC2 ou Fargate disponibles sur cette page. Notez que les tâches Fargate peuvent aussi être orchestrées avec Amazon EKS et la majorité des éléments abordés dans cet article (en anglais) peut être appliquée avec Amazon EKS. Cependant, par simplicité, ce blog couvre uniquement les options de déploiement et la nomenclature d’Amazon ECS. Il est aussi important de noter que, dans cet article, nous faisons des comparaisons uniquement sur la base des coûts financiers. Les coûts opérationnels, bien que non inclus ici, sont un facteur important et doivent être inclus dans une approche globale des coûts. Vous pouvez vous référer à cet article (en anglais) pour des considérations spécifiques de quelques-uns des aspects opérationnels. Bien que le blog indiqué couvre EKS, les mêmes principes peuvent être appliqués à ECS.
Qu’appelons nous les types de lancements d’Amazon ECS ?
Amazon ECS est un orchestrateur de conteneurs utilisé pour provisionner et gérer des clusters de conteneurs. Il permet aussi un déploiement rapide et de passer à l’échelle les tâches de travail conteneurisées sans avoir à configurer, gérer, et mettre à l’échelle vos propres outils de gestion de conteneurs.
ECS supporte deux types de lancements : EC2 et Fargate. Les clusters de conteneurs peuvent être configurés en utilisant soit l’un soit un mix des deux, avec une variation des options de facturation pour les deux types. Avec le type lancement EC2, les clusters sont construits comme une flotte d’Amazon Elastic Compute Cloud instances (EC2). Cela fournit un contrôle plus grand sur la personnalisation de vos environnements. Cependant, si vous bénéficiez de la possibilité de configurer votre infrastructure pour correspondre à vos besoins (comme choisir des instances optimisées en termes de réseaux ou de GPU), vous êtes aussi responsable de toute la partie opérationnelle, comme la sélection d’instances, les configurations réseaux et de sécurité de ces instances ainsi que leurs mise à jour.
Avec le type de lancement Fargate, vous pouvez vous concentrer sur le développement et la maintenance de vos applications conteneurisées, en abstrayant les serveurs sous-jacents. Fargate supprime le besoin de provisionnement et de gestion des serveurs. Vous pouvez alors simplement spécifier les ressources par tâche, ce qui améliore aussi la sécurité à travers l’isolation native de vos applications. ECS communique avec Fargate pour lancer, exécuter et gérer les conteneurs pour vous.
Comparaison des coûts
Le coût pour le type de lancement basés sur EC2 est déterminé par la mémoire et la capacité de calcul provisionnées pour un type d’instance donné. Vous payez pour la totalité de l’instance indépendamment de votre utilisation par votre application. En comparaison, Fargate vous donne une alternative où le prix peut souvent être plus proche de vos besoins en termes de ressources. Les charges de travail Fargate sont facturées pour le CPU et la mémoire utilisés par tâche, AWS gère l’allocation de ces tâches avec une infrastructure sous-jacente. Jusqu’à un certain seuil, l’utilisation de Fargate est plus optimisée en termes de coût qu’un type de lancement basé sur EC2. Cependant, il y a un seuil à partir duquel gérer votre propre flotte d’EC2 est plus optimisé en termes de coût que si vous utilisiez Fargate. L’objectif de cet article est d’illustrer ces limites, mais gardez à l’esprit que vous n’êtes pas limité à un choix binaire, vous pouvez utiliser les deux simultanément via les Fournisseurs de capacité Amazon ECS.
Dans cet article, nous allons commencer avec une comparaison théorique entre le coût pour faire tourner une instance m5.8xlarge
et celui d’un cluster Fargate avec une équivalence en termes de capacité de calcul et de mémoire. L’instance de type instance à usage général m5.8xlarge
est un choix populaire pour faire tourner des conteneurs, mais notez que la conclusion de cet article peut être appliquée à de multiples types de charges de travail et types d’instances.
Comme souligné sur la page de détails de facturation sur Fargate, le type de lancement Fargate est basé sur la taille de la tâche. La quantité de vCPU et de mémoire qui peut être requise pour une définition de tâche, est limitée par les configurations supportées par Fargate. Voici les configurations supportées :
Notez ici que nous ne prenons pas en compte la sur-allocation pour le type de lancement EC2 et qu’une utilisation à 100% est possible. Cependant, en pratique, cela n’est pas réaliste et nécessiterait une stratégie de binpacking parfaite. Vous pouvez en apprendre plus sur la sur-allocation (article en anglais) et les stratégies de placement des tâches (dont binpack fait parti).
Il est important de faire ces simplifications parce que d’autres facteurs peuvent influer sur le coût, comme la partie opérationnelle avec l’utilisation d’EC2. Par exemple, avec le type de lancement EC2, vous pouvez vouloir passer du temps et des efforts dans la gestion du passage à l’échelle de vos flottes et dans la configuration de vos machines (comme le type et la taille de l’instance, disques, etc). Dans ce scénario de charges variables sur vos flottes, parvenir à une configuration EC2 optimisée qui peut vous fournir des avantages en termes de coûts peut présenter des challenges qui ne sont pas pris en compte dans cette comparaison. En complément, avec le type de lancement EC2, le stockage via Amazon EBS n’est pas inclu dans les coûts, alors qu’avec Fargate il est inclu. Ces points devront être pris en considération dans une comparaison complète des coûts.
Cette section compare le coût théorique de faire tourner un cluster Fargate de 8 tâches au coût de faire tourner 8 tâches sur une seule instance EC2 avec les vCPUs et la capacité mémoire nécessaires. Cette instance sert de base de comparaison seulement. Une bonne pratique est de choisir plusieurs instances à travers plusieurs zones de disponibilité, vu que 4 instances m5.2xlarge auront le même coût qu’une seule instance m5.8xlarge et augmenteraient la redondance.
Instance | vCPU | Memoire |
m5.8xlarge | 32 | 128 |
Les 8 tâches qui tournent sur cette instance utiliseront uniquement une partie de la capacité en fonction de leur taille. Cet article fait référence à la portion des ressources de l’instance EC2 utilisée comme le ratio de réservation vCPU pour la partie calcul, et le ratio de réservation mémoire pour la partie mémoire avec les ratios suivants :
- Ratio de réservation mémoire = (nombre de tâches * mémoire par tâche) / (mémoire disponible sur l’instance EC2)
- Ratio de réservation vCPU = (nombre de tâches * vCPU par tâche) / (vCPU disponible sur l’instance EC2)
Nombre de tâches | vCPU par tâche | m5.8xlarge nombre de vCPU disponible | Ratio de réservation CPU | Mémoire par tâche (GB) | m5.8xlarge mémoire disponible | Ratio de réservation mémoire |
8 | 4 | 32 | 4*8/32=100% | 16 | 128 | 8*16/128=100% |
8 | 4 | 32 | 100% | 8 | 128 | 50% |
8 | 2 | 32 | 50% | 8 | 128 | 50% |
Sur chacun de graphes suivants, pour une configuration de réservation mémoire et vCPU, l’axe des ordonnées indique combien Fargate est plus optimisé en terme de coût qu’EC2, en pourcentage. Si celui-ci est au-dessus de 0, Fargate est plus optimal qu’EC2, et inversement. Les calculs ont été effectués sur un ensemble de valeurs de capacité de calcul pour les définitions de tâches Fargate (0.5, 1, 2 et 4 vCPU), avec leur correspondance en terme de mémoire.
Si nous prenons le premier histogramme à gauche comme exemple, Fargate obtient une réduction des coûts de 87% par rapport à son équivalent EC2 lorsque le ratio de réservation mémoire et vCPU de l’EC2 sont respectivement à 6.25% et 12.5%. À l’autre extrême, lorsque l’instance EC2 est complètement utilisée, le type de lancement EC2 permet une réduction des coûts de 20% par rapport à Fargate.
Comme on peut le voir, les avantages du type de lancement Fargate diminuent en même temps que l’utilisation des ressources de calculs et de mémoire approche de la capacité totale de l’instance EC2. Pour une application prédictible qui utilise un ratio plus élevé de CPU et de mémoire, EC2 peut être plus optimisé en terme de coût, comme il est possible de simplement choisir le type d’instance pour lequel vos tâches peuvent utiliser les ressources disponibles de façon optimale.
Pour des charges de travail dynamiques, pour lesquelles choisir la bonne taille et le passage à l’échelle de votre infrastructure EC2 introduisent des risques de sous ou sur-provisionner, la flexibilité en terme de coût et opérationnelle permet à Fargate d’être plus interessant.
Plus d’options de facturation
Pour des tâches soutenues et prédictibles, un lancement basé sur une instance EC2 hautement utilisée peut aider à l’optimisation des coûts, puisque le type d’instance qui sied le mieux aux besoins de performance et capacité de votre tâche peut être sélectionné à un coût inférieur à Fargate avec la même capacité. Cependant, nous avons uniquement regardé le modèle de facturation à la demande. Savings Plans peut permettre de réduire encore les coûts requis par la maintenance d’une application continue en utilisant à la fois EC2 et Fargate en s’engageant à un certain niveau d’utilisation de capacité de calcul sur des périodes allant de 1 à 3 ans. Nous allons explorer comment Savings Plans impacte les deux types de lancements. Notez que Savings Plans s’appliquent à la fois à EC2 et Fargate, les client n’ont donc pas besoins de souscrire à des Savings plans différents.
Ce diagramme montre la différence de réduction de prix entre EC2 et Fargate avec Savings plans en payant à l’avance pour une période de 3 ans. Lorsque l’utilisation des CPUs est plus élevée, le fait d’utiliser Saving Plans joue en la faveur d’EC2, et accentue la différence de prix avec Fargate. Nous pouvons donc tirer parti des réductions des coûts à travers Savings Plans en utilisant EC2 comme type de lancement lorsque nous pouvons prédire les ressources de calculs qui seront utilisées.
Pour les architectures qui sont conçues pour être résilientes aux interruptions, les instances Spot (article en anglais) peuvent être intéressantes pour permettre de réduire les coûts jusqu’à 70% par rapport aux alternatives à la demande. Pour en savoir un peu plus sur comment utiliser Spot pour vos tâches ECS. (article en anglais)
Ci-dessus, vous pouvez trouver les différences en terme de coûts pour faire tourner 8 tâches qui utilisent le mode spot pour les deux types de lancements. Nous avons pris les coûts de spot à un temps donné, mais notez que puisque la facturation Spot varie en fonction des variations de l’offre et de la demande, le résultat peut être différent dans chacun des cas. Lorsque vous comparez le mode Spot par rapport au mode à la demande, le seuil se déplace cette fois, en faveur de Fargate. Ainsi, dans les cas où les charges de travail sont tolérantes aux échecs, en tirant parti de Fargate Spot, vous obtiendrez une réduction des coûts plus grande. Cependant, plutôt que de choisir entre les types de lancements, il est préférable d’utiliser leur complémentarité et d’utiliser un mélange d’EC2 et de Fargate en fonction de vos besoins.
Comparaison des coûts
Ce graphique montre la corrélation des différences de prix entre les types de lancements Fargate et EC2 avec les différents modes de facturation, pour différents ratios de consommation de mémoire. Comme nous pouvons le voir, le pourcentage pour lequel Fargate est plus optimisé en terme de coûts est indépendant du modèle de facturation. Cependant des différences deviennent de plus en plus prononcées lorsque la consommation de mémoire et de CPU augmente. Cela signifie que quelque soit le modèle de facturation que nous choisissons, les même conclusions observées plus haut s’appliquent ici aussi : plus l’utilisation des capacités de l’instance est élevée, plus le type de lancement EC2 est optimisé en terme de coûts. Cependant, vous pouvez toujours bénéficier de plus amples réductions en choisissant le meilleur modèle de facturation pour votre application.
Conclusion
Dans cet article, nous avons illustré la comparaison théorique entre les deux modes de lancements, Fargate et EC2, pour vos charges de travail de conteneurs. Nous avons montrer les avantages de l’utilisation d’EC2 en maximisant l’utilisation de vos clusters, et les bénéfices de Fargate lorsque l’utilisation est en dessous d’un certain seuil. Cependant, pendant les phases de conception vous devez prendre en compte l’ensemble des tenants et aboutissants, entre les coûts et les autres piliers du Well-Architecture Framework ou d’autres prérequis techniques. Par exemple, avec le pilier de l’efficacité des performances, utiliser le type de lancement EC2 peut être un levier important, en venant tirer parti des différentes configurations d’instance possibles (type de disque, GPU). À l’inverse, vous pouvez obtenir des bénéfices plus grands en utilisant AWS Fargate et l’optimisation du pilier de l’excellence opérationnelle, sans prendre en compte les coûts bruts en considérations. En laissant les bonnes pratiques pour les conteneurs guider vos choix d’architectures, vous pouvez arriver à une décision prenant en compte les 5 piliers du Well-Architected Framework. Pour finir, le choix du type de lancement pour votre cluster de conteneurs est fortement dépendant de vos cas d’usage.
Article original rédigé en anglais par Julia Beck, Thomas Le Moullec, Kévin Polossat et Sam Sanders, adapté en français par Kévin Polossat.