Air France-KLM refactorise son application de maintenance prédictive pour le cloud

Le groupe aérien vient de porter sur AWS son application Prognos. Initialement développée pour le sur site, la solution est maintenant proposée dans une version cloud à d’autres compagnies.

Comme beaucoup d’acteurs du secteur aéronautique, Air France-KLM et sa filiale maintenance Air France industries s’est intéressé très tôt au Big Data. En analysant les données générées par les milliers de capteurs qui équipent les avions de ligne, la mise en œuvre d’algorithmes permet de passer d’une maintenance préventive à une maintenance prédictive, synonyme d’économies et surtout de moins d’appareils immobilisés pour cause de panne.

Suite de l'article ci-dessous

Dès 2016, Air France Industries a mis en production Prognos, sa propre application de maintenance prédictive, suivant en cela les initiatives de General Electric, Honeywell et Safran, mais précédant Aviatar - le service que Lufthansa Technik a présenté un an plus tard - ou que le service Skywise d’Airbus, lui-aussi lancé en 2017.

Le choix technique réalisé alors par l’IT du groupe Air France-KLM est assez classique pour une plateforme Big Data : un cluster Hadoop/Spark déployé sur site. Une architecture complétée d’une base de données MongoDB pour stocker les résultats des algorithmes prédictifs et les présenter aux utilisateurs via une plateforme Web Tomcat.

Depuis, cette plateforme a été amenée à évoluer - comme l’explique Solène Richard, Data Scientist & Project Coordinator, Air France-KLM Group lors de la conférence Xebicon 2019.

« Prognos est exploitée depuis 2016 afin de monitorer la flotte Air France-KLM. Nous avions développé cette application sur site mais nous avons commencé à réfléchir à passer dans le cloud à partir de 2018 [...]. Des compagnies aériennes, dont Air France Industries assure la maintenance de la flotte, étaient elles-aussi intéressées par ce service. Nous souhaitions étendre l’utilisation de Prognos et le commercialiser auprès de ces compagnies ».

Pour effectuer le passage à l’échelle, l’équipe projet s’est tout naturellement intéressée au cloud. « Le cloud nous permettait de consommer les ressources informatiques dont nous avions besoin, au moment où nous en avions besoin. En outre, un acteur du cloud global nous permettait aussi d’être au plus près de clients, qui sont localisés un peu partout dans le monde, et éviter ainsi tout problème de latence ».

Un changement de plateforme sans impact sur le plan fonctionnel

Pour les nouveaux utilisateurs de Prognos, la plateforme technique cloud fonctionne exactement sur le même principe que son ancêtre « on-prem ». Prognos collecte et traite les données générées par les équipements des avions. Les algorithmes mis au point par les Data Scientists d’Air France-KLM génèrent leurs prédictions et une IHM les présente aux responsables de la maintenance.

Pour l’IT du groupe, le refactoring de la chaîne applicative Prognos a été, évidemment, beaucoup plus complexe à mener. « Nous avions l’habitude de concevoir des architectures sur site. Le cloud nous a apporté de nouvelles manières de faire » explique Julien Maréchal, Responsable IT Cloud & Open Systems & Big Data infrastructure services chez Air France-KLM Group.

« Outre le volet technique, opérer cette application dans le cloud supposait aussi de porter une grande attention à la partie financière. On ne fait pas du cloud comme on fait du on-premise. Il faut que cette notion soit intégrée dès le démarrage du projet. En outre, comme il s’agit d’une application qui est commercialisée, on se doit d’être scalable - c’est-à-dire pouvoir grossir et répondre aux demandes des clients sans avoir des contraintes opérationnelles d’investissement et de mise en place de nouveaux matériels. »

Priorité aux services managés et au Serverless

Parmi les grands principes édictés pour ce portage, la DSI d’Air France-KLM veut privilégier au maximum les services managés. Avant même de choisir le fournisseur cloud, le premier travail de l’équipe de Julien Maréchal a été de vérifier quels services existaient déjà sous forme de services managés sur le marché puis d'effectuer un mapping de l’existant avec les plateformes cloud... sachant que l’architecture globale de l’application ne devait pas être remise en cause.

Au final, c'est AWS qui est choisi.

