Cloud Run à l'essai

Nous étudions depuis un certain temps la migration de certaines de nos charges de travail vers une infrastructure serverless. Nous avions d'abord envisagé AWS Lambda comme solution de référence, mais la prise en charge native des conteneurs par Cloud Run était une option attrayante, car elle réduisait le coût de migration des conteneurs existants.

Nous avons d'abord envisagé de migrer nos sites web non statiques. Voici ce que nous avons appris en l'utilisant et pourquoi nous avons décidé qu'il n'est pas encore prêt pour la production.

Migrer les charges de travail

Si vos conteneurs sont déjà stockés sur GCR, la mise en place de Cloud Run est très simple. Le code a dû être adapté pour écouter sur le $PORT défini par Cloud Run. Cela s'est révélé plus compliqué que prévu, car nous utilisons Nginx et sa configuration ne prend pas en charge les variables d'environnement dans les fichiers de configuration.

Les options étaient soit d'utiliser un langage de script comme LUA ou PERL pour créer une variable Nginx à partir de la variable d'environnement, soit d'utiliser envsubst pour transformer un modèle de configuration en substituant les valeurs des variables d'environnement.

Trafic chiffré

Un avantage évident de Cloud Run est que vous n'avez plus besoin de configurer votre point de terminaison TLS/SSL, car Cloud Run s'en charge.

Cela offre une sécurité accrue, puisque vous n'avez plus à suivre les bonnes pratiques de configuration TLS, les protocoles à prendre en charge, etc. Mais cela réduit aussi votre marge de manœuvre si vous souhaitez appliquer une politique stricte ou prendre en charge d'anciens navigateurs.

Dans ces cas, une configuration TLS gérée sans possibilité de la configurer pose un gros problème.

Connexion à des services externes

Une fois le service opérationnel, il n'arrêtait pas de se plaindre de la connexion à la base de données SQL. À notre surprise, Cloud Run ne prend en charge que la connexion aux services Google internes. Une base de données qui ne tourne pas sur GCP n'est pas prise en charge.

Cela limite aussi l'intérêt de Cloud Run pour plusieurs cas d'usage qui nécessitent des connexions sortantes. Si vous en avez vraiment besoin, il est possible d'exécuter Cloud Run sur un GKE dédié, mais la configuration était si complexe et la documentation si peu claire que nous avons simplement abandonné.

Pour poursuivre les tests, nous avons fini par mettre en place une base de données sur GCP avec Cloud SQL. La connexion SQL se fait toutefois via des fichiers socket montés dans le conteneur sous /cloudsql/.

Cette mise en place a aussi nécessité des modifications du code, mais elle était très simple ; le vrai plaisir est venu lorsque nous avons dû gérer l'erreur de politique IAM et les API manquantes. Ce n'est pas agréable, mais une fois que cela fonctionne, réutiliser le même compte de service pour se connecter à la base de données est transparent et nettement plus sécurisé.

Montée en charge

Une fois Cloud Run configuré et la connexion à la base de données fonctionnelle, est venu le moment de vérité : comment se comporte-t-il en matière de montée en charge et de performances ?

Lancer des milliers de connexions sur le service a fonctionné à merveille, atteignant 1k QPS avec des pics à 1.6k QPS.

La montée en charge a été une agréable surprise et a fonctionné immédiatement ; vous risquez de rencontrer un goulot d'étranglement au niveau de la base de données si elle est sous-dimensionnée.

Latence

La latence a malheureusement été le point rédhibitoire. Maintenir une latence relativement faible pour nos sites web était important pour offrir une bonne expérience utilisateur.

La latence actuelle varie de 40 ms à 2000 ms en moyenne, avec 3000 ms au 95e percentile.

La latence de Cloud Run était tout simplement horrible, entre 4000 ms et 8000 ms. Nous avons pu constater une baisse de la latence après un démarrage à froid, mais même alors, les valeurs atteintes restaient élevées, entre 600 ms et 4000 ms, avec de fréquents pics à 8000 ms.

Verdict

Cloud Run semblait très prometteur et possède clairement un grand potentiel grâce à sa prise en charge native des conteneurs. Son intégration avec Cloud Build semble aussi un gros avantage pour automatiser les déploiements.

L'absence de prise en charge des connexions sortantes limite son utilité et ses scénarios d'intégration ; je suppose que c'est pour éviter que le service soit détourné pour mener des attaques DDoS.

Si les chiffres de montée en charge sont impressionnants, la latence est très problématique, ce qui limite son utilité pour exécuter des sites web, voire des API.

Utiliser le service pour des tâches non sensibles à la latence reste une option, tant qu'elles ne nécessitent pas de connexion sortante.