Conseils en matière de dimensionnement approprié
Cette section propose des conseils pour vous aider à dimensionner correctement vos instances EC2 et vos instances de bases de données RDS.
Un dimensionnement approprié grâce aux données de performances
Analysez les données de performances pour dimensionner correctement vos instances EC2. Identifiez les instances inactives et celles qui sont sous-utilisées. Les principales métriques à rechercher sont l'utilisation du processeur et celle de la mémoire. Identifiez les instances dont l'utilisation maximale du processeur et de la mémoire est inférieure à 40 % sur une période de quatre semaines. Il s'agit des instances qu'il faudra dimensionner correctement pour réduire les coûts.
Pour les instances optimisées pour le calcul, gardez à l'esprit les points suivants :
-
Concentrez-vous sur les données d'instance les plus récentes (les anciennes données peuvent ne pas être exploitables).
-
Concentrez-vous sur les instances qui ont été exécutées pendant au moins la moitié de la période qui vous intéresse.
-
Ignorez les familles d'instances à capacité extensible (instances de type T2), car ces familles sont conçues pour fonctionner avec de faibles pourcentages d'UC pendant de longues périodes.
Concernant les instances optimisées pour le stockage (instances de type I2 et D2), dont la principale caractéristique est le volume élevé d'opérations d'entrée/sortie par seconde, concentrez-vous sur les opérations d'entrée/sortie par seconde pour voir si les instances sont surallouées. Gardez à l'esprit les points suivants relativement aux instances optimisées pour le stockage :
-
Les instances de taille différente ont différents taux d'opérations d'entrée/sortie par seconde. Il est donc préférable d'adapter vos rapports à chaque type d'instance. Commencez par le type d'instance optimisé pour le stockage le plus couramment utilisé.
-
Les valeurs NetworkIn et NetworkOut maximales sont mesurées en octets par minute. Utilisez la formule suivante pour convertir ces métriques en mégabits par seconde :
NetworkIn maximale (ou NetworkOut) x 8 (octets en bits) /1024/1024/ 60 = nombre de Mbits/s
-
Notez l'évolution des métriques de pourcentage d'UC et d'entrées/sorties pendant la journée et s'il y a des pics qui doivent être pris en compte.
Effectuez un dimensionnement approprié par rapport à la mémoire si vous constatez que l'utilisation maximale de la mémoire sur une période de quatre semaines est inférieure à 40 %. AWS fournit des exemples de scripts
Lors de l'analyse des données de performances pour les instances de bases de données Amazon RDS, concentrez-vous sur les métriques suivantes pour déterminer si l'utilisation réelle est inférieure à la capacité de l'instance :
-
Utilisation moyenne du processeur
-
Utilisation maximale du processeur
-
Mémoire vive minimale disponible
-
Nombre moyen d'octets lus sur le disque par seconde
-
Nombre moyen d'octets écrits sur le disque par seconde
Dimensionnement approprié en fonction des besoins d'utilisation
Lorsque vous surveillez les performances actuelles, identifiez les besoins et les modèles d'utilisation suivants afin de tirer parti des options de dimensionnement adaptées :
-
Stabilité : la charge reste relativement constante au fil du temps et vous pouvez prévoir avec précision la charge de calcul probable. Pour ce modèle d'utilisation, vous pouvez envisager des instances réservées, ce qui peut permettre de réaliser des économies importantes.
-
Variable, mais prévisible : la charge change, mais selon un calendrier prévisible. AWS Auto Scaling
convient parfaitement aux applications dont les modèles de demande sont stables avec une variabilité d'utilisation horaire, quotidienne ou hebdomadaire. Vous pouvez utiliser cette fonction pour augmenter ou diminuer la capacité d'Amazon EC2 en cas de pics de trafic ou de fluctuations prévisibles du trafic. -
Développement/test/production : les environnements de développement, de test et de production sont généralement utilisés seulement pendant les heures ouvrables et peuvent être désactivés le soir, le week-end et les jours fériés. (Fiez-vous aux étiquettes pour identifier les instances de développement/test/production.)
-
Temporaire : pour les charges de travail temporaires dont les heures de début sont flexibles et peuvent être interrompues, vous pouvez envisager une instance Spot Amazon EC2 plutôt que d'utiliser une instance à la demande.
Dimensionnement approprié en désactivant les instances inactives
Le moyen le plus simple de réduire les coûts opérationnels consiste à désactiver les instances qui ne sont plus utilisées. Si certaines instances sont inactives depuis plus de deux semaines, vous pouvez les arrêter ou même la mettre hors service en toute sécurité. Avant de mettre hors service une instance inactive depuis deux semaines ou moins, tenez compte des points suivants :
-
À qui appartient l'instance ?
-
Quel est l'impact potentiel de la mise hors service de l'instance ?
-
Dans quelle mesure sera-t-il difficile de recréer l'instance si vous devez la restaurer ?
L'arrêt d'une instance EC2 laisse tous les volumes EBS attachés opérationnels. Ces volumes continueront à vous être facturés jusqu'à ce que vous les supprimiez. Si vous avez à nouveau besoin de l'instance, vous pouvez facilement la réactiver. En revanche, la mise hors service d'une instance supprime automatiquement les volumes EBS attachés et nécessite un effort de réallocation si l'instance est à nouveau nécessaire. Si vous décidez de supprimer un volume EBS, pensez à stocker un instantané de ce volume afin qu'il puisse être restauré ultérieurement si nécessaire.
Un autre moyen simple de réduire les coûts consiste à arrêter les instances utilisées dans le développement et la production pendant les heures où ces instances ne sont pas utilisées, puis à les redémarrer lorsque leur capacité est requise. Par exemple, pour une semaine de travail de 50 heures, vous pouvez économiser 70 % en arrêtant automatiquement les instances de développement/test/production en dehors des heures ouvrables. De nombreux outils sont disponibles pour automatiser la planification, notamment Amazon EC2 Scheduler
Dimensionnement approprié en sélectionnant la bonne famille d'instances
Vous pouvez dimensionner correctement une instance en migrant vers un modèle différent au sein de la même famille d'instances ou en migrant vers une autre famille d'instances. Lors de la migration au sein de la même famille d'instances, vous devez uniquement prendre en compte le processeur virtuel, la mémoire, le débit réseau et le stockage éphémère. En règle générale, pour les instances EC2, si votre utilisation maximale du processeur et de la mémoire est inférieure à 40 % sur une période de quatre semaines, vous pouvez réduire les instances de moitié en toute sécurité. Par exemple, si vous utilisez une instance EC2 c4.8xlarge, vous pouvez passer à une instance EC2 c4.4xlarge, ce qui permettrait d'économiser 190 $ tous les 10 jours.
Lors de la migration vers une autre famille d'instances, assurez-vous que le type d'instance actuel et le nouveau type sont compatibles, en termes de type de virtualisation, de réseau et de plateforme :
-
Type de virtualisation : les instances doivent avoir le même type de virtualisation d'AMI Linux (AMI de virtualisation paravirtuelle par rapport à HVM) et de plateforme (EC2-Classic par rapport à EC2-VPC). Pour en savoir plus, consultez la page Types de virtualisation AMI Linux.
-
Réseau : certaines instances ne sont pas prises en charge dans EC2-Classic et doivent être lancées dans un cloud privé virtuel (VPC). Pour en savoir plus, consultez la section Types d'instances disponibles uniquement dans un VPC.
-
Plateforme : si votre type d'instance actuel prend en charge les AMI 32 bits, veillez à sélectionner un nouveau type d'instance qui les prend également en charge (ce n'est pas le cas de tous les types d'instances EC2). Pour vérifier la plateforme de votre instance, accédez à l'écran Instances dans la console Amazon EC2 et choisissez Afficher/Masquer les colonnes, Architecture.
Lors du redimensionnement d'une instance EC2, l'instance redimensionnée a généralement le même nombre de volumes de stockage d'instances que celui spécifié lors du lancement de l'instance initiale. Vous ne pouvez pas attacher de volumes de stockage d'instances à une instance après l'avoir lancée. Par conséquent, si vous souhaitez ajouter des volumes de stockage d'instances, vous devez migrer vers un nouveau type d'instance contenant le plus grand nombre de volumes.
Dimensionnement approprié de vos instances de bases de données
Vous pouvez mettre à l'échelle vos instances de bases de données en ajustant la mémoire ou la puissance de calcul à la hausse ou à la baisse en fonction de l'évolution des performances et des capacités. Voici quelques points à prendre en compte lors de la mise à l'échelle d'une instance de base de données :
-
Le stockage et le type d'instance sont découplés. Lorsque vous augmentez ou diminuez la taille de votre instance de base de données, votre taille de stockage reste la même et n'est pas affectée par la modification.
-
Vous pouvez modifier séparément votre instance de base de données Amazon RDS pour augmenter l'espace de stockage alloué ou améliorer les performances en changeant le type de stockage (tel que SSD polyvalent en SSD à IOPS provisionnés).
-
Avant de procéder à la mise à l'échelle, veillez à disposer de la licence appropriée pour les moteurs commerciaux (SQL Server, Oracle), en particulier si vous apportez votre propre licence (BYOL).
-
Déterminez à quel moment vous souhaitez appliquer la modification. Vous avez la possibilité de l'appliquer immédiatement ou pendant le créneau de maintenance spécifié pour l'instance.
