Cette page présente les bonnes pratiques pour tester la charge de votre service Cloud Run afin de déterminer s'il évolue correctement lors de l'utilisation en production et d'identifier les goulots d'étranglement qui l'empêchent de s'ajuster.
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 que la latence et l'utilisation du processeur excessives, 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, assurez-vous de contacter l'équipe Google chargée de votre compte et de définir une nouvelle valeur maximale. 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-west1offre une limite de quota élevée. Google recommande donc d'effectuer des tests de charge danseurope-west1.
Si vous pensez approcher les limites de quota, coordonnez-vous avec l'équipe chargée de votre compte et envoyez une demande d'assistance en précisant la durée et l'ampleur du test.
Tester un profil approprié d'utilisation du processeur et d'initialisation du service
Dans un scénario idéal, vous déployez une version test de votre service sur Cloud Run et vous la testez directement en charge. Toutefois, dans certains cas, il est possible que vous ne puissiez pas déployer de version test de votre service. Par exemple, votre service Cloud Run peut faire partie d'un écosystème complexe difficile à reproduire dans un environnement de test.
Dans ce cas, vous pouvez approximer les performances de votre service en le simulant avec un service plus simple qui présente une utilisation du processeur et des temps d'initialisation comparables.
Le temps d'initialisation est particulièrement important pour un scaling rapide. N'oubliez pas que tester avec quelque chose de trop simple est également problématique. Par exemple, évitez de tester avec un service hello world simple qui renvoie les requêtes reçues sans aucun traitement.
Utiliser un atelier de test pour générer des charges
Vous pouvez générer des charges de test entraînant un pic de trafic contrôlé à l'aide d'un atelier 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 de simples requêtes HTTP 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 du développeur. 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 vous ne pouvez pas contrôler le taux et la simultanéité. Pub/Sub n'est pas un bon outil pour générer de la charge, car vous ne pouvez pas contrôler le taux de 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.
Analyser en détail les 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 l'exportation des journaux avant de commencer 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 inutiles
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 évolue de manière linéaire
Répétez le test à différentes charges pour vous assurer que votre service Cloud Run évolue de manière linéaire avec la charge et n'atteint pas de goulot d'étranglement limitant à une charge inférieure à celle que vous prévoyez 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 et 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'inspecter le schéma de journaux exporté et d'afficher un aperçu des résultats. Exécutez les requêtes et représentez les résultats sous forme graphique à l'aide de Colab, qui est prêt à s'intégrer à BigQuery, Pandas et Matplotlib. Colab s'intègre également facilement aux outils de visualisation de données enrichies tels que Seaborn.
Identifier les goulots d'étranglement
Les tests de charge peuvent vous aider à détecter l'existence de 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 plus 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 un verrouillage au niveau de la table peut constituer un goulot d'étranglement qui empêchera le service Cloud Run de faire l'objet d'un scaling, car une seule transaction peut être exécutée à la fois.
Vérifier les performances telles qu'elles sont perçues par le client
Vous pouvez interroger les journaux capturés par JMeter, qui 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 en fonction du 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.