Milvus-Autoscaling auf Kubernetes mit EC2 und S3-gestĂĽtztem persistentem Speicher
Eine AI-Plattform mit schnell wachsenden Vektordaten (Embeddings für Suche, Empfehlungen und RAG) benötigte ihre Milvus-Vektordatenbank, um automatisch basierend auf Abfragelast und Datenvolumen zu skalieren — mit langlebigem, kostengünstigem Speicher, der bei Neustart von Pods oder Austausch von Nodes nicht verloren ginge.
Ihr Projekt besprechen
Die Herausforderung
Der Betrieb von Milvus im ProduktionsmaĂźstab stellte mehrere Infrastrukturherausforderungen dar:
- Feste Kapazität — Statische Milvus-Deployments konnten 10-fache Spitzen bei der Abfragelast während der Hauptverkehrszeiten nicht bewältigen
- Risiko von Datenverlust — Pod-Neustarts auf ephemerem Speicher verursachten Index-Rebuilds, die bei großen Sammlungen Stunden dauerten
- Kostenineffizienz — Die Überprovisionierung für Spitzenlasten bedeutete, 70% der Zeit für ungenutzte Rechenleistung zu zahlen
- Speicherkosten — An Instanzen gebundene Block-Storage-Volumes waren teuer für Multi-Terabyte-Vektordatenbestände
- Index-Rebuilds — Das Neuindizieren von Millionen von Vektoren nach einem Node-Austausch verursachte stundenlange Ausfallzeiten
- Multi-AZ-Dauerhaftigkeit — Single-AZ-Speicher konnte Verfügbarkeitszonenausfälle nicht überstehen
Unsere Lösung
Wir haben Milvus auf Kubernetes (EKS) mit Horizontal Pod Autoscaling für Query-Nodes, Cluster Autoscaler für Compute und Amazon S3 als persistenten Speicher-Backend eingesetzt — wodurch das Risiko von Datenverlust eliminiert und die Speicherkosten um ca. 80 % gesenkt wurden.
Architektur
- Orchestrierung: Amazon EKS (Elastic Kubernetes Service)
- Compute: EC2-Instanzen (gemischte Instanztypen) verwaltet vom Cluster Autoscaler
- Vektor-DB: Milvus bereitgestellt ĂĽber Helm Chart im verteilten Modus
- Objektspeicher: Amazon S3 fĂĽr Segmentdateien, Indexdateien und Binlog-Persistenz
- Metadaten: etcd-Cluster fĂĽr Milvus-Koordination und Metadaten
- Message Queue: Message-Streaming fĂĽr die Milvus-Log-Pipeline
- Monitoring: Prometheus + Grafana fĂĽr Milvus-Metriken und Autoscaling-Signale
Milvus verteilte Architektur auf Kubernetes
Komponenten-Deployment
Milvus läuft im verteilten Modus mit dedizierten Node-Typen, wobei jeder als Kubernetes-Workload mit unabhängiger Skalierung bereitgestellt wird:
- Proxy Nodes — Verwalten Client-Verbindungen und Request-Routing
- Query Nodes — Führen Vektorsuchen aus und laden Segmente in den Speicher
- Data Nodes — Verwalten Schreibpfade und flushen Segmente zu S3
- Index Nodes — Erstellen Vektorindizes und schreiben zu S3
- Coordinator — Cluster-Koordination und Zeitstempel-Zuweisung
- etcd — Metadatenspeicher und Service Discovery
- Message Queue — Log-Streaming und Write-Ahead-Log
Horizontal Pod Autoscaling (HPA)
Query Node Autoscaling
Query-Nodes sind das primäre Skalierungsziel — sie laden Vektorsegmente in den Speicher und führen Suchen aus. Die Skalierung wird durch mehrere Metriken gesteuert, einschließlich CPU-Auslastung, Speicherauslastung, Abfrage-Warteschlangentiefe und P99-Abfragelatenz. Die HPA ist mit entsprechenden Min/Max-Replicas, schnellem Scale-up zur Bewältigung von Spitzen und gradueller Scale-down zur Vermeidung von Flapping konfiguriert.
Index Node Autoscaling
Index-Nodes skalieren basierend auf ausstehenden Index-Build-Jobs — sie skalieren hoch, wenn die Build-Warteschlange ausstehende Elemente enthält, und wieder herunter, wenn sie inaktiv sind.
EC2 Cluster Autoscaler
Instanz-Strategie
- Node Groups: Mehrere Node Groups mit unterschiedlichen Instanztypen zur Kostenoptimierung
- Query-Workload: Speicheroptimierte Instanzen fĂĽr In-Memory-Vektorsegmente
- Index-Workload: Compute-optimierte Instanzen fĂĽr CPU-intensive Indexerstellung
- Spot Instances: Index-Nodes und nicht-kritische Data Nodes laufen auf Spot Instances fĂĽr erhebliche Einsparungen
- On-Demand: Query-Nodes und Coordinators auf On-Demand-Instanzen für Stabilität
Skalierungsverhalten
Wenn HPA neue Pods erstellt, die nicht geplant werden können, provisioniert der Cluster Autoscaler neue EC2-Instanzen in der entsprechenden Node Group. Neue Query-Nodes laden dann ihre zugewiesenen Segmente von S3 in den Speicher und beginnen mit der Bearbeitung von Abfragen, wobei der gesamte Scale-up-Prozess in wenigen Minuten abgeschlossen ist.
S3-gestĂĽtzter persistenter Speicher
Warum S3 anstelle von Block Storage
S3 bietet erhebliche Vorteile gegenĂĽber Block Storage fĂĽr Milvus:
- ~80 % niedrigere Speicherkosten fĂĽr groĂźe Datasets
- 11-Nines-Dauerhaftigkeit mit integrierter Multi-AZ-Replikation
- Unbegrenzte Skalierung ohne manuelle Volume-Anpassung
- Pod-unabhängig — Daten immer verfügbar, unabhängig vom Pod- oder Node-Lebenszyklus
- Kein AZ-Lock-in — Daten aus jeder Availability Zone zugänglich
Datenfluss mit S3
- Schreibpfad: Data Nodes puffern Inserts im Speicher und flushen dann versiegelte Segmente zu S3
- Index-Erstellung: Index Nodes lesen Segmente von S3, erstellen Indizes und schreiben Indexdateien zurĂĽck zu S3
- Abfragepfad: Query-Nodes laden Segmente und Indizes von S3 herunter, laden sie in den Speicher und bedienen Abfragen
- Wiederherstellung: Bei Pod-Neustart laden Query-Nodes zugewiesene Segmente erneut von S3 herunter (kein Datenverlust)
S3-Performance-Optimierung
- Segmentgrößen-Optimierung gleicht S3-Anfragekosten mit Datenaktualität ab
- Lokales SSD-Caching auf NVMe-Instanzspeicher vermeidet wiederholte S3-Lesevorgänge für Hot Segments
- Parallele Downloads ermöglichen schnellen Start von Query-Nodes
- Lifecycle Policies archivieren alte Daten in gĂĽnstigere Speicherebenen
Monitoring & Observability
Das Deployment umfasst ein umfassendes Monitoring ĂĽber Prometheus und Grafana:
- Abfrage-Performance — Latenzverteilung, QPS, Cache-Hit-Rate
- Cluster-Übersicht — Node-Anzahl, Pod-Status, Ressourcenauslastung
- Speicherintegrität — S3-Nutzung, Segmentanzahl, Flush-Raten
- Autoscaling-Events — HPA-Events, Node-Skalierung, Pod-Scheduling-Latenz
- Alerting — Automatisierte Alerts für hohe Latenz, OOM-Risiko, Flush-Fehler und Kapazitätsgrenzen
Hauptmerkmale
- Query Node HPA — Automatische Skalierung basierend auf CPU, Speicher, Latenz und Warteschlangentiefe
- EC2 Cluster Autoscaler — Dynamische Node-Bereitstellung mit gemischten Instanztypen
- S3-Persistenz — 11-Nines-Dauerhaftigkeit, ~80 % günstiger als Block Storage, übersteht AZ-Ausfälle
- Spot Instances — Index- und Data Nodes auf Spot Instances für erhebliche Compute-Einsparungen
- Lokaler SSD-Cache — NVMe-Caching eliminiert wiederholte S3-Lesevorgänge für Hot Segments
- Zero-Downtime Recovery — Pod-Neustarts laden Segmente von S3 neu, ohne Datenverlust
- Multi-AZ — S3-Speicher + Multi-AZ Node Groups für volle AZ-Fehlertoleranz
- Observability — Prometheus + Grafana mit Milvus-spezifischen Metriken und Autoscaling-Sichtbarkeit
Ergebnisse
Technologie-Stack
caseStudyDetail.more Fallstudien
Entdecken Sie mehr unserer technischen Implementierungen
KI-gestĂĽtzte Rechnungsverarbeitung mit OCR und QuickBooks-Integration
Ein mittelständisches Unternehmen, das monatlich Hunderte von Lieferantenrechnungen verarbeitete, musste die manuelle Dateneingabe eliminieren, indem es Rechnungsdaten automatisch mithilfe von AI/OCR extrahierte und diese direkt mit QuickBooks für die Buchhaltung und Zahlungsverfolgung synchronisierte.
Clientseitige Anzeigeninsertion (CSAI) mit SCTE-35 Marker-Parsing & Multi-Plattform-Player-Integration
Eine Video-Streaming-Plattform musste die Clientseitige Anzeigeninsertion (CSAI) über Web-, Mobil- und Connected TV-Apps hinweg implementieren – was personalisierte, gerätespezifische Anzeigenerlebnisse mit vollständiger Unterstützung der Anzeigeninteraktion (anklickbare Overlays, Companion-Banner, Skip-Buttons) ermöglicht, die serverseitige Insertion nicht bieten kann.
Häufig gestellte Fragen
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.
Bereit, Ihr Unternehmen zu transformieren?
Lassen Sie uns besprechen, wie wir ähnliche Lösungen für Ihre Herausforderungen anwenden können.