El caso de uso de atención al paciente de misión crítica que se convirtió en una odisea de Kubernetes

El tiempo de inactividad puede tener consecuencias graves.

Estas palabras son más ciertas para las empresas del campo de la tecnología médica que para la mayoría de las otras industrias: en su caso, las "consecuencias graves" pueden incluir literalmente la muerte. Recientemente tuvimos la oportunidad de analizar la pila tecnológica de una empresa que busca transformar el mantenimiento de registros médicos del lápiz y papel a datos digitales seguros a los que se pueda acceder en cualquier momento y en cualquier lugar del mundo. Estos datos abarcan desde información del paciente hasta directivas de atención, marcadores biológicos, análisis médicos, registros históricos y todo lo demás compartido entre los equipos de atención médica.

Desde el principio, la empresa ha buscado abordar una pregunta aparentemente sencilla: ¿Cómo podemos ayudar a los cuidadores a registrar datos fácilmente en tiempo real? Sin embargo, a medida que la empresa ha crecido, la necesidad de escalar y hacer que los datos estén constantemente disponibles ha hecho que resolver ese desafío sea cada vez más complejo. Aquí describimos cómo la trayectoria tecnológica de la empresa los ha llevado a adoptar Kubernetes y NGINX Ingress Controller .

Pila tecnológica de un vistazo

• Sistema operativo: Linux
• Orquestación de contenedores: Microsoft Azure Kubernetes Service
• Redes: Kubernetes , controlador de ingreso NGINX basado en NGINX Plus
• Lenguaje/marco de desarrollo de software: .Net 
• Monitoreo, observabilidad y alertas – Prometheus
• Panel de control de monitorización – Grafana
• Registro – Grafana Loki
• Base de datos: Servicio SQL de Azure
• Servidor de aplicação : Azure App Service , .Net
• Mensajería y streaming: Azure Event Hubs
• Almacenamiento en caché – Redis
• Seguridad – NGINX App Protect
• Ubicación e infraestructura: dos zonas de disponibilidad, dos clústeres de Kubernetes, entre 15 y 20 nodos y entre 60 y 100 pods 
• DevOps: Servicios de Azure DevOps

A continuación, se muestra cómo encaja NGINX en su arquitectura:

El problema con el papel

Capturar información sobre el estado del paciente y su atención a intervalos regulares es una tarea fundamental para el personal sanitario. Tradicionalmente, la información del paciente se registraba en papel o, más recientemente, en un ordenador portátil o una tableta. Hay un par de desventajas graves:

• Los trabajadores de la salud pueden interactuar con docenas de pacientes por día, por lo que generalmente no es práctico escribir notas detalladas mientras brindan atención. Como resultado, los trabajadores terminan escribiendo sus notas al final de su turno. En ese momento, la fatiga mental y física hace que resulte tentador grabar sólo comentarios genéricos.
• Los trabajadores también deben depender de su memoria para recordar detalles sobre el comportamiento del paciente. Las imprecisiones podrían enmascarar patrones que facilitan el diagnóstico de problemas de salud más graves si se documentan de manera correcta y consistente a lo largo del tiempo.
• Los registros en papel no se pueden compartir fácilmente entre departamentos dentro de un mismo departamento, y mucho menos con otras entidades como técnicos en emergencias médicas, personal de salas de emergencia y compañías de seguros. La situación no es mucho mejor con los ordenadores portátiles o las tabletas si no están conectados a un almacén de datos central o a la nube.

Para abordar estos desafíos, la empresa creó un sistema simplificado de registro de datos que proporciona atajos para acceder a la información del paciente y registrar eventos comunes como la dispensación de medicamentos. Esta facilidad de acceso y uso permite registrar las interacciones de los pacientes en tiempo real a medida que ocurren.

