Le Blog Amazon Web Services
Utiliser la réservation de capacité en optimisant les coûts et l’impact environnemental
Une bonne pratique pour gagner en résilience est de déployer vos applications sur plusieurs zones de disponibilité d’une région AWS, en séparant les composants qui peuvent l’être ou en s’assurant de votre capacité à conserver le service disponible en cas de perte d’un ou de plusieurs composants.
Toutefois, certaines applications nécessitent des ressources importantes et peuvent exiger que les composants soient concentrés sur un seul serveur. Ces applications ne peuvent donc pas, par design, profiter d’une architecture « multi-az » (zones de disponibilités multiples) et sont déployées dans une même zone de disponibilité.
En cas de défaillance majeure sur la zone de disponibilité où est déployé l’environnement de production, nos clients souhaitent garantir la disponibilité de la capacité de calcul Amazon EC2 dans une autre zone de disponibilité pour activer le plan de continuité d’activité et sécuriser leurs processus métier.
Afin de garantir la capacité de ressources de calcul EC2 dans une zone de disponibilité d’une région AWS, notamment pour les environnements de production, nos clients disposent de deux fonctionnalités. D’un coté les réservations d’instance par zone de disponibilité et de l’autre la réservation de capacité à la demande, une solution flexible qui s’articule pleinement avec l’usage des Savings Plans, EC2 ou Compute. Ces deux fonctionnalités ont une portée limitée à la zone de disponibilité définie.
Une question récurrente de nos clients est : “Comment puis-je avoir la meilleure efficience économique et limiter mon empreinte carbone tout en ayant la certitude d’avoir la capacité nécessaire lors de l’activation de mon plan de continuité ?”
Une approche commune est de déployer un environnement de non-production; souvent la préproduction, dont le dimensionnement est identique à la production, dans une seconde zone de disponibilité et de réserver la capacité nécessaire à son fonctionnement.
En cas de défaillance de la zone de disponibilité hébergeant l’environnement de production, nous pourrons arrêter l’environnement de non-production et profiter de sa capacité réservée pour démarrer la production. À noter que les Réservations de Capacité peuvent être partagées entre différents comptes AWS ou à travers la même AWS Organizations. Ainsi, il n’est pas nécessaire de faire résider les instances de production et les instances de non-production dans le même compte AWS. Suivant ce lien vous trouverez plus d’information sur le partage de la capacité réservée : https://docs.thinkwithwp.com/fr_fr/AWSEC2/latest/UserGuide/capacity-reservation-sharing.html
Nous proposons une architecture de Disaster Recovery aux coûts optimisés qui permettra de profiter de la réservation de capacité dans deux zones de disponibilités (la première pour la production, la seconde pour un environnement non-prod comme la Pré-production) pour surmonter la défaillance éventuelle d’une zone de disponibilité. Cette architecture correspond au “Pilot Light” que nous décrivons plus précisément dans le livre blanc correspondant.
Cette architecture permet de répondre à trois enjeux soulignés dans les piliers du Well-Architected Framework. Elle permet d’optimiser les coûts, de limiter l’empreinte carbone et d’optimiser la résilience en densifiant l’usage des infrastructures et limiter le gaspillage de ressources réservées mais non-utilisées.
Quelques exemples d’architectures Mono-AZ qui peuvent profiter de cette implémentation : SAP, Oracle sur EC2, ou toute application limitant le nombre d’instances pour des raisons d’optimisation des licences.
Implémentation
- Créer une réservation de capacité à la demande dans la zone où la production sera lancée :
- Instance Type – Type d’instance à lancer dans la capacité réservée,
- Instance Platform – Le système d’exploitation de l’instance à lancer dans la capacité réservée,
- Availability Zone – La zone de disponibilité où l’instance sera lancée,
- Instance Count – Le nombre de fois que la capacité sera réservée. 2 pour avoir la capacité pour lancer 2 instances du même type, 3 pour 3 instances.
Cette commande retourne un json contenant le CapacityReservationId pour la production semblable à
cr-05e49c438fd186e71
Dans la console AWS :
Cliquer sur Create Capacity Reservation
La réservation de capacité à la demande permet aux utilisateurs AWS de définir une plage d’utilisation où cette capacité sera réservée, par exemple pour garantir l’exécution de calculs intensifs en batch (clôture comptable…). Dans notre cas nous souhaitons contrôler manuellement la fin de cette réservation et cibler quelle instance l’utilise (Instance Eligibility: Targeted)
Monitoring de l’usage de la réservation de capacité
La fonctionnalité de Réservation de Capacité à la Demande permet de choisir une date à laquelle la réservation est arrêtée. Cela est intéressant lors de besoins ponctuels, et dont la fin de traitement est prédictible, mais pour lesquels il est nécessaire de garantir la disponibilité de calcul (Batch, HPC).
Dans notre cas, nous ne définissons pas de date de fin pour la réservation de capacité. Il convient alors de monitorer l’usage de la réservation pour s’assurer de son usage complet et éviter des coûts ne correspondant pas à l’usage réel de celle-ci.
Le monitoring de l’usage de la Réservation de la Capacité à la Demande se fait à partir des Métriques Cloudwatch, en utilisant la métrique InstanceUtilization de l’espace de nom AWS/EC2CapacityReservations (https://docs.thinkwithwp.com/AWSEC2/latest/UserGuide/capacity-reservation-cw-metrics.html).
Il est alors possible de déclencher une alarme lorsque le seuil de cette métrique est inférieur à 100. Cette alarme peut alors envoyer une notification SNS (https://docs.thinkwithwp.com/fr_fr/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html).
- Créer une réservation de capacité à la demande dans la zone où la non-production sera lancé :
Cette commande retourne un json contenant le CapacityReservationId pour la non-production semblable à
cr-0ae49148abd30e4fc - Lancer l’instance de production dans la capacité réservée en production :
- Image Id – Id de l’image AMI à lancer
- Count – Le nombre d’instances à lancer
- Instance Type – Type d’instance à lancer dans la capacité réservée
- Subnet Id – Id du subnet où l’instance sera lancée
- Capacity Reservation Id – L’Id de la capacité réservée
Cette commande retourne l’id de l’instance lancée.
Dans la Console AWS, lors de la définition de l’instance EC2, on peut alors procéder à la configuration suivante :
- Lancer l’instance de non-production et lui affecter la capacité réservée de non-production :
Reprise d’activité
En cas d’exécution du plan de reprise d’activité :
- Arrêter l’instance de non-production, ce qui libère la capacité réservée de non-production dans la zone de disponibilité eu-west-3b
- Lancer l’instance de production à partir de l’AMI et lui affecter la capacité réservée de non-production :
Après la reprise d’activité
Après l’exécution du plan de reprise d’activité nous pouvons recréer l’instance de production et lui affecter la réservation de capacité de production, nous procédons de la même façon avec l’instance de non-production pour rétablir la situation nominale.
Conclusion
Cet article propose d’utiliser la Réservation de Capacité à la Demande pour optimiser vos coûts et l’impact environnemental de vos infrastructures de production tout en améliorant leur résilience. La réservation de capacité à la demande est flexible et réversible à chaque instant en fonction de l’évolution de vos environnements et vos besoins réels de capacité. Entièrement automatisable via la CLI AWS, le SDK AWS ou AWS CloudFormation vous pouvez dès maintenant actualiser les runbooks de vos différentes applications.
Article rédigé par Alexis Dagues, Senior Solutions Architect, Juan Diaz, Iadh Allani, Solutions Architect, Laurent Busecké, Senior Technical Account Manager.