Le cas d'utilisation des soins aux patients essentiels à la mission qui est devenu une odyssée Kubernetes

Les temps d’arrêt peuvent entraîner de graves conséquences.

Ces mots sont plus vrais pour les entreprises du secteur des technologies médicales que pour la plupart des autres secteurs : dans leur cas, les « conséquences graves » peuvent littéralement aller jusqu’à la mort. Nous avons récemment eu l’occasion de décortiquer la pile technologique d’une entreprise qui cherche à transformer la tenue des dossiers médicaux sur papier en données numériques sécurisées accessibles à tout moment et partout dans le monde. Ces données vont des informations sur les patients aux directives de soins, en passant par les marqueurs biologiques, les analyses médicales, les dossiers historiques et tout ce qui est partagé entre les équipes de soins de santé.

Dès le départ, l’entreprise a cherché à répondre à une question apparemment simple : « Comment pouvons-nous aider le personnel soignant à enregistrer facilement des données en temps réel ? » Cependant, à mesure que l'entreprise s'est développée, la nécessité d'évoluer et de rendre les données constamment disponibles a rendu la résolution de ce défi de plus en plus complexe. Nous décrivons ici comment le parcours technologique de l'entreprise l'a conduit à adopter Kubernetes et NGINX Ingress Controller .

Aperçu de la pile technologique

• Système d’exploitation – Linux
• Orchestration de conteneurs – Service Microsoft Azure Kubernetes
• Mise en réseau – Kubernetes , contrôleur d'entrée NGINX basé sur NGINX Plus
• Langage/cadre de développement logiciel – .Net 
• Surveillance, observabilité et alerte – Prometheus
• Tableau de bord de surveillance – Grafana
• Journalisation – Grafana Loki
• Base de données – Service SQL Azure
• Serveur d'applications – Azure App Service , .Net
• Messagerie et streaming – Azure Event Hubs
• Mise en cache – Redis
• Sécurité – NGINX App Protect
• Emplacement et infrastructure – Deux zones de disponibilité, 2 clusters Kubernetes, 15 à 20 nœuds, 60 à 100 pods 
• DevOps – Services Azure DevOps

Voici un aperçu de la place de NGINX dans leur architecture :

Le problème du papier

La saisie de l’état des patients et des informations sur les soins à intervalles réguliers est une tâche essentielle du personnel de santé. Traditionnellement, les informations des patients étaient enregistrées sur papier ou, plus récemment, sur un ordinateur portable ou une tablette. Il y a quelques inconvénients sérieux :

• Les professionnels de santé peuvent interagir avec des dizaines de patients par jour, il n’est donc généralement pas pratique de rédiger des notes détaillées tout en prodiguant des soins. En conséquence, les travailleurs finissent par écrire leurs notes à la fin de leur quart de travail. À ce stade, la fatigue mentale et physique fait qu’il est tentant d’enregistrer uniquement des commentaires génériques.
• Les travailleurs doivent également se fier à leur mémoire pour connaître les détails du comportement des patients. Les inexactitudes peuvent masquer des schémas qui facilitent le diagnostic de problèmes de santé plus graves s’ils sont documentés correctement et systématiquement au fil du temps.
• Les dossiers papier ne peuvent pas être facilement partagés entre les services d’un même service, et encore moins avec d’autres entités comme les ambulanciers, le personnel des urgences et les compagnies d’assurance. La situation n’est guère meilleure avec les ordinateurs portables ou les tablettes s’ils ne sont pas connectés à un stockage de données central ou au cloud.

Pour relever ces défis, l’entreprise a créé un système d’enregistrement de données simplifié qui fournit des raccourcis pour accéder aux informations des patients et enregistrer des événements courants comme la distribution de médicaments. Cette facilité d’accès et d’utilisation permet d’enregistrer les interactions avec les patients en temps réel au fur et à mesure qu’elles se produisent.

Toutes les données sont stockées dans des systèmes cloud gérés par l'entreprise, et l'application s'intègre à d'autres systèmes de dossiers médicaux électroniques pour fournir une vue longitudinale complète des comportements des résidents. Cela aide les soignants à assurer une meilleure continuité des soins, crée un dossier historique sécurisé et peut être facilement partagé avec d’autres systèmes logiciels de santé.