Todos los datos se almacenan en sistemas en la nube mantenidos por la empresa, y la aplicación se integra con otros sistemas de registros médicos electrónicos para proporcionar una visión longitudinal integral del comportamiento de los residentes. Esto ayuda a los cuidadores a brindar una mejor continuidad de la atención, crea un registro histórico seguro y se puede compartir fácilmente con otros sistemas de software de atención médica.

Los médicos y otros especialistas también utilizan la plataforma para admitir pacientes o interactuar con ellos de alguna otra forma. Existe un registro de preferencias y necesidades personales que viajan con el paciente a cualquier centro. Estos se pueden utilizar para ayudar a los pacientes a sentirse cómodos en un nuevo entorno, lo que mejora resultados como el tiempo de recuperación.

Existen requisitos legales estrictos sobre el tiempo durante el cual las empresas deben almacenar los datos de los pacientes. Los desarrolladores de la empresa han creado el software para ofrecer una disponibilidad extremadamente alta con SLA de tiempo de actividad mucho mejores que los de las aplicações genéricas en la nube. Dejar esperando una ambulancia porque el expediente de un paciente no carga no es una opción.

El viaje del garaje a la nube y a Kubernetes

Como muchas empresas emergentes, la compañía inicialmente ahorró dinero al ejecutar la primera aplicação de prueba de concepto en un servidor en la casa de un cofundador. Una vez que quedó claro que la idea tenía viabilidad, la empresa trasladó su infraestructura a la nube en lugar de administrar el hardware en un centro de datos. Al ser una tienda de Microsoft, eligieron Azure. La arquitectura inicial ejecutaba aplicações en máquinas virtuales (VM) tradicionales en Azure App Service, un servicio de entrega de aplicação administrado que ejecuta el servidor web IIS de Microsoft. Para el almacenamiento y la recuperación de datos, la empresa optó por utilizar SQL Server de Microsoft ejecutándose en una máquina virtual como aplicação administrada.

Después de varios años operando en la nube, la empresa estaba creciendo rápidamente y experimentando problemas de escalabilidad. Necesitaba escalar infinitamente, horizontalmente en lugar de verticalmente, ya que este último es lento y costoso con las máquinas virtuales. Este requisito condujo, de forma bastante natural, a la contenedorización y a Kubernetes como posible solución. Otro punto a favor de la contenerización fue que los desarrolladores de la empresa necesitan enviar actualizaciones a la aplicação y a la infraestructura con frecuencia, sin riesgo de interrupciones. Como las notas de los pacientes se agregan constantemente en múltiples zonas horarias, no hay un tiempo de inactividad natural para impulsar los cambios a producción sin el riesgo de que los clientes se vean afectados inmediatamente por fallas.

Un punto de partida lógico para la empresa fue la oferta de Kubernetes administrado de Microsoft, Azure Kubernetes Services (AKS). El equipo investigó las mejores prácticas de Kubernetes y se dio cuenta de que necesitaban un controlador de Ingress que se ejecutara frente a sus clústeres de Kubernetes para administrar de manera eficaz el tráfico y las aplicações que se ejecutaban en nodos y pods en AKS.

El enrutamiento del tráfico debe ser flexible pero preciso

El equipo probó el controlador Ingress predeterminado de AKS, pero descubrió que sus funciones de enrutamiento de tráfico simplemente no podían entregar actualizaciones a los clientes de la empresa de la manera requerida. Cuando se trata de la atención al paciente, no hay lugar para la ambigüedad o la información contradictoria: es inaceptable que un trabajador de atención vea una bandera naranja y otro una bandera roja para el mismo evento, por ejemplo. Por lo tanto, todos los usuarios de una organización deben usar la misma versión de la aplicación, lo que supone un gran reto a la hora de realizar actualizaciones. No existe un momento natural para la transición de un cliente a una nueva versión, por lo que la empresa necesitaba una forma de usar reglas a nivel de servidor y red para enrutar a diferentes clientes a diferentes versiones de la aplicación.

