Test de charge AWS – Équilibrage de la charge et meilleures pratiques

Le but de cet article est d’expliquer l’environnement AWS et ses fonctionnalités, fonctionnalités, et aussi discuter des meilleures pratiques lorsque vous travaillez avec AWS, en particulier les tests de charge AWS et l’autoscaling. Nous comparerons également les tests de charge AWS avec le fonctionnement de LoadView et nous serons beaucoup plus faciles à utiliser que d’autres outils et solutions sur le marché aujourd’hui.

Tests de charge distribués sur AWS

Les tests de charge distribués sur AWS, une solution qui simule des milliers de connexions simultanées à un seul point de terminaison, seront expliqués. Il est un outil très utile pour tous ceux qui itèrent sur leur développement d’applications et de performances.

Qu’est-ce qui est testé exactement?

Imaginez que vous êtes un développeur et vous avez construit la plus grande application du monde (ou peut-être que c’est la plus grande application que vous avez jamais construit). En tant que développeur, vous êtes sûr que cela fonctionne très bien puisque vous avez fait des tests unitaires et fonctionnels. Ce que vous devez savoir ensuite, c’est, est-ce que cela va se produire en production et va-t-il fonctionner à l’échelle? L’évolutivité est incroyablement importante. Les applications de test de charge peuvent être considérées comme les mêmes que les tests fonctionnels, mais il suffit d’appliquer de la charge à vos applications et d’observer ce qui se passe. Il ya une différence entre pour les tests pour un utilisateur et de le tester pour un millier de personnes est différente.

La solution construit un cadre où vous pouvez tester vos applications sous charge en utilisant elastic container services pour faire tourner des conteneurs qui créent des centaines de connexions à votre point final et vous pouvez faire tourner des centaines de ces conteneurs. La page de lancement de Distributed Load Testing on AWS est illustrée ci-dessous.

Comme il est vu à partir de la figure, il ya un lien vers un modèle CloudFormation qui va faire tourner la solution dans le compte de l’utilisateur avec un couple de clics, un guide de déploiement détaillé. Le Guide de déploiement View est un guide détaillé qui donne des instructions sur les considérations architecturales et les étapes de configuration pour le déploiement de Distributed Load Testing sur AWS dans le cloud Amazon Web Services (AWS). Le code source est disponible sur GitHub si l’utilisateur souhaite le prendre et le personnaliser pour ses propres besoins et exigences. Le diagramme d’architecture représente l’infrastructure globale de la solution qui comprend l’extrémité avant et l’arrière.

AWS Front-End

Lorsque l’on considère l’extrémité avant : il y a une console Web et une interface utilisateur que l’utilisateur peut utiliser pour interagir avec la solution. Il existe également une API, qui vous permet de créer des tests, d’afficher l’état du test, de rééder le test et de supprimer les opérations de test. L’interface utilisateur provient du modèle CloudFormation. C’est là que les utilisateurs commencent réellement à configurer le test lui-même.

AWS Back-End

le back-end comprend deux choses: il y a un pipeline Docker , puis le moteur de test lui-même. D’où docker pipeline vient est solution utilise un logiciel open-source appelé Taurus. Il y a l’image Docker disponible sur Docker Hub qu’un utilisateur peut utiliser. Cela permet à l’utilisateur de générer des centaines de connexions simultanées à un point de terminaison. Il prend également en charge JMeter et Gatling, qui sont d’autres outils de test. Il s’agit de la partie de test réel des images et c’est l’application qui va faire le test et qui vient sous la forme d’une image Docker. Pipeline back-end va prendre ce paquet d’images pour nous et le pousser à S3 dans le compte du client. Et puis CodePipeline et CodeBuild sont utilisés pour construire cette image et l’enregistrer auprès des services de conteneurs élastiques.

Les tests réels se produisent dans AWS Fargate. Il s’agit d’un service géré qui vous permettra d’exécuter vos conteneurs sur Elastic Container Service sans avoir à vous soucier de la mise en réseau ou de l’infrastructure sous-jacente. Il est littéralement juste tourner jusqu’à une tâche, exécuter le nombre de conteneurs que vous voulez tout le reste est pris en charge. En outre, nous avons une fonction Lambda qui prendra les demandes de notre API et c’est ce qui est réellement en cours d’exécution des tests. Il stockera un modèle de test en S3. Il stockera toutes les informations que nous recueillons dans Dynamo, puis nous utilisons SQS pour mettre en file d’attente ces tâches dans AWS Fargate afin que nous puissions commencer à faire tourner nos conteneurs.