Les médecins et autres spécialistes utilisent également la plateforme lors de l’admission ou de toute autre interaction avec les patients. Il existe un registre des préférences et des besoins personnels qui accompagne le patient dans n’importe quel établissement. Ils peuvent être utilisés pour aider les patients à se sentir à l’aise dans un nouvel environnement, ce qui améliore les résultats comme le temps de récupération.

Il existe des exigences légales strictes concernant la durée pendant laquelle les entreprises doivent conserver les données des patients. Les développeurs de l’entreprise ont conçu le logiciel pour offrir une disponibilité extrêmement élevée avec des SLA de disponibilité bien meilleurs que ceux des applications cloud génériques. Faire attendre une ambulance parce que le dossier d’un patient ne se charge pas n’est pas une option.

Le voyage du garage au cloud jusqu'à Kubernetes

Comme de nombreuses startups, l’entreprise a initialement économisé de l’argent en exécutant la première application de preuve de concept sur un serveur situé au domicile d’un cofondateur. Une fois qu’il est devenu clair que l’idée avait du succès, l’entreprise a déplacé son infrastructure vers le cloud plutôt que de gérer son matériel dans un centre de données. Étant une boutique Microsoft, ils ont choisi Azure. L’architecture initiale exécutait des applications sur des machines virtuelles (VM) traditionnelles dans Azure App Service, un service de distribution d’applications géré qui exécute le serveur Web IIS de Microsoft. Pour le stockage et la récupération des données, l’entreprise a choisi d’utiliser le serveur SQL de Microsoft exécuté sur une machine virtuelle en tant qu’application gérée.

Après plusieurs années de fonctionnement dans le cloud, l'entreprise connaissait une croissance rapide et rencontrait des difficultés de mise à l'échelle. Il fallait pouvoir évoluer à l'infini, horizontalement plutôt que verticalement, car cette dernière est lente et coûteuse avec les machines virtuelles. Cette exigence a conduit assez naturellement à la conteneurisation et à Kubernetes comme solution possible. Un autre argument en faveur de la conteneurisation était que les développeurs de l’entreprise devaient pouvoir envoyer fréquemment des mises à jour à l’application et à l’infrastructure, sans risquer de pannes. Les notes des patients étant constamment ajoutées sur plusieurs fuseaux horaires, il n'y a pas de temps d'arrêt naturel pour appliquer des modifications à la production sans risquer que les clients soient immédiatement affectés par des problèmes.

Le point de départ logique pour l'entreprise était l'offre Kubernetes gérée de Microsoft, Azure Kubernetes Services (AKS). L'équipe a étudié les meilleures pratiques Kubernetes et a réalisé qu'elle avait besoin d'un contrôleur Ingress exécuté devant ses clusters Kubernetes pour gérer efficacement le trafic et les applications exécutées dans les nœuds et les pods sur AKS.

Le routage du trafic doit être flexible mais précis

L’équipe a testé le contrôleur Ingress par défaut d’AKS, mais a constaté que ses fonctionnalités de routage du trafic ne pouvaient tout simplement pas fournir des mises à jour aux clients de l’entreprise de la manière requise. En matière de soins aux patients, il n’y a pas de place pour l’ambiguïté ou les informations contradictoires. Il est inacceptable qu’un professionnel de la santé voie un drapeau orange et un autre un drapeau rouge pour le même événement, par exemple. Par conséquent, tous les utilisateurs d'une organisation donnée doivent utiliser la même version de l'application. Cela représente un défi de taille en matière de mises à niveau. Il n’existe pas de moment naturel pour faire passer un client à une nouvelle version. L’entreprise avait donc besoin d’un moyen d’utiliser des règles au niveau du serveur et du réseau pour orienter différents clients vers différentes versions d’application.

