Certeza Técnica en la Nube: Cómo la Validación de Hipótesis Transformó la Escalabilidad de un sistema clínico de alta demanda

Un proveedor de telerradiología necesitaba duplicar su capacidad a 200.000 estudios mensuales sin saber si su infraestructura lo permitía. En lugar de escalar a ciegas, Nursoft aplicó un diagnóstico riguroso basado en validación de hipótesis: pruebas de laboratorio controladas que revelaron la causa raíz de los eventos de memoria, el impacto real de la compresión DICOM y un cuello de botella de disco no contemplado. El resultado fue certeza técnica donde había opacidad, una propuesta de optimización con ahorro proyectado del 40% y una hoja de ruta clara para el crecimiento.

En sistemas críticos, la intuición no basta. Este artículo detalla cómo un diagnóstico riguroso basado en el método científico permitió transformar una fuente de inestabilidad operativa en una estrategia de crecimiento con base técnica sólida para un sistema de imágenes médicas de alta demanda.

Contexto

La telemedicina y el diagnóstico radiológico remoto son pilares del sistema de salud moderno en Chile. En este escenario, los proveedores de telerradiología operan plataformas que deben estar disponibles las 24 horas del día: cuando un médico radiólogo recibe una tomografía computada o una resonancia magnética para diagnosticar, cada segundo de latencia tiene impacto clínico directo.

El estándar técnico que gobierna el almacenamiento y comunicación de estas imágenes es DICOM (Digital Imaging and Communications in Medicine), y el software que lo implementa se denomina PACS (Picture Archiving and Communication System).

El desafío del cliente era concreto: preparar la plataforma para duplicar su capacidad y alcanzar los 200.000 estudios mensuales hacia 2026. Pero el volumen no es el único vector de crecimiento: una tendencia sostenida en radiología es el aumento en el uso de instancias multiframe, archivos DICOM que contienen múltiples imágenes dentro de una misma instancia, propios de modalidades como tomografías computadas y resonancias magnéticas de alta resolución. A medida que estas técnicas se masifican, los archivos individuales serán cada vez más pesados, lo que multiplica la presión sobre la infraestructura más allá del simple aumento en cantidad de estudios.

Problema

La configuración de la plataforma había evolucionado de forma reactiva: cada parámetro---el límite de memoria de los pods, la cantidad de réplicas activas, los recursos de CPU asignados, la familia de máquinas utilizada---había sido ajustado bajo la presión de mantener la operación, no a partir de un entendimiento técnico profundo del sistema. El límite de RAM, por ejemplo, quedó fijado en 13 GB por prueba y error, como el valor mínimo que evitaba reinicios frecuentes por eventos Out of Memory (OOM).

El problema real era la incertidumbre estructural: no se sabía si la configuración era la correcta, qué factores realmente limitaban el rendimiento, cuántas réplicas eran necesarias y cuándo, ni si la familia de máquinas elegida era la más adecuada para la carga real. Escalar sin responder esas preguntas implicaba el riesgo de invertir en infraestructura equivocada o de comprometer la disponibilidad del servicio en el momento de crecer.

Las consecuencias de no resolver esto eran concretas: una plataforma que no puede garantizar sus acuerdos de nivel de servicio pierde competitividad, y escalar se convierte en una apuesta arriesgada que puede resultar en costos innecesarios o, peor aún, en fallos operativos.

Solución

Sin un error conocido ni un punto de partida claro, la primera tarea fue delimitar el espacio del problema. Se levantó un conjunto de hipótesis lo bastante amplio como para no dejar causas posibles sin explorar, y se diseñaron pruebas de laboratorio controladas para confirmar o descartar cada una. Las decisiones de optimización vendrían después, una vez que los datos hablaran.

Diagnóstico: Validación de Hipótesis

Hipótesis 1: Memory Leak en el software PACS de código abierto o sus plugins

Los gráficos de Kubernetes mostraban memoria subiendo hasta el límite configurado y manteniéndose ahí, patrón clásico de una fuga. Al analizar la métrica correcta---container_memory_rss, que excluye caché---el proceso del software PACS consume normalmente alrededor de 500 MB. El resto corresponde a caché del sistema operativo: Linux usa la RAM disponible para acelerar operaciones de disco, y Kubernetes la contabilizaba dentro del contenedor. No había fuga; el equipo estaba mirando la métrica equivocada. Hipótesis refutada.

Hipótesis 2: El software PACS escala de forma predecible bajo distintas condiciones de carga

No se sabía cómo respondía el sistema ante picos de demanda ni si añadir réplicas era la estrategia correcta. Pruebas de laboratorio con distintos niveles de carga simultánea mostraron que el tiempo de respuesta crece de forma aproximadamente lineal con los estudios concurrentes. La estrategia de escalar horizontalmente con réplicas es válida y el comportamiento del software es predecible. Hipótesis confirmada.

El tiempo de recepción crece de forma aproximadamente lineal con la carga. La visualización no se ve afectada significativamente.

