Observabilidad de GPU a Escala: Transición de Adobe Firefly a Amazon Managed Prometheus

El monitoreo de infraestructuras de entrenamiento de GPU a escala de hyperscaler presenta un desafío fundamental en la gestión de series de tiempo de alta cardinalidad y volumen. A diferencia de las cargas de trabajo de CPU, donde una métrica de utilización puede ser suficiente, las GPU requieren la observación coordinada de múltiples dimensiones (cómputo, memoria, red) para identificar cuellos de botella. Un solo trabajo de entrenamiento distribuido puede generar miles de millones de puntos de datos en una ventana de consulta, superando las capacidades de rendimiento de las soluciones de monitoreo auto-gestionadas.

Este problema se agudiza con el crecimiento exponencial de modelos de IA y la necesidad de escalar la infraestructura de entrenamiento. La capacidad de consultar rápidamente grandes volúmenes de datos de series de tiempo es crítica para la depuración y optimización de trabajos de entrenamiento, así como para la gestión proactiva de la salud del clúster. La latencia en las consultas o la incapacidad de procesar rangos de tiempo extendidos impacta directamente la eficiencia de los ingenieros y la disponibilidad de la infraestructura.

La solución radica en adoptar sistemas de series de tiempo distribuidos y optimizados para consultas de alta cardinalidad, que puedan escalar horizontalmente y ofrecer garantías de rendimiento y disponibilidad. La transición de soluciones auto-gestionadas a servicios gestionados es una respuesta común a esta complejidad operativa, permitiendo a los equipos enfocarse en el valor de negocio en lugar de la infraestructura subyacente de monitoreo.

Arquitectura del Sistema

La arquitectura original de Adobe Firefly para la observabilidad se basaba en una infraestructura Prometheus auto-gestionada, desplegada dentro de clústeres Amazon EKS. Esta configuración utilizaba Prometheus para el scraping de métricas in-cluster y un endpoint remoto para la retención a largo plazo. Sin embargo, el crecimiento en el volumen y la cardinalidad de las métricas de GPU (ej., 2,000 nodos, 16,000 GPUs, scraping cada 30 segundos, generando más de mil millones de puntos de datos por consulta) sobrepasó las capacidades de rendimiento de esta configuración.

La evolución de la arquitectura implicó la introducción de Amazon Managed Service for Prometheus (AMP) para manejar métricas críticas. En lugar de una migración completa, se adoptó un enfoque incremental. Los 'managed scrapers' de AMP (conocidos como Amazon Managed Service for Prometheus collector) se desplegaron junto con la configuración existente de Prometheus. Estos colectores asumieron la responsabilidad de recolectar métricas específicas (utilización de GPU, consumo de memoria, throughput de red por trabajo; estado de pods y nodos; salud de GPU) y las reenviaron directamente a los workspaces de AMP. La configuración existente de Prometheus continuó operando para otras métricas, permitiendo una transición sin interrupciones.

AMP, como un servicio gestionado, proporciona un backend de series de tiempo optimizado para consultas rápidas sobre datos de alta cardinalidad y volumen, con alta disponibilidad incorporada y escalabilidad hasta 50 millones de series de tiempo activas por workspace (con capacidad de escalar hasta mil millones). La integración nativa con Amazon EKS y Amazon Managed Grafana simplifica la recolección y visualización de métricas. Este diseño desacopla la recolección de métricas críticas de la infraestructura de almacenamiento y consulta, delegando la complejidad operativa a AWS y liberando recursos de ingeniería.

Fundamentos Teóricos

El desafío de gestionar y consultar eficientemente grandes volúmenes de datos de series de tiempo de alta cardinalidad se relaciona con los principios fundamentales de las bases de datos optimizadas para cargas de trabajo de escritura intensiva y consultas analíticas. Los sistemas de series de tiempo modernos a menudo emplean estructuras de datos como el Log-Structured Merge-tree (LSM-tree), popularizado por sistemas como Bigtable (Chang et al., 2006) y Cassandra, que son eficientes para ingestas de datos secuenciales y permiten compactaciones en segundo plano. La optimización de consultas sobre estos datos, especialmente con filtros de etiquetas (label matching) y agregaciones, es un área activa de investigación en bases de datos.

La necesidad de alta disponibilidad y escalabilidad en sistemas distribuidos de monitoreo se alinea con los principios de diseño de sistemas tolerantes a fallos y escalables horizontalmente, como los descritos en el teorema CAP (Brewer, 2000) y sus extensiones. La elección de un servicio gestionado como Amazon Managed Service for Prometheus implica delegar la implementación de estos principios (replicación, sharding, recuperación de fallos) a un proveedor de nube, que típicamente utiliza algoritmos de consenso distribuidos (como Raft o Paxos) y estrategias de particionamiento de datos para lograr la durabilidad y disponibilidad requeridas. La capacidad de AMP para manejar miles de millones de puntos de datos y millones de series de tiempo activas es una manifestación de la aplicación de estos principios a escala de hyperscaler.