Quelle démarche pour améliorer les performances d’une chaîne de traitements numériques ?

La practice HPC d’ANEO intervient régulièrement chez ses clients pour améliorer les performances de leurs chaînes de traitement numériques. Afin de répondre à ces demandes, ANEO a mis au point la démarche « OPTIMEO » permettant de proposer des actions bénéficiant l’effet de levier le plus important. Cette démarche est inspirée des méthodologies et outils utilisés en excellence opérationnelle pour améliorer la performance des processus industriels. Pour en savoir plus sur les outils de l’excellence opérationnelle, nous vous invitons à consulter l’excellent site de Christian HOHMANN (christian.hohmann.free.fr).

La méthodologie mise en œuvre dans OPTIMEO est adaptée de la DMAIC (Define, Measure, Analyze, Improve, Control), une méthodologie utilisée en excellence opérationnelle. En cinq étapes, cette méthodologie nous permet:
1) de définir les objectifs de l’optimisation ;
2) de mesurer la situation au départ, ce qui sera nécessaire pour mesurer les progrès accomplis ;
3) d’analyser la chaîne de traitement afin de déterminer les goulets d’étranglement des performances ;
4) d’améliorer la chaîne de traitement afin de maximiser les performances en limitant l’effet, voire en supprimant les goulets d’étranglement des performances ;
5) de maîtriser la chaîne de traitement améliorée afin de ne pas risquer de perdre les effets de l’investissement réalisé.

I – Définir les objectifs de l’optimisation

Pour pouvoir optimiser les performances d’une chaîne de traitements numériques, il faut tout d’abord définir ce que sont les performances de cette chaîne… Et ce n’est pas toujours simple !

Plutôt que de rester dans des notions abstraites, considérons l’exemple de la chaîne de traitement 3D pour les jeux vidéo : l’indicateur de performance le plus regardé par les joueurs pour juger des performances d’un moteur 3D est le débit d’image ou FPS (Frames Per Second). Les performances des différentes cartes graphiques sont exprimées en FPS ; les performances des différents moteurs sont comparées en fonction du FPS obtenu sur une configuration donnée pour une scène 3D donnée. Ces éléments peuvent laisser entendre que le seul objectif de la chaîne de rendu 3D est d’obtenir le débit d’image le plus élevé possible. On ne pourrait être plus éloigné de la vérité ! Un moteur capable de générer 1000 images par seconde mais avec une latence de 10 minutes ne pourra pas être considéré comme un « bon » moteur 3D. Dans le cas extrême, il est possible d’obtenir un débit d’image maximal en générant un film qui sera visionné bien après le début du traitement. Dans le cas des jeux vidéo, le moteur 3D est également soumis à des contraintes dites de « réactivité », c’est-à-dire que les éléments ne doivent pas mettre plus d’un certain temps pour apparaître à l’écran. Enfin pour satisfaire l’utilisateur (le joueur), un débit d’image et une réactivité élevés ne sont pas suffisants : il faut en plus que la scène affichée, avec une résolution élevée, soit suffisamment riche et complexe pour que le rendu soit satisfaisant. Pour être considérée comme performante, une chaîne de rendu devra donc assurer un débit suffisant, avoir une latence suffisamment faible et permettre le traitement de scènes suffisamment complexes.

De manière simplifiée, nous pouvons décomposer la performance d’une chaîne de traitement selon trois axes :
–          la latence correspond au temps requis pour effectuer un traitement ;
–          le débit correspond au nombre de traitement réalisables par unité de temps ;
–          la complexité d’un traitement est plus difficile à quantifier : elle représente d’une certaine manière la quantité d’opérations nécessaires pour effectuer un traitement et comprends donc des aspects fonctionnels de l’application comme par exemple le modèle physique employé.

En réalité, les performances d’une chaîne se décompose au moins sur ces trois axes. Ils correspondent au niveau de service offert par la chaîne de traitement. L’enjeu de l’optimisation des performances d’une chaîne de traitement doit donc se faire au regard du niveau de services requis par les utilisateurs. Les SLAs (Service Level Agreement) recensent les niveaux de services sur lesquels se sont accordée le fournisseur de la chaîne de traitement et ses utilisateurs. 

Dans notre exemple les SLA permettant le satisfaire un joueur sont :
–          la latence soit inférieure à 1ms afin de ne pas être perceptible ;
–          le débit d’image soit supérieur à la fréquence de rafraîchissement de l’écran ;
–          les scènes affichées soient d’une complexité suffisantes.
 