Pour y parvenir, l’entreprise utilise la même plateforme back-end pour tous les utilisateurs d’une organisation et ne propose pas de multi-location avec segmentation au niveau de la couche d’infrastructure au sein de l’organisation. Avec Kubernetes, il est possible de diviser le trafic à l'aide de routes de réseau virtuelles et de cookies sur les navigateurs ainsi que de règles de trafic détaillées. Cependant, l’équipe technique de l’entreprise a constaté que le contrôleur Ingress par défaut d’AKS ne peut diviser le trafic que sur une base de pourcentage, et non avec des règles qui fonctionnent au niveau de l’organisation du client ou de l’utilisateur individuel selon les besoins.

Dans sa configuration de base, le contrôleur d'entrée NGINX basé sur NGINX Open Source présente la même limitation. La société a donc décidé de passer au contrôleur d'entrée NGINX plus avancé basé sur NGINX Plus, un produit de qualité professionnelle qui prend en charge le contrôle granulaire du trafic. Les recommandations du contrôleur d'entrée NGINX de Microsoft et de la communauté Kubernetes, basées sur le niveau élevé de flexibilité et de contrôle, ont contribué à consolider le choix. La configuration répond mieux aux besoins de l’entreprise en matière de gestion des pods (par opposition à la gestion du trafic classique), en garantissant que les pods fonctionnent dans les zones appropriées et que le trafic est acheminé vers ces services. Parfois, le trafic est acheminé en interne, mais dans la plupart des cas d'utilisation, il est acheminé vers l'extérieur via NGINX Ingress Controller pour des raisons d'observabilité.

Ici il y a des dragons : Surveillance, observabilité et performances des applications

Avec NGINX Ingress Controller, l'équipe technique a un contrôle total sur l'expérience du développeur et de l'utilisateur final. Une fois que les utilisateurs se connectent et établissent une session, ils peuvent être immédiatement redirigés vers une nouvelle version ou revenir à une ancienne. Les correctifs peuvent être appliqués simultanément et presque instantanément à tous les utilisateurs d’une organisation. Le logiciel ne dépend pas de la propagation DNS ni des mises à jour du réseau sur la plateforme cloud.

NGINX Ingress Controller répond également aux exigences de l’entreprise en matière de surveillance granulaire et continue. Les performances des applications sont extrêmement importantes dans le domaine de la santé. La latence ou les temps d’arrêt peuvent entraver la réussite des soins cliniques, en particulier dans les situations de vie ou de mort. Après le passage à Kubernetes, les clients ont commencé à signaler des temps d’arrêt que l’entreprise n’avait pas remarqués. L'entreprise a rapidement découvert la source du problème : Azure App Service s’appuie sur des données échantillonnées. L'échantillonnage est parfait pour les moyennes et les grandes tendances, mais il ignore complètement des éléments tels que les demandes rejetées et les ressources manquantes. Il ne montre pas non plus les pics d’utilisation qui se produisent généralement toutes les demi-heures lorsque les soignants s’enregistrent et enregistrent les données des patients. L’entreprise n’avait qu’une image incomplète de la latence, des sources d’erreur, des mauvaises requêtes et du service indisponible.

Les problèmes ne s’arrêtent pas là. Par défaut, Azure App Service conserve les données stockées pendant seulement un mois, ce qui est bien loin des dizaines d’années imposées par les lois dans de nombreux pays.  L’extension du stockage de données nécessaire à une conservation plus longue était extrêmement coûteuse. De plus, la solution Azure ne peut pas voir l’intérieur de la pile réseau Kubernetes. NGINX Ingress Controller peut surveiller à la fois les paramètres d'infrastructure et d'application lorsqu'il gère le trafic de couche 4 et de couche 7.

Pour le suivi des performances et l'observabilité, l'entreprise a choisi une base de données de séries chronologiques Prometheus associée à un moteur de visualisation et à un tableau de bord Grafana. L'intégration avec Prometheus et Grafana est pré-intégrée dans le plan de données et de contrôle NGINX ; l'équipe technique n'a dû effectuer qu'une petite modification de configuration pour diriger tout le trafic via les serveurs Prometheus et Grafana. Les informations ont également été acheminées vers une base de données de journalisation Grafana Loki pour faciliter l'analyse des journaux et donner à l'équipe logicielle plus de contrôle sur les données au fil du temps. 

