D'un serveur dédié à une infrastructure multi-cloud : l'évolution d'Infoclimat

Cet article a été rédigé par l'association Infoclimat dans le cadre de notre nouvelle série Give Me The Pen qui prête la plume de notre blog aux organisations de notre communauté.
Nous sommes ravis d'accueillir Frédéric Ameye, bénévole, vice-président de l'association Infoclimat et responsable de l'infrastructure et du site web https://www.infoclimat.fr/ depuis 2009 pour nous présenter l'historique des choix techniques et les challenges associés à leur évolution.

Infoclimat tire ses origines d’un groupe de passionnés qui a vu à la fin des années 90 l’intérêt du réseau Internet pour partager ses données météo au plus grand nombre : relevés météo, photographies, phénomènes dangereux,...

Principalement porté par un site Internet, l’initiative a grossi jusqu’à nécessiter des moyens informatiques importants et des coûts de bande passante exponentiels, nécessitant en 2003 la création d’une association loi 1901.

Aujourd’hui, l’association a un budget annuel de quasi 60.000€, 1800 adhérents, et s’auto-finance entièrement. Elle installe ses propres stations météo, réalise des actions pédagogiques sur le terrain et avec les établissements scolaires, et contribue à l’établissement d’un commun numérique, par l’ouverture de ses données.

C’est un peu comme OpenStreetMap ou Wikipédia, mais pour la météo !

L'évolution jusqu'à 7 millions de visiteurs

À l’époque, nous avions une dizaine de stations météo qui reportaient une donnée par heure.

Aujourd’hui, nous récoltons les données de 30.000 stations météo de part le monde, qui reportent toutes les demi-heures ou dix minutes, nous avons des algorithmes d’interpolation sophistiqués, des cartographies interactives, 6 milliards d’entrées dans nos bases de données, et des Téraoctets de cartographies. Sans compter un forum de discussion à 3.5 millions de messages, et un trafic annuel de 6 à 7 millions de visiteurs uniques.

Nos bases de données (MySQL) supportent un bon millier de requêtes par seconde, et il en va de même pour nos serveurs web (NGINX).
Et pour exploiter au mieux toutes ces données météo, nous utilisons massivement des serveurs de cartographie (mapserver) et de nombreux codes de calcul scientifique qui sont assez intensifs en CPU et en accès disques, des moteurs de recherche (Elastic/Sphinx) et bien évidemment de nombreuses couches de cache applicatif (memcached/Redis).

Notre site a une réputation dans la qualité des données affichées, mais aussi dans le confort de navigation. Nous n’avons pas de publicités ou de trackers, c’est un choix de notre part, et nous veillons à ce que nos pages soient efficaces au chargement, malgré la quantité de données et la complexité des interfaces (graphiques, cartographies). Nous souhaitons le moins possible reposer sur des services externes qui pourraient disparaître du jour au lendemain (et en 20 ans, on en a vu !), et ainsi assurer la pérennité de nos données.

La sécurité et la sûreté de nos données nous tient beaucoup à cœur : la masse de données météo collectée et contrôlée minutieusement par nos bénévoles est inestimable, et nous portons une grande attention aux données personnelles de nos adhérents et visiteurs.

Le chemin vers une architecture robuste

De 2004 à 2015, nous gérions nos machines en “bare metal”, à la main, ce qui nécessitait un investissement bénévole toujours plus conséquent.

En 2015, nous sommes passés à une solution “Dedicated Cloud” de notre hébergeur historique OVH, pour remplacer nos dix serveurs dédiés. L’objectif : quitte à payer un peu plus cher, simplifier la gestion pour les bénévoles en charge de l’infra. La solution était basée sur VMWare vSphere, et, à performances égales, devait coûter environ 1.5x plus cher que nos machines bare-metal, mais avec une bien meilleure aisance dans la gestion.

