Besoins des applications à la santé sur grille ---------------------------------------------- Ce document est un retour d'expérience sur les applications biomédicales déployées actuellement sur l'infrastructure de production EGEE. Plus de 12 applications du domaine de la santé (imagerie médicale, bioinformatique, analyse moléculaire...) avec des besoins diversifiés utilisent actuellement cette infrastructure. Ce domaine applicatif soulève de nombreux défis pour les grilles en raison de sa grande compléxité. Une liste complète et une description détaillée de ces applications est disponible depuis: http://egee-na4.ct.infn.it/biomed/applications.html La grille de production EGEE présente une infrastructure rustique mais intégrant tous les services de bases nécessaire au développement et au déploiement d'applications. Il est important de souligner ici la nécessité d'un système opérationel, même limité dans ses fonctionnalités, du point de vue de l'utilisateur final. La grille au sens du middleware LCG2 est une collection de ferme de calcul. Les ressources sont dédiées au calcul et administrées par centres (chaque centre étant responsable de sa politique de sécurité et de mise à disposition logicielle). Le middleware y a accès à travers les différents systèmes de batch, se présentant ainsi comme un super batch, assorti d'un système de gestion de fichiers partagés. Si les besoins exprimés ci-dessous peuvent sembler avoir déjà fait l'objet de nombreuses études, une grande difficulté d'un point de vue applicatif provient du fait que bien peu de systèmes intégrés existent. Des prototypes résolvant individuellement tel ou tel problème ne sont pas suffisants. Dans ce domaine, l'interopérabilité est primordiale - et engendre souvent des contraintes supplémentaires. Un deuxième problème général provient de l'échelle du système déployé. L'infrastructure EGEE représente actuellement 12000 noeuds de calcul distribués dans 130 centres différents sur 3 continents. Si la majorité des points abordés ci-dessous ont été des sujets d'étude pour la communauté des systèmes distribués de longue date, les hypothèse sous jacentes à une grille d'une telle taille ont rarement été envisagées, et encore plus rarement expérimentées. Un grille de cette taille est un système dont la topologie précise est en permanence inconnue (des ressources "apparaissent" et "disparaissent" continuellement), et dont il n'est pas possible de connaître l'état à un instant donné: au mieux le système d'information ne peut donner qu'une vue partielle, et souvent décalée dans le temps de l'état de la grille. Cela a des implications fortes sur les stratégies d'ordonnancement ou de réservation des resources. En outre, les latences induites dans un système d'une telle taille sont très largement supérieures à celles rencontrées dans de nombreux systèmes parallèles et distribués. Les besoins de tolérance aux fautes sont exacerbés par les nombreuses sources d'erreur possibles (réseau grande distance, configuration des sites sur lesquels s'exercent un contrôle faible, problèmes matériels, hétérogénéité des logiciels installés, etc). Sur un tel système, le monitoring du système lui même (permettant l'étude du système, la détection des erreurs et de leur cause) et le monitoring des activités des utilisateurs est rendu particulièrement difficile. La détermination précise des causes d'erreur et leur remontée vers l'utilisateur est un problème en soi étant donné le nombre de couches logicielles impliquées et la diversité des causes possibles. Le debugging est également particulièrement difficile en raison de la distribution des traces d'exécution et l'absence d'accès aux ressources ayant participé à l'exécution en général. Concernant les besoins plus précis relatifs aux applications à la santé, plusieurs composantes principales ont émergées de l'expérience menée dans le groupe de travail NA4 d'EGEE. Bien que potentiellement calculatoires, ces applications sont souvent dominées par les données: très gros volumes de données (les images médicales rerésentent des Po de données par an), complexité et hétérogénéité des formats, confidentialité... Le service minimal attendu par les utilisateur de la grille en terme de gestion de donnée est un accès transparent et homogène aux ressources de stockage. Ce but n'est que partiellement atteint actuellement avec un middleware qui expose trop souvent des contraintes liées à la localisation des données. La stratégie optée par le middleware est celle de la réplication des données pour améliorer l'accessibilité et la tolérance aux pannes. Cependant, cette stratégie soulève de nombreux points encore non résolus: il n'existe pas de stratégie de réplication ou de cache des données (les réplications sont ordonnées manuellement par l'utilisateur) et aucune cohérence des réplicas n'est mise en oeuvre (c'est un système "lecture seule", les modifications de fichier ne sont possibles que par l'intermédiaire de la création d'une nouvelle instance). La traçabilité des données (et des calculs) est également un besoin fort dans le domaine médical (reproductibilité des expériences, identification des données originales, etc). La résolution de ce problème se rattache probablement au monitoring exprimé précédemment. Outre les données brutes (images, séquences génomiques, structures de molécules, etc), les méta-données (informations relatives portant sur le patient, le génome, etc) ont une importances particulière pour interpréter et structurer les données médicales complexes. Si la gestion de fichiers sur grille est un sujet largement étudié (avec des solutions très diverses envisagées), la gestion efficaces des métadonnées (en général sous forme relationnelle) distribuées sur de nombreux sites sous des formes hétérogènes est également un domaine en pleine exploration. Les contraintes de sécurité relatives à certaines données médicales sont en soi un problème complexe et faisant l'objet de nombreux travaux. Si les techniques à mettre en oeuvre sont bien maitrisées (encryption, pseudonimité, etc), les politiques de sécurité, leur expression, et leur mise en oeuvre est un problème très complexe. Dans le cadre d'une grille, ce problème est rendu encore plus délicat par la distribution des données (sur des sites partagés dont les administrateurs ne sont pas nécessairement accrédités à accéder aux données confidentielles) et la très grande communauté d'utilisateurs (dont l'étendue et la structure exacte n'est pas connue à l'avance, tout comme le système lui même). Les calculs nécessaires aux applications de la santé ont conduit à l'identification de besoins spécifiques qui sont mal pris en compte par les systèmes de batch utilisés. Plusieurs applications se sont révélées intensives par l'usage des données mais nécessitant des tâches de calcul relativement courtes. Dans ce cas, les systèmes de batch imposent un surcoût souvent prohibitif montrant qu'il est nécessaire de trouver les moyens de faire coexister des tâches courtes avec des tâches beaucoup plus longues sur une même infrastructure en assurant un partage équitable. Dans le cadre de ces applications, il faut parfois être capable de réagir à des cas d'urgence médicale par exécution prioritaire et préemption de ressources. Bien peu de systèmes sont capables de garantir l'exécution de tâches prioritaires dans un temps donné. Une autre difficulté provient de la nature interactive de nombreuses applications: la déportation des calculs sur la grille conduit à des infrastructures logicielles complexes permettant de découpler l'interface de la partie calculatoire qui sont souvent mises en oeuvre au cas par cas. Faire face aux nécessités des applications interactives nécessite également souvent la possibilité de réserver de ressources en avance, ce qui est rarement faisable avec les systèmes de batch. Enfin, plusieurs applications ont montré un intérêt certain pour des gestionnaires de workflow facilitant la construction d'applications à partir de composant de base existant et permettant l'exécution efficace des calcul sur une grille. Ces gestionnaires doivent être capable d'ordonnancer les calculs en prenant en compte les données (localisation et taille) souvent dominantes. Si l'étude des workflow a déjà fait couler beaucoup d'encre dans la communauté des systèmes distribués, bien peu des systèmes existants sont capables de s'appliquer aux spécificités des grilles (e.g. impossibilité de modéliser précisément la topologie de la grille) ou bien gèrent de manière inefficace les grandes quantités de données. Il est difficile de rentrer plus dans le détail sans devenir très long. Pour plus de détails, on pourra se référrer au papier suivant, écrit en 2003, qui approfondit de nombreux points et qui n'a pas encore trop vielli: "Using grid technologies to face medical image analysis challenges" J. Montagnat, V. Breton, I. E. Magnin, Biogrid'03, proceedings of the IEEE CCGrid03, pp 588-593, May 2003, Tokyo, Japan. Disponible en ligne sous http://www.i3s.unice.fr/~johan -> lien publications. Le commité technique d'EGEE a également mis en place une base de donnés détaillant finement les besoins des applications. Elle est accessible depuis l'URL: https://savannah.cern.ch/support/?group=egeeptf Plus d'informations sur la démarche de collection et de prise en compte des besoins est disponible dans: https://svn.lal.in2p3.fr/EGEE/PTF/web/requirements.html Johan Montagnat http://www.i3s.unice.fr/~johan