« Une fois ce choix fait, nous avons refait le mapping et le design d’architecture pour effectuer le même traitement de la donnée. Ce design d’architecture achevé, il faut parvenir à assembler ces services entre eux et sur ce point, nous voulions que tout soit automatisé, donc sans aucune action humaine - depuis le traitement des données jusqu’à l’affichage des prévisions dans l’IHM. »

Pour coder l’application, l’équipe projet a privilégié l'usage du « Function as a Service ». Des fonctions Serverless AWS Lambda permettent le chargement des données avion, leur filtrage et leur traitement automatique dès le moment où elles sont disponibles, puis l’exécution des différents services managés jusqu’à la production des prévisions de panne.

Pour couvrir l’intégralité de cette chaîne, les ingénieurs ont opté pour un nombre impressionnant de services managés AWS. S3 pour le stockage des données, SQS pour le messaging, EMR (Hadoop/Spark) pour les calculs, mais aussi la base NoSQL DynamoDB pour stocker les résultats d’analyse, Beanstalk /ELB, Lambda, Cognito et un peu d’EC2.

« Porter une application on-premise vers le cloud n’a pas été un changement fondamental au niveau du code, mais il y a des changements d’interactions. Typiquement, nous utilisions MongoDB sur site or il n’y avait pas de MongoDB en service managé chez AWS. Nous avons dû revoir nos connexions dans le code pour supporter DynamoDB » résume le responsable. Il ajoute qu' « un point très important porte sur l’aspect financier, le "Pay as you Consume". [...] Alors que notre infrastructure sur site tourne en continu, dans le cloud, nous ne démarrons nos Managed Services EMR qu’à la demande, avec des fonctions Lambda. Les algorithmes vont tourner sur Hadoop uniquement quand ils doivent traiter de nouvelles données. Ils s’arrêtent ensuite automatiquement, ce qui permet d’optimiser les coûts de cette infrastructure. »

De leur côté, les Data Scientists n’ont visiblement eu aucun mal à mette en œuvre AWS Sagemaker pour élaborer leurs algorithmes et réaliser les apprentissages de leurs modèles. Ils y ont retrouvé leurs outils et framework Open Source habituels, à savoir le notebook Jupyter ou TensorFlow.

L’Infrastructure as a Code, une clé vers le multi-cloud

Un autre point-clé de ce projet de refactoring a été la volonté des « Ops » de privilégier l’approche « Infrastructure as a Code ».

« Le cloud était quelque chose de nouveau pour nous et comme nous travaillons en DevOps, nous avons souhaité masquer ce volet cloud via l’Infrastructure as a Code. »

Ainsi, pour le volet Ops de ce projet, la DSI n’a pas souhaité mettre en œuvre les outils d’administration proposés par AWS, afin de limiter au maximum l’impact d’un changement de plateforme cloud dans le futur.

L’idée a été de mettre pleinement à profit Terraform, mis en œuvre par les équipes Ops pour opérer la plateforme sur site d’Air France KLM. « Nous faisons de l’automatisation dans notre datacenter depuis 2007 pour l’ensemble des services que nous délivrons sur site ».

Lorsque Air France-KLM a lancé ses premiers projets Big Data en 2010/2011, le déploiement de l’ensemble des briques logicielles a été totalement automatisé via cette plateforme qui s’appuie essentiellement sur Ansible et Terraform. « Nous voulions éviter d’avoir à supporter les spécificités ou un langage par type de cloud. Notre plateforme d’automatisation doit pouvoir prendre en charge n’importe quelle solution, que celle-ci soit on-premise ou dans le cloud. C’est la raison pour laquelle nous avons fait le choix de Terraform. »

Cette approche doit permettre à l’IT du groupe de négocier une probable évolution vers le multi-cloud et l’arrivée d’autres fournisseurs cloud dans le portefeuille de services de l’entreprise.

Reste encore à la DSI à intégrer ces nouvelles composantes cloud à sa chaîne de CI/CD basée sur Micro Focus et Atlassian, de même qu’automatiser le traitement des fichiers de logs issus de ces briques AWS dont le traitement reste encore local.

La prochaine étape sera la mise en œuvre d’une solution de gestion des logs à base d’ELK. La question d’opter pour une solution cloud ou sur site pour Air France - KLM en interne reste encore à trancher.

Pour approfondir sur DevOps et Agilité

Close