Una infraestructura de producción bien diseñada permite a su equipo de desarrollo dormir tranquilo por las noches y descansar los fines de semana, mientras los usuarios se benefician de su aplicación las 24 horas del día, los 7 días de la semana.
Por eso, antes de pasar a producción con su aplicación basada en FHIR, es imprescindible que aborde dos riesgos críticos y los minimice:
- pérdida de datos
- tiempo de inactividad del sistema
Estos consejos le ayudarán a desarrollar una solución FHIR fiable y lista para producción en la nube. Para simplificar, omitiremos intencionadamente los temas de seguridad, redes y monitorización, y nos centraremos en los aspectos fundamentales para avanzar.
¡Sin punto único de fallo!
El diseño de infraestructura comienza por elegir los principios adecuados. El principio fundamental para construir sistemas de alta disponibilidad es que no exista ningún punto único de fallo. En términos sencillos, deberá duplicar los componentes clave del sistema, es decir, hacerlos redundantes.
La solución FHIR básica incluye dos componentes clave que deben duplicarse:
- Aplicación(es) – Aidbox backend FHIR
- Base(s) de datos – PostgreSQL
Si dispone de más componentes clave, puede aplicar este principio a todos ellos de la misma manera.
Las aplicaciones y las bases de datos requieren enfoques y tecnologías diferentes en cuanto a la duplicación. Veamos cómo abordar cada una de ellas.
Sin tiempo de inactividad. Duplique su servidor FHIR y ejecútelo en paralelo
Para evitar un punto único de fallo en la capa de aplicación, necesita disponer de dos o más instancias del servidor/backend FHIR que atiendan las solicitudes en paralelo. Además, no puede operar su solución sin un mecanismo que supervise, relance y distribuya el tráfico entre sus aplicaciones en caso de fallo.
La implementación concreta depende de la nube y los servicios que haya seleccionado. Hoy en día, las nubes públicas ofrecen muchas opciones, así que elija con criterio en función de su presupuesto y el nivel de control que desee.
Recomendamos encarecidamente valorar el servicio de Kubernetes (K8s) gestionado: EKS en AWS, GKE en GCP y AKS en Azure. Desde nuestra perspectiva, es la mejor relación calidad-precio.
Cuando ejecuta sus aplicaciones en contenedores dentro del clúster de Kubernetes, K8s:
- reinicia los contenedores que fallan
- reemplaza los contenedores
- elimina los contenedores que no responden a su comprobación de estado definida por el usuario
- los anuncia a los clientes únicamente cuando están listos para servir
Este proceso se denomina autocuración (self-healing).
Para configurar esta solución basada en Kubernetes, necesita iniciar el clúster de Kubernetes en una nube, configurando comprobaciones de estado y políticas de autocuración/liveness. La política básica de autocuración incluye los siguientes parámetros que puede ajustar según sus necesidades:
- comprobar el estado de vida cada 5 segundos
- redirigir el tráfico si un contenedor (aplicación) no responde durante más de 10 segundos
- reiniciar si un contenedor (aplicación) no responde durante más de 20 segundos
Consulte el ejemplo de sonda de liveness de Kubernetes aquí.
Comience con el servidor FHIR de Aidbox para almacenamiento de datos, integraciones, analítica sanitaria y mucho más, o contrate a nuestro equipo para dar soporte a sus necesidades de desarrollo de software.
También es importante señalar que Kubernetes está diseñado de forma que un único clúster puede ejecutarse en múltiples zonas de fallo. Esto protege su ecosistema en la nube frente a fallos de infraestructura y de zona de disponibilidad. Por ello, téngalo en cuenta al configurar el clúster.
Como paso final, deberá asegurarse de que el servidor FHIR seleccionado pueda atender solicitudes en paralelo. Por ejemplo, la plataforma FHIR de Aidbox dispone de una caché interna integrada y un mecanismo de sincronización de caché entre instancias. Las instancias de Aidbox pueden compartir estado y configuraciones comunes entre sí, lo que las hace intercambiables.
Resumen breve: Como resultado, obtendrá una capa de aplicación básica de alta disponibilidad con conmutación por error automatizada basada en el mecanismo de autocuración de K8s. Este enfoque le ayuda a minimizar el tiempo de inactividad del sistema y no requerirá intervenciones manuales como parte del proceso de recuperación.
Sin pérdida de datos. Replique y haga copias de seguridad de su base de datos correctamente
Para evitar un punto único de fallo en la capa de base de datos, necesitamos disponer de una réplica, copias de seguridad y un proceso de conmutación por error y recuperación (idealmente automatizado). En nuestro caso utilizamos PostgreSQL y los ejemplos a continuación se basarán en él.
PostgreSQL permite configurar dos o más réplicas mediante la función de replicación en streaming integrada. Sugerimos los siguientes parámetros:
- al menos una réplica síncrona, y
- una réplica con un retraso de 12 a 24 horas
Esto protegerá sus datos si elimina accidentalmente una tabla de la base de datos, permitiéndole recuperarla fácilmente.
Las copias de seguridad de PostgreSQL se pueden clasificar en dos tipos:
- incremental – mantiene un registro de escritura anticipada (WAL) que registra cada cambio realizado en la base de datos
- base (completa) – copia de seguridad completa de la base de datos
Para configurar un flujo de copias de seguridad, necesitará extensiones adicionales y una aplicación que desencadene y ejecute el proceso. Recomendamos valorar la extensión WAL-G para PostgreSQL. WAL-G es una herramienta de restauración de archivos para PostgreSQL, MySQL/MariaDB y MS SQL Server (en fase beta para MongoDB y Redis). La mejor práctica para almacenar copias de seguridad en la nube es utilizar el servicio de almacenamiento de archivos AWS S3 de Amazon o Google Cloud Storage.
Yendo más allá, la mejor práctica es disponer de una política de copias de seguridad propia y documentada, basada en los requisitos y el uso de su solución. Esta política constituirá la base de su configuración de copias de seguridad. A continuación se presenta un ejemplo de las variables clave para esta política que puede servir de referencia:
- copias de seguridad incrementales ~diarias
- copias de seguridad base (completas) ~semanales
- retención de copias de seguridad ~mensual
Para probar y perfeccionar su solución basada en FHIR antes de salir en producción, pruebe la versión gratuita de Aidbox. Ofrece un entorno completo para desarrollar y validar su solución, proporcionando todas las herramientas necesarias sin limitaciones de funcionalidades.
Conclusión y lista de verificación
Una infraestructura de producción bien diseñada debe ser fiable y autocurativa. Esto significa que si alguno de los componentes clave falla, el sistema se reequilibrará y continuará funcionando sin problemas.
En la práctica, es necesario duplicar los componentes e integrar mecanismos de conmutación por error tanto en la capa de aplicación como en la de base de datos por separado.
El clúster de Kubernetes, con su monitorización nativa de comprobaciones de estado y su lógica de autocuración, gestionará sus contenedores basados en FHIR, mientras que PostgreSQL se replicará y respaldará con la extensión WAL-G y las funciones de replicación integradas.
El próximo gran reto será crear un mecanismo inteligente de conmutación por error y recuperación para las bases de datos. Nos aseguraremos de explorar este tema en artículos futuros.
Lista de verificación básica
- Configurar el clúster de Kubernetes con autocuración y ejecutarlo en múltiples zonas
- Utilizar múltiples instancias de servidores FHIR que funcionen en paralelo
- Configurar una réplica síncrona de la base de datos
- Configurar una réplica adicional de la base de datos con un retraso de 12 a 24 horas
- Configurar copias de seguridad incrementales diarias
- Configurar copias de seguridad base (completas) semanales
- Implementar una política de retención de copias de seguridad mensual
- Desarrollar y utilizar una estrategia de conmutación por error y recuperación de la base de datos
Esta lista de verificación es suficiente para proteger su solución frente a la pérdida de datos y el tiempo de inactividad del sistema. Para una infraestructura lista para producción llave en mano, también deberá ocuparse de la seguridad, las redes y la monitorización, o delegarlo en soluciones SaaS todo en uno como la plataforma FHIR de Aidbox en AWS.
Autor: Mike Ryzhikov COO en Health Samurai
Véase también: Escalado horizontal y vertical de Aidbox y Salvaguardas técnicas HIPAA de Aidbox.
