Cette page présente les bonnes pratiques à suivre pour tester la charge de votre service Cloud Run afin de déterminer s'il évolue correctement en production et d'identifier les goulots d'étranglement qui empêchent son scaling.
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 excessive et l'utilisation 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 prévoyez que votre test de charge dépassera cette valeur par défaut, assurez-vous de travailler avec votre équipe de gestion de compte Google 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 us-central1
La région Google Cloud us-central1 offre une limite de quota élevée. Google recommande donc d'effectuer des tests de charge dans us-central1. Si vous prévoyez d'atteindre les limites de quota, coordonnez-vous avec votre équipe de gestion de compte et envoyez une demande d'assistance en indiquant l'heure et l'échelle du test.
Tester un profil d'initialisation de service et d'utilisation du processeur approprié
Dans l'idéal, vous déployez une version de test de votre service sur Cloud Run et effectuez un test de charge directement. Toutefois, dans certains cas, vous ne pourrez peut-être pas déployer de version de 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 ces cas, vous pouvez estimer les performances de votre service en le simulant avec un service plus simple, avec une utilisation du processeur comparable et des temps d'initialisation comparables.
Le temps d'initialisation est particulièrement important pour une mise à l'échelle rapide. Gardez à l'esprit que les tests avec des éléments trop simples peuvent également poser problème. Par exemple, évitez d'effectuer des tests avec un simple service hello world qui renvoie les requêtes reçues sans 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 faisceau 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 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 lui-même lié au projet.
Ne générez pas de charge à partir d'outils dont le taux et la simultanéité ne peuvent pas être contrôlés. Pub/Sub n'est pas un bon choix d'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 débit et la simultanéité, vous ne saurez pas ce que vous testez.
Utiliser une analyse détaillée des journaux à l'aide de 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 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 intempestifs
Pour réduire 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 qu'il n'atteint pas de goulot d'étranglement limitant à une charge inférieure à celle que vous attendez en production.
Analyser et visualiser les résultats dans Colab
Les graphiques de surveillance récapitulatifs vous permettent d'obtenir une compréhension générale des résultats et 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 peut être intégré facilement à BigQuery, Pandas et Matplotlab. Colab s'intègre également facilement à des outils de visualisation de données riches 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 mise à l'échelle. Le code inefficace entraîne des coûts plus élevés, car il doit gérer davantage de trafic, mais n'empêche pas nécessairement le scaling. Par exemple, une dépendance à l'égard d'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 de s'adapter, 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, qui incluent les latences mesurées chez le 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 la bonne option et si votre service peut s'adapter au 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.