La mesure en continu dans le devops, ou comment piloter facilement l’efficience de ses applications

Posted on by Olivier PHILIPPOT
Reading Time: 5 minutes

Le « time-to-market » des services numériques est devenu crucial pour la compétitivité des entreprises. Les pratiques actuelles de développement vont donc dans le sens d’une plus grande agilité, et de déploiements toujours plus rapprochés..

Dans ce contexte sont apparues les pratiques DEVOPS qui essaient de répondre à ce besoin. Cela se traduit par (d’après l’excellent Devops for Dummies) :

  • Des tests réalisés en continu,
  • Des boucles d’amélioration courtes,
  • Une surveillance étroite de la qualité en production.

Une approche DEVOPS réussie s’appuie sur des métriques de pilotage permettant d’infléchir rapidement les pratiques. Le but est d’éviter les « effets tunnel » qui amènent des découvertes tardives de défauts fonctionnels ou de bugs. Il en va de même pour les problèmes de consommation de ressources. Une lenteur de l’application ou une surconsommation d’énergie découverte trop tard (après la mise en production) aura un impact négatif sur l’image de l’application et le coût de correction sera important. Parmi les métriques à suivre dans une approche DEVOPS agile, la performance de l’application et sa consommation de ressources sont donc cruciales, car elles auront un impact non négligeable sur la qualité de l’application finale.

La mise en place de pratiques DEVOPS apporte l’opportunité de mettre en place des pratiques de mesure en continue de l’efficience. Les métriques seront choisies en fonction des priorités du projet : performance, mémoire, énergie… Au même titre que le devops utilise les pratiques du continuous integration ou du continuous deployment, nous ajouterons le continuous measurement.

Voici les points clé de cette démarche :

Des tests réalisés en continu

La mise en place du devops requiert de valider le bon fonctionnement de l’application à la suite des tests d’intégration : le build est OK, les tests unitaires aussi, mais quid après ? Ceci implique la mise en œuvre de tests fonctionnels automatisés. Même si ces tests ne sont pas couvrants au début de la démarche, ils doivent permettre de vérifier le minimum requis pour l’application (cf. la notion de produit MVP). Ces tests pourront être complétés par des tests de charge pour s’assurer de la tenue fonctionnelle quel que soit le nombre d’utilisateurs.

La mise en place des tests fonctionnels automatisés est une opportunité pour mesurer les ressources consommées (temps de réponse, consommation d’énergie, consommation de mémoire…) de façon fine. On peut faire un parallèle avec les tests de charge, où l’on va surveiller non pas uniquement la tenue fonctionnelle mais aussi la consommation CPU du serveur par exemple.Aujourd’hui, il est possible – et fortement recommandé – d’inclure cette approche « ressources » sur tous les types de tests, y compris les tests fonctionnels.

A l’opposé, une démarche DEVOPS sans tests automatisés est un frein à la mise en place de mesure de consommations en continu. Cette absence d’automatisation des tests est souvent symptomatique d’un manque de maturité de la démarche. Notez que ce nouveau besoin de mesurer en continu renforce la nécessité d’automatiser les tests. Il s’agit donc d’un cercle vertueux d’amélioration de la démarche.

Des tests réalisés en continu, même sans tests fonctionnels

Mais l’absence de tests automatisés n’est pas totalement rédhibitoire à la mesure en continu. En effet, des premiers tests simples (lancement de la page web, ou d’une application mobile) peuvent permettre d’obtenir les premières mesures. On pourra citer par exemple Web Page Test pour la performance web.

Pour la mesure des consommations de batterie et de ressources, nous avons choisi de mettre en place le GREENSPECTOR Benchmark Runner : il s’agit d’une fonctionnalité qui va lancer un test standardisé et pré-automatisé. Le scénario du test va lancer l’application (ou une url) sur un appareil mobile, va attendre (pour mesurer la consommation en idle), scroller puis mettre l’application en tâche de fond. Ce test est prêt à lancer, ce qui permet aux équipes qui ne disposent pas de tests automatisés de disposer de leurs premières évaluations en continu. Même si nous ne validons pas le fonctionnel, nous mesurons les consommations de ressource et d’énergie de différents états de l’application.

Des plates-formes de mesure

Une des clés de la mesure en continu est de mesurer dans un environnement « le plus proche possible » de la production. C’est aussi une des clés de la démarche devops. Pour cela il sera nécessaire d’exécuter les mesures sur des plates-formes bien définies :

  • Les tests de charge sur la pré-production (environnement iso -prod) ;
  • Les tests de performance web sur un maximum de plates-formes diversifiées ;
  • Les tests d’efficience sur des appareils mobiles (smartphones, tablettes) ou PC réels.

