TechTarget
Conseil

Comment choisir le bon type d’instances AWS

AWS propose un catalogue d’instances EC2 diversifiées pour cibler différentes configurations. Mais problème : les entreprises qui choisissent la mauvaise formule ne récolteront pas les gains escomptés.

Chris Moyer
par
Publié le: 29 sept. 2016

AWS propose (à l’écriture de cet article) 5 catégories d’instances EC2 : celles à usage général, les familles M, celles pour le calcul optimisé (la famille C), d’autres avec la mémoire optimisée, d’autres encore pour les applications GPU. Les deux dernières sont destinées à des applications gourmandes en stockage ou ayant des besoins en stockage dense. Dans chacune de ces familles, on retrouve aussi des instances types disponibles en plusieurs tailles.

A chaque fois qu’AWS met à jour un type d’instance, il continue de supporter l’ancienne et incrémente la version avec la nouvelle. Par exemple, la première instance EC2 était M1. Lorsqu’AWS a mis à jour cette instance avec un nouveau type d’hardware, l’instance M2 est arrivée au catalogue. A la mi-2016, ce type d’instance en est à la version M4.

La nature des workloads d’une entreprise déterminera donc le type d’instance le plus approprié. Pour la plupart des applications, la famille la plus générique est un bon point de départ. Après avoir placé une application sur cette instance et contrôlé la consommation CPU et mémoire dans CloudWatch, l’administrateur peut décider de passer à un autre type d’instance.

En général, avec de nouvelles workloads, il est préférable de choisir la dernière génération d’instances. Elles sont souvent moins chères et plus rapides. Par exemple, M1.large coûte 17,5 cents de l’heure et propose 4 Compute Units (ECU) et 7,5 Go de RAM ; la M4.large coûte 14 cents de l’heure, propose 6,5 ECU et 8 Go de RAM.

Lorsque vous naviguez dans les familles d’instances, vous pouvez seulement en modifier la taille. Avec les instances réservées, si un administrateur achète une instance M4.large et décide de passer à un niveau supérieur, il peut passer à M4.xlarge, mais il ne pourra pas accroître la puissance CPU en passant à C4.large.

La classification des instances

La famille T et les familles M sont des types d’instances génériques. La principale différence est que les T sont  plus réduites, mais offrent des capacités de débordement. Elles sont adaptées aux sites Web qui sont confrontés à des courbes de trafic non linéaires. Si celui-ci n’a une audience qu’occasionnelle, il n’a pas besoin de 100% du CPU en permanence. Ainsi une instance T est idéale, mais si son trafic est régulier, il est préférable d’opter pour une M.

Les instances optimisées pour le calcul (C) offrent plus de CPU et moins de RAM. Ainsi une instance C4.large propose 8 ECU, mais seulement 3,75 Go de RAM. Cela est adapté aux applications gourmandes en ressources CPU (les opérations intensives de calculs en sont un exemple). Si les CPU sont utilisés à 100%, mais que seulement 20% de la RAM est sollicitée, il peut qu’il soit préférable de passer à une instance optimisée pour le calcul.

Celles optimisées pour les applications en mémoire sont donc l’inverse des précédentes : des capacités de calculs plus réduites mais davantage de RAM. Cela convient donc bien aux applications telles que les systèmes de cache en mémoire ou encore les outils d’indexation. Apache SolR, par exemple, pourrait bien fonctionner sur ce type d’instance, car il peut charger d’avantage d’éléments de son index dans la RAM plutôt que d’avoir à créer une file d’attente des processus sur disque.

Les instances où le stockage est optimisé sont proposées selon 2 formules : I et D. Les instances de type I ont des disques SSD ; les D des disques durs traditionnels. Ces dernières sont adaptées pour les applications de bases de données qui privilégient le stockage, et non l’accès, aux données. Les SSD sont quant à eux beaucoup plus rapides, mais beaucoup plus chers que les disques durs classiques. Si la vitesse est une priorité, le type I est préférable. Autrement, choisissez le type D, moins couteux.

Le dernier type d’instance est la plus spécifique. Les instances optimisées pour les GPU sont adaptées aux calculs mathématiques intensifs et donc utilisé dans la recherche scientifique, comme le séquençage du génome. Ces instances sont couteuses – la moins chère des G2.xlarge coûte 65 cents à l’heure. Si toutefois vous optez pour une instance de type G, jetez un coup d’œil aux Spot Instances. Ce qui peut être intéressant si l’administrateur utilise le traitement en mode batch – ce qu’il pourra ainsi faire à moindre coût.

La taille des instances

Chaque application a besoin de ressources spécifiques. Il est donc important de choisir non seulement le bon type d’instance et aussi sa bonne taille. Sur ce dernier point, on peut démarrer petit et voir comment l’application se comporte. Partir sur une taille trop grande implique de dépenser plus d’argent que nécessaire. Démarrez avec 75% des ressources CPU, puis passez à l’échelle quand nécessaire.

Il faut également garder à l’esprit un point : il convient d’optimiser une application en fonction du nombre de CPU. M4.large propose 2 vCPU ; passer à une M4.xlarge permet d’avoir le rendement de 4 vCPU et davantage de RAM. Il n’est pas toujours adapté de passer à la taille supérieure, car deux instances de type large coûtent presque la même chose qu’une instance xlarge. La taille des instances permet certes de mieux dimensionner, mais complique le fait d’avoir à ajuster dynamiquement la taille. Il est facile de supprimer une instance ; beaucoup moins d’en changer la taille.

Les instances de grandes tailles conviennent aussi lorsqu’il s’agit d’une instance destinée au développement. Ces instances pour le « Build » sont idéales pour les développeurs car ceux-ci n’ont pas besoin d’utiliser de grosses machines. Une entreprise peut utiliser plusieurs instances C4.2xlarge uniquement pour cette opération. S’appuyer sur une instance de très grande taille pour ce scenario convient parfaitement car le développement est plus rapide et les administrateurs passent moins de temps à attendre la fin du process et de la compilation. Si utiliser une C4.2xlarge peut être couteuse, il est bien plus cher d’utiliser une instance plus réduite et de voir les développeurs patienter jusqu’à la fin du traitement. Lorsque vous choisissez une taille d’instances, il faut garder à l’esprit qu’au final, il est couteux de sélectionner une instance trop petite.

D’une façon générale, conservez de petites instances, mais n’hésitez pas les dimensionner quand cela est nécessaire. Il faut aussi se préparer à lancer occasionnellement des instances 2xlarge si les développeurs sont dans  l’urgence. Il est également intéressant de contrôler les instances avec CloudWatch et de repérer les goulets d’étranglement. Ce permet de choisir une catégorie d’instances plus adaptée et calée sur les usages  CPU et RAM.

 Traduit et adapté par la rédaction

 

Pour approfondir sur IaaS

Close