MicrocosmWorksInnovando y Arquitectando el Cosmos Digital
Acerca deContacto
MicrocosmWorksInnovando y Arquitectando el Cosmos Digital

Ofreciendo soluciones de TI que importan. Nos apasiona la tecnología, la seguridad y ayudar a las empresas a crecer a través de una infraestructura de TI confiable e innovadora.

[email protected]
+91 7011868196
New Delhi, India

Centro de Crecimiento de IA

Centro de IAInnovación para StartupsAcelerador Empresarial

Soluciones

Todas las SolucionesAplicaciones de Bienestar y FitnessPlataforma de Video con IADesarrollo de Agentes de IA

Recursos

PerspectivasGuías de la IndustriaPlanos de Casos de UsoPatrones de ArquitecturaEstudios de Caso

Compañía

Sobre NosotrosContactoNuestro Trabajo

Servicios

Consultoría DigitalInfraestructura en la NubeDesarrollo SaaSDesarrollo de IATecnología de Video
Desarrollo ERPPersonalización de ZohoDesarrollo de OdooIntegración de SalesforceDesarrollo de CRM Personalizado
Integración de QuickBooksSoluciones IoTDesarrollo de Blockchain
Consultoría de CiberseguridadSoporte IT - L3

© 2026 MicrocosmWorks. Todos los derechos reservados.

Política de PrivacidadTérminos de Servicio
Volver a Casos de Estudio
Vector DatabasesPublicado June 22, 2026 · Actualizado June 22, 2026

Milvus Autoscaling en Kubernetes con EC2 y Almacenamiento Persistente Respaldado por S3

Una plataforma de AI con datos vectoriales de rápido crecimiento (embeddings para búsqueda, recomendaciones y RAG) necesitaba que su base de datos vectorial Milvus escalara automáticamente según la carga de consultas y el volumen de datos, con un almacenamiento duradero y rentable que no se perdería si los pods se reiniciaran o los nodos fueran reemplazados.

Discuta Su Proyecto
milvus-autoscaling-kubernetes-s3.webp
Vector Databases
Domain
11
Technologies
6
Key Results
Delivered
Status

El Desafío

Ejecutar Milvus a escala en producción presentaba varios desafíos de infraestructura:

  • Capacidad Fija — Las implementaciones estáticas de Milvus no podían manejar picos de carga de consultas de 10x durante las horas pico
  • Riesgo de Pérdida de Datos — Los reinicios de pods en almacenamiento efímero causaban reconstrucciones de índices que tomaban horas en colecciones grandes
  • Ineficiencia de Costos — El sobreaprovisionamiento para la carga pico significaba pagar por computación ociosa el 70% del tiempo
  • Costos de Almacenamiento — Los volúmenes de almacenamiento en bloque vinculados a las instancias eran caros para conjuntos de datos vectoriales de varios terabytes
  • Reconstrucciones de Índices — La reindexación de millones de vectores después de un reemplazo de nodo tomaba horas de inactividad
  • Durabilidad Multi-AZ — El almacenamiento de una sola AZ no podía sobrevivir a fallas de zona de disponibilidad

Nuestra Solución

Implementamos Milvus en Kubernetes (EKS) con Horizontal Pod Autoscaling para nodos de consulta, Cluster Autoscaler para 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 instancia 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: cluster etcd para la coordinación y los 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 autoscaling

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 — Manejan las conexiones de clientes y el enrutamiento de solicitudes
  • Nodos de Consulta — Ejecutan búsquedas vectoriales y cargan segmentos en la memoria
  • Nodos de Datos — Manejan las rutas de escritura y vacían los segmentos a S3
  • Nodos de Índice — Construyen índices vectoriales y escriben a S3
  • Coordinador — Coordinación de cluster y asignación de marcas de tiempo
  • etcd — Almacenamiento de metadatos y descubrimiento de servicios
  • Cola de Mensajes — Streaming de logs y write-ahead log

Horizontal Pod Autoscaling (HPA)

Autoscaling de Nodos de Consulta

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

Autoscaling de Nodos de Índice

Los nodos de índice escalan en función de los trabajos de construcción de índices pendientes: escalando cuando la cola de construcción tiene elementos pendientes y desescalando cuando están inactivos.

EC2 Cluster Autoscaler

Estrategia de Instancias

  • Grupos de Nodos: Múltiples grupos de nodos con diferentes tipos de instancias para 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 índice y los nodos de datos no críticos se ejecutan en instancias Spot para ahorros significativos
  • On-Demand: Nodos de consulta y coordinadores en instancias On-Demand para estabilidad

Comportamiento de Escalado

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

Almacenamiento Persistente Respaldado por S3

