Stage - Ingénierie des pipelines de données

Full Time

Job expired!

Proposition de thèse NPX
Observabilité
RQ1:
Problématique de recherche:
Lors de l'interrogation de PA pour extraire les données d'utilisation de HPC, des lacunes apparaissent. Ce processus d'interrogation crée à son tour davantage de lacunes entre l'utilisation réelle de HPC et l'utilisation enregistrée de HPC. (peut-être parce que PA n'observe pas passivement ou ne sauvegarde pas les données pendant cette action).
Question de recherche:
Comment pouvons-nous observer avec précision (ingénierie observable) les pipelines de données et rapporter une utilisation correcte de HPC?
Qu'est-ce que l'observabilité?
En général, l'observabilité est la mesure dans laquelle vous pouvez comprendre l'état interne ou la condition d'un système complexe uniquement à partir de la connaissance de ses sorties externes. Plus un système est observable, plus vous pouvez naviguer rapidement et précisément d'un problème de performance identifié vers sa cause profonde, sans tests ou codage supplémentaires.
Dans ce problème de recherche, l'observabilité serait utilisée pour la surveillance de l'utilisation de HPC.
Méthode de recherche (Solution possible):
Améliorer l'observabilité des grappes HPC est la clé.
•
Définir de nouvelles métriques et méthodes d'automatisation pour comprendre quand il y a une lacune.
•
Analyser la télémétrie d'observabilité, par exemple, pour identifier la fréquence d'une lacune significative qui doit être résolue.
•
Analyser la corrélation entre les métriques et les lacunes pour déclencher une solution pour corriger une lacune avant même qu'elle ne devienne trop grande.
Sur la base de ces points, nous pouvons développer un outil qui peut résoudre ce problème de lacune.
L'idée principale est d'observer passivement le cluster HCP afin de collecter les métriques clés utilisées par l'outil de solution. Cela permet à l'outil de fonctionner comme une file d'attente : une fois les métriques observées capturées, elles sont mises en file d'attente vers l'outil qui peut vérifier si le PA a une lacune par rapport à ce que l'outil a observé.
Problème avec la solution proposée:
Déclencher continuellement la base de données pour essayer d'atteindre un écart de zéro signifierait invoquer récursivement la mise à jour. Il serait donc nécessaire de déterminer un écart minimum acceptable pour le cas d'utilisation. L'important est d'éviter un écart à la fin de seuils spécifiques tels que la fin de la journée/fin de la semaine/fin du mois.
RQ2:
Problème de recherche:
La question principale tourne autour de l'écart entre l'utilisation réelle de HPC et l'utilisation enregistrée de HPC. La solution de ce problème doit être généralisée afin de résoudre d'autres problèmes de lacunes provenant de l'observabilité de HPC.
Question de recherche:
En appliquant la solution précédente à un système différent, peut-elle être généralisable ?
Méthode de recherche:
•
Analyser le système dans lequel nous voulons augmenter l'observabilité
•
Découvrir si nous pouvons mesurer certains paramètres qui peuvent être utilisés pour définir les métriques du système
•
Vérifier si ces nouvelles métriques peuvent être utilisées pour la solution précédente ;
Cette approche devrait nous permettre d'appliquer la logique généralisée et de la configurer en tenant compte de la structure du système, en utilisant donc une solution générique sur un système différent en personnalisant les métriques.
Références:
•
https://onlinelibrary.wiley.com/doi/epdf/10.1002/spe.3116
•
https://www.ibm.com/topics/observability
•
https://grafana.com/blog/2020/03/03/the-benefits-of-observability/
Tâche de résilience de sauvegarde
RQ3:
Problème de recherche:
Résilience du pipeline de données et de son infrastructure.
Question de recherche:
Comment pouvons-nous anticiper les circonstances mesurables qui peuvent mal tourner avec le travail ? (par exemple, les pannes de pipeline)
Méthode de recherche et solution proposée:
Définir les scénarios dans lesquels le pipeline a échoué:
•
Faire une analyse sur les problèmes précédents de pipeline et leurs rapports
•
Découvrir quelques cas limites
Travaux et Références connexes
Dans la littérature sur le HPC, certaines recherches ont été menées sur le système de sauvegarde. Une enquête sur la méthode de résilience du HPC : https://link.springer.com/article/10.1007/s11704-022-2096-3
Les études ont conclu qu'un "système de sauvegarde" augmente la résilience du pipeline et devrait diminuer l'utilisation du HPC car le travail n'est pas obligé d'être redémarré:
•
https://journals.sagepub.com/doi/epub/10.1177/1094342021990433
•
https://resilienthpc.eu/sites/default/files/pdf/Blueprint2020__Towards-Resilient-EU-HPC-Systems.pdf
Hypothèses et considérations:
Les systèmes de microservices disposent d'un mécanisme de résilience dans lequel chaque microsystème est dupliqué en cas de défaillance de l'élément principal. De plus, certaines politiques garantissent un nombre minimum de microservices dupliqués pour augmenter la disponibilité du système. Le "système de sauvegarde" précédemment mentionné peut être considéré comme une garantie sur le cluster HPC qui étend la disponibilité et l'exécution continue du travail, de sorte que le travail HPC peut être récupéré ou exécuté après une défaillance. Cela ne devrait pas nécessiter de redémarrer le travail échoué depuis le début.
RQ4:
Problématique de recherche:
Le pipeline de données et l'infrastructure ont un système de sauvegardes capable de récupérer un pipeline de données défaillant.
Question de recherche:
Comment pouvons-nous vérifier que le système de sauvegarde fonctionne bien?
Qu'est-ce que l'ingénierie du chaos?
L'ingénierie du chaos est un ensemble de principes pour améliorer la résilience du système. En particulier :
•
Construire une hypothèse autour du comportement à l'état stable du système.
•
Varier les événements du monde réel.
•
Effectuer des expériences en production.
•
Automatiser les expériences pour les faire fonctionner en continu.
•
Atténuer le rayon d'impact des expériences.
Dans notre cas, nous essayons de faire ces tests sur le système de sauvegarde.
Méthode de recherche (Solution possible):
L'ingénierie du chaos peut être utilisée pour vérifier l'état des sauvegardes par le biais d'expériences de chaos:
1.
Trouver l'outil de chaos le plus approprié pour produire des expérimentations de chaos sur l'infrastructure potentiellement résiliente
2.
Définir les expériences de chaos les plus significatives sur la base des analyses post-mortem disponibles
3.
Tester le système de sauvegarde résultant avec des expérimentations de chaos pour déceler :
a.
Le rayon d'impact des échecs imprévisibles/ingérables
b.
La grâce des échecs et leurs impacts mesurables
Objectif:
L'approche proposée est supposée augmenter la résilience du système de sauvegarde, de sorte qu'en cas de défaillance du pipeline, la récupération de ce pipeline devrait être plus efficace, sans nécessité de redémarrer le pipeline.
Hypothèses
Un système de sauvegarde partiellement implémenté existe déjà et est disponible pour extension/expérimentation.
Références:
Compte tenu de la nature technique du système de sauvegarde, il convient de sélectionner un outil spécifique d'ingénierie du chaos.
-
https://www.ibm.com/topics/chaos-engineering
-
https://www.gremlin.com/community/tutorials/chaos-engineering-tools-comparison/