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 konfigurierte die horizontale Pod-Autoskalierung mit benutzerdefinierten Metriken aus Milvus' integriertem Speicherverbrauch-Exporter, die Scale-Out-Ereignisse auslösen, wenn ein Abfrageknoten 75 % der Speichernutzung überschreitet. Sammlungsegmente werden mithilfe von Milvus' Segment-Manager automatisch auf neue Knoten umverteilt, wodurch verhindert wird, dass ein einzelner Knoten zum Engpass wird.
MicrocosmWorks wählte S3-basierten Speicher, wobei MinIO als Objektspeicherschicht verwendet wurde, weil es den Speicher von der Rechenleistung entkoppelt. Dies ermöglicht es Abfrageknoten, unabhängig zu skalieren, ohne neue EBS-Volumes bereitstellen zu müssen. Diese Architektur senkt die Speicherkosten um etwa 60% im Vergleich zu gp3 EBS-Volumes, während Segmentladezeiten von S3 von unter 100 ms beibehalten werden.
MicrocosmWorks konfigurierte die Bereitstellung mit Replica Sets für jede Milvus-Komponente, einschließlich Query Nodes, Index Nodes und Data Nodes, wobei Pod Disruption Budgets eine minimale Verfügbarkeit während Rolling Updates gewährleisten. Da alle persistenten Daten in S3 liegen, kann der Ersatz eines ausgefallenen Knotens sofort auf alle Segmente zugreifen, ohne dass eine Datenmigration erforderlich ist.
MicrocosmWorks hat festgestellt, dass r6i.2xlarge-Instanzen das optimale Kosten-Leistungs-Verhältnis für Milvus-Abfrageworkloads bieten, die 64 GB Arbeitsspeicher für das In-Memory-Segment-Caching zu einem wettbewerbsfähigen Spot-Preis bereitstellen. Für GPU-beschleunigte Indexerstellung haben g5.xlarge-Instanzen mit NVIDIA A10G GPUs die Indexerstellungszeiten im Vergleich zu reinen CPU-Builds um das 8-fache reduziert.
MicrocosmWorks liefert Kubernetes-Infrastrukturprojekte zu Stundensätzen von 30-50 $/Std., wobei eine Milvus-Autoscaling-Bereitstellung, einschließlich Helm-Chart-Anpassung, HPA-Konfiguration, S3-Integration und Überwachungseinrichtung, typischerweise 150-250 Stunden erfordert. Fortlaufender verwalteter Support für Cluster-Optimierung und Upgrades ist zu den gleichen Stundensätzen verfügbar.
Bereit, Ihr Unternehmen zu transformieren?
Lassen Sie uns besprechen, wie wir ähnliche Lösungen für Ihre Herausforderungen anwenden können.