Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Considérations relatives à la conception

Cette section décrit les décisions de conception importantes et les options de configuration pour la solution Distributed Load Testing on AWS, y compris les applications prises en charge, les types de tests, les options de planification et les considérations relatives au déploiement.

Applications prises en charge

Cette solution permet de tester des applications basées sur le cloud et des applications sur site tant que vous disposez d'une connectivité réseau entre votre compte AWS et votre application. La solution prend en charge les API qui utilisent les protocoles HTTP ou HTTPS.

Types de tests

Les tests de charge distribués sur AWS prennent en charge plusieurs types de tests : tests de points de terminaison HTTP simples, JMeter, k6 et Locust. Chaque type de test, à l'exception du simple point de terminaison HTTP, peut être exécuté dans l'un ou l'autre mode de forme de trafic. Pour plus d'informations, reportez-vous à la section Modes de forme du trafic.

Tests de points de terminaison HTTP simples

La console Web fournit une interface de configuration de point de terminaison HTTP qui vous permet de tester n'importe quel point de terminaison HTTP ou HTTPS sans écrire de scripts personnalisés. Vous définissez l'URL du point de terminaison, sélectionnez la méthode HTTP (GET, POST, PUT, DELETE, etc.) dans un menu déroulant et ajoutez éventuellement des en-têtes de demande et des charges utiles de corps de requête personnalisés. Cette configuration vous permet de tester les API avec des jetons d'autorisation personnalisés, des types de contenu ou tout autre en-tête HTTP et corps de requête requis par votre application.

Lorsque vous configurez un point de terminaison HTTP, la solution convertit votre configuration en un plan de test qui est exécuté par le binaire Apache JMeter fourni via le framework Taurus. Les tests HTTP Endpoint simples n'acceptent pas d'archive de test, ils ne peuvent donc pas remplacer le binaire ou les plugins JMeter fournis. Si vous devez exécuter des tests de point de terminaison HTTP avec un JMeter corrigé, utilisez plutôt le type de test JMeter. Pour des raisons de sécurité, reportez-vous à Apache JMeter.

Étant donné que la solution génère le plan de test pour ce type de test, les tests Simple HTTP Endpoint s'exécutent uniquement en mode Standard. Le mode natif nécessite que vous téléchargiez un script. Pour plus d'informations, reportez-vous à la section Modes de forme du trafic.

Tests JMeter

Lorsque vous créez un scénario de test à l'aide de la console Web, vous pouvez télécharger un script de test JMeter. La solution télécharge le script dans le compartiment S3 des scénarios. Lorsque les tâches Amazon ECS sont exécutées, elles téléchargent le script JMeter depuis S3 et exécutent le test.

Si vous avez des fichiers d'entrée JMeter, vous pouvez compresser les fichiers d'entrée avec le script JMeter. Vous pouvez choisir le fichier zip lorsque vous créez un scénario de test.

Si vous souhaitez inclure des plugins, tous les fichiers .jar inclus dans un sous-répertoire /plugins du fichier zip fourni seront copiés dans le répertoire des extensions JMeter et seront disponibles pour les tests de charge.

Si vous incluez des plugins JMeter, les fichiers .jar doivent être regroupés dans un sous-répertoire nommé /plugins à la racine du fichier zip. Par rapport à la racine du fichier zip, le chemin d'accès aux fichiers jar doit être. /plugins/BUNDLED_PLUGIN.bocal.

Pour plus d'informations sur l'utilisation des scripts JMeter, consultez le manuel de l'utilisateur de JMeter.

essais K6

La solution prend en charge les tests basés sur le framework k6. Vous pouvez télécharger le fichier de test k6 avec tous les fichiers d'entrée nécessaires dans un fichier d'archive. La console Web affiche un message d'accusé de réception de licence lorsque vous créez un nouveau test k6. Pour plus de détails sur la licence et la sécurité, reportez-vous à Grafana k6.

Tests acridiens

La solution prend en charge les tests basés sur le framework Locust. Vous pouvez télécharger le fichier de test Locust ainsi que tous les fichiers d'entrée nécessaires dans un fichier d'archive.

