Le dirigeable de Flying Whales vole déjà… dans les nuages d’AWS

En 2024, le LCA60T permettra de rapatrier le bois depuis les forêts des Pyrénées et les Alpes sans utiliser de camions. D’ici là, il faut le concevoir. Or, la startup n’a pas les moyens de s’offrir un supercalculateur.

Le projet du dirigeable LCA60T est né en 2012 de la volonté des ministères de l’Économie et de l’Écologie d’augmenter la production de bois, notamment en déchargeant d’un coup 60 tonnes d’arbres pyrénéens et alpins par les airs, plutôt qu’aller les chercher avec une enfilade de camions. La startup bordelaise Flying Whales s’acharne depuis lors à concevoir l’appareil pour qu’il puisse prendre son envol dès 2024. L’entreprise a trouvé dans le cloud public d’AWS les importantes ressources en calculs qu’elle ne pouvait pas s’offrir sur site.

Suite de l'article ci-dessous

« La complexité d’un dirigeable est similaire à celle d’un avion. Ici, nous devons concevoir l’aérodynamique externe, faire des études thermiques (ce qui est très important pour un dirigeable puisqu’il flotte), évaluer ses efforts critiques selon la charge… », explique Guillaume Martinat, ingénieur en chef de l’aérodynamique chez Flying Whales.

« Surtout, nous devons surmonter deux difficultés. La première est que nous sommes une entreprise relativement jeune qui ne peut pas s’appuyer sur des données historiques. La seconde est la taille du dirigeable : en soufflerie, une maquette longue d’un mètre donne une idée assez éloignée des comportements qu’aura notre appareil long de 200 mètres et large de 50. Nous sommes donc condamnés à faire beaucoup de simulations », ajoute-t-il.

Selon lui, la simulation présente l’intérêt d’éprouver le comportement de l’appareil en taille réelle, mais elle nécessite en aérodynamisme des machines de calcul très spécifiques. « Le domaine fluide autour du dirigeable est un maillage de 40 à 60 millions de points qui sont reliés entre eux par 300 à 400 interactions. Pour simuler les comportements de tous ces points interconnectés, la puissance processeur importe moins que la latence mémoire et la vitesse du réseau entre les nœuds de calcul, deux éléments assez coûteux. Un cluster qui aurait les caractéristiques adéquates coûte des centaines de milliers, voire des millions d’euros. »

Le cloud AWS pour des ressources illimitées, à la demande, au meilleur prix

Après avoir mené des essais sur des petits clusters de 200 cœurs – saturés lorsqu’il fallait faire des calculs, mais sous-utilisés la plupart du temps –, Flying Whales a l’idée de passer par des ressources en cloud lors d’une visite au forum Teratec fin 2018. « L’intérêt du cloud est que vous n’avez plus besoin de chercher à amortir votre matériel. Vous ne payez que pour les ressources que vous utilisez, quand vous les utilisez », dit Guillaume Martinat.

Une autre option, plus économique sur le papier, mais non retenue lors de Teratec, consistait à passer par le Genci. Le Genci est l’entité publique qui possède les ressources en supercalcul des centres de recherche en France ; il accorde gratuitement du temps de calcul aux entreprises qui planchent sur des techniques de pointe.

« Le Genci a des machines très performantes, mais pour y accéder, il faut répondre à un appel d’offres qui a lieu tous les six mois. Le problème est qu’il faut savoir précisément six mois à l’avance de quelle puissance vous aurez besoin. Alors qu’en cloud, nous bénéficions de l’élasticité. Les ressources sont théoriquement infinies : nous pouvons décupler les ressources que nous utilisons d’une semaine sur l’autre si nécessaire. »

Guillaume Martinat compare trois fournisseurs de services de calcul en cloud selon leurs performances brutes, leur coût et leur qualité de service. « Nous voulions travailler avec des gens qui comprennent notre langage », dit-il. Rapidement, AWS l’emporte dans ces trois critères.

« Concernant les performances, AWS est le seul à avoir une offre qui nous permet de monter en charge de manière linéaire. Dans leur catalogue d’infrastructures virtuelles, nous choisissons un certain nombre de machines virtuelles EC2 et nous les interconnectons avec un réseau Elastic Fabric Adapter. »

« La magie de ce système est qu’en deux heures, nous calculons l’aérodynamique sur une matrice de 30 millions de points avec leurs interactions à partir de 300 cœurs. Quand nous voulons faire un calcul plus poussé sur une matrice de 60 millions de points, il nous suffit d’activer 600 cœurs pour que le calcul dure toujours deux heures. Et si nous multiplions le nombre de cœurs par quatre, nous obtenons tout simplement nos résultats quatre fois plus vite », détaille l’ingénieur en chef, qui évoque un gain de productivité pour ses équipes.

