Les tests de charge de votre service Cloud Run vous aident à déterminer s'il évolue correctement lors de l'utilisation en production. L'exécution de tests de charge vous permet également d'identifier les goulots d'étranglement qui empêchent votre service d'évoluer.
Tests à exécuter avant les tests de charge
Identifiez et résolvez les problèmes de simultanéité dans un environnement de développement ou de test limité avant de procéder aux tests de charge. Mesurez la simultanéité des conteneurs avant d'effectuer un test de charge et assurez-vous que votre service Cloud Run démarre de manière fiable.
Concentrez vos tests de conteneur sur de petits décomptes incrémentiels dans des exécutions avec scaling manuel. Vous pouvez estimer le scaling manuel dans Cloud Run en définissant le nombre maximal d'instances sur la valeur vers laquelle vous souhaitez effectuer le scaling.
Si vous avez récemment créé ou récemment modifié votre image de conteneur, testez-la indépendamment avant d'effectuer un test de charge.
Vous devez également vérifier d'autres types de problèmes de performances, tels qu'une latence excessive et une utilisation élevée du processeur, avant d'exécuter un test de charge à grande échelle.
Utiliser max instances de manière appropriée
Cloud Run applique un nombre maximal d'instances pour limiter le scaling d'un service. Le nombre maximal d'instances par défaut est de 100. Si vous pensez que votre test de charge dépassera cette valeur par défaut, contactez l'équipe responsable de votre compte chez Google et définissez un nouveau maximum. Si vous n'êtes pas encore en lien avec une équipe de gestion de compte, contactez le service commercial Google Cloud .
Le nombre maximal d'instances que vous pouvez sélectionner dépend de vos limites de processeur et vos limites de mémoire, ainsi que de la région dans laquelle vous effectuez le déploiement.
Ces limites sont gérées par une limite de quota et peuvent être augmentées en effectuant une demande d'augmentation de limite de quota.
Test de charge dans la région europe-west1
La région Google Cloud europe-west1 offre une limite de quota élevée. Google recommande donc d'effectuer des tests de charge dans europe-west1.
Contactez l'équipe chargée de votre compte et envoyez une demande d'assistance en indiquant l'heure et l'échelle du test si vous pensez approcher des limites de quota.
Tester un profil d'utilisation du processeur et d'initialisation du service approprié
Dans un scénario idéal, vous déployez une version de test de votre service sur Cloud Run et vous effectuez un test de charge directement. Toutefois, dans certains cas, vous ne pourrez peut-être pas déployer une version de test de votre service. Par exemple, votre service Cloud Run peut faire partie d'un écosystème complexe difficile à répliquer dans un environnement de test.
Dans ce cas, vous pouvez estimer les performances de votre service en le simulant avec un service plus simple, dont l'utilisation du processeur et les temps d'initialisation sont comparables.
Le temps d'initialisation est particulièrement important pour un scaling rapide. N'oubliez pas que tester avec un élément trop simple est également problématique. Par exemple, évitez d'effectuer des tests avec un service hello world simple qui renvoie les requêtes reçues sans aucun traitement.
Utiliser un harnais de test pour générer des charges
Vous pouvez générer des charges de test provoquant un pic de trafic contrôlé à l'aide d'un harnais de test, tel que JMeter. Vous pouvez utiliser le nombre de groupes de threads JMeter et le délai entre les requêtes dans le test JMeter pour augmenter la charge.
Vous pouvez également envoyer des requêtes HTTP simples ou enregistrer une session de navigateur avec JMeter. Cloud Run vous permet de tester votre service sans accès à Internet à l'aide de l'authentification des développeurs. Cela permet d'accéder à un faisceau de test tel que JMeter, exécuté sur une machine virtuelle Compute Engine associée à un cloud privé virtuel (VPC) lui-même lié au projet.
Ne générez pas de charge à partir d'outils dont le débit et la simultanéité ne peuvent pas être contrôlés. Pub/Sub n'est pas un bon outil pour générer de la charge, car vous ne pouvez pas contrôler le débit du trafic ni le nombre de clients. Si vous ne connaissez pas le taux et la simultanéité, vous ne saurez pas ce que vous testez.
Utiliser l'analyse détaillée des journaux à l'aide des journaux exportés
Vous avez besoin d'une analyse d'événements seconde par seconde pour comprendre la réponse de votre service Cloud Run aux pics de trafic rapides. Il est nécessaire d'analyser les journaux car la précision des données de surveillance n'est pas suffisamment précise. L'analyse des journaux vous permet également d'examiner les raisons des requêtes avec une latence élevée.
Lorsque vous écrivez des journaux, vous pouvez améliorer les performances de journalisation en écrivant directement dans stdout au lieu d'utiliser une bibliothèque cliente Cloud Logging.
Pour configurer une exportation de journaux avant de lancer le test, créez un récepteur de journaux avec la destination BigQuery et un filtre d'inclusion, par exemple :
resource.type="cloud_run_revision"
resource.labels.service_name="[your app]"
Éviter les démarrages à froid parasites
Pour minimiser les démarrages à froid rencontrés par les utilisateurs, définissez le nombre minimal d'instances sur au moins 1.
S'assurer que votre service effectue un scaling horizontal de manière linéaire
Répétez le test à différentes charges pour vous assurer que votre service Cloud Run effectue un scaling horizontal linéaire avec la charge et n'atteint pas un goulot d'étranglement limitant à une charge inférieure à celle que vous attendez en production.
Analyser et visualiser les résultats dans Colaboratory
Utilisez les graphiques de surveillance récapitulatifs pour obtenir une vue d'ensemble des résultats afin de compléter l'analyse détaillée des journaux à l'aide des journaux exportés.
Les graphiques de surveillance peuvent vous aider à déterminer les points suivants :
- Comment les instances sont-elles créées et initialisées (à la seconde près) ?
- Quelle est la répartition uniforme des requêtes sur différentes instances ?
- À quelle vitesse la latence, évaluée à différents centiles, peut-elle être réduite à une valeur d'état stable ?
Vous pouvez utiliser l'interface utilisateur de la console Google Cloud pour BigQuery afin d'introduire le schéma de journaux exporté et d'afficher les résultats. Exécutez les requêtes et tracez les résultats à l'aide de Colab, qui est déjà intégré à BigQuery, Pandas et Matplotlab. Colab s'intègre également facilement à des outils de visualisation de données enrichis tels que Seaborn.
Identifier les goulots d'étranglement
Les tests de charge peuvent vous aider à détecter l'existence d'un code inefficace et de goulots d'étranglement de scaling. Un code inefficace entraîne des coûts plus élevés, car il doit gérer davantage de trafic, mais il n'empêche pas nécessairement le scaling. Par exemple, une dépendance à une traduction de base de données avec verrouillage au niveau de la table peut constituer un goulot d'étranglement qui empêchera le service Cloud Run d'effectuer un scaling, car une seule transaction peut s'exécuter à la fois.
Vérifier les performances telles qu'elles sont perçues par le client
Vous pouvez interroger les journaux capturés par JMeter, où les journaux incluent les latences mesurées au niveau du client. Toutefois, comme les outils de test de serveur tels que JMeter ne sont pas les mêmes que pour un navigateur ou un client mobile, vous pouvez également exécuter un test avec un framework basé sur un navigateur, tel que Selenium Webdriver, ou un framework de test de client mobile. Faites attention aux latences maximales excessives liées à l'initialisation de la connexion TLS, qui peuvent fausser les résultats et générer des anomalies.
Récapitulatif des bonnes pratiques
Effectuez un test de charge pour déterminer si la migration vers Cloud Run est le bon choix et si votre service peut évoluer pour atteindre le trafic maximal attendu. Exécutez le test avec un outil ayant du potentiel, tel que JMeter. Exportez les journaux vers BigQuery pour une analyse détaillée.