Para lograrlo, la empresa ejecuta la misma plataforma backend para todos los usuarios de una organización y no ofrece multitenencia con segmentación en la capa de infraestructura dentro de la organización. Con Kubernetes, es posible dividir el tráfico utilizando rutas de red virtuales y cookies en los navegadores junto con reglas de tráfico detalladas. Sin embargo, el equipo técnico de la empresa descubrió que el controlador Ingress predeterminado de AKS solo puede dividir el tráfico en términos de porcentaje, no con reglas que operen a nivel de organización del cliente o usuario individual según sea necesario.

En su configuración básica, el controlador de ingreso NGINX basado en NGINX Open Source tiene la misma limitación, por lo que la empresa decidió cambiar al controlador de ingreso NGINX más avanzado basado en NGINX Plus, un producto de nivel empresarial que admite el control de tráfico granular. Encontrar recomendaciones de NGINX Ingress Controller de Microsoft y la comunidad de Kubernetes basadas en el alto nivel de flexibilidad y control ayudó a consolidar la elección. La configuración respalda mejor la necesidad de la empresa de administrar pods (a diferencia de la administración de tráfico clásica), lo que garantiza que los pods se ejecuten en las zonas adecuadas y que el tráfico se enrute a esos servicios. A veces, el tráfico se enruta internamente, pero en la mayoría de los casos de uso, se enruta nuevamente a través del controlador de ingreso NGINX por razones de observabilidad.

Aquí hay dragones: Monitoreo, observabilidad y rendimiento de las aplicação

Con NGINX Ingress Controller, el equipo técnico tiene control total sobre la experiencia del desarrollador y del usuario final. Una vez que los usuarios inician sesión y establecen una sesión, pueden ser redirigidos inmediatamente a una nueva versión o volver a una anterior. Los parches se pueden enviar de manera simultánea y casi instantáneamente a todos los usuarios de una organización. El software no depende de la propagación de DNS ni de las actualizaciones de la red en la plataforma en la nube.

El controlador de ingreso NGINX también cumple con los requisitos de la empresa en materia de monitoreo granular y continuo. El rendimiento de las aplicação es extremadamente importante en el ámbito sanitario. La latencia o el tiempo de inactividad pueden obstaculizar una atención clínica exitosa, especialmente en situaciones de vida o muerte. Después de la migración a Kubernetes, los clientes comenzaron a informar tiempos de inactividad que la empresa no había notado. La empresa pronto descubrió el origen del problema: Azure App Service se basa en datos muestreados. El muestreo está bien para promedios y tendencias generales, pero omite por completo aspectos como solicitudes rechazadas y recursos faltantes. Tampoco muestra los picos de uso que comúnmente ocurren cada media hora cuando los cuidadores registran los datos de los pacientes. La empresa sólo obtenía una imagen incompleta de la latencia, las fuentes de error, las solicitudes incorrectas y el servicio no disponible.

Los problemas no acabaron ahí. De forma predeterminada, Azure App Service conserva los datos almacenados solo durante un mes, muy por debajo de las decenas de años que exigen las leyes de muchos países.  Ampliar el almacén de datos según fuera necesario para una conservación más prolongada era prohibitivamente costoso. Además, la solución de Azure no puede ver el interior de la pila de red de Kubernetes. El controlador de ingreso NGINX puede monitorear tanto la infraestructura como los parámetros de la aplicação mientras maneja el tráfico de capa 4 y capa 7.

Para la monitorización y observabilidad del rendimiento, la empresa eligió una base de datos de series de tiempo Prometheus conectada a un motor de visualización y un panel de control de Grafana. La integración con Prometheus y Grafana está preintegrada en el plano de control y datos de NGINX; el equipo técnico solo tuvo que realizar un pequeño cambio de configuración para dirigir todo el tráfico a través de los servidores Prometheus y Grafana. La información también se envió a una base de datos de registro de Grafana Loki para facilitar el análisis de registros y brindarle al equipo de software más control sobre los datos a lo largo del tiempo. 

