Monitorer la perf des apps serverless, nouvel enjeu du cloud
Grâce aux services cloud dits serverless, plus besoin de configurer et gérer serveurs et machines virtuelles. Le code des applications s'exécute via ce qu'on appelle des "fonctions" en réponse à des événements (une requête HTTP par exemple). D'où le terme "Function as a Service", ou FaaS, qui est aussi utilisé pour désigner ce type de solution. Taillé pour les architectures en microservices, le serverless conviendra notamment aux applications web, IoT ou encore au back end d'apps mobiles, c'est-à-dire aux briques IT avec une composante événementielle. Sur ce segment, on retrouve Amazon qui fait figure de pionnier avec son environnement AWS Lambda lancé dès 2014. Mais aussi Microsoft et son offre Azure Functions ou encore Google avec Cloud Functions.
Les clouds serverless sont facturés à la fois au regard du nombre de fonctions exécutées, du temps de traitement (à la milliseconde près), et de la mémoire consommée. D'où l'importance de contrôler de près la santé des applications qu'ils mettent en musique. S'ils sont consacrés à des workloads critiques pour lesquels une latence minimale est cruciale, "les utilisateurs pourront également avoir besoin d'être rapidement alertés en cas de problèmes en vue d'identifier et solutionner les goulots d'étranglement", souligne Daniel Langer, responsable produit serverless chez Datadog, spécialiste américain du monitoring de systèmes cloud.
Monitorer une application serverless n'en demeure pas moins un exercice délicat. "Par définition, on sort de la logique de supervision d'un site web traditionnel et des indicateurs de disponibilité ou de temps d'accès à une page", commente Fabien Bourdier, directeur des opérations chez TravelClick Video Solution International (groupe TravelClick). Mesurer la performance d'une application serverless implique des KPI plus variés : suivi du nombre d'appels fonction par fonction, de leur durée d'exécution, des tentatives d'appel ayant échoué. Sans oublier le taux d'erreurs par fonction. "Si l'une d'elles retourne des centaines d'erreurs, cela signifiera probablement des dysfonctionnements pour l'utilisateur final. Le savoir permettra de creuser dans les logs et remonter à l'origine du problème", argue Daniel Langer chez Datadog.
"La console AWS Lambda offre un premier niveau de mesure de performance"
TravelClick Video Solution International utilise le service serverless d'Amazon depuis avril dernier. Le spécialiste des applications digitales pour l'hôtellerie a bâti une "web factory" sur le cloud de l'Américain. Objectif : permettre à ses clients hôteliers de mettre en œuvre et opérer leur site internet. La plateforme fait appel à Lambda pour orchestrer leurs déploiements via le réseau mondial de diffusion de contenu d'AWS, Cloudfront. "Pour superviser nos fonctions Lambda, nous avons recours à CloudWatch (l'outil de monitoring d'AWS, ndlr) car il fédère tous des logs de nos applications sur AWS, y compris ceux en provenance d'autres services cloud d'Amazon", explique Fabien Bourdier. "C'est vrai que l'ergonomie de CloudWatch n'est pas optimum et la navigation pas évidente. Mais cette brique reste un vrai plus."
Pour les entreprises orientées multi-cloud, une solution fédérant des indicateurs de performance en provenance de plusieurs providers de FaaS pourra se révéler nécessaire. "C'est l'objectif que nous nous sommes fixé chez Datadog. Notre plateforme a pour but d'unifier à terme en un point unique les métriques, logs et traçabilité AMP (pour Application Performance Monitoring, ndlr) des applications serverless quel que soit le fournisseur de cloud chez lequel elles sont installées", confie Daniel Langer. Datadog ira puiser à la fois au sein des outils de supervision des providers, mais également au niveau des fonctions elles-mêmes. Exit les agents de supervision à disséminer au sein de l'architecture. Logique, puisque le serverless permet de s'abstraire de la couche serveur. Par définition, il n'y donne donc pas accès.
Et Daniel Langer de conseiller pour finir : "Mieux vaudra se limiter aux logs qui peuvent être récupérés de manière différée sans gêner l'exécution, et ne pas chercher à récupérer des métriques au niveau des fonctions car les requêtes http nécessaires pour le faire risquent de grever les performances."