L'image ci-dessus montre notre architecture de 2006, qui était basée sur des machines placées sur un “cloud dédié” à base de vSphere. La solution coûtait quelques milliers d’euros par mois à l’association, et quelques cheveux blancs par semaine à l’auteur de cet article.

Nous avons été assez échaudés par cette solution : après une très longue migration, les performances n’étaient pas acceptables, le site web était souvent en panne, et nous avons eu quelques corruptions de machines virtuelles et de bases de données qui nous ont donné de grosses nuits blanches et des pertes de données. Nous avons découvert quelques bugs de l’hyperviseur qui ont été corrigés par le fournisseur et ont stabilisé la situation, nous avons aussi appliqué d’énormes optimisations dans nos applications, mais le constat était clair : la solution n’était pas assez performante, et aurait nécessité un coût 2 à 3x plus important qu’avant pour être suffisamment stable.

En 2016, nous avons dit stop à cette solution, et sommes repartis sur des machines dédiées, avec les idées un peu plus claires sur les erreurs à ne pas refaire.

L'architecture de 2020 ci dessus était axée sur l’aspect “stockage”. Les flux applicatifs ne sont pas représentés, mais représentent environ ¼ de machines pour le back-end (NGINX, PHP), ¼ de machines de calcul (modèles météo, générations de cartographies), ¼ de machines de stockage (bases de données et serveurs de fichiers), et ¼ de machines spécialisées (serveurs de tuiles, caches, moteurs de recherche).

En particulier, nous avons toujours un peu “buté” sur le stockage de nos volumineux contenus (cartographies mondiales, photos,...), et avons évolué progressivement. Pendant quelques années, nous avons administré notre propre cluster GlusterFS. C’était très satisfaisant dans l’utilisation, la scalabilité et la sûreté des données, mais la gestion était très complexe, à cause d’un parc de serveurs hétérogène (versions de Debian, et donc versions du protocole GlusterFS). Nous sommes revenus à une solution plus simple, à savoir un unique serveur de fichiers - cela est cependant plus risqué.

Une stratégie multi-cloud pour assurer la resilience

À l’avenir, nous souhaiterions basculer vers une solution plus résiliente, mais cela nécessite d’importants travaux sur notre base de code existante (plus de 400.000 lignes de code).

Depuis toujours, nous avons apporté un grand soin à nos backups, qui étaient chiffrés puis envoyés sur des espaces de stockage fournis par notre hébergeur. Nous étions bloqués par la taille limitée de ces espaces, qui rendaient les backups compliqués à gérer. Avec les téraoctets qui s'accumulent, c’est vite devenu bloquant et stressant.

Nous avons commencé par mettre en place un NAS chez un de nos administrateurs fibré, pour effectuer une sauvegarde “à froid”, chiffrée, de tous nos contenus (une trentaine de téraoctets aujourd’hui).

En 2021, nous avons comme beaucoup d’acteurs revu un peu notre stratégie, et avons compris qu’avoir tous ses œufs dans le même panier n’était pas une bonne idée, et avons cherché d’autres hébergeurs chez qui nous pourrions stocker nos backups, avec une grande flexibilité dans l’espace de stockage.

La solution d’Object Storage de Scaleway nous a paru la plus pertinente : nous avons éliminé d’office tout acteur des GAFAM, et souhaitions un hébergeur français, pour coller à nos valeurs historiques.

Pour ce faire, nous utilisons Duplicity et Rclone pour gérer nos sauvegardes incrémentales sur différents buckets Object Storage, et gérer finement le cycle de vie de nos sauvegardes. On dort l’esprit bien plus tranquille depuis cette mise en place !

La totalité de l’infrastructure chez nos deux hébergeurs nous coûte environ 15.000€ par an, en hausse régulière face à l’augmentation du nombre de données hébergées et les fonctionnalités toujours plus poussées !

Les premiers pas vers le multi-cloud

