# Concevoir votre charge de travail de sorte qu’elle s’adapte aux changements de demande
Une **charge de travail** évolutive permet d’ajouter ou de supprimer automatiquement des ressources de manière à ce qu’elles correspondent à la demande actuelle à un moment donné.
**Topics**
+ [REL07-BP01 Utiliser l’automatisation lors de l’obtention des ressources ou de leur mise à l’échelle](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 Obtenir des ressources après la détection d’un problème sur une charge de travail](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 Obtenir des ressources après avoir réalisé qu’un plus grand nombre de ressources est nécessaire pour une charge de travail](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 Testez votre charge de travail](rel_adapt_to_changes_load_tested_adapt.md)
# REL07-BP01 Utiliser l’automatisation lors de l’obtention des ressources ou de leur mise à l’échelle
La définition programmatique, le provisionnement et la gestion de votre infrastructure et de vos ressources constituent la pierre angulaire de la fiabilité dans le cloud. L’automatisation vous aide à rationaliser le provisionnement des ressources, à faciliter des déploiements cohérents et sécurisés et à mettre à l’échelle les ressources sur l’ensemble de votre infrastructure.
**Résultat escompté** : vous gérez votre infrastructure en tant que code (IaC). Vous définissez et gérez votre code d’infrastructure dans des systèmes de contrôle de version (VCS). Vous déléguez le provisionnement des ressources AWS à des mécanismes automatisés et vous tirez parti de services gérés tels qu’Application Load Balancer (ALB), Network Load Balancer (NLB) et des groupes Auto Scaling. Vous provisionnez vos ressources à l’aide de pipelines d’intégration continue et livraison continue (CI/CD) afin que les modifications du code déclenchent automatiquement des mises à jour des ressources, y compris des mises à jour de vos configurations Auto Scaling.
**Anti-modèles courants :**
+ Vous déployez des ressources manuellement via la ligne de commande ou dans la AWS Management Console (processus également appelé *ClickOps*).
+ Vous associez étroitement vos ressources et composants d’application et vous créez ainsi des architectures rigides.
+ Vous mettez en œuvre des politiques de mise à l’échelle rigides qui ne s’adaptent pas à l’évolution des exigences commerciales, des modèles de trafic ou des nouveaux types de ressources.
+ Vous estimez manuellement la capacité pour répondre de façon anticipée à la demande.
**Avantages liés au respect de cette bonne pratique** : l’infrastructure en tant que code (IaC) permet de définir programmatiquement l’infrastructure. Vous pouvez ainsi gérer les modifications d’infrastructure en suivant le même cycle de développement logiciel que pour des modifications d’application, ce qui favorise la cohérence et la reproductibilité et réduit le risque de tâches manuelles susceptibles d’engendrer des erreurs. Vous pouvez rationaliser davantage le processus de provisionnement et de mise à jour des ressources en implémentant l’infrastructure en tant que code avec des pipelines de livraison automatisés. Vous pouvez déployer des mises à jour d’infrastructure de manière fiable et efficace sans nécessiter d’intervention manuelle. Cette agilité est particulièrement importante lorsque vous mettez à l’échelle les ressources pour répondre à des demandes fluctuantes.
Vous pouvez obtenir une mise à l’échelle dynamique et automatisée des ressources en conjonction avec l’infrastructure en tant que code et les pipelines de livraison. En surveillant les métriques clés et en appliquant des politiques de mise à l’échelle prédéfinies, Auto Scaling peut automatiquement provisionner ou déprovisionner les ressources selon les besoins, ce qui améliore les performances et la rentabilité. Cela réduit le risque d’erreurs manuelles ou de retards en réponse aux modifications des exigences en matière d’application ou de charge de travail.
La combinaison de l’infrastructure en tant que code, des pipelines de livraison automatisés et d’Auto Scaling aide les organisations à provisionner, mettre à jour et mettre à l’échelle leurs environnements en toute confiance. Cette automatisation est essentielle pour maintenir une infrastructure cloud réactive, résiliente et gérée efficacement.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Pour configurer l’automatisation avec des pipelines CI/CD et une infrastructure en tant que code (IaC) pour votre architecture AWS, choisissez un système de contrôle de version tel que Git pour stocker vos modèles et votre configuration IaC. Ces modèles peuvent être écrits à l’aide d’outils tels qu’[AWS CloudFormation](https://aws.amazon.com/cloudformation/). Pour commencer, définissez les composants de votre infrastructure (tels que les VPC AWS, les groupes Amazon EC2 Auto Scaling et les bases de données Amazon RDS) dans ces modèles.
Ensuite, intégrez ces modèles d’infrastructure en tant que code à un pipeline CI/CD pour automatiser le processus de déploiement. [AWS CodePipeline](https://aws.amazon.com/codepipeline/) fournit une solution AWS native transparente, ou vous pouvez utiliser d’autres solutions CI/CD tierces. Créez un pipeline qui s’active lorsque des modifications surviennent dans votre référentiel de contrôle de version. Configurez le pipeline de manière à inclure des étapes qui vérifient et valident vos modèles d’infrastructure en tant que code, déploient l’infrastructure dans un environnement intermédiaire, exécutent des tests automatisés et déploient finalement la solution en production. Incorporez des étapes d’approbation si nécessaire pour garder le contrôle sur les modifications. Ce pipeline automatisé accélère le déploiement, mais favorise également la cohérence et la fiabilité entre les environnements.
Configurez la mise à l’échelle automatique de ressources telles que les instances Amazon EC2, les tâches Amazon ECS et les réplicas de base de données dans votre infrastructure en tant que code afin d’assurer l’augmentation horizontale et la réduction horizontale automatiques selon les besoins. Cette approche améliore la disponibilité et les performances des applications et optimise les coûts en ajustant dynamiquement les ressources en fonction de la demande. Pour obtenir la liste des ressources prises en charge, consultez [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) et [AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html).
### Étapes d’implémentation
1. Créez et utilisez un référentiel de code source pour stocker le code qui contrôle la configuration de votre infrastructure. Validez les modifications apportées à ce référentiel afin de refléter les modifications continues que vous souhaitez apporter.
1. Sélectionnez une solution d’infrastructure en tant que code, telle qu’AWS CloudFormation pour maintenir à jour votre infrastructure et détecter les incohérences (dérive) par rapport à l’état prévu.
1. Intégrez votre plateforme IaC à votre pipeline CI/CD pour automatiser les déploiements.
1. Déterminez et collectez les métriques appropriées pour la mise à l’échelle automatique des ressources.
1. Configurez la mise à l’échelle automatique des ressources à l’aide de politiques d’augmentation horizontale et de réduction horizontale pour vos composants de charge de travail. Envisagez d’utiliser une mise à l’échelle planifiée pour les modèles d’utilisation prévisibles.
1. Surveillez les déploiements pour détecter les défaillances et les régressions. Mettez en œuvre des mécanismes de restauration au sein de votre plateforme CI/CD pour annuler les modifications si nécessaire.
## Ressources
**Documents connexes :**
+ [AWS Auto Scaling: Fonctionnement des plans de dimensionnement](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: produits utilisables avec autoscaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Gestion automatique de la capacité de débit avec l’autoscaling de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Utiliser un équilibreur de charge avec un groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ [Qu’est-ce qu’AWS Global Accelerator ?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Qu’est-ce qu’Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [Qu’est-ce qu AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ [Qu’est-ce qu’Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected)
+ [Qu’est-ce qu’Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [Qu’est-ce qu’Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [Qu’est-ce qu’un équilibreur de charge Network Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [Qu’est-ce qu’un équilibreur de charge Application Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [Intégration de Jenkins avec AWS CodeBuild et AWS CodeDeploy](https://aws.amazon.com/blogs/devops/setting-up-a-ci-cd-pipeline-by-integrating-jenkins-with-aws-codebuild-and-aws-codedeploy/)
+ [Création d’un pipeline à quatre étapes avec AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-four-stage-pipeline.html)
**Vidéos connexes :**
+ [Back to Basics : Déployer votre code sur Amazon EC2](https://www.youtube.com/watch?v=f2wvEQ_sWS8)
+ [AWS Supports You \$1 Démarrer votre solution d’infrastructure en tant que code en utilisant les modèles AWS CloudFormation](https://www.youtube.com/watch?v=bgfx76jr7tA)
+ [Rationaliser votre processus de publication de logiciel en utilisant AWS CodePipeline](https://www.youtube.com/watch?v=zMa5gTLrzmQ)
+ [Surveiller les ressources AWS à l’aide des tableaux de bord Amazon CloudWatch](https://www.youtube.com/watch?v=I7EFLChc07M)
+ [Créer des tableaux de bord CloudWatch inter-comptes et inter-régions \$1 Amazon Web Services](https://www.youtube.com/watch?v=eIUZdaqColg)
# REL07-BP02 Obtenir des ressources après la détection d’un problème sur une charge de travail
Si la disponibilité est affectée, mettez à l’échelle les ressources de manière réactive si nécessaire, afin de restaurer la disponibilité de la charge de travail.
Vous devez commencer par configurer les surveillances de l’état et les critères de ces vérifications pour indiquer quand la disponibilité est affectée par le manque de ressources. Informez ensuite le personnel approprié qu’il doit mettre à l’échelle manuellement la ressource ou lancer l’automatisation pour procéder à une mise à l’échelle automatique.
La mise à l’échelle peut être ajustée manuellement en fonction de votre charge de travail. Par exemple, vous pouvez modifier le nombre d’instances EC2 dans un groupe Auto Scaling ou le débit d’une table DynamoDB via la AWS Management Console ou la AWS CLI. Cependant, l’automatisation doit être utilisée dans la mesure du possible (voir **Utiliser l’automatisation lors de l’obtention ou de la mise à l’échelle des ressources**).
**Résultat escompté :** les activités de mise à l’échelle (automatiquement ou manuellement) sont lancées pour rétablir la disponibilité en cas de détection d’une panne ou d’une dégradation de l’expérience client.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Mettez en œuvre l’observabilité et la surveillance de tous les composants de votre charge de travail, afin de surveiller l’expérience client et de détecter les défaillances. Définissez les procédures, manuelles ou automatisées, de mise à l’échelle des ressources requises. Pour plus d’informations, consultez [REL11-BP01 Surveiller tous les composants de la charge de travail afin de détecter les défaillances](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html).
### Étapes d’implémentation
+ Définissez les procédures, manuelles ou automatisées, de mise à l’échelle des ressources requises.
+ Les procédures de mise à l’échelle dépendent de la conception des différents composants de votre charge de travail.
+ Les procédures de mise à l’échelle varient également en fonction de la technologie sous-jacente utilisée.
+ Les composants qui utilisent AWS Auto Scaling peuvent utiliser des plans de mise à l’échelle pour configurer un ensemble d’instructions pour la mise à l’échelle de vos ressources. Si vous utilisez AWS CloudFormation ou que vous ajoutez des balises à des ressources AWS, vous pouvez configurer des plans de mise à l’échelle pour différents ensembles de ressources, par application. Auto Scaling fournit des recommandations pour les stratégies de mise à l’échelle personnalisées pour chaque ressource. Une fois que vous avez créé votre plan de mise à l’échelle, Auto Scaling combine les méthodes de mise à l’échelle dynamique et prédictive pour prendre en charge votre stratégie de mise à l’échelle. Pour plus de détails, consultez [Comment fonctionnent les plans de mise à l’échelle](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html).
+ Amazon EC2 Auto Scaling permet de vous assurer que vous disposez du bon nombre d’instances Amazon EC2 disponibles pour gérer la charge de l’application. Vous créez des ensembles d’instances EC2, appelés groupes Auto Scaling. Vous pouvez spécifier le nombre minimal et maximal d’instances dans chaque groupe Auto Scaling et Amazon EC2 Auto Scaling s’assure que votre groupe n’est jamais au-dessus ou en dessous de ces limites. Pour plus d’informations, consultez [Qu’est-ce qu’Amazon EC2 Auto Scaling ?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ L’autoscaling d’Amazon DynamoDB utilise le service d’autoscaling d’application pour ajuster de manière dynamique la capacité de débit approvisionné en votre nom, en réponse aux schémas de trafic réels. Cela permet à une table ou à un index secondaire global d’augmenter les capacités en lecture et écriture qui lui sont allouées afin de gérer les hausses soudaines de trafic sans limitation. Pour plus d’informations, voir [Gestion automatique de la capacité de débit avec l’autoscaling de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html).
## Ressources
**Bonnes pratiques associées :**
+ [ REL07-BP01 Utiliser l’automatisation lors de l’obtention des ressources ou de leur mise à l’échelle ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 Surveiller tous les composants de la charge de travail pour détecter les défaillances](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html)
**Documents connexes :**
+ [AWS Auto Scaling : Fonctionnement des plans de dimensionnement](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Gestion automatique de la capacité de débit avec l’autoscaling de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Qu’est-ce qu’Amazon EC2 Auto Scaling ?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP03 Obtenir des ressources après avoir réalisé qu’un plus grand nombre de ressources est nécessaire pour une charge de travail
L’une des fonctionnalités les plus précieuses du cloud computing est sa capacité à provisionner des ressources de manière dynamique.
Dans les environnements informatiques sur site traditionnels, vous devez identifier et provisionner une capacité suffisante à l’avance pour répondre à un pic de demande. Cela pose problème car cela coûte cher et présente des risques pour la disponibilité si vous sous-estimez la capacité maximale requise par la charge de travail.
Dans le cloud, vous n’avez pas à le faire. Au lieu de cela, vous pouvez provisionner comme il se doit des capacités de calcul, de base de données et d’autres ressources pour répondre à la demande actuelle et prévue. Des solutions automatisées telles qu’Amazon EC2 Auto Scaling et Application Auto Scaling peuvent mettre en ligne des ressources pour vous sur la base de métriques que vous spécifiez. Cela peut faciliter le processus de mise à l’échelle et le rendre prévisible, et cela peut rendre votre charge de travail nettement plus fiable en garantissant que vous disposez de suffisamment de ressources à tout moment.
**Résultat escompté** : vous configurez la mise à l’échelle automatique des ressources de calcul et autres pour répondre à la demande. Vous prévoyez une marge de manœuvre suffisante dans vos politiques de mise à l’échelle pour permettre de répondre à des pics de trafic pendant que des ressources supplémentaires sont mises en ligne.
**Anti-modèles courants :**
+ Vous provisionnez un nombre fixe de ressources évolutives.
+ Vous choisissez une métrique de mise à l’échelle qui ne correspond pas à la demande réelle.
+ Vous ne parvenez pas à prévoir une marge de manœuvre suffisante dans vos plans de mise à l’échelle pour faire face aux pics de demande.
+ Vos politiques de mise à l’échelle tardent trop à augmenter la capacité, ce qui entraîne l’épuisement de la capacité et une dégradation du service lors de la mise en ligne de ressources supplémentaires.
+ Vous ne parvenez pas à configurer correctement le nombre minimal et le nombre maximal de ressources, ce qui entraîne des échecs de mise à l’échelle.
**Avantages liés au respect de cette bonne pratique :** il est essentiel de disposer de suffisamment de ressources pour répondre à la demande actuelle afin de garantir une haute disponibilité de votre charge de travail et de respecter les objectifs de niveau de service (SLO) définis. La mise à l’échelle automatique vous permet de fournir la bonne quantité de ressources de calcul, de base de données et autres dont votre charge de travail a besoin afin de répondre à la demande actuelle et prévue. Vous n’avez pas besoin de déterminer la capacité maximale requise et d’allouer statiquement des ressources pour la fournir. Au lieu de cela, à mesure que la demande augmente, vous pouvez allouer davantage de ressources pour y répondre et, une fois que la demande est retombée, vous pouvez désactiver les ressources pour réduire les coûts.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Tout d’abord, déterminez si le composant de charge de travail est adapté à la mise à l’échelle automatique. Ces composants sont appelés *évolutifs horizontalement* car ils fournissent les mêmes ressources et se comportent de manière identique. Parmi les composants évolutifs horizontalement, citons les instances EC2 configurées de la même manière, les tâches [Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/) et les pods exécutés sur [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/). Ces ressources de calcul sont généralement situées derrière un équilibreur de charge et sont appelées *réplicas*.
Les autres ressources répliquées peuvent inclure des réplicas en lecture de base de données, des tables [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) et des clusters [Amazon ElastiCache](https://aws.amazon.com/elasticache/) (Redis OSS). Pour obtenir la liste complète des ressources prises en charge, consultez [Services AWS que vous pouvez utiliser avec Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/integrated-services-list.html).
Pour les architectures basées sur des conteneurs, il peut être nécessaire de procéder à une mise à l’échelle de deux manières différentes. Tout d’abord, vous devrez peut-être mettre à l’échelle les conteneurs qui fournissent des services évolutifs horizontalement. Ensuite, vous devrez peut-être mettre à l’échelle les ressources de calcul pour libérer de l’espace pour de nouveaux conteneurs. Il existe différents mécanismes de mise à l’échelle automatique pour chaque couche. Pour mettre à l’échelle les tâches ECS, vous pouvez utiliser [Application Auto Scaling](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html). Pour mettre à l’échelle les pods Kubernetes, vous pouvez utiliser [Horizontal Pod Autoscaler (HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) ou [Kubernetes Event-driven Autoscaler (KEDA)](https://keda.sh/). Pour mettre à l’échelle les ressources de calcul, vous pouvez utiliser les [fournisseurs de capacité](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html) pour ECS, ou pour Kubernetes, vous pouvez utiliser [Karpenter](https://karpenter.sh) ou [Cluster Autoscaler](https://kubernetes.io/docs/concepts/cluster-administration/cluster-autoscaling/).
Ensuite, sélectionnez de quelle façon vous voulez effectuer la mise à l’échelle automatique. Il existe trois options principales : la mise à l’échelle basée sur des métriques, la mise à l’échelle planifiée et la mise à l’échelle prédictive.
**Mise à l’échelle basée sur des métriques**
La mise à l’échelle basée sur des métriques provisionne les ressources en fonction de la valeur d’une ou de plusieurs *métriques de mise à l’échelle*. Une métrique de mise à l’échelle est une métrique qui correspond à la demande de votre charge de travail. Un bon moyen de déterminer les métriques de mise à l’échelle appropriées consiste à effectuer des tests de charge dans un environnement hors production. Pendant vos tests de charge, maintenez fixe le nombre de ressources évolutives et augmentez lentement la demande (par exemple, débit, simultanéité ou utilisateurs simulés). Recherchez ensuite des métriques qui augmentent (ou diminuent) à mesure que la demande augmente, et inversement diminuent (ou augmentent) lorsque la demande diminue. Les métriques de mise à l’échelle typiques incluent l’utilisation du processeur, la profondeur de la file d’attente de travail (telle qu’une file d’attente [Amazon SQS](https://aws.amazon.com/sqs/)), le nombre d’utilisateurs actifs et le débit du réseau.
**Note**
AWS a observé qu’avec la plupart des applications, l’utilisation de la mémoire augmente à mesure que l’application monte en intensité, puis atteint une valeur stable. Lorsque la demande diminue, l’utilisation de la mémoire reste généralement élevée au lieu de diminuer en parallèle. Étant donné que l’utilisation de la mémoire ne correspond pas à la demande dans les deux cas de figure (à savoir en augmentant ni en diminuant avec la demande), réfléchissez bien avant de sélectionner cette métrique pour la mise à l’échelle automatique.
La mise à l’échelle basée sur des métriques est une *opération latente*. Plusieurs minutes peuvent être nécessaires pour que les métriques d’utilisation se propagent aux mécanismes de mise à l’échelle automatique, et ces mécanismes attendent généralement un signal clair d’augmentation de la demande avant de réagir. Ensuite, à mesure que l’outil de mise à l’échelle automatique crée de nouvelles ressources, la mise en service complète de ces dernières peut prendre plus de temps. Pour cette raison, il est important de ne pas définir vos cibles de métriques de mise à l’échelle trop proches de l’utilisation totale (par exemple, 90 % d’utilisation du processeur). Cela risque d’épuiser la capacité de ressources existante avant qu’une capacité supplémentaire puisse être mise en ligne. Les cibles typiques d’utilisation des ressources peuvent varier entre 50 et 70 % pour une disponibilité optimale, en fonction des modèles de demande et du temps nécessaire pour provisionner des ressources supplémentaires.
**Mise à l’échelle planifiée**
La mise à l’échelle planifiée provisionne ou supprime des ressources en fonction du calendrier ou de l’heure de la journée. Elle est fréquemment utilisée pour les charges de travail dont la demande est prévisible, telles que les pics d’utilisation pendant les heures ouvrables de semaine ou lors de soldes. [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) et [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) prennent tous deux en charge la mise à l’échelle planifiée. La fonctionnalité [cron scaler](https://keda.sh/docs/latest/scalers/cron/) de KEDA prend en charge la mise à l’échelle planifiée des pods Kubernetes.
**Mise à l’échelle prédictive**
La mise à l’échelle prédictive utilise le machine learning pour mettre à l’échelle automatiquement les ressources en fonction de la demande anticipée. La mise à l’échelle prédictive analyse la valeur historique d’une métrique d’utilisation que vous fournissez et prédit en permanence sa valeur future. La valeur prédite est ensuite utilisée pour augmenter ou réduire verticalement la ressource. [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html) peut effectuer une mise à l’échelle prédictive.
### Étapes d’implémentation
1. Déterminez si le composant de charge de travail est adapté à la mise à l’échelle automatique.
1. Déterminez le type de mécanisme de mise à l’échelle le plus approprié pour la charge de travail : mise à l’échelle basée sur des métriques, mise à l’échelle planifiée ou mise à l’échelle prédictive.
1. Sélectionnez le mécanisme de mise à l’échelle automatique approprié pour le composant. Pour les instances Amazon EC2, utilisez Amazon EC2 Auto Scaling. Pour les autres services AWS, utilisez Application Auto Scaling. Pour les pods Kubernetes (tels que ceux exécutés dans un cluster Amazon EKS), pensez à Horizontal Pod Autoscaler (HPA) ou à Kubernetes Event-driven Autoscaling (KEDA). Pour les nœuds Kubernetes ou EKS, pensez à Karpenter et à Cluster Auto Scaler (CAS).
1. Pour une mise à l’échelle basée sur des métriques ou planifiée, effectuez des tests de charge afin de déterminer les métriques de mise à l’échelle et les valeurs cibles appropriées pour votre charge de travail. Pour une mise à l’échelle planifiée, déterminez le nombre de ressources nécessaires aux dates et heures que vous sélectionnez. Déterminez le nombre maximal de ressources nécessaires pour répondre aux pics de trafic attendus.
1. Configurez l’outil de mise à l’échelle en fonction des informations collectées ci-dessus. Pour plus d’informations, consultez la documentation du service de mise à l’échelle automatique. Vérifiez que les limites de mise à l’échelle maximale et minimale sont correctement configurées.
1. Vérifiez que la configuration de mise à l’échelle fonctionne comme prévu. Effectuez des tests de charge dans un environnement hors production, observez comment le système réagit et ajustez le cas échéant. Lorsque vous activez la mise à l’échelle automatique en production, configurez les alarmes appropriées pour être averti de tout comportement inattendu.
## Ressources
**Documents connexes :**
+ [Qu’est-ce qu’Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [Conseils prescriptifs AWS : tests de charge des applications](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/)
+ [AWS Marketplace: produits utilisables avec autoscaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Gestion automatique de la capacité de débit avec l’autoscaling de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Mise à l’échelle prédictive pour EC2 alimentée par le machine learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Mise à l’échelle planifiée pour Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [Telling Stories About Little’s Law](https://brooker.co.za/blog/2018/06/20/littles-law.html)
# REL07-BP04 Testez votre charge de travail
Adoptez une méthodologie de test de charge pour déterminer si la mise à l’échelle répond aux exigences de la charge de travail.
Il est important d’exécuter régulièrement des tests de charge. Les tests de charge doivent découvrir le point de rupture et tester les performances de votre charge de travail. AWS facilite la mise en place d'environnements de test temporaires qui modélisent l'échelle de votre charge de travail de production. Dans le Cloud, vous pouvez créer un environnement d’essai à l’échelle de la production et à la demande, exécuter les tests, puis désactiver les ressources. Puisque vous ne payez l’environnement de test que lorsqu’il s’exécute, vous pouvez simuler votre environnement réel pour une fraction du coût d’un test sur site.
Les tests de charge en production doivent également être intégrés aux tests de simulation de pannes, lors desquels le système de production est mis sous tension pendant les périodes où le client est moins utilisé et tout le personnel est disponible pour interpréter les résultats et résoudre les problèmes qui surviennent.
**Anti-modèles courants :**
+ Exécution de tests de charge sur des déploiements qui n’ont pas la même configuration que votre production.
+ Exécution d’un test de charge uniquement sur des éléments individuels de votre charge de travail, et non sur l’ensemble de la charge de travail.
+ Exécution de tests de charge avec un sous-ensemble de demandes et non un ensemble représentatif de demandes réelles.
+ Exécution de tests de charge avec un faible facteur de sécurité au-dessus de la charge prévue.
**Avantages du respect de cette bonne pratique :** vous savez quels composants de votre architecture échouent sous charge et vous pouvez identifier les métriques à surveiller qui indiquent suffisamment à temps que vous approchez de cette charge pour que vous résolviez le problème et empêchiez ainsi l’impact de cette défaillance.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
+ Exécutez des tests de charge pour identifier l’aspect de votre charge de travail qui indique que vous devez ajouter ou supprimer de la capacité. Les tests de charge doivent avoir un trafic représentatif similaire à ce que vous recevez en production. Augmentez la charge tout en surveillant les métriques que vous avez instrumentées pour déterminer quelle métrique indique quand vous devez ajouter ou supprimer des ressources.
+ [Test de charge distribué sur AWS : simulez des milliers d'utilisateurs connectés](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ Identifiez le mélange de demandes. Comme vous pouvez avoir divers mélanges de demandes, vous devez examiner les différentes périodes lors de l’identification de la combinaison de trafic.
+ Implémentez un pilote de charge. Vous pouvez utiliser un code personnalisé, un logiciel open source ou un logiciel commercial pour implémenter un pilote de charge.
+ Effectuez un test de charge initial avec une faible capacité. Vous constatez des effets immédiats en entraînant une charge moindre, éventuellement aussi petite qu’une instance ou un conteneur.
+ Effectuez un test de charge par rapport à une capacité plus importante. Étant donné que les effets seront différents sur une charge distribuée, vous devez procéder à des essais dans un environnement aussi proche que possible de celui du produit.
## Ressources
**Documents connexes :**
+ [Test de charge distribué sur AWS : simulez des milliers d'utilisateurs connectés](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Tests de charge des applications](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html)
**Vidéos connexes :**
+ [AWS Sommet ANZ 2023 : Accélérez en toute confiance grâce AWS aux tests de charge distribués](https://www.youtube.com/watch?v=4J6lVqa6Yh8)