L’objectif de cette première étape de la démarche OPTIMEO est de caractériser les critères de performances de la chaîne de traitements étudiée. Cette caractérisation doit aboutir à des objectifs chiffrés, que nous appellerons « critères de performances » par la suite.

II – Mesurer la situation au départ

La seconde étape consiste à établir un état des lieux de la chaîne de traitements. Le premier objectif est d’aboutir à un protocole de mesure permettant in fine de mesurer les gains obtenus à l’issue du projet. La mise en œuvre de ce protocole nous permet de mesurer les performances de la chaîne de traitements selon les différents axes identifiés lors de la première étape et aboutit à identifier les SLAs qui ne sont pas correctement remplis.

La mise au point d’un protocole de mesure est une étape relativement délicate. En effet, il ne s’agit pas ici se simplement mesurer un temps mais de mesurer les éléments qui font que les performances de l’application sont ou non satisfaisantes. Il s’agit donc de définir précisément comment obtenir les métriques intéressantes, définir comment prendre en charge les phases de montée en charge et de ralentissement. Bien d’autres critères sont à prendre en compte comme l’environnement d’exécution. En production, une application peut tourner sur un ensemble de machines partagées avec d’autres applications. Selon la charge de celles-ci, les performance de l’application étudiée peut varier. À l’opposé, la procédure de mesure peut également impacter les performances : une sonde analysant le trafic réseau consommera un peu de puissance de calcul et pourra impacter les performances de l’application.  Naturellement, le protocole de mesure dépend de l’environnement client. L’implication des équipes de de développement et de production/exploitation de la chaîne de traitement est donc importante afin de bien cerner les contraintes à respecter pour éviter d’impacter les performances de l’application.

Enfin se pose la question du périmètre des mesures. Les besoins de l’utilisateur sont généralement définis pour une application dans sa globalité. Néanmoins, la démarche Optimeo peut n’être mise en œuvre que pour une petite partie de la chaîne. Comment dans ce cas faire correspondre aux critères de performances globaux des mesures localisées au périmètre étudié.

Vous l’aurez compris, à travers la mise au point d’un protocole de mesure, cette phase doit fournir les données permettant un diagnostic fiable et précis de l’état de la chaîne de calcul dans son environnement de production.

III – Analyser la chaîne de traitement

L’objectif de cette étape est de comprendre de manière la plus fine possible ce qui limite les performances de l’application. La première phase consiste en une analyse globale visant à identifier les étapes qui ne sont pas nécessaires – autrement dit les ressources de traitement qui sont gaspillées. Ensuite, des analyses plus poussées ont lieu en fonction des critères de performances qui ne sont pas satisfaits. Les approches utilisées peuvent alors varier. Par exemple, dans le cas d’un problème de latence, le profilage de la chaîne de traitement doit permettre d’identifier les étapes prenant la majorité du temps et dont l’accélération doit permettre de réduire significativement la latence globale. Par contre, dans le cas d’un problème de débit, l’approche est totalement différente. Elle repose sur une modélisation des flux afin de trouver le maillon de la chaîne qui limite le débit global.

Pour illustrer la différence de problématique entre une réduction de latence et une augmentation de débit, prenons l’exemple de la fabrication d’une voiture. Si l’objectif est de diminuer le temps requis pour assembler une seule voiture (problématique de latence), on cherchera à trouver une organisation permettant aux différents ouvriers et techniciens de travailler simultanément sans se marcher sur les pieds, quitte à ce que certaines personnes doivent attendre leur tour à certains moments. Si, par contre, l’objectif est de maximiser le nombre de voitures assemblées par jour (problématique de latence), la ressource bloquante n’est plus l’accès au véhicule mais la main d’œuvre : le travail à la chaîne sera généralement plus performant car aucun personnel n’aura à attendre. Par contre, le temps écoulé entre le début et la fin de l’assemblage d’une voiture (la latence de la chaîne) augmentera. Dans une chaîne de calcul, les mêmes principes s’appliquent : optimiser la latence peut mener à ne pas utiliser toutes les ressources de calcul en permanence alors que pour optimiser le débit, il convient de s’assurer qu’aucune ressource de calcul ne soit inactive.