Dénomination des scripts de test

Lorsque vous chargez un seul .py fichier, la solution le stocke sous l'identifiant de test et y fait directement référence, de sorte que le fichier peut avoir n'importe quel nom. Lorsque vous chargez une .zip archive, la solution recherche dans l'archive un fichier nommélocustfile.py. Si l'archive contient un script Python sous un autre nom, le test échoue au démarrage du conteneur avec le messageNo test script (.py) in zip file.

Dépendances Python personnalisées

Le conteneur de test de charge inclut Locust et ses dépendances. Il n'inclut pas les packages Python tiers. Si votre script Locust importe un package qui n'est pas présent dans le conteneur, le test échoue avecModuleNotFoundError. Pour rendre des packages supplémentaires disponibles, incluez un requirements.txt fichier à la racine de votre .zip archive. Le conteneur installe les packages répertoriés requirements.txt avant le début du test.

Vous pouvez fournir des dépendances de deux manières différentes :

L'exemple suivant montre la mise en page de l'archive :

my-test.zip
├── locustfile.py         # Required — must use this name
├── requirements.txt      # Optional — packages to install
└── packages/             # Optional — wheels, for offline install only
    └── *.whl

Les deux requirements.txt et le packages sous-répertoire doivent se trouver à la racine de l'archive, à côté locustfile.py de. Omettez les deux si votre script importe uniquement des packages que le conteneur fournit déjà. Le packages sous-répertoire prend effet uniquement à côté d'un requirements.txt fichier ; seul, il est ignoré et aucun package n'est installé.

Préparation des roues pour le conteneur

Le conteneur de test de charge exécute Linux sur l'architecture x86_64 avec Python 3.11. Les Wheels compilés pour un système d'exploitation, une architecture ou une version de Python différents ne s'installent pas. Les packages écrits en Python pur sont distribués sous forme de roues indépendantes de la plate-forme et fonctionnent n'importe où, mais les packages contenant des extensions compilées nécessitent une roue conçue pour la plate-forme du conteneur. Comme le conteneur n'inclut pas de compilateur, il ne peut pas créer de distribution source au démarrage de la tâche.

Exécutez la commande suivante pour télécharger des roues compatibles avec la plate-forme du conteneur. Vous pouvez exécuter cette commande à partir de n'importe quel système d'exploitation, y compris macOS et Windows. Incluez ensuite le packages répertoire obtenu dans votre archive :

pip download -r requirements.txt \
  --dest packages \
  --platform manylinux2014_x86_64 \
  --python-version 3.11 \
  --only-binary=:all:

Les --python-version options --platform et ciblent le conteneur et non la machine sur laquelle vous exécutez la commande. L'--only-binary=:all:option entraîne l'échec de la commande au lieu de revenir silencieusement à une distribution source que le conteneur ne peut pas créer. La manylinux2014 balise spécifie une roue compatible avec la glibc 2.17 et les versions ultérieures, qui inclut la version du conteneur.

Pour regrouper un package que vous gérez vous-même, créez une roue à partir du répertoire source de votre packagepip wheel . --wheel-dir packages, puis ajoutez-y le nom du packagerequirements.txt.

Modes de circulation

Chaque test est exécuté dans l'un des deux modes de circulation, Standard ou Natif. Le mode détermine trois choses : quel côté contrôle la charge, quelle image de conteneur les tâches Fargate utilisent et quels paramètres de charge la solution envoie au framework de test. Pour savoir comment choisir un mode lorsque vous créez un test, reportez-vous à la section Modes de forme du trafic dans la section Utiliser la solution.

Mode standard

Les tâches Fargate utilisent l'image sur laquelle Taurus est installé. Taurus reçoit le nombre de tâches, la simultanéité, la montée en puissance et la durée d'attente de la solution. Il traduit ces valeurs dans les propres contrôles de charge du framework sous-jacent. Taurus a priorité sur la charge déclarée par votre script. Il réécrit ou ignore un bloc d'options k6, un groupe de threads Locust ou LoadTestShape JMeter. Les utilisateurs virtuels générés par une région sont le nombre de tâches multiplié par la simultanéité pour chaque tâche. Cette forme est la même pour tous les cadres. C'est ainsi que la solution exécutait tous les tests avant la version 4.3.0.

