Autoescalado de Milvus en Kubernetes con EC2 y Almacenamiento Persistente con Respaldo en S3

Implementamos Milvus en Kubernetes (EKS) con Horizontal Pod Autoscaling para los nodos de consulta, Cluster Autoscaler para la computación y Amazon S3 como backend de almacenamiento persistente, eliminando el riesgo de pérdida de datos y reduciendo los costos de almacenamiento en aproximadamente un 80%.

Arquitectura

• Orquestación: Amazon EKS (Elastic Kubernetes Service)
• Computación: instancias EC2 (tipos de instancias mixtos) gestionadas por Cluster Autoscaler
• Base de Datos Vectorial: Milvus implementado mediante Helm chart en modo distribuido
• Almacenamiento de Objetos: Amazon S3 para archivos de segmentos, archivos de índices y persistencia de binlog
• Metadatos: clúster etcd para la coordinación y metadatos de Milvus
• Cola de Mensajes: Streaming de mensajes para el pipeline de logs de Milvus
• Monitoreo: Prometheus + Grafana para métricas de Milvus y señales de autoescalado

Arquitectura Distribuida de Milvus en Kubernetes

Implementación de Componentes

Milvus se ejecuta en modo distribuido con tipos de nodos dedicados, cada uno implementado como una carga de trabajo de Kubernetes con escalado independiente:

• Nodos Proxy — Gestionan las conexiones de clientes y el enrutamiento de solicitudes
• Nodos de Consulta — Ejecutan búsquedas vectoriales y cargan segmentos en memoria
• Nodos de Datos — Gestionan las rutas de escritura y vacían segmentos a S3
• Nodos de Índices — Construyen índices vectoriales y escriben en S3
• Coordinador — Coordinación del clúster y asignación de marcas de tiempo
• etcd — Almacenamiento de metadatos y descubrimiento de servicios
• Cola de Mensajes — Streaming de logs y log de escritura anticipada

Autoescalado Horizontal de Pods (HPA)

Autoescalado de Nodos de Consulta

Los nodos de consulta son el objetivo principal de escalado: cargan segmentos vectoriales en memoria y ejecutan búsquedas. El escalado se basa en múltiples métricas, incluyendo la utilización de CPU, la utilización de memoria, la profundidad de la cola de consultas y la latencia de consultas P99. El HPA se configura con réplicas mínimas/máximas apropiadas, escalado rápido para manejar picos y un escalado descendente gradual para evitar el "flapping".

Autoescalado de Nodos de Índices

Los nodos de índices escalan en función de los trabajos de construcción de índices pendientes: escalan hacia arriba cuando la cola de construcción tiene elementos pendientes y vuelven a escalar hacia abajo cuando están inactivos.

Cluster Autoscaler de EC2

Estrategia de Instancias

• Grupos de Nodos: Múltiples grupos de nodos con diferentes tipos de instancias para la optimización de costos
• Carga de Trabajo de Consulta: Instancias optimizadas para memoria para segmentos vectoriales en memoria
• Carga de Trabajo de Índices: Instancias optimizadas para computación para la construcción de índices intensiva en CPU
• Spot Instances: Los nodos de índices y los nodos de datos no críticos se ejecutan en spot instances para ahorros significativos
• Bajo Demanda: Nodos de consulta y coordinadores en instancias bajo demanda para mayor estabilidad

Comportamiento de Escalado

Cuando el HPA crea nuevos pods que no se pueden programar, el Cluster Autoscaler aprovisiona nuevas instancias EC2 en el grupo de nodos apropiado. Los nuevos nodos de consulta luego cargan sus segmentos asignados desde S3 a la memoria y comienzan a atender consultas, completándose el proceso total de escalado ascendente en minutos.

Almacenamiento Persistente con Respaldo en S3

Por qué S3 en lugar de Block Storage

S3 ofrece ventajas significativas sobre el block storage para Milvus:

• ~80% menos costo de almacenamiento para grandes conjuntos de datos
• Durabilidad de 11 nueves con replicación multi-AZ integrada
• Escalado ilimitado sin redimensionamiento manual de volúmenes
• Independiente del Pod — Datos siempre disponibles independientemente del ciclo de vida del pod o del nodo
• Sin AZ lock-in — Datos accesibles desde cualquier availability zone

Flujo de Datos con S3

1. Ruta de Escritura: Los nodos de datos almacenan inserciones en memoria, luego vacían segmentos sellados a S3
2. Construcción de Índices: Los nodos de índices leen segmentos de S3, construyen índices y escriben los archivos de índices de vuelta a S3
3. Ruta de Consulta: Los nodos de consulta descargan segmentos e índices de S3, los cargan en memoria y atienden consultas
4. Recuperación: Al reiniciar un pod, los nodos de consulta vuelven a descargar los segmentos asignados de S3 (sin pérdida de datos)

Optimización del Rendimiento de S3

• Ajuste del tamaño de segmento equilibra los costos de solicitudes de S3 vs. la frescura de los datos
• Caché local en SSD en almacenamiento de instancias NVMe evita lecturas repetidas de S3 para segmentos "calientes"
• Descargas paralelas permiten un inicio rápido de los nodos de consulta
• Políticas de ciclo de vida archivan datos antiguos en niveles de almacenamiento más económicos

Monitoreo y Observabilidad

La implementación incluye monitoreo integral a través de Prometheus y Grafana:

• Rendimiento de Consultas — Distribución de latencia, QPS, tasa de aciertos de caché
• Visión General del Clúster — Conteo de nodos, estado de pods, utilización de recursos
• Salud del Almacenamiento — Uso de S3, conteo de segmentos, tasas de vaciado
• Eventos de Autoescalado — Eventos HPA, escalado de nodos, latencia de programación de pods
• Alertas — Alertas automatizadas para alta latencia, riesgo de OOM, fallas de vaciado y límites de capacidad

Características Clave

1. HPA de Nodos de Consulta — Escalado automático basado en CPU, memoria, latencia y profundidad de cola
2. Cluster Autoscaler de EC2 — Aprovisionamiento dinámico de nodos con tipos de instancias mixtos
3. Persistencia en S3 — Durabilidad de 11 nueves, ~80% más económico que el block storage, sobrevive a fallas de AZ
4. Spot Instances — Nodos de índices y de datos en spot para ahorros significativos en computación
5. Caché Local en SSD — El caché NVMe elimina las lecturas repetidas de S3 para segmentos "calientes"
6. Recuperación sin Tiempo de Inactividad — Los reinicios de pods recargan segmentos de S3 sin pérdida de datos
7. Multi-AZ — Almacenamiento en S3 + grupos de nodos multi-AZ para tolerancia total a fallas de AZ
8. Observabilidad — Prometheus + Grafana con métricas específicas de Milvus y visibilidad de autoescalado