Hipótesis 3: La compresión en disco impacta significativamente el rendimiento

La instancia tenía compresión DICOM activada por decisión histórica, pero nunca se había medido su impacto real. Con compresión activa, el tiempo de recepción de estudios es hasta el doble bajo carga alta. Sin embargo, la compresión reduce el espacio de almacenamiento en un factor de 2,1x en promedio. Hipótesis confirmada. Estas mediciones abrieron una pregunta adicional: si desactivar la compresión mejora el rendimiento, ¿qué impacto tiene eso sobre el disco?

Hipótesis emergente: La velocidad del disco es un factor limitante independiente de la compresión

Las pruebas de compresión revelaron un segundo factor limitante: sin compresión y con solo 5 estudios concurrentes, la velocidad de escritura al disco alcanzó 136 MB/s---por encima del máximo teórico del Filestore Basic HDD utilizado en producción (100 MB/s). Esto significa que incluso resolviendo el trade-off de la compresión, el almacenamiento se convierte en el próximo cuello de botella a medida que crece la carga. Este hallazgo no cambia las decisiones inmediatas, pero sí delimita hasta dónde puede llegar la arquitectura actual sin intervenir en la capa de almacenamiento.

Hipótesis 4: Limitación arquitectural en el manejo de instancias multiframe

Los reinicios por OOM coincidían con la llegada de estudios multiframe, pero no se sabía cuánta memoria requerían ni por qué. Usando Valgrind y Massif para perfilar el heap del software PACS durante la recepción de una instancia multiframe de 1,5 GB, se midió un consumo de 7,1 GB de RAM. La revisión del código fuente explicó el porqué: el software PACS carga cada instancia DICOM completa en memoria antes de procesarla, a diferencia de otros sistemas que usan streaming. El consumo puede alcanzar hasta 4,7 veces el tamaño del archivo. En los 60 días previos al análisis, la plataforma había recibido 319 estudios multiframe desde 35 centros médicos distintos---no es un caso aislado. Hipótesis confirmada.

Hipótesis emergente: ¿Es esta limitación propia del software o del estándar DICOM?

Confirmada la limitación, surgió la pregunta natural: ¿es una restricción del software PACS en uso o de la forma en que el estándar DICOM obliga a procesar instancias multiframe? Se ejecutó la misma prueba con una alternativa equivalente de código abierto, ampliamente usada en la industria. El resultado: la alternativa mantuvo un uso de memoria estable alrededor de los 900 MB independiente del tipo de instancia. La limitación es estructural al software PACS utilizado, no al estándar. Esto descarta una solución de configuración y apunta directamente a una decisión de software. Hipótesis confirmada.

La alternativa usa más memoria en reposo, pero se mantiene completamente estable ante instancias multiframe. La limitación no es del estándar DICOM.

Propuesta de Optimización

Con el diagnóstico completo, la propuesta se articuló en tres ejes.

Tuning del stack: mantener la compresión activada

Desactivar la compresión mejora el rendimiento de recepción, pero el análisis de costos descarta esta opción. Sin compresión, los estudios ocupan 2,1 veces más espacio en disco: pasar de 1 TB a 2,5 TB en Filestore Basic HDD eleva el costo de almacenamiento de USD 225 a USD 563 mensuales. Además, como muestran las pruebas de disco, desactivarla satura el almacenamiento antes que las máquinas. El ahorro en almacenamiento supera al potencial ahorro en cómputo: la compresión se mantiene.

Modernización de infraestructura: familia de máquinas C4

Los procesadores Emerald Rapids de la familia C4 ofrecen un 20% mejor rendimiento en visualización respecto a las máquinas C2 en uso, con una granularidad de recursos superior que permite ajustar CPU y RAM de forma más precisa. La máquina propuesta (c4-highcpu-8: 8 vCPU, 16 GB RAM) puede absorber la carga habitual en una única instancia del software PACS---con 13 GB de RAM reservados, suficientes para recibir la instancia multiframe más grande registrada en producción---y escalar automáticamente mediante HPA ante picos de demanda. El costo de máquinas se reduce en un 59% respecto a la configuración actual.

Precios con CUD de 3 años, región Santiago. En negrita, la configuración propuesta. C4 permite elegir entre perfiles highcpu, standard e highmem según el balance CPU/RAM requerido; C2 solo ofrece una relación fija.

Nueva arquitectura de separación: recepción y visualización diferenciadas

A mediano plazo, la limitación estructural del software PACS apunta hacia una separación de responsabilidades en la infraestructura: nodos de alta RAM dedicados a la recepción de estudios---donde el pico de memoria es la restricción crítica---y nodos ligeros y escalables para visualización, donde la CPU es el factor dominante. Esta diferenciación no es viable con el software PACS actual por su diseño monolítico, pero es el punto de partida natural de cualquier migración a una alternativa o desarrollo de un PACS propio: ambas opciones permiten dimensionar cada capa de forma independiente y absorber el crecimiento en volumen y peso de los estudios sin intervenir en toda la infraestructura simultáneamente.