Mode natif

Les tâches Fargate utilisent l'image dédiée pour le framework du test, qui n'inclut pas Taurus. Au lieu d'écrire une configuration Taurus, la solution invoque directement le framework : jmeter -n -tk6 run, ou. locust --headless Il ne transmet aucun paramètre de charge. Votre script est la seule autorité sur le trafic qu'il génère.

Deux conséquences découlent de cette conception, qui influent toutes deux sur la façon dont vous dimensionnez un test :

Planification des tests

La solution propose trois options de synchronisation d'exécution pour exécuter des tests de charge :

Lorsque vous sélectionnez Exécuter une fois, vous spécifiez la durée d'exécution au format 24 heures et la date d'exécution à laquelle le test de charge doit commencer.

Lorsque vous sélectionnez Exécuter selon un calendrier, vous pouvez soit saisir manuellement une expression cron, soit sélectionner l'un des modèles cron courants (par exemple, toutes les heures, tous les jours à une heure précise, en semaine ou tous les mois). L'expression cron utilise un format de planification précis avec des champs pour les minutes, les heures, le jour du mois, le mois, le jour de la semaine et l'année. Vous devez également spécifier une date d'expiration, qui définit le moment où le test programmé doit cesser de fonctionner. Pour plus d'informations sur les règles de validation de la planification, consultez la section Contraintes de planification de ce guide.

Tests simultanés

Chaque fois qu'un test de charge est exécuté, la fonction AWS Lambda de l'exécution des tâches crée un tableau de CloudWatch bord Amazon nommé EcsLoadTesting-<testId>-<region> dans chaque région où le test est exécuté. Le CloudWatch tableau de bord affiche le résultat combiné de toutes les tâches exécutées dans le cluster Amazon ECS en temps réel : temps de réponse moyen, nombre d'utilisateurs simultanés, nombre de demandes réussies et nombre de demandes échouées. La solution regroupe chaque métrique à la seconde et met à jour le tableau de bord toutes les minutes.

Les exécutions suivantes du même scénario de test mettent à jour le même tableau de bord, de sorte que votre compte contienne un tableau de bord pour chaque scénario de test dans chaque région. Ces tableaux de bord restent dans votre compte une fois les tests terminés. Ils sont facturés mensuellement jusqu'à ce que vous les supprimiez. La solution supprime les tableaux de bord d'un scénario lorsque vous supprimez le scénario de test (par exemple, via la console Web). Les tableaux de bord ne sont pas supprimés lorsque vous supprimez les CloudFormation piles de la solution. Pour plus d'informations, reportez-vous à la section Coût et à la section Suppression manuelle des ressources conservées de ce guide.

Gestion des utilisateurs

Lors de la configuration initiale, vous fournissez un nom d'utilisateur et une adresse e-mail qu'Amazon Cognito utilise pour vous autoriser à accéder à la console Web de la solution. La console n'assure pas l'administration des utilisateurs. Pour ajouter des utilisateurs supplémentaires, vous devez utiliser la console Amazon Cognito. Pour plus d'informations, reportez-vous à la section Gestion des utilisateurs dans les groupes d'utilisateurs du manuel Amazon Cognito Developer Guide.

Pour migrer des utilisateurs existants vers des groupes d'utilisateurs Amazon Cognito, consultez le blog AWS Approches pour la migration des utilisateurs vers des groupes d'utilisateurs Amazon Cognito.

Fédération du fournisseur d'identité

Le pool d'utilisateurs Amazon Cognito de la solution prend en charge la fédération avec des fournisseurs d'identité externes (IdPs) à l'aide des protocoles SAML 2.0 ou OpenID Connect (OIDC). La fédération permet aux utilisateurs de se connecter à la console Web en utilisant leurs informations d'identification d'entreprise ou d'organisation existantes au lieu de leurs Cognito-native informations d'identification. Les utilisateurs fédérés reçoivent les mêmes autorisations d'accès que les utilisateurs créés directement dans le groupe d'utilisateurs Cognito.