Configuration d’un test AWS

Ci-dessous, il ya une présentation sur l’extrémité avant sur la façon dont nous configurer un test.

1. L’utilisateur frappe le bouton dubouton ” Créer letest »
2. L’utilisateur donne un Nom, Description, Compte de tâches (c’est le nombre de conteneurs que vous souhaitez exécuter), Concurrence (c’est le nombre pour chaque conteneur. Combien de connexions simultanées qui vont créer), Ramp Up (combien de temps je vais obtenir du début pour obtenir jusqu’à ce nombre de connexions simultanées), Hold For (combien de temps vais-je tenir ce test pour?)
3. Scénario : POINT de terminaison HTTP à l’essai (actuellement point d’extrémité unique de prise en charge AWS), méthode HTTP (AWS prend en charge GET, PUT, POST, DELETE operations), HTTP Headers, Body Payload (En-têtes et charge utile peuvent être parsed).

Ci-dessous, une capture d’écran d’un test actuellement en cours d’exécution est fournie:

Les détails du test ont été fournis. Dans cet exemple précis, 20 conteneurs ont été demandés, 20 conteneurs sont en cours d’exécution. Une fois que c’est terminé sur l’extrémité arrière, chacun des conteneurs exécutera les tests, prendre les résultats, puis stocker que sous la forme d’un fichier XML en S3 de notre fonction Back-end Lambda. Une fois que tous les conteneurs auront terminé, nous prendront cette information et l’agrégerons, transmettons toutes ces informations à Dynamo.

Ci-dessous, il ya trois captures d’écran d’une page qui représente les résultats du test.

Si l’utilisateur regarde un test terminé, un résumé lui est présenté; les résultats des tests qui sont les temps de réponse moyens, la latence, les métriques CloudWatch afin que nous puissions voir comment nous fonctionnons, un certain nombre d’autres points de données, ainsi qu’un historique des résultats.

Imaginez que vous puissiez l’exécuter une fois, faire quelques ajustements sur votre point final sur votre API, puis réexécuter le test pour voir comment cela améliore le temps de réponse afin que les développeurs puissent itérer et voir leurs résultats au fil du temps de la Améliorations pour la fabrication de leur application. Plus important encore, ils voient des performances à l’échelle.

Il s’agissait d’une plongée profonde dans les essais de charge distribués sur AWS. Cette solution élimine toutes les complexités de générer de la charge pour tester vos applications à l’échelle.

AWS Autoscaling

La mise à l’échelle automatique est une méthode utilisée dans le cloud computing, par laquelle un certain nombre de ressources de calcul dans une batterie de serveurs, généralement mesuré en termes de nombre de serveurs actifs, est automatiquement mis à l’échelle en fonction de la charge sur la batterie de serveurs. AWS Autoscaling permet d’atteindre l’évolutivité horizontale de votre application. Il permet d’atteindre une disponibilité élevée, d’augmenter et de réduire la capacité EC2, de maintenir la capacité souhaitée, d’augmenter/diminuer la capacité de manière transparente en fonction de la demande, ce qui conduit à des optimisations des coûts. Il fonctionne avec ELP et CloudWatch.

Création d’un balanceur de charge élastique

La figure ci-dessous montre la structure générale pour aider à comprendre les bases.

Créer un balanceur de charge élastique

Avant de pouvoir créer et configurer la configuration de lancement et l’autoscaling, nous devons créer notre balanceur de charge élastique (ELB) qui est un fournisseur de services par AWS pour répartir le trafic entrant uniformément dans les instances EC2 saines qui sont sous son contrôle. Healthy est le mot clé ici. L’équilibreur de charge élastique effectue des contrôles d’intégrité configurables périodiques et prend des décisions sur l’emplacement d’envoi du trafic. La capture d’écran ci-dessous est un titre vers le tableau de bord EC2.

Ici, notre objectif est d’aller pour les serveurs virtuels EC2 dans le cloud. Comme il est montré ci-dessous, sous Network & Security, nous sélectionnons les 3e à charge.

Après cela, l’utilisateur frappe le bouton de créer le bouton Balanceur de charge.

