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 et les options de configuration importantes pour la solution de test de charge distribué sur 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, à condition que vous disposiez 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 point de terminaison HTTP simples, JMeter, K6 et Locust.
Note
La solution distribue JMeter, K6 et Locust en tant que composants tiers sans modification. Pour les considérations relatives à la sécurité, les options d'application des correctifs et les informations de licence, reportez-vous aux frameworks de Third-party test.
Tests de point 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 requête et des charges utiles 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 considérations de sécurité, reportez-vous à Apache JMeter.
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 s'exécutent, elles téléchargent le script JMeter depuis S3 et exécutent le test.
Important
Bien que votre script JMeter puisse définir la simultanéité (utilisateurs virtuels), les taux de transaction (TPS), les temps de montée en puissance et d'autres paramètres de chargement, la solution remplacera ces configurations par les valeurs que vous spécifiez sur l'écran Traffic Shape lors de la création du test. La configuration Traffic Shape contrôle le nombre de tâches, la simultanéité (utilisateurs virtuels par tâche), la durée de montée en puissance et la durée de suspension pour l'exécution du 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 de JMeter et seront disponibles pour les tests de charge.
Note
Si vous incluez des fichiers d'entrée JMeter dans votre fichier de script JMeter, vous devez inclure le chemin relatif des fichiers d'entrée dans votre fichier de script JMeter. En outre, les fichiers d'entrée doivent se trouver dans le chemin relatif. Par exemple, lorsque vos fichiers d'entrée et votre fichier de script JMeter se trouvent dans le home/user répertoire/et que vous vous référez aux fichiers d'entrée dans le fichier de script JMeter, le chemin des fichiers d'entrée doit être. /FICHIERS_D'ENTRÉE. Si vous utilisez plutôt/home/user/INPUT_FILES, le test échouera car il ne pourra pas trouver les fichiers d'entrée.
Si vous incluez des plug-ins 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.jar.
Pour plus d'informations sur l'utilisation des scripts JMeter, reportez-vous au manuel de l'utilisateur de JMeter
Tests K6
La solution prend en charge les tests basés sur le framework K6. Vous pouvez télécharger le fichier de test K6 ainsi que 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 les détails de licence et de sécurité, reportez-vous à Grafana K6.
Important
Bien que votre script K6 puisse définir la simultanéité (utilisateurs virtuels), les étapes, les seuils et d'autres paramètres de charge, la solution remplacera ces configurations par les valeurs que vous spécifiez sur l'écran Traffic Shape lors de la création du test. La configuration Traffic Shape contrôle le nombre de tâches, la simultanéité (utilisateurs virtuels par tâche), la durée de montée en puissance et la durée de suspension pour l'exécution du test.
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.
Important
Bien que votre script Locust puisse définir la simultanéité (nombre d'utilisateurs), le taux d'apparition et d'autres paramètres de charge, la solution remplacera ces configurations par les valeurs que vous spécifiez sur l'écran Traffic Shape lors de la création du test. La configuration Traffic Shape contrôle le nombre de tâches, la simultanéité (utilisateurs virtuels par tâche), la durée de montée en puissance et la durée de suspension pour l'exécution du test.
Planification des tests
La solution propose trois options de synchronisation d'exécution pour exécuter des tests de charge :
-
Exécuter maintenant - Exécute le test de charge immédiatement après la création
-
Exécuter une fois : exécute le test à une date et à une heure spécifiques dans le futur
-
Exécuter selon un calendrier : créez des tests récurrents à l'aide d'expressions cron pour définir le calendrier
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 à s'exécuter.
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 planifié doit cesser de fonctionner. Pour plus d'informations sur le fonctionnement de la planification, reportez-vous à la section Workflow de planification des tests de ce guide.
Note
-
Durée des tests : tenez compte de la durée totale des tests lors de la planification. Par exemple, un test avec un temps de démarrage de 10 minutes et un temps d'attente de 40 minutes prendra environ 80 minutes.
-
Intervalle minimum : assurez-vous que l'intervalle entre les tests planifiés est supérieur à la durée estimée du test. Par exemple, si le test dure environ 80 minutes, programmez-le pour qu'il ne soit pas exécuté plus fréquemment que toutes les 3 heures.
-
Limite horaire : le système ne permet pas de planifier les tests avec une différence d'une heure seulement, même si la durée estimée du test est inférieure à une heure.
Tests simultanés
Cette solution crée un CloudWatch tableau de bord Amazon pour chaque test qui affiche le résultat combiné de toutes les tâches exécutées dans le cluster Amazon ECS en temps réel. Le CloudWatch tableau de bord indique le temps de réponse moyen, le nombre d'utilisateurs simultanés, le nombre de demandes réussies et le nombre de demandes ayant échoué. La solution agrège chaque métrique par seconde et met à jour le tableau de bord toutes les minutes.
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 donner accès à 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 la migration d'utilisateurs existants vers des groupes d'utilisateurs Amazon Cognito, consultez le blog AWS Approaches for 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 professionnelles ou organisationnelles 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 en utilisant les 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 :
-
Un fournisseur d'identité externe compatible avec SAML 2.0 ou OIDC
-
Accès administrateur pour configurer l'IdP externe (pour définir des URI de redirection ou des URL ACS)
-
L'ID du groupe d'utilisateurs Cognito de la solution (disponible dans les ressources de la CloudFormation pile ou dans la console Amazon Cognito)
-
Le préfixe de domaine Cognito de la solution (disponible dans les sorties de la CloudFormation pile ou dans la console Cognito sous Intégration des applications > Domaine)
Étape 1 : configurer votre fournisseur d'identité
Configurez votre fournisseur d'identité externe avec les valeurs suivantes afin qu'il puisse communiquer avec le groupe d'utilisateurs Cognito de la solution.
Pour les fournisseurs d'identité SAML :
-
ID de l'entité SP :
urn:amazon:cognito:sp:_<UserPoolId>_ -
URL ACS :
\https://<cognito-domain>.auth.<region>.amazoncognito.com/saml2/idpresponse
Pour les fournisseurs d'identité OIDC :
-
URI de redirection :
\https://<cognito-domain>.auth.<region>.amazoncognito.com/oauth2/idpresponse
Pour en savoir plus sur les besoins de votre IdP, reportez-vous à la section Ajout de fournisseurs d'identité SAML à un groupe d'utilisateurs ou Ajout de 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 Ajouter la connexion à un groupe d'utilisateurs via un tiers dans le manuel Amazon Cognito Developer Guide.
É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 de Cognito. Au minimum, associez la demande d'e-mail de l'utilisateur provenant du fournisseur externe à l'attribut Cognitoemail. 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'applications de groupe d'utilisateurs dans le manuel Amazon Cognito Developer Guide.
Note
La solution configure déjà les URL de rappel et de déconnexion du client de l'application, les étendues OAuth et le domaine d'interface utilisateur hébergé. Vous n'avez pas besoin de modifier ces paramètres. Activez uniquement votre fournisseur d'identité sur le client d'application existant.
Important
La solution omet intentionnellement cette SupportedIdentityProviders propriété dans la configuration du client de CloudFormation l'application. Cela vous permet d'ajouter des fournisseurs d'identité après le déploiement sans déclencher de détection de CloudFormation dérive. Si cette propriété était définie dans le modèle, toute modification manuelle de l'IdP via la console ou la CLI serait remplacée lors de la prochaine mise à jour de la pile, renvoyant le client de l'application aux seuls fournisseurs répertoriés dans le modèle.
Cette propriété étant omise, CloudFormation elle ne permet pas de suivre ni de gérer les fournisseurs d'identité activés sur le client de l'application. Après avoir configuré la fédération, vous êtes responsable de la gestion du contenu SupportedIdentityProviders du client de l'application. Pour surveiller les modifications non autorisées, activez la CloudTrail journalisation AWS et créez des EventBridge règles Amazon pour émettre des alertes CreateIdentityProvider et des appels d'UpdateUserPoolClientAPI ciblant le groupe d'utilisateurs Cognito de la solution.
Note
-
L'ajout d'un fournisseur d'identité externe n'empêche pas les Cognito-native utilisateurs existants de se connecter avec leurs informations d'identification actuelles.
-
Les utilisateurs fédérés sont soumis aux mêmes contraintes de disponibilité régionales que le groupe d'utilisateurs de Cognito. Pour plus d'informations, reportez-vous à la section Déploiement régional.
-
Testez la connexion fédérée auprès d'un petit groupe d'utilisateurs avant de la déployer dans votre organisation.
Désactiver ou supprimer 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
Pour plus de détails, reportez-vous à la section Gestion et recherche de comptes utilisateur dans le manuel Amazon Cognito Developer Guide.
Déploiement régional
Cette solution utilise Amazon Cognito, disponible uniquement 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