La solution déploie déjà le groupe d'utilisateurs, le domaine, le client d'application et l'interface utilisateur hébergée de Cognito. Pour activer la fédération, il vous suffit d'enregistrer votre fournisseur d'identité et de l'activer sur le client d'application existant.

Si vous déployez l'intégration optionnelle du serveur MCP, les utilisateurs fédérés peuvent également accéder au serveur MCP à l'aide des mêmes informations d'identification du groupe d'utilisateurs Cognito.

Conditions préalables

Avant de configurer la fédération, vous devez disposer des éléments suivants :

Étape 1 : Configuration de votre fournisseur d'identité

Configurez votre fournisseur d'identité externe avec les valeurs suivantes afin qu'il puisse communiquer avec le pool d'utilisateurs Cognito de la solution.

Pour les fournisseurs d'identité SAML :

Pour les fournisseurs d'identité OIDC :

Pour plus d'informations sur les besoins de votre IdP, consultez les rubriques Ajouter des fournisseurs d'identité SAML à un groupe d'utilisateurs ou Ajouter des fournisseurs d'identité OIDC à un groupe d'utilisateurs dans le manuel Amazon Cognito Developer Guide.

Étape 2 : enregistrer le fournisseur d'identité dans Cognito

Ajoutez votre fournisseur d'identité externe au groupe d'utilisateurs Cognito existant de la solution à l'aide de la console Amazon Cognito.

Pour obtenir des instructions détaillées, reportez-vous à la section Ajout d'une connexion à un groupe d'utilisateurs via un tiers dans le guide du développeur Amazon Cognito.

Étape 3 : Configuration des mappages d'attributs

Configurez les mappages d'attributs entre les revendications de votre fournisseur d'identité et les attributs du groupe d'utilisateurs Cognito. Au minimum, associez la réclamation par e-mail de l'utilisateur auprès du fournisseur externe à l'emailattribut Cognito. Pensez également à les cartographier name ou nickname à demander à votre fournisseur d'identité de les fournir.

Pour obtenir des instructions, reportez-vous à la section Spécification des mappages d'attributs des fournisseurs d'identité pour votre groupe d'utilisateurs dans le manuel Amazon Cognito Developer Guide.

Étape 4 : activer le fournisseur d'identité sur le client de l'application

Dans la console Amazon Cognito, recherchez le client d'application créé par la solution et activez votre nouveau fournisseur d'identité dans les paramètres de l'interface utilisateur hébergée.

Pour obtenir des instructions, reportez-vous à la section Configuration d'un client d'application de groupe d'utilisateurs dans le guide du développeur Amazon Cognito.

Désactivation ou suppression de l'utilisateur Cognito par défaut

Après avoir configuré la fédération, vous souhaiterez peut-être désactiver ou supprimer l'utilisateur par défaut créé lors du déploiement de la pile. Ceci est facultatif : l'utilisateur par défaut continue de travailler parallèlement à la connexion fédérée.

Pour désactiver un utilisateur, accédez au groupe d'utilisateurs Cognito de la solution dans la console Amazon Cognito, sélectionnez l'onglet Utilisateurs, choisissez l'utilisateur, puis sélectionnez Désactiver l'accès utilisateur. Pour supprimer un utilisateur, vous devez d'abord le désactiver, puis choisir Supprimer l'utilisateur. La désactivation d'un utilisateur révoque ses jetons et l'empêche de se connecter tout en préservant le compte ; la suppression définitive le supprime.

Pour plus de détails, consultez la section Gestion et recherche de comptes utilisateurs dans le guide du développeur Amazon Cognito.

Déploiement régional

Cette solution utilise Amazon Cognito, qui n'est disponible que dans certaines régions AWS. Par conséquent, vous devez déployer cette solution dans une région où Amazon Cognito est disponible. Pour connaître la disponibilité des services la plus récente par région, consultez la liste des services régionaux AWS.