Pour les tests sur appareils mobiles, utiliser un banc de test maison permettra d’initier la démarche. Des services de device labs en ligne (Saucelab, Xamarin Test Cloud, Perfecto Mobile…) permettront de lancer des tests sur différents appareils mobiles réel ou – le plus souvent – émulés. Chez GREENSPECTOR, nous offrons aussi un service « Power TestCloud » permettant de tester la consommation d’énergie sur différents appareils réels – car seuls des appareils réels permettent des mesures crédibles de consommations de ressources.

La solution idéale est bien sûr de mêler devices locaux et distants pour bénéficier d’un panel exhaustif de plates-formes : devices locaux plus représentatifs et facilement paramétrables, devices online plus nombreux et dont la gestion est externalisée.

A noter que la diversité se fera aussi sur la variation des configurations : lancer les tests sur différentes connexions (2G, 3G, WiFi…) permettra d’augmenter la connaissance du comportement du système dans différentes situations. C’est un des avantages important de la mesure en continu : avoir la capacité de couvrir plus de configurations grâce à l’automatisation du processus de mesure.

Et… le pilotage de la mesure

Une fois la mise en place des outils et des tests effectuée, il ne suffit pas de laisser les mesures se dérouler en continu, encore faut-il les analyser ! Pour cela il est important de placer des seuils pour piloter les ressources. On parlera de « budget » de ressources ou de batterie consommée. C’est la démarche proposée par la méthodologie RAIL (Response Animation Idle Load) pour le pilotage de la performance.

Le modèle précise :

  • moins de 100 ms pour les temps de réponse utilisateur,
  • 10 ms pour produire une frame d’animation,
  • Regrouper les blocs par 50 ms pour maximiser l’idle,
  • Délivrer un contenu en moins de 1 000 ms.

Ces limites vont permettre d’initier le pilotage de la mesure en continu. Si l’on suit ces métriques, dès qu’un seuil est dépassé un avertissement peut être notifié à l’équipe de développement ; dans les cas graves, le déploiement sera bloqué.

Nous utilisons la même démarche pour l’efficience, en mettant en place des « budgets énergie ». Par exemple : telle fonction ne doit pas conduire à doubler la vitesse de décharge du smartphone.
Ces seuils sont des critères d’acceptation importants dans le cycle de déploiement du devops. Ils doivent permettre à l’équipe de ne pas passer de temps sur l’analyse des mesures et d’être sereine sur la mise en production de la solution : il n’y aura pas de surprise de performance et de ressource découverte par les utilisateurs finaux.

Une démarche d’amélioration continue

La mise en place de cette mesure en continu et des seuils permet de s’engager dans une démarche d’amélioration continue comme le préconisent les pratiques Devops. En effet, au fur et à mesure des déploiements, l’équipe va avoir une meilleure connaissance de l’impact des fonctionnalités. A chaque intégration fonctionnelle ou technique dans l’application, l’évolution de la consommation de ressources va être visible.

Par exemple pour une application mobile, si on intègre une animation, la mesure va montrer une augmentation importante de la consommation d’énergie. A ce moment, l’équipe va pouvoir corriger immédiatement : suppression, choix alternatif (barre de progression par exemple), discussion avec le marketing, la maîtrise d’ouvrage…

Cette connaissance de l’impact des fonctionnalités va se compléter d’une connaissance des données ressources. En effet, la mesure en continu va rendre les données (de performance, de CPU, d’énergie, de volume de données échangées…) plus familière pour l’équipe, au même titre que d’autres métriques comme par exemple le taux de couverture des tests.

On peut citer la démarche poussée de Facebook sur la mise en place de mesures de performance qui permet de détecter des régressions à tous les commits de code. Sans aller jusqu’à ce niveau, l’amélioration continue est possible pour toutes les équipes !

L’amélioration continue se fera dans le temps en réduisant les seuils d’alerte. Une fois que l’équipe maîtrisera les seuils (pas de dépassement, meilleure qualité…), elle pourra de façon collégiale (avec le product owner, les acteurs du projet…) les diminuer pour réduire la consommation de ressources et proposer une application encore meilleure aux utilisateurs.

Arriver à un bon niveau de maturité (automatisation de tous les cas fonctionnels, tests sur un maximum de plates-formes…), cela peut prendre du temps. La démarche doit être progressive mais les premières actions sont simples. Lancer des premiers tests techniques dans un Jenkins par exemple, sur une seule plate-forme, sans mettre forcément de seuil permettra d’avoir des premières mesure en continu. Il faut juste se lancer !