Cette configuration assure également une protection future contre les incidents nécessitant un échantillonnage de données extrêmement fréquent et volumineux pour le dépannage et la correction des bogues. La gestion de ces types d’incidents peut s’avérer coûteuse avec les systèmes de surveillance des applications fournis par la plupart des grandes entreprises de cloud, mais le coût et les frais généraux de Prometheus, Grafana et Loki dans ce cas d’utilisation sont minimes. Tous trois sont des produits open source stables qui ne nécessitent généralement guère plus qu'un simple correctif après le réglage initial.

Restez sur la bonne voie : Focus sur la haute disponibilité et la sécurité

L'entreprise a toujours eu une double préoccupation : la sécurité pour protéger l'un des types de données les plus sensibles qui soient, et la haute disponibilité pour garantir que l'application soit disponible à chaque fois que cela est nécessaire. Lors du passage à Kubernetes, ils ont apporté quelques modifications pour augmenter les deux capacités.

Pour une disponibilité maximale, l'équipe technique déploie une conception d'infrastructure distribuée active-active, multizone et multigéographique pour une redondance complète sans point de défaillance unique. L'équipe maintient une infrastructure active-active N+2 avec deux clusters Kubernetes dans deux zones géographiques différentes. Dans chaque zone géographique, le logiciel s'étend sur plusieurs centres de données afin de réduire les risques d'indisponibilité, offrant une couverture en cas de panne à n'importe quelle couche de l'infrastructure. Les règles d'affinité et d'anti-affinité peuvent rediriger instantanément les utilisateurs et le trafic vers des pods opérationnels pour éviter les interruptions de service. 

Pour des raisons de sécurité, l’équipe déploie un pare-feu d’application Web (WAF) pour se protéger contre les mauvaises requêtes et les acteurs malveillants. La protection contre le Top 10 de l'OWASP est un enjeu de taille fourni par la plupart des WAF. Lors de la création de l’application, l’équipe a étudié un certain nombre de WAF, notamment le WAF natif Azure et ModSecurity. Finalement, l’équipe a choisi NGINX App Protect avec son WAF en ligne et sa protection contre les déni de service distribués (DDoS).

L’un des principaux avantages de NGINX App Protect est sa colocation avec NGINX Ingress Controller, qui élimine un point de redondance et réduit la latence. D’autres WAF doivent être placés en dehors de l’environnement Kubernetes, ce qui contribue à la latence et au coût. Même des retards minimes (disons 1 milliseconde supplémentaire par requête) s’accumulent rapidement au fil du temps.

Quête secondaire surprise : Aucun temps d'arrêt pour les développeurs

Après avoir achevé la transition vers AKS pour la plupart de son infrastructure d'application et de réseau, la société a également réalisé des améliorations significatives dans son expérience de développeur (DevEx). Les développeurs détectent désormais presque toujours les problèmes avant que les clients ne les remarquent eux-mêmes. Depuis le changement, le volume d'appels au support concernant des erreurs a diminué d'environ 80 % !

Les équipes de sécurité et de performance des applications de l’entreprise disposent d’un tableau de bord Grafana détaillé et d’alertes unifiées, éliminant ainsi le besoin de vérifier plusieurs systèmes ou d’implémenter des déclencheurs pour les textes d’avertissement et les appels provenant de différents processus. Les équipes de développement et DevOps peuvent désormais livrer des mises à jour de code et d’infrastructure quotidiennement, voire plusieurs fois par jour, et utiliser des modèles bleu-vert extrêmement granulaires. Auparavant, ils expédiaient des mises à jour une ou deux fois par semaine et devaient s'y rendre pendant les périodes de faible utilisation, une situation stressante. Désormais, le code est livré lorsqu’il est prêt et les développeurs peuvent surveiller l’impact directement en observant le comportement de l’application.

Les résultats sont positifs dans tous les domaines : augmentation de la vitesse de développement des logiciels, amélioration du moral des développeurs et davantage de vies sauvées.