Une infrastructure de production bien conçue permet à votre équipe de développement de dormir sur ses deux oreilles la nuit et de se reposer les fins de semaine, pendant que les utilisateurs profitent de votre application 24 h sur 24, 7 jours sur 7.
Ainsi, avant de déployer votre application FHIR en production, vous devez impérativement prendre en charge deux risques critiques et les minimiser :
- la perte de données
- l'interruption de service
Ces conseils vous aideront à développer une solution FHIR fiable et prête pour la production dans le nuage. Par souci de simplicité, nous passerons intentionnellement sous silence les sujets de la sécurité, de la mise en réseau et de la surveillance. Nous nous concentrerons plutôt sur les bases pour aller de l'avant.
Aucun point de défaillance unique !
La conception de l'infrastructure commence par le choix des bons principes. Le principe fondamental de la création de systèmes à haute disponibilité est l'absence de point de défaillance unique. En termes simples, vous devrez dupliquer les composants clés du système, c'est-à-dire les rendre redondants.
La solution FHIR de base comprend deux composants clés qui doivent être dupliqués :
- Application(s) – Aidbox serveur dorsal FHIR
- Base(s) de données – PostgreSQL
Si vous avez d'autres composants clés, vous pouvez appliquer ce principe à tous de la même façon.
Les applications et les bases de données requièrent des approches et des technologies différentes en matière de duplication. Voyons comment les traiter chacun à leur tour.
Aucune interruption de service. Dupliquez votre serveur FHIR et exécutez-le en parallèle
Pour éviter un point de défaillance unique au niveau de la couche applicative, vous devez disposer de deux instances ou plus du serveur FHIR/serveur dorsal qui traiteront les requêtes en parallèle. Vous ne pouvez pas non plus exploiter votre solution sans un mécanisme permettant de surveiller, de relancer et d'allouer le trafic à vos applications en cas de défaillance.
La mise en œuvre particulière dépend du nuage et des services que vous avez choisis. De nos jours, les nuages publics offrent de nombreuses options ; choisissez donc judicieusement en fonction de votre budget et du niveau de supervision souhaité.
Nous vous recommandons vivement d'examiner le service Kubernetes (K8s) géré : EKS dans AWS, GKE dans GCP et AKS dans Azure. De notre point de vue, c'est la solution gagnante qui offre le meilleur rapport qualité-prix.
Lorsque vous exécutez vos applications conteneurisées au sein du groupe Kubernetes, K8s va :
- redémarrer les conteneurs qui tombent en panne
- remplacer les conteneurs
- supprimer les conteneurs qui ne répondent pas à votre vérification de l'état de santé définie par l'utilisateur
- les annoncer aux clients uniquement lorsqu'ils sont prêts à servir
Ce processus est appelé auto-guérison (self-healing).
Pour configurer cette solution basée sur Kubernetes, vous devez démarrer le groupe Kubernetes dans un nuage, en configurant les vérifications de l'état de santé et les politiques d'auto-guérison/de vivacité. La politique d'auto-guérison de base comprend les paramètres suivants que vous pouvez ajuster selon vos besoins :
- vérifier la vivacité toutes les 5 secondes
- allouer le trafic si un conteneur (application) ne répond pas pendant plus de 10 secondes
- redémarrer si un conteneur (application) ne répond pas pendant plus de 20 secondes
Consultez l'exemple de sonde de vivacité Kubernetes ici.
Commencez avec le serveur FHIR Aidbox pour le stockage des données, les intégrations, l'analytique en santé et bien plus encore, ou engagez notre équipe pour répondre à vos besoins en développement logiciel.
Il est également important de noter que Kubernetes est conçu de sorte qu'un seul groupe Kubernetes peut s'étendre sur plusieurs zones de défaillance. Cela protège votre écosystème en nuage contre les pannes d'infrastructure et de zones de disponibilité. Veuillez donc en tenir compte lors de la configuration du groupe.
En guise d'étape finale, vous devrez vous assurer que le serveur FHIR que vous avez choisi peut traiter les requêtes en parallèle. Par exemple, la plateforme FHIR Aidbox dispose d'un cache interne intégré et d'un mécanisme de synchronisation du cache entre les instances. Les instances Aidbox peuvent partager l'état et les configurations communes entre elles, ce qui les rend interchangeables.
Résumé rapide : Vous disposez ainsi d'une couche applicative à haute disponibilité de base avec basculement automatisé des applications reposant sur le mécanisme d'auto-guérison de K8s. Cette approche vous aide à minimiser les interruptions de service et n'exigera pas d'interventions manuelles dans le cadre du processus de reprise.
Aucune perte de données. Répliquez et sauvegardez votre base de données correctement
Pour éviter un point de défaillance unique au niveau de la couche base de données, nous devons disposer d'un réplica, de sauvegardes et d'un processus de basculement/reprise (idéalement automatisé). Dans notre cas, nous utilisons PostgreSQL et les exemples ci-dessous en seront tirés.
PostgreSQL vous permet de configurer deux réplicas ou plus en utilisant la fonctionnalité de réplication en continu intégrée. Nous vous suggérons de vous en tenir aux paramètres suivants :
- au moins un réplica synchrone, et
- un réplica avec un délai de 12 à 24 heures
Cela préservera vos données si vous supprimez accidentellement une table de la base de données, vous permettant ainsi de la récupérer facilement.
Les sauvegardes PostgreSQL peuvent être regroupées en deux types :
- incrémentielle – maintient un journal des transactions (WAL) qui enregistre chaque modification apportée à une base de données
- de base (complète) – sauvegarde complète de la base de données
Pour configurer un pipeline de sauvegarde, vous aurez besoin d'extensions supplémentaires et d'une application pour déclencher et exécuter le processus. Nous vous recommandons d'examiner l'extension WAL-G pour PostgreSQL. WAL-G est un outil de restauration par archivage pour PostgreSQL, MySQL/MariaDB et MS SQL Server (version bêta pour MongoDB et Redis). La meilleure approche pour stocker les sauvegardes dans le nuage est le service de stockage de fichiers AWS S3 d'Amazon ou Google Cloud Storage.
Pour aller plus loin, la meilleure pratique consiste à disposer de votre propre politique de sauvegarde documentée, basée sur les exigences et l'utilisation de votre solution. Cette politique constituera la base de votre configuration de sauvegarde. Voici un exemple des variables clés de cette politique qui peut servir de référence :
- sauvegardes incrémentielles ~quotidiennes
- sauvegardes de base (complètes) ~hebdomadaires
- rétention des sauvegardes ~mensuelle
Pour tester et peaufiner votre solution FHIR avant sa mise en service, essayez la version gratuite d'Aidbox. Elle offre un environnement complet pour développer et valider votre solution, en fournissant tous les outils nécessaires sans aucune limitation de fonctionnalités.
Conclusion et liste de vérification
Une infrastructure de production bien conçue doit être fiable et auto-guérisseuse. Cela signifie que si l'un des composants clés tombe en panne, le système se rééquilibrera et continuera à fonctionner sans interruption.
En pratique, vous devez dupliquer vos composants et intégrer des mécanismes de basculement séparément aux niveaux applicatif et base de données.
Le groupe Kubernetes, avec sa surveillance native des vérifications de l'état de santé et sa logique d'auto-guérison, gérera vos conteneurs FHIR, tandis que PostgreSQL sera répliqué et sauvegardé grâce à l'extension WAL-G et aux fonctionnalités de réplication intégrées.
Le prochain grand défi consistera à créer un mécanisme intelligent de basculement et de reprise pour les bases de données. Nous ne manquerons pas d'explorer ce sujet dans de futurs articles.
Liste de vérification de base
- Configurer le groupe Kubernetes avec auto-guérison et l'exécuter dans plusieurs zones
- Utiliser plusieurs instances de serveurs FHIR qui fonctionnent en parallèle
- Configurer un réplica de base de données synchrone
- Configurer un réplica de base de données supplémentaire avec un délai de 12 à 24 heures
- Configurer une sauvegarde incrémentielle quotidienne
- Configurer une sauvegarde de base (complète) hebdomadaire
- Mettre en œuvre une politique de rétention des sauvegardes mensuelle
- Élaborer et utiliser une stratégie de basculement et de reprise de la base de données
Cette liste de vérification est suffisante pour protéger votre solution contre la perte de données et les interruptions de service. Pour une infrastructure de production clé en main, vous devrez également prendre soin de la sécurité, de la mise en réseau et de la surveillance, ou déléguer ces tâches à des solutions SaaS tout-en-un comme la plateforme FHIR Aidbox dans AWS.
Auteur : Mike Ryzhikov COO chez Health Samurai
Voir aussi : Mise à l'échelle horizontale et verticale d'Aidbox et Mesures de protection techniques HIPAA d'Aidbox.