Esta configuración también garantiza la protección contra incidentes que requieren un muestreo de datos extremadamente frecuente y de gran volumen para solucionar problemas y corregir errores. Abordar este tipo de incidentes puede resultar costoso con los sistemas de monitoreo de aplicação que ofrecen la mayoría de las grandes empresas de la nube, pero el costo y los gastos generales de Prometheus, Grafana y Loki en este caso de uso son mínimos. Los tres son productos estables de código abierto que, por lo general, requieren poco más que parches después del ajuste inicial.

Mantener el rumbo: Un enfoque en la alta disponibilidad y la seguridad

La empresa siempre ha tenido un doble enfoque: en la seguridad, para proteger uno de los tipos de datos más sensibles que existen, y en la alta disponibilidad para garantizar que la aplicación esté disponible siempre que se necesite. En la transición a Kubernetes, realizaron algunos cambios para aumentar ambas capacidades.

Para lograr la máxima disponibilidad, el equipo técnico implementa un diseño de infraestructura distribuida activa-activa, multizona y multigeográfica para lograr redundancia completa sin un solo punto de falla. El equipo mantiene una infraestructura activa-activa N+2 con clústeres duales de Kubernetes en dos geografías diferentes. Dentro de cada geografía, el software abarca múltiples centros de datos para reducir el riesgo de tiempo de inactividad y brindar cobertura en caso de fallas en cualquier capa de la infraestructura. Las reglas de afinidad y antiafinidad pueden redirigir instantáneamente a los usuarios y el tráfico a pods en funcionamiento para evitar interrupciones del servicio. 

Por seguridad, el equipo implementa un firewall de aplicação web (WAF) para protegerse contra solicitudes incorrectas y actores maliciosos. La protección contra el Top 10 de OWASP es una apuesta mínima que ofrecen la mayoría de los WAF. Al crear la aplicación, el equipo investigó varios WAF, incluido el WAF nativo de Azure y ModSecurity. Al final, el equipo eligió NGINX App Protect con su WAF en línea y protección distribuida contra denegación de servicio (DDoS).

Una gran ventaja de NGINX App Protect es su coubicación con NGINX Ingress Controller, que elimina un punto de redundancia y reduce la latencia. Otros WAF deben ubicarse fuera del entorno de Kubernetes, lo que contribuye a la latencia y el costo. Incluso los retrasos minúsculos (digamos 1 milisegundo adicional por solicitud) se acumulan rápidamente con el tiempo.

Misión secundaria sorpresa: Sin tiempo de inactividad para los desarrolladores

Tras completar la transición a AKS para la mayor parte de su infraestructura de aplicação y redes, la empresa también ha logrado mejoras significativas en su experiencia para desarrolladores (DevEx). Ahora los desarrolladores casi siempre detectan los problemas antes de que los clientes los noten por sí mismos. ¡Desde el cambio, el volumen de llamadas de soporte sobre errores ha disminuido aproximadamente un 80%!

Los equipos de seguridad y rendimiento de aplicaciones de la empresa cuentan con un panel de control detallado de Grafana y alertas unificadas, lo que elimina la necesidad de verificar múltiples sistemas o implementar activadores para textos de advertencia y llamadas provenientes de diferentes procesos. Los equipos de desarrollo y DevOps ahora pueden enviar actualizaciones de código e infraestructura diariamente o incluso varias veces al día y utilizar patrones azul-verde extremadamente granulares. Anteriormente, enviaban actualizaciones una o dos veces por semana y tenían que estar allí durante períodos de poco uso, lo cual era una propuesta estresante. Ahora, el código se envía cuando está listo y los desarrolladores pueden monitorear el impacto directamente observando el comportamiento de la aplicação .

Los resultados son positivos en todos los aspectos: un aumento en la velocidad del desarrollo de software, una mejora en la moral de los desarrolladores y más vidas salvadas.