Diagnostiquer (et éviter) les 3 principaux problèmes AWS EC2

Il existe un nombre impressionnant d'entreprises qui construisent leurs applications principales autour des offres cloud d'Amazon Web Services, telles que leur Elastic Compute Cloud (EC2). En 2010, Amazon a annoncé un taux de croissance EC2 de 35%. Il a été utilisé pour tout, de la création d'un cluster de supercalcul à la demande pour la recherche pharmaceutique au renforcement du backend pour l'application de reconnaissance musicale Shazam.

EC2 est extrêmement utile pour les équipes informatiques d'entreprise qui cherchent à rassembler une puissance de calcul massive sans acheter d'infrastructure physique, et pour celles qui doivent se préparer à des pics réguliers de la demande des clients. Ceci étant dit, EC2 est un outil comme un autre. Il est susceptible d'être mal utilisé ou mal configuré, et si cela se produit, votre entreprise pourrait se retrouver sans évolutivité. Voici comment éviter les erreurs EC2 les plus courantes avant que votre application ne commence à planter.

1. Latence de stockage déroutante

Les volumes de stockage d'Amazon EC2 (appelés Elastic Block Storage ou EBS) sont disponibles en deux versions. Les volumes standard servent les données à peu près au même taux qu'un disque dur de bureau standard, mais les volumes provisionnés sont conçus pour servir les données beaucoup plus rapidement. Si vous avez besoin d'un débit allant jusqu'à 4 000 IOPS (opérations d'entrée/sortie par seconde), les volumes provisionnés peuvent l'obtenir pour vous, en supposant que vous franchissiez plusieurs étapes.

Par exemple, l'instance utilisée doit être compatible avec le nombre d'IOPS dont vous avez besoin. Vous devez définir la taille du bloc sur 16 Ko ou moins, et les blocs doivent avoir été accédés au moins une fois. Vos volumes ralentiront si une sauvegarde est sur le point d'être effectuée. Enfin, Amazon EC2 n'inclut apparemment pas d'outil qui vous fournira des données IOPS en temps réel à partir d'un volume donné (bien que cela puisse être calculé à l'aide d'applications de surveillance tierces).

Cette dernière restriction peut entraîner certaines difficultés. Il est possible que les événements suivants se produisent :

• Les IOPS augmentent à l'insu de l'administrateur jusqu'à ce qu'elles atteignent le seuil d'un volume,
• Les opérations commencent ensuite à faire la queue,
• L'ensemble de l'application est alors limité par l'EBS,
• L'application échoue complètement.

Résoudre ce problème signifie trouver d'autres moyens de suivre les IOPS. La métrique VolumeQueueLength suit le nombre de demandes d'E/S en attente. Si vous constatez que vos volumes EBS ralentissent et que vous trouvez un VolumeQueueLength associé élevé, cela peut indiquer un problème avec les IOPS.

2. Instances EC2 inactives

Amazon peut désormais facturer à la seconde l'utilisation d'une instance EC2. Pour certaines entreprises, par exemple celles qui ont besoin d'utiliser moins de deux minutes de capacité flexible à la fois, cela représente une bonne affaire. Pour d'autres cas, cela peut représenter un lent filet d'argent gaspillé. Les environnements de test restants, les applications sous-performantes et d'autres cas d'utilisation se prêtent à des instances EC2 sous-utilisées. Comment les traquez-vous ?

Les métriques sont un moyen de résoudre ce problème, mais elles constituent une cible mouvante. Différentes applications utilisent différentes quantités de CPU, par exemple, vous ne pouvez donc pas simplement regarder l'utilisation du CPU pour voir où se trouvent les moins performants. Vous devez éliminer les instances dans lesquelles toutes les métriques d'utilisation sont faibles, où « faible » signifie « inférieur à l'utilisation de base de toutes vos instances EC2 ». Les instances dont les métriques d'utilisation sont faibles dans l'ensemble peuvent être réduites ou consolidées.

3. Fuites de mémoire EC2

Il est possible que les instances EC2 manquent de mémoire. Comme certaines instances EC2 n'incluent pas de volumes d'échange, les applications associées ne pourront pas libérer de mémoire en même temps qu'elle est allouée. Comme cela se produit à des moments d'utilisation particulièrement intensive des applications, il est donc possible qu'EC2 se bloque alors qu'il subit une charge de travail maximale, ce qui va plus ou moins complètement à l'encontre de l'objectif initial d'acheter des instances EC2.

Comme c'est le cas avec les IOPS, il peut être difficile de voir sous le capot d'EC2 afin de déterminer quelles applications utilisent trop de mémoire. Bien qu'EC2 tue automatiquement les processus monopolisant la mémoire, il est préférable de ne pas avoir à tuer ces processus en premier lieu. Il est également possible d'ajouter plus d'instances EC2 afin de fonctionner comme un volume d'échange, ou comme un basculement en cas d'arrêt d'un processus vital. L'ajout de ces instances est cependant coûteux. Il existe un meilleur moyen.

Surveiller AWS EC2 avec AppNeta

Une chose est claire :les instances AWS EC2 ne donnent pas aux administrateurs de nombreux outils intégrés pour afficher les performances. La programmation intelligente, la planification du basculement et la surveillance manuelle des implémentations ne peuvent vous mener que très loin. AppNeta propose une solution de visibilité des performances pour AWS qui permet aux administrateurs de rechercher les erreurs de manière proactive.

Jetez un œil à l'intérieur du SDN d'Amazon (oui, c'est en fait possible) et comprenez les goulots d'étranglement et les ralentissements avec une clarté instantanée. Pour plus d'informations, essayez notre démo dès aujourd'hui.