Côté coût à la performance, Guillaume Martinat assure n’avoir pas trouvé de tarifs plus avantageux chez les concurrents d’AWS. En l’occurrence, il utilise pour les calculs les plus lourds des machines virtuelles C5n à base de 72 cœurs x86 Xeon à 3,4 GHz, 144 Go de RAM et qui disposent d’une connectivité réseau en 100 Gbit/s. Pour les calculs plus courants, il opte pour des machines virtuelles C6gn à base de processeurs ARM 64 bits Neoverse, en 64 cœurs virtuels et 128 Go de RAM. Elles offrent la même connectivité réseau et des performances quasiment similaires, mais elles sont 40 % moins chères. 

« Il est difficile de donner un prix exact, car nous achetons du temps à la seconde sur ces machines virtuelles par l’intermédiaire du service Spot. Celui-ci consiste à payer moins cher en allant puiser dans les ressources d’AWS non utilisées à un instant T par ses autres clients », indique Guillaume Martinat.

Jongler entre les ARM, les x86, le stockage Lustre, le stockage S3

Il explique réserver les machines virtuelles ARM aux calculs stationnaires qui durent environ deux heures. Les machines virtuelles x86 sont utilisées dans les calculs itératifs, où l’on détermine plusieurs fois les valeurs de tous les points du maillage pour simuler leur évolution dans le temps. « Les VM ARM sont 15 % moins rapides que les VM x86. Sur un calcul stationnaire, il n’est pas pénalisant de passer 15 % de temps en plus à attendre. En revanche, sur des calculs itératifs qui prennent plusieurs fois deux heures, les minutes qui s’ajoutent à chaque fois peuvent devenir rédhibitoires. »

En pratique, les équipes de Guillaume Martinat modélisent pendant plusieurs jours un maillage pour le dirigeable sur leurs stations de travail Linux, avec le logiciel Omnis de Cadence (anciennement Numeca). Il s’agit en l’occurrence de stations Dell avec des GPU Nvidia P400. Les calculs sont quant à eux exécutés par le logiciel OpenFoam qui fonctionne donc sur les VMs d’AWS, en Linux. OpenFoam est une solution Open source, mais validée industriellement : il est notoire que Volkswagen l’utilise abondamment.

Flying Whales a préparé en amont trois images de VMs qu’il redéploie en ligne à chaque fois qu’il a besoin de faire des calculs : une image OpenFoam pour x86, la même pour ARM et une troisième avec des outils de visualisation. Cette dernière est déployée sur un autre type de VM, équipée de GPU virtuels.

Les données en cours de calcul sont chargées sur le service de stockage FSX d’AWS, qui correspond à un cluster de stockage Lustre. Les résultats sont ensuite archivés sur du stockage objet S3 classique d’AWS. « FSX a un certain coût, calculé à sa taille. Comme nous n’utilisons ce stockage qu’à chaque fois que nous lançons un calcul, nous ne le surdimensionnons pas. Au contraire de S3 qui, lui, a un coût marginal », précise notre interlocuteur. Il ajoute que, selon les cas, de nouveaux calculs peuvent recharger dans FSX des données précédemment stockées sur S3.

« Nous avons passé l’essentiel de l’année 2019 à faire des tests pour valider la solution sur AWS. Nous avons commencé à utiliser intensivement la solution en 2020, quasiment au même moment qu’ont débuté la crise sanitaire et ses mesures de confinements. Utiliser des VPN sur nos PC portables, pour accéder depuis chez nous à nos stations graphiques, et exécuter les calculs sur AWS, nous a permis de continuer à travailler sans difficulté. »

Une utilisation sans accroc depuis un an

Au bout d’un an, Guillaume Martinat se félicite d’une utilisation sans accroc. « Nous avons aujourd’hui accès à des ressources que nous n’aurions même pas imaginé possibles il y a cinq ans. Les gains de productivité dépassent toutes nos attentes, c’est une vraie bonne surprise », commente-t-il.

Il témoigne être même parvenu à se sortir de situations difficiles avec une simplicité déconcertante. « À un moment, nous avons voulu simplifier certains modèles de calcul. Le problème est que nous avions été trop optimistes et que nous nous sommes rendu compte au dernier moment que nos résultats ne convenaient pas. Il nous fallait rattraper le temps perdu. En quelques clics, nous avons eu la possibilité de passer de 5 à 7 calculs en parallèle sur 2 000 cœurs à une vingtaine de calculs simultanés sur 7 000 cœurs. Cela s’est fait sans aucun problème, c’était inespéré. »

Et, surtout, il loue l’assistance d’AWS chez qui, justement, il a trouvé des interlocuteurs qui parlent le même langage que lui. « Nous avons eu besoin de l’aide d’AWS pour installer et configurer OpenFoam sur leur architecture. Ils l’ont mis en place très rapidement, bien plus que ce que nous aurions pu le faire. En tout, entre les tests de fonctionnement et les processus de décision, l’opération a pris moins de deux semaines. Sans eux, cela aurait été bien plus long. »

« Aujourd’hui, l’infrastructure n’est plus un problème. Notre stratégie consiste juste à chercher les coûts les plus bas », conclut-il.

Pour approfondir sur ARM

Close