Por qué S3 en lugar de Almacenamiento en Bloque

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

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 índice leen segmentos de S3, construyen índices y escriben los archivos de índice de vuelta a S3
  3. Ruta de Consulta: Los nodos de consulta descargan segmentos e índices de S3, los cargan en memoria y sirven consultas
  4. Recuperación: En el reinicio del 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 segmentos equilibra los costos de solicitud de S3 frente a la frescura de los datos
  • Caching local de SSD en el almacenamiento de instancias NVMe evita lecturas repetidas de S3 para segmentos activos
  • 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 Cluster — Recuento de nodos, estado de pods, utilización de recursos
  • Salud del Almacenamiento — Uso de S3, recuento de segmentos, tasas de vaciado
  • Eventos de Autoscaling — Eventos de HPA, escalado de nodos, latencia de programación de pods
  • Alertas — Alertas automáticas 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. EC2 Cluster Autoscaler — Aprovisionamiento dinámico de nodos con tipos de instancias mixtos
  3. Persistencia de S3 — 11 nueves de durabilidad, ~80% más económico que el almacenamiento en bloque, sobrevive a fallas de AZ
  4. Spot Instances — Nodos de índice y de datos en Spot para ahorros significativos en computación
  5. Caché SSD Local — El caching NVMe elimina lecturas repetidas de S3 para segmentos activos
  6. Recuperación sin Tiempo de Inactividad — Los reinicios de pods recargan segmentos de S3 sin pérdida de datos
  7. Multi-AZ — Almacenamiento S3 + grupos de nodos multi-AZ para tolerancia completa a fallas de AZ
  8. Observabilidad — Prometheus + Grafana con métricas específicas de Milvus y visibilidad de autoscaling

Resultados

Costo de Almacenamiento: ~80% de reducción vs. implementación respaldada por almacenamiento en bloque
Costo de Computación: ~40% de reducción mediante instancias Spot y autoscaling de tamaño adecuado
Latencia de Consultas: P99 mantenido por debajo de 200ms durante picos de carga de 10x

Stack Tecnológico

MilvusAmazon EKSKubernetes HPACluster AutoscalerAmazon EC2Amazon S3etcdPrometheusGrafanaHelmNVMe Instance Storage

caseStudyDetail.more Casos de Estudio

Explore más de nuestras implementaciones técnicas

AI Accounting

Procesamiento de Facturas Potenciado por AI con OCR e Integración con QuickBooks

Una empresa de tamaño mediano que procesa cientos de facturas de proveedores mensualmente necesitaba eliminar la entrada de datos manual extrayendo automáticamente los datos de las facturas usando AI/OCR y sincronizándolos directamente en QuickBooks para la contabilidad y el seguimiento de pagos.

Leer Caso de Estudio
Video Encoding

Inserción de Anuncios en el Lado del Cliente (CSAI) con Análisis de Marcadores SCTE-35 e Integración de Reproductor Multiplataforma

Una plataforma de streaming de video necesitaba implementar la Inserción de Anuncios en el Lado del Cliente (CSAI) en sus aplicaciones web, móviles y de TV conectada, lo que permitiría experiencias publicitarias personalizadas a nivel de dispositivo con soporte completo para la interacción con anuncios (superposiciones clicables, banners complementarios, botones para omitir) que la inserción del lado del servidor no puede proporcionar.

Preguntas Frecuentes

MicrocosmWorks configured horizontal pod autoscaling with custom metrics from Milvus's built-in memory usage exporter, triggering scale-out events when any query node exceeds 75% memory utilization. Collection segments are automatically redistributed across new nodes using Milvus's segment manager, preventing any single node from becoming a bottleneck.

MicrocosmWorks selected S3-backed storage using MinIO as the object storage layer because it decouples storage from compute, allowing query nodes to scale independently without provisioning new EBS volumes. This architecture reduces storage costs by approximately 60% compared to gp3 EBS volumes while maintaining sub-100ms segment load times from S3.

MicrocosmWorks configured the deployment with replica sets for each Milvus component, including query nodes, index nodes, and data nodes, with pod disruption budgets ensuring minimum availability during rolling updates. Since all persistent data resides in S3, a failed node's replacement can immediately access all segments without data migration.

MicrocosmWorks found that r6i.2xlarge instances provide the optimal cost-to-performance ratio for Milvus query workloads, offering 64GB of memory for in-memory segment caching at a competitive spot price. For GPU-accelerated index building, g5.xlarge instances with NVIDIA A10G GPUs reduced index build times by 8x compared to CPU-only builds.

MicrocosmWorks delivers Kubernetes infrastructure projects at rates of $30-$50/hr, with a Milvus autoscaling deployment including Helm chart customization, HPA configuration, S3 integration, and monitoring setup typically requiring 150-250 hours. Ongoing managed support for cluster optimization and upgrades is available at the same hourly rates.

¿Listo para Transformar su Negocio?

Hablemos sobre cómo podemos aplicar soluciones similares a sus desafíos.

ContáctenoscaseStudyDetail.viewAllCaseStudies
Tiempo de Recuperación: Reinicio de pod a servicio de consultas en 30-90 segundos (recarga de segmento S3)
Durabilidad: Cero pérdida de datos en múltiples reemplazos de nodos y conmutaciones por error de AZ
Escala: Manejó más de 50M de vectores con escalado automático de 2 a 20 nodos de consulta
Leer Caso de Estudio
Web Scraping

Plataforma de Raspado y Generación de Contenido para Blogs Impulsada por AI

Una empresa de medios necesitaba una plataforma de contenido inteligente que pudiera automatizar la creación de contenido para blogs mediante el raspado de contenido web existente, analizándolo usando AI y generando publicaciones de blog originales y optimizadas para SEO a partir de los datos extraídos.

Leer Caso de Estudio