Impacto

Eliminación de la incertidumbre

El resultado más valioso del proyecto no fue una métrica de ahorro, sino la certeza técnica: por primera vez, el equipo comprende con precisión qué factores determinan el comportamiento de la plataforma. Las decisiones de escala dejaron de basarse en intuición y prueba y error, y pasaron a estar fundadas en evidencia de laboratorio reproducible.

Potencial de ahorro identificado del ~40%

La propuesta de optimización proyecta un ahorro del 59% en el costo de máquinas. Considerando el conjunto de la infraestructura, el ahorro neto proyectado se sitúa en torno al 40%. Gran parte de ese ahorro proviene de elegir una máquina con exactamente los recursos que la carga requiere, sin pagar por CPU o RAM que el sistema no utiliza.

La validación en producción confirmó que la consolidación de instancias es viable en términos de costos, aunque reveló una pérdida de rendimiento del 20% en los tiempos de respuesta bajo la configuración sin máquinas C4. Dado que las máquinas C4 no estaban disponibles en el datacenter de Santiago al momento de aplicar el cambio, este fue revertido para no impactar la plataforma.

Seguridad operativa ante el crecimiento

El diagnóstico confirma que la plataforma puede absorber el volumen de 200.000 estudios mensuales con la arquitectura actual, y que no existe una urgencia operativa inmediata que obligue a intervenciones estructurales. Las limitaciones identificadas---el manejo de instancias multiframe y la velocidad de escritura del disco---marcan el techo de lo que puede optimizarse en configuración, pero no impiden el crecimiento proyectado.

Lo que el diagnóstico sí entrega es la información necesaria para tomar esa decisión con evidencia: el costo de migrar a otra solución PACS o parchear el software actual debe evaluarse frente al costo de escalar con la arquitectura actual hasta el techo de producción del mercado chileno---estimado en 600.000 estudios mensuales---antes de comprometer recursos en un cambio que puede no ser necesario.

Como primer paso en esa dirección, el equipo consultó a la comunidad del software sobre el comportamiento identificado en instancias multiframe ^[1]. La respuesta del equipo de mantenimiento fue clara: el soporte de streaming---que resolvería el problema de raíz---está en el roadmap, pero requiere cientos de horas de desarrollo sin financiamiento asegurado. No hay una corrección oficial disponible en el corto plazo, lo que convierte la evaluación de alternativas en una decisión concreta, no solo una precaución.

Anticipación de un cuello de botella no visible

Las pruebas de compresión identificaron la velocidad de escritura del disco como un factor limitante independiente, no contemplado en las hipótesis originales. Con compresión activada y la carga actual, el disco opera a 39,9 MB/s---dentro del margen del Filestore Basic HDD (100 MB/s máximos teóricos). Pero sin compresión, con solo 5 estudios concurrentes, la escritura alcanza los 136 MB/s, superando ese límite.

Este hallazgo no requiere acción inmediata, pero delimita con precisión cuándo y cómo el almacenamiento se convierte en el próximo cuello de botella. A medida que el volumen de estudios crece y los archivos se vuelven más pesados, la presión sobre el disco aumenta de forma proporcional---independientemente de cuántas máquinas o réplicas se agreguen. El siguiente nivel de Filestore (Basic SSD) cuesta USD 1.075 mensuales, frente a los USD 225 actuales, lo que convierte la decisión de almacenamiento en una variable estratégica que debe planificarse con anticipación, no bajo presión operativa.

Conclusiones

El cliente enfrentaba una presión concreta: duplicar la capacidad de una plataforma clínica crítica sin saber si la arquitectura actual lo permitía, cuánto costaría, ni qué estaba realmente fallando. La única certeza era que escalar sin entender el sistema primero era un riesgo que no podían asumir.

El mayor logro de este proyecto no fue resolver un fallo puntual, sino construir conocimiento técnico fundamentado donde había opacidad. Al terminar el análisis, el equipo del cliente sabe con precisión qué factores determinan el comportamiento de su plataforma, hasta dónde puede crecer con la arquitectura actual, qué decisiones pueden tomarse hoy y cuáles requieren más evidencia antes de comprometer recursos. Eso es lo que permite planificar el crecimiento con confianza en lugar de reaccionar bajo presión.

Este tipo de problema---técnicamente complejo, sin causa raíz evidente, con consecuencias de negocio directas---es exactamente el escenario donde una metodología rigurosa marca la diferencia. No porque garantice una solución inmediata, sino porque convierte la incertidumbre en conocimiento accionable: hipótesis concretas, experimentos reproducibles, datos que respaldan cada decisión. El resultado no es solo una recomendación técnica; es la capacidad de tomar decisiones estratégicas de infraestructura con evidencia, no con intuición.

Referencias

https://discourse.orthanc-server.org/t/high-memory-consumption-during-ingestion-of-large-1-5-gb-multi-frame-instances/6408 ↩︎