Selon la problématique, la ressource contraintes ou goulet d’étranglement, peut varier. Dans notre exemple, il s’agit de l’accès au véhicule dans le cas d’un problème de latence ou la quantité de travail disponible dans le cas d’un problème de débit. Un des objectifs de l’analyse est donc de déterminer quelles sont les goulets d’étranglement des performances. Dans notre analyse, tous les éléments de la chaîne de calcul sont étudiés : algorithmes, architecture, implémentation, matériel, etc. Dans la mesure du possible, cette analyse s’appuiera sur des mesures effectuées en situation réelle de production afin de pouvoir prendre en compte les spécificités, en particulier matérielles, de configuration et de charges propres à ces environnements. De ce fait, cette étape requiert aussi bien l’implication des équipes de développement de l’application que celle des équipes de support et d’exploitation.

IV – Améliorer la chaîne de traitement

Cette étape vise à diminuer l’impact des goulets d’étranglement sur les performances globale de la chaîne de traitement. Pour cela elle s’appuie sur l’étape précédente afin d’agir sur les leviers d’optimisation les plus importants. Selon le cas, les améliorations proposées peuvent concerner aussi bien des mises à jour logicielles ou matérielles, voire aller jusqu’à la réécriture d’une portion de la chaîne de traitement et l’utilisation de matériels spécifiques (cartes accélératrices type GPU ou Xeon Phi).

À l’issue de cette phase, une mesure des performances obtenues doit permettre d’estimer les gains apportés par les différentes optimisations et de valider le respect des critères de performances.

V – Maîtriser la chaîne de traitement améliorée

L’objectif de cette étape est de pérenniser les gains obtenus au cours du projet. En effet, selon le contexte industriel, une chaîne de calcul peut être amenée à évoluer très souvent. Certains de nos client disposent de processus de développement et d’industrialisation permettant de faire évoluer la chaîne de calcul en fonction des demandes des utilisateurs sur un rythme hebdomadaire. Ces évolutions sont généralement minimes, néanmoins, leur impact sur les performances de l’ensemble de la chaîne peut être important. Par exemple, une modification fonctionnelle nécessitant la modification de deux lignes de codes à un endroit peut impacter la façon dont les données seront stockées en mémoire et donc les performances de tout le reste de l’application. Fournir au client les moyen de s’assurer que les gains obtenus dans le cadre de la démarche OPTIMEO ne seront pas annulés par une modification ultérieure est donc très important.

Pour cela, il peut être nécessaire de mettre en place des procédures de validation permettant de s’assurer que de futures évolutions ne mettront pas à mal les optimisations réalisées. La mise en place de ces procédures peut avoir un impact sur l’organisation des équipes de développement, de  support et d’exploitation, les procédures existantes,  la composition des équipes de développement et nécessiter des formations spécifiques des personnels.

Ces procédures de maîtrise peuvent nécessiter le mise en place d’outils permettant de détecter l’impact des nouveaux développement sur les performances des goulets d’étranglement. Ces outils devront vérifier que les conditions nécessaires pour permettre les optimisations restent remplies. Par exemple, il conviendra de vérifier que la façon dont la mémoire est allouée n’empêche pas le compilateur de mettre en œuvre ses optimisations. Afin de mettre en place ces outils, il peut être nécessaire de modifier le processus d’industrialisation des développements et l’environnement de tests. Enfin, il est alors également nécessaire de former les équipes impactées (équipes de développement fonctionnels, équipes d’industrialisation, équipes de support/exploitation, etc.).

Conclusion

La mise en oeuvre d’OPTIMEO se déroule en cinq étapes en suivant une méthodologie issue de l’excellence opérationnelle. À l’issue de ces cinq étapes, outre une amélioration des performances au regards des enjeux importants pour les utilisateurs, la mise en oeuvre d’OPTIMEO apporte un regard extérieur sur l’état des chaînes de calcul (performances, optimalité, environnement de développement, bonnes pratiques, etc.). C’est une occasion de prendre du recul sur les enjeux autant business que techniques de la chaîne de traitements et de les faire partager à l’ensemble des acteurs. Les différentes analyses ainsi que le travail nécessaire à la maîtrise de la chaîne conduisent également à la rédaction d’une documentation du fonctionnement de la chaîne de traitement et à transférer aux équipes de développement et d’exploitation les bonnes pratiques à appliquer aux projets logiciels sensibles à la question des performances de calcul.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *