Économie de la Virtualisation d'Applications sur AWS
CloudFoundry a lancé la version 2.0 de sa plate-forme en tant que service (PaaS) plus tôt cet été, annonçant une nouvelle architecture de la plate-forme fonctionnant sur l'infrastructure Amazon EC2. James Watter, chef de la production, du marketing et de l'écosystème à CloudFoundry, a récemment décrit comment CloudFoundry met à profit l'isolement des Linux Containers à l'intérieur des instances EC2 pour abaisser les coûts d'hébergement d'un facteur allant jusqu'à 10.
Watters commence par montrer comment les instances EC2 réservées permettent de réduire jusqu'à trois fois les coûts par rapport à l'utilisation d'instances à la demande pour l'hébergement d'applications. Les instances EC2 réservées entraînent un coût initial mais ont un prix horaire plus bas, ce qui se traduit par des économies pour des processus d'exécution longs. Mais Watters souligne en outre qu'il y a des économies supplémentaires à faire si vous pouvez entasser plus de besoins applicatifs dans des instances plus grandes et moins chères.
Les instances réservées coûtent presque 3x moins par Go. Bien que ce soit de notoriété publique, utiliser l'instance XL ayant la plus grande mémoire permet d'économiser presque autant, 2,5x/Go sans pré-acheter d'instance réservée.
En 2008, la version 2.6.24 du noyau Linux a introduit les groupes de contrôle, qui prennent en charge l'isolement de groupes de processus et permettent la virtualisation au niveau du système d'exploitation, comme les Linux Containers (LXC). Amazon EC2 est antérieur à cette fonctionnalité et par conséquent est limité au modèle de machine virtuelle qui fournit des instances à gros grains, comparé aux systèmes plus efficaces basés sur les conteneurs.
Watters se réfère à une étude de cas menée en 2012 sur les instances EC2 pour comprendre l'impact financier du modèle EC2 :
...une étude sur 250 entreprises utilisant 250 000 instances a révélé des taux d'utilisation de seulement 15 %. Les 200 000 instances moyennes/petites auraient un coût mensuel de plus de $18M - laissant de quoi économiser $11M pour l'utilisation mémoire. Pousser l'utilisation de la mémoire à 80% et la consolider avec des instances XL [Cluster Memory], les $18M dépensés mensuellement sont réduits à $2,7M.
Donc, la majeure partie de l'utilisation d'EC2 est inefficace et la façon de tirer le plus de puissance de calcul sur AWS est de déployer beaucoup d'applications sur des instances EC2 à grande mémoire.
Watters révèle comment Cloud Foundry utilise l'isolement de groupe de contrôle (Control Group) avec un package qu'ils ont développé, appelé Warden. Warden fournit une API pour gérer les conteneurs. L'objectif de Warden est similaire aux objectifs du projet LXC, mais contrairement aux LXC, Warden n'est pas explicitement lié à Linux. Warden s'exécute sur un deamon indépendant de l'OS et prend en charge les systèmes d'exploitation spécifiques via un back-end additionnel. La nouvelle architecture CloudFoundry est construite autour des conteneurs Warden :
En utilisant cette approche, les VMs à grande mémoire sont transformées en des centaines de conteneurs d'applications hautement économiques, étroitement regroupées sans contention de ressources. Cette architecture moderne élimine le fardeau de la tarification d'AWS sur les instances de petites applications.
Watters conclut son analyse en considérant comment EC2 pourrait être forcé de réagir à l'adoption à grande échelle de virtualisation à base de conteneurs :
Comme CloudFoundry se développe sur la communauté AWS, il sera intéressant de voir comment EC2 va réagir. Les instances petites et moyennes sont une vache à lait pour leur portefeuille et il y a peu de chances qu'ils l'abandonnent de sitôt.