Mise à l'échelle automatique de Milvus sur Kubernetes avec stockage persistant basé sur EC2 et S3
Une plateforme d'AI avec des données vectorielles en croissance rapide (embeddings pour la recherche, les recommandations et le RAG) avait besoin que sa base de données vectorielle Milvus s'adapte automatiquement en fonction de la charge des requêtes et du volume de données — avec un stockage durable et économique qui ne serait pas perdu si les pods redémarraient ou si les nœuds étaient remplacés.
Discutez de Votre Projet
Le DĂ©fi
L'exécution de Milvus à grande échelle en production présentait plusieurs défis d'infrastructure :
- Capacité fixe — Les déploiements statiques de Milvus ne pouvaient pas gérer des pics de charge de requêtes 10x pendant les heures de pointe
- Risque de perte de données — Les redémarrages de pods sur un stockage éphémère entraînaient des reconstructions d'index prenant des heures sur de grandes collections
- Inefficacité des coûts — Le sur-provisionnement pour la charge de pointe signifiait payer pour du calcul inactif 70% du temps
- Coûts de stockage — Les volumes de stockage en bloc liés aux instances étaient coûteux pour des jeux de données vectorielles de plusieurs téraoctets
- Reconstructions d'index — La réindexation de millions de vecteurs après le remplacement d'un nœud entraînait des heures d'indisponibilité
- Durabilité Multi-AZ — Le stockage Single-AZ ne pouvait pas survivre aux pannes de zone de disponibilité
Notre Solution
Nous avons déployé Milvus sur Kubernetes (EKS) avec Horizontal Pod Autoscaling pour les nœuds de requête, Cluster Autoscaler pour le calcul, et Amazon S3 comme backend de stockage persistant — éliminant le risque de perte de données et réduisant les coûts de stockage d'environ 80%.
Architecture
- Orchestration : Amazon EKS (Elastic Kubernetes Service)
- Calcul : instances EC2 (types d'instances mixtes) gérées par Cluster Autoscaler
- Base de données vectorielle : Milvus déployé via un Helm chart en mode distribué
- Stockage d'objets : Amazon S3 pour les fichiers de segment, les fichiers d'index et la persistance des binlog
- Métadonnées : Cluster etcd pour la coordination et les métadonnées de Milvus
- File d'attente de messages : Message streaming pour le pipeline de logs de Milvus
- Monitoring : Prometheus + Grafana pour les métriques Milvus et les signaux d'autoscaling
Architecture distribuée de Milvus sur Kubernetes
DĂ©ploiement des composants
Milvus fonctionne en mode distribué avec des types de nœuds dédiés, chacun étant déployé comme une workload Kubernetes avec une mise à l'échelle indépendante :
- Nœuds Proxy — Gèrent les connexions client et le routage des requêtes
- Nœuds de requête — Exécutent les recherches vectorielles et chargent les segments en mémoire
- Nœuds de données — Gèrent les chemins d'écriture et purgent les segments vers S3
- Nœuds d'index — Construisent les index vectoriels et les écrivent sur S3
- Coordinateur — Coordination du cluster et allocation d'horodatages
- etcd — Stockage des métadonnées et découverte de services
- File d'attente de messages — Streaming de logs et write-ahead log
Horizontal Pod Autoscaling (HPA)
Autoscaling des nœuds de requête
Les nœuds de requête sont la cible principale de la mise à l'échelle — ils chargent les segments vectoriels en mémoire et exécutent les recherches. La mise à l'échelle est pilotée par plusieurs métriques, notamment l'utilisation du CPU, l'utilisation de la mémoire, la profondeur de la file d'attente des requêtes et la latence P99 des requêtes. Le HPA est configuré avec les réplicas min/max appropriés, une mise à l'échelle rapide pour gérer les pics et une réduction progressive pour éviter le flapping.
Autoscaling des nœuds d'index
Les nœuds d'index s'adaptent en fonction des tâches de construction d'index en attente — mise à l'échelle à la hausse lorsque la file d'attente de construction contient des éléments en attente et réduction à la baisse lorsqu'ils sont inactifs.
EC2 Cluster Autoscaler
Stratégie d'instances
- Groupes de nœuds : Plusieurs groupes de nœuds avec différents types d'instances pour l'optimisation des coûts
- Workload de requêtes : Instances optimisées pour la mémoire pour les segments vectoriels en mémoire
- Workload d'index : Instances optimisées pour le calcul pour la construction d'index gourmande en CPU
- Spot Instances : Les nœuds d'index et les nœuds de données non critiques s'exécutent sur des Spot Instances pour des économies significatives
- On-Demand : Nœuds de requête et coordinateurs sur des instances On-Demand pour la stabilité
Comportement de mise Ă l'Ă©chelle
Lorsque le HPA crée de nouveaux pods qui ne peuvent pas être planifiés, le Cluster Autoscaler provisionne de nouvelles instances EC2 dans le groupe de nœuds approprié. Les nouveaux nœuds de requête chargent ensuite leurs segments assignés depuis S3 en mémoire et commencent à servir les requêtes, le processus total de mise à l'échelle se terminant en quelques minutes.
Stockage persistant basé sur S3
Pourquoi S3 plutĂ´t que le stockage en bloc
S3 offre des avantages significatifs par rapport au stockage en bloc pour Milvus :
- Coût de stockage réduit d'environ 80% pour les grands jeux de données
- Durabilité de 11-nines avec réplication multi-AZ intégrée
- Mise à l'échelle illimitée sans redimensionnement manuel des volumes
- Indépendant des pods — Données toujours disponibles quel que soit le cycle de vie du pod ou du nœud
- Pas de verrouillage AZ — Données accessibles depuis n'importe quelle zone de disponibilité
Flux de données avec S3
- Chemin d'écriture : Les nœuds de données mettent en tampon les insertions en mémoire, puis purgent les segments scellés vers S3
- Construction d'index : Les nœuds d'index lisent les segments depuis S3, construisent les index et écrivent les fichiers d'index sur S3
- Chemin de requête : Les nœuds de requête téléchargent les segments et les index depuis S3, les chargent en mémoire et servent les requêtes
- Récupération : Au redémarrage du pod, les nœuds de requête téléchargent à nouveau les segments assignés depuis S3 (aucune perte de données)
Optimisation des performances S3
- Ajustement de la taille des segments équilibre les coûts des requêtes S3 et la fraîcheur des données
- Mise en cache locale sur SSD sur le stockage d'instances NVMe évite les lectures S3 répétées pour les segments chauds
- Téléchargements parallèles permettent un démarrage rapide des nœuds de requête
- Politiques de cycle de vie archivent les anciennes données vers des niveaux de stockage moins chers
Monitoring et observabilité
Le déploiement comprend une surveillance complète via Prometheus et Grafana :
- Performances des requêtes — Distribution de la latence, QPS, taux de réussite du cache
- Aperçu du cluster — Nombre de nœuds, statut des pods, utilisation des ressources
- Santé du stockage — Utilisation de S3, nombre de segments, taux de vidage
- Événements d'autoscaling — Événements HPA, mise à l'échelle des nœuds, latence de planification des pods
- Alerting — Alertes automatisées pour la latence élevée, le risque d'OOM, les échecs de vidage et les limites de capacité
Fonctionnalités clés
- HPA des nœuds de requête — Mise à l'échelle automatique basée sur le CPU, la mémoire, la latence et la profondeur de la file d'attente
- EC2 Cluster Autoscaler — Provisionnement dynamique des nœuds avec des types d'instances mixtes
- Persistance S3 — Durabilité de 11-nines, ~80% moins cher que le stockage en bloc, survit aux pannes AZ
- Spot Instances — Nœuds d'index et de données sur Spot Instances pour des économies de calcul significatives
- Cache SSD local — Le caching NVMe élimine les lectures S3 répétées pour les segments chauds
- Récupération sans interruption — Les redémarrages de pods rechargent les segments depuis S3 sans perte de données
- Multi-AZ — Stockage S3 + groupes de nœuds multi-AZ pour une tolérance complète aux pannes AZ
- Observabilité — Prometheus + Grafana avec des métriques spécifiques à Milvus et une visibilité de l'autoscaling
RĂ©sultats
Stack Technologique
caseStudyDetail.more Études de Cas
Découvrez plus de nos implémentations techniques
Traitement de factures assisté par l'IA avec OCR et intégration QuickBooks
Une entreprise de taille moyenne, traitant des centaines de factures fournisseurs chaque mois, devait éliminer la saisie manuelle des données en extrayant automatiquement les données des factures à l'aide de l'IA/OCR et en les synchronisant directement dans QuickBooks pour la tenue de livres et le suivi des paiements.
Insertion d'annonces côté client (CSAI) avec analyse des marqueurs SCTE-35 et intégration de lecteurs multiplateformes
Une plateforme de streaming vidéo devait implémenter l'insertion d'annonces côté client (CSAI) sur les applications web, mobiles et de télévision connectée — permettant des expériences publicitaires personnalisées au niveau de l'appareil avec un support complet d'interaction publicitaire (superpositions cliquables, bannières complémentaires, boutons de saut) que l'insertion côté serveur ne peut pas offrir.
Questions fréquemment posées
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.
PrĂŞt Ă Transformer Votre Entreprise ?
Discutons de la façon dont nous pouvons appliquer des solutions similaires à vos défis.