Cette page présente les bonnes pratiques relatives aux tests de charge de votre service Cloud Run afin de déterminer s'il permet un scaling efficace lors de l'utilisation en production, et de détecter les goulots d'étranglement qui empêchent le 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é du conteneur 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 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, veillez à collaborer avec l'équipe de gestion de votre compte Google et à 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 l'emplacement us-central1. Contactez votre équipe de gestion du compte et envoyez une demande d'assistance en indiquant le temps et l'échelle du test si vous prévoyez d'approcher les limites de quota.
Tester un profil d'utilisation du processeur et d'initialisation de service approprié
Dans un scénario idéal, vous déployez une version de test de votre service sur Cloud Run et vous la testez 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 de tels cas, vous pouvez estimer les performances de votre service en simulant un service plus simple avec une utilisation du processeur comparable et des temps d'initialisation comparables.
Le délai d'initialisation est particulièrement important pour un scaling rapide. Gardez à l'esprit que le test d'éléments trop simples pose également problème. 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 faisceau 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 un 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 de 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 lui-même lié au projet.
Ne générez pas de charge à partir d'outils où le taux et la simultanéité ne peuvent pas être contrôlés. Pub/Sub n'est pas un bon outil pour générer la charge, car vous ne pouvez pas contrôler le taux du trafic et le nombre de clients. Si vous ne connaissez pas le taux et la simultanéité, vous ne saurez pas ce que vous testez.
Utiliser une 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 obtenir de meilleures performances de journalisation en écrivant directement dans stdout au lieu d'utiliser une bibliothèque cliente Cloud Logging.
Pour configurer une exportation de journal avant de lancer le test, créez un récepteur de journaux avec la destination BigQuery et un filtre d'inclusion, tel que:
resource.type="cloud_run_revision"
resource.labels.service_name="[your app]"
Éviter les démarrages à froid parasites
Pour minimiser les démarrages à froid effectué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 effectue un scaling linéaire avec la charge et n'atteint pas un goulot d'étranglement limitant la charge comme vous le souhaitez en production.
Analyser et visualiser les résultats dans Colab
Utilisez les graphiques de surveillance récapitulatifs pour obtenir une compréhension globale 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 les résultats de tracé à l'aide de Colab, qui est prêt à être intégré à BigQuery, Pandas et Matplotlab. Colab s'intègre également facilement à de puissants outils de visualisation de données tels que Seaborn.
Identifier les goulots d'étranglement
Les tests de charge peuvent vous aider à détecter l'existence de codes inefficaces et de goulots d'étranglement. Un code inefficace entraîne des coûts plus élevés, car il doit gérer plus de trafic, mais cela n'empêche pas nécessairement le scaling. Par exemple, une dépendance à une traduction de base de données avec verrouillage de la table peut être un goulot d'étranglement qui empêche le service Cloud Run de se redimensionner, car une seule transaction peut être exécutée à la fois.
Vérifier les performances du 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 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.