L’utilisateur donne un nom. Dans cet exemple spécifique, nous laissons Créer un té en équilibreur de charge interne non contrôlé. Cela dirigera le nom DNS vers une adresse IP publique. S’il est vérifié, le nom DNS sera un point à une adresse IP privée à la place. Activer la configuration VPC avancée sera vérifiée, ce qui nous permettra d’attribuer des sous-réseaux à ELB dans une étape ultérieure. La configuration auditeur nous permet de cartographier le trafic ELB entrant vers les ports d’instances EC2. La cartographie par défaut du port 80 contribue à notre application.

Configurer le bilan de santé

L’étape suivante, qui est indiquée ci-dessous, est de configurer le bilan de santé.

Configurez le bilan de santé : Options

Ici, nos options incluent HTTP, TCP, HTTPS et SSL standard. Dans notre exemple, nous nous en tenirons à HTTP et nous nous dirigeons vers les robots.txt fichier. Si notre serveur Web ne peut pas répondre à la demande statique, alors nous pouvons supposer en toute sécurité quelque chose ne va pas avec l’instance et aucun autre trafic ne devrait lui être envoyé jusqu’à ce qu’il devienne sain. Avec les paramètres actuels sous des détails avancés, une instance EC2 sera vérifiée toutes les 30 secondes. Il dispose de 5 secondes pour répondre à la demande. Le fait de ne pas répondre dans le temps alloué signifie que l’instance peut être malsaine. Deux contrôles malsains consécutifs mettrait les instances EC2 hors service. Pour redevenre en bonne santé. Il doit passer 10 contrôles sanitaires consécutifs avant de commencer à recevoir du trafic. Ces seuils sont acceptables pour notre demande.

Sélectionnez Sous-réseaux/Zones

Sélectionnez parmi les options Subnet montre ci-dessous.

Nous ajouterons chaque sous-réseau que nous avons créé pour nos serveurs Web. Il est important de mentionner que nous ne pouvons ajouter qu’un sous-réseau par zone de disponibilité.

Attribution de groupes de sécurité

Voici une capture d’écran de ce que l’attribution des groupes de sécurité ressemble.

Nous devons sélectionner un groupe de sécurité pour notre ELB, donc pour cet exemple, nous sélectionnerons le groupe de sécurité ELB préconfiguré.

Ajout d’instances EC2

Voici une capture d’écran montrant comment ajouter des instances EC2.

Dans cette étape, nous devons nous assurer que l’équilibrage de charge Enable Cross Zone est vérifié. Sans elle, notre conception de haute disponibilité est inutile. Activer le drainage de connexion doit également être vérifié, ce qui détermine la façon dont le trafic est géré lorsqu’une instance n’est pas enregistrée ou a été déclarée malsaine.

Créer la page d’examen de l’ équilibreur de charge

La page Examen est affichée ci-dessous. De là, vous pouvez examiner vos sélections et apporter des modifications supplémentaires, si nécessaire.

Maintenant, l’ELB est créé. Une fois qu’il est terminé, nous sommes prêts à créer notre configuration de lancement une politique d’échelle automatique. La création de la stratégie d’autoscaling est également facile, par conséquent, un utilisateur peut passer par le processus eux-mêmes.

LoadView versus la concurrence: Pourquoi LoadView se démarque

Cette section fournit des comparaisons de haut niveau entre d’autres outils et solutions de test de charge populaires et LoadView. Tous les outils de test de charge ne sont pas créés égaux. Même si les outils open source ne nécessitent généralement pas de coûts initiaux et d’investissements, ce qui peut en faire une option facile à utiliser, il est préférable de comprendre ce qui rend LoadView plus facile à utiliser que d’autres outils.

Apache JMeter

Apache JMeter, qui est un logiciel open-source, est pour tester le comportement fonctionnel de chargement et mesurer les performances des applications Web. Ensuite, nous allons prendre un point culminant les avantages et les inconvénients de JMeter.

Avantages Apache JMeter