Nous avons depuis longtemps la volonté de tirer parti du meilleur des technos : les serveurs dédiés pour les processus sensibles où les performances sont critiques, mais pouvoir être flexibles dans la gestion du stockage et de la charge (et donc du budget). Aujourd’hui, notre volonté est de basculer progressivement dans un mode “hybride”, pour ajuster au mieux les coûts, et surtout simplifier la gestion, le déploiement, et la montée en charge.

Nous avons donc commencé à expérimenter l’interfaçage de notre infra existante avec une infra chez un autre provider, Gandi, pour autre chose que des backups :

• une des machines nous sert à faire de la répartition de charge sur nos serveurs de cartes interactives (mapserver). Auparavant, nous avions de nombreuses latences à cause de leur surcharge, et les performances ont été considérablement améliorées grâce à cela. Un load balancer software sur une de nos machines permet de répartir la charge ou de faire du failover sur ces différentes machines_._
• une deuxième machine nous permet de faire de la réplication temps réel de nos bases de données MySQL, et donc de réaliser des sauvegardes sans downtime. Auparavant, nos sauvegardes étaient réalisées une fois par jour, la nuit, et verrouillaient le site pendant assez longtemps. Ce n’était pas satisfaisant, pour des raisons d’intégrité des données, et pour l’indisponibilité du site ! Grâce à cette machine, nous réalisons une réplication MySQL sur site distant, et avons éliminé tout downtime.

Aujourd’hui, nous souhaiterions aller encore plus loin, cependant, nous sommes bloqués par notre caractère bénévole : une seule personne s’occupe sur son temps libre de toute l’infra et de tout le développement depuis plus de 13 ans, et elle n’a pas la capacité d’aller plus loin. Pour cette raison, cette année nous recrutons notre premier salarié : un dév full-stack PHP/JS !

Nos prochaines étapes

Nous espérons bien recruter un DevOps pour nous aider à rendre notre architecture plus scalable, facilement déployable dans un contexte multi cloud, et rendre open-source tout ça, tout comme nos données sont Open-Data !

Avec cette personne, nous aimerions :

• rendre la totalité du backend résiliente, en ayant la possibilité d’héberger une partie de nos serveurs applicatifs (PHP) ailleurs, par exemple sur des instances Scaleway. Nous avons encore un peu de travail côté code et déployabilité pour rendre cela possible.
• apporter de la flexibilité sur nos systèmes de cartographie, en utilisant de l’Object Storage pour y stocker les fichiers source (Cloud-Optimized-GeoTIFF), et des instances dédiées pour les traiter. Cela nous pose encore quelques questions sur la performance des accès aux fichiers dans ce contexte (actuellement, nous utilisons des partages NFS !), et les éventuels coûts de bande passante (aujourd’hui, ~20TB par mois entre machines), mais les briques technologiques sont là. Cela nous permettrait de ne plus nous soucier de l’espace disque de nos machines.
• améliorer nos bases de données, et éliminer la complexité de gestion, en passant à des solutions managées type TimescaleDB. Cela nécessite aussi de très difficiles migrations sur nos applications, et une analyse de la réversibilité de la solution (nous voulons pouvoir reprendre la main à tout moment sur nos Téraoctets de données :-)) et de sa scalabilité à chaud.

Comment aider Infoclimat ?

Aujourd’hui, l’association cherche à recruter des salariés, pour accompagner le développement d’une telle infrastructure, ce qui demande un apport financier colossal pour une petite structure comme la nôtre — et grâce à nos adhérents et donateurs, nous allons y arriver !

Nous cherchons à diversifier nos soutiens et sources de revenus, pour assurer une stabilité dans la durée, nous invitons tous les acteurs de la tech’ à nous y aider, par exemple par des actions de mécénat financier, matériel ou de compétences

Évidemment, les développeurs, DevOps, infographistes et autres Data Scientists ou Cloud Architects sont les bienvenus pour nous aider dans cette tâche, à titre bénévole ou salarié selon nos ouvertures de postes.