Vivien Quéma : chercheur de pannes pour des systèmes informatiques sans failles

Distinctions Informatique

Vivien Quéma est professeur à Grenoble INP, membre du Laboratoire d’Informatique de Grenoble (LIG, CNRS/Inria/Grenoble INP/Université Grenoble Alpes). Il devient, en octobre 2019, membre junior de l’Institut universitaire de France. Dans cet entretien, il nous présente ses travaux de recherche, ou comment résoudre des pannes de système dans un monde où l’informatique est de plus en plus présente et ses failles complexes…

Pouvez-vous nous présenter votre thématique de recherche ? Quels sont ses enjeux ?

Vivien Quéma : Je m’intéresse aux systèmes en informatique. Il en existe deux sortes : les systèmes distribués que l’on décrit comme un ensemble d’ordinateurs interconnectés, et les systèmes d’exploitation (comme ceux que l’on a dans nos machines). Les systèmes distribués trouvent de nombreuses applications, par exemple, Google utilise ce genre de système pour permettre à l’utilisateur différentes requêtes (gmail, google maps, etc.). Mon travail consiste à améliorer l’efficacité des systèmes, c’est-à-dire qu’ils soient en mesure d’effectuer le plus d’actions possibles par unité de temps avec un temps de réponse minimal, mais aussi énergétiquement parlant. Le second paramètre pour améliorer la performance des systèmes est la robustesse : la tolérance aux fautes, ce que l’on appelle aussi plus généralement des pannes. Construire un programme robuste s’apparente à ce qu’il n’y ait pas d’interruption du service malgré l’occurrence des pannes. Par exemple, dans un datacenter, les machines tombent régulièrement en panne mais pour autant le service reste fonctionnel, il existe une tolérance aux fautes. Pour pallier les fautes du système, la redondance est très utile : les calculs sont exécutés plusieurs fois sur plusieurs machines.

Comment étudie-t-on les pannes informatiques ?

V. Q. : Il existe un grand nombre de pannes possibles au-delà de la panne franche où le système cesse de fonctionner. Dans mes recherches, je me focalise plus particulièrement sur les pannes qui sont arbitraires. En outre, cela signifie qu’il existe un grand nombre de modes de défaillances envisageables. Dans ce cas, on fait l’hypothèse que les byzantins (erreurs) ne sont pas majoritaires et donc que l’on peut faire confiance à la majorité. Pour qu’un système soit robuste, il faut commencer par émettre des hypothèses sur combien d’ordinateurs vont être touchés par la panne mais aussi sur les types de pannes possibles.

Mon rôle consiste à obtenir un système le plus efficace, en tolérant un niveau de panne donné tout en traitant le plus de pannes possibles.

Mes travaux trouvent ainsi de nombreuses applications dans les grands systèmes d’aujourd’hui. Par exemple, Oracle exploite une partie de mes travaux afin de mieux appréhender la performance des systèmes multicœurs et le placement des données.

Quels sont vos projets à venir ?

V. Q. : Mon projet vise à poursuivre ces travaux et notamment au sein des systèmes d’exploitation. Je travaille sur la conception d’un système permettant d’obtenir une vue globale de ce qui se passe au sein du programme, afin d’avoir une vision très fine de l’architecture du système et des activités qui s’y déroulent. Ces recherches ont pour but de permettre une prise de décision plus pertinente de la part du système. Plus concrètement, je mène à la fois des travaux de nature algorithmique lorsqu'il s'agit d'implanter de nouveaux algorithmes de décision au sein d'un système et des travaux de nature système, lorsqu'il s'agit, par exemple, de concevoir des outils de monitoring pour une meilleure compréhension des systèmes : ces outils enregistrent des mesures statistiques qui ne doivent pas être intrusives sinon il y a un risque de ralentissement du système.

Le défi actuel dans ces recherches est dû à la complexification croissante des systèmes, avec l’essor des outils informatiques. Il en découle que les architectures des programmes sont donc de plus en plus complexes également. Bien sûr, les pannes ont toujours existé, mais aujourd’hui on travaille sur un grand nombre de machines en simultané. Les pannes sont donc plus difficiles à identifier, par exemple : comment identifier l’erreur dans la blockchain sachant qu’il y plusieurs contributeurs ?

Contact

Vivien Quéma
Professeur à Grenoble INP, membre du LIG