• Plate-forme indépendante. JMeter peut fonctionner dans n’importe quel système d’exploitation comme Mac, Windows et Linux.
• Open-source. L’outil est open-source, ce qui signifie qu’il peut être utilisé gratuitement. Un développeur de logiciels peut également apporter des modifications et le configurer à leurs exigences, ce qui conduit à beaucoup de flexibilité. Un développeur peut personnaliser JMeter, appliquer des tests d’automatisation à JMeter.
• Fonctionnalité. Avec JMeter, un utilisateur peut faire n’importe quel type de test qu’il veut – tests de charge, tests de résistance, tests fonctionnels, tests distribués, etc.
• Rapports. JMeter fournit de nombreux rapports et graphiques – Graphique, Graphique et Vue arbre. De plus, les formats HTML, JSON et XML pour les rapports sont pris en charge.
• Prise en charge de nombreux protocoles. JMeter prend en charge FTP, HTTP, LDAP, SOAP, JDBC et JMS.
• Capacité de génération de charge. Le logiciel a une capacité illimitée de génération de charge.
• Exécution. Il est facile à exécuter. L’utilisateur a juste besoin d’installer Java, télécharger JMeter et télécharger le fichier de script JMeter.
  Rapport d’analyse. Les résultats sont faciles à comprendre pour les ingénieurs et les utilisateurs moins expérimentés, et permettent également une analyse approfondie pour les testeurs.

Apache JMeter Inconvénients

• Ne pas être convivial. Vous devez écrire beaucoup de scripts, il n’est donc pas aussi convivial que d’autres outils. Ça peut être déroutant. Pour être en mesure d’effectuer des tests, l’utilisateur a besoin d’écrire des scripts qui peuvent être difficiles, déroutants, il conduit le logiciel n’étant pas convivial.
• Manque de prise en charge des applications de bureau. JMeter est idéal pour tester des applications Web, mais il n’est pas idéal pour les tests d’applications de bureau.
• Consommation de mémoire. JMeter est capable de simuler une charge lourde, visualiser le rapport de test qui absorbe beaucoup de mémoire, conduit la mémoire étant sous une grande charge.
• Pas de prise en charge JavaScript. JMeter n’est pas un navigateur, donc il ne se comporte, ou simule, qu’un véritable navigateur. Il ne prend pas en charge AJAX et JavaScript, ce qui affecte l’efficacité du test. Vous n’êtes pas en mesure d’évaluer correctement les performances côté client (pour plus d’informations sur les avantages et les inconvénients de JMeter, consultez notre Guide ultime des tests de performances avec JMeter)

LoadNinja

LoadNinja est la plate-forme de test de charge dans le cloud vous permettant de déterminer de manière fiable les performances de vos sites Web et de votre application Web sans utiliser de scripts. LoadNinja a été construit et conçu à partir de la base jusqu’aux médias les défis auxquels sont confrontés les outils conventionnels de test de charge basés sur le protocole. Nous allons discuter de certains des faits saillants et des limites de LoadNinja.

Avantages LoadNinja

• Utilise de vrais navigateurs
• Mesures basées sur le navigateur avec des fonctionnalités d’analyse et de reporting.
• VU Debugger. Permet aux développeurs de trouver et d’isoler les erreurs pendant le test.
• INSPECTEUR VU. Donne aux utilisateurs un aperçu de la façon dont les utilisateurs virtuels interagissent avec leurs pages Web et applications pendant que le test est en cours d’exécution.
• Outil d’enregistrement. Similaire à l’enregistreur Web EveryStep, que nous allons couvrir plus en détail ci-dessous, permet de point et cliquez sur scripting.

Désavantages LoadNinja

• Dépendant d’AJAX. Ne fonctionne pas si JavaScript est désactivé ou non pris en charge.
• Contenu dynamique. Le contenu dynamique ne sera pas rendu visible pour votre application ajax.
• Latence. Les problèmes de latence peuvent être plus élevés, juste en fonction du comportement asynchrone d’AJAX.
• Coût. Peut être cher, par rapport à d’autres outils sur le marché et les fonctionnalités incluses.

LoadRunner

Il s’agit d’un outil de test logiciel de Micro Focus. Il est utilisé pour tester les applications, mesurer le comportement du système, et les performances sous charge. Il peut simuler des milliers d’utilisateurs simultanément à l’aide d’un logiciel d’application. Jetons un coup d’oeil rapide à ce qui rend LoadRunner populaire et certains des inconvénients de la solution.

Avantages de LoadRunner

• Fonctionnalité de relecture et d’enregistrement (en plus de la corrélation automatisée).
• La variété des protocoles sont pris en charge en plus de ceux propriétaires comme Remote Desktop, Citrix et Mainframes.
• Le logiciel peut tenter d’effectuer une analyse automatisée du goulot d’étranglement.
• Intégration avec une infrastructure comme HP ALM, QTP.

Le logiciel peut se surveiller lui-même et l’application à l’essai en termes de disponibilité des ressources (RAM, CPU, etc.).

Inconvénients de LoadRunner

• LoadRunner est un outil de test logiciel coûteux. Il a récemment publié des versions d’essai gratuites mais il ne peut pas être simplement téléchargé pour une utilisation.
• LoadRunner a une capacité de production de charge limitée. L’utilisateur ne peut pas surcharger l’outil LoadRunner avec trop d’utilisateurs ou de threads. (Si l’utilisateur est à la recherche d’un outil de test de performance qui effectuera des tests lourds et aussi trop d’utilisateurs et de groupes de threads, alors LoadRunner ne serait pas le meilleur choix).
• L’exécution est complexe. Il crée un thread pour chaque utilisateur.
• En termes de rapport d’analyse, l’information dans un format brut qui est analyser par HP Analysis pour générer divers graphiques.

LoadView

Le logiciel est un outil de stress et de test de charge basé sur le cloud pour les pages Web, les applications Web, les API et même les médias en streaming. Étant donné que LoadView est basé sur le cloud, les ingénieurs et les testeurs peuvent rapidement faire des tours et mettre à l’échelle les tests de charge en fonction de leurs besoins en charge. Un utilisateur peut produire autant de trafic que demandé. Dans ce processus, l’utilisateur n’a pas besoin de gérer l’infrastructure supplémentaire, ce qui est un énorme avantage sur les outils open-source comme JMeter, qui oblige les utilisateurs à exécuter des tests à partir de leurs propres machines, et ne peut pas l’échelle au niveau que LoadView offre En outre, le logiciel génère une séquence de HTTP GET / POST demande de tester les serveurs Web et les API web.

Avantages LoadView

• Aucune obligation de tarification à long terme, est livré avec un modèle de tarification à l’utilisation, de sorte que les clients peuvent charger le test quand ils en ont besoin.
• Les supports d’enregistrement des scénarios utilisateur pour les applications Internet dynamiques et riches (RIA), tels que Java, HTML5, Flash, Vue, Angular, React, PHP, Silverlight et Ruby (entre autres) sont pris en charge. S’il peut être rendu dans le navigateur d’un utilisateur, l’enregistreur Web EveryStep le prend en charge.
• Les utilisateurs peuvent utiliser des serveurs de nombreux emplacements géographiques mondiaux pour imiter la base d’utilisateurs attendue.
• Créer des scripts de test de charge sans même avoir à toucher une ligne de code.
• Test de charge basé sur le cloud dans de vrais navigateurs.
• Testez la compatibilité sur plus de 40 appareils et navigateurs de bureau/mobiles.
• Plus de 20 géolocalisations d’injecteurs de charge dans le monde entier.
• Diagnostiquer les goulots d’étranglement, assurer l’évolutivité et déterminer les performances globales.
• Rapports de performance, mesures de planification de la capacité, tableaux de bord des performances, et plus encore.

En résumant cette section, il est démontré que LoadView est plus facile à utiliser, plus efficace que les autres outils que nous avons couverts.

 

Conclusion : Test de charge AWS – Équilibrage de la charge et meilleures pratiques

Dans cet article, nous avons couvert la façon d’effectuer des tests de charge distribués avec AWS, ce qui efface toute la complexité de générer de la charge pour tester vos applications à l’échelle. Les tests de charge AWS sont utilisés pour aider les utilisateurs à construire et reproduire des milliers d’utilisateurs connectés réalisant le nombre de transactions. Nous avons également couvert la fonction d’autoscaling au sein d’AWS, y compris les définitions de l’autoscaling, la façon de créer des balanceurs de charge élastiques pour lancer la configuration, et la mise en place d’autoscaling. Nous avons également pris un coup d’oeil à certains des autres outils populaires de test de charge sur le marché et pourquoi LoadView est beaucoup plus facile à utiliser que d’autres outils.

Pour un examen plus approfondi de LoadView par rapport à d’autres outils et solutions de test de charge sur le marché aujourd’hui, veuillez visiter notre page Alternatives pour des comparaisons et des informations complètes côte à côte.

Commencez avec LoadView dès aujourd’hui ! Inscrivez-vous à l’essai gratuit et obtenez des tests de charge gratuits lorsque vous commencez.