Milvus-Autoskalierung auf Kubernetes mit EC2 und S3-gestütztem persistentem Speicher
Eine KI-Plattform mit schnell wachsendem Vektordatenbestand (Einbettungen für Suche, Empfehlungen und RAG) benötigte ihre Milvus-Vektordatenbank, um sich automatisch basierend auf Abfragelast und Datenvolumen zu skalieren — mit langlebigem, kosteneffizientem Speicher, der nicht verloren geht, wenn Pods neu gestartet oder Knoten ersetzt werden.
Ihr Projekt besprechen
Die Herausforderung
Der Betrieb von Milvus im großen Maßstab in der Produktion stellte mehrere Infrastrukturherausforderungen dar:
- Feste Kapazität — Statische Milvus-Bereitstellungen konnten 10-fache Abfragelastspitzen während der Stoßzeiten nicht bewältigen
- Risiko von Datenverlust — Pod-Neustarts auf flüchtigem Speicher führten zu Index-Neuaufbauten, die bei großen Sammlungen Stunden dauerten
- Kostenineffizienz — Überprovisionierung für Spitzenlast bedeutete, 70% der Zeit für ungenutzte Rechenleistung zu zahlen
- Speicherkosten — An Instanzen gebundene Blockspeichervolumen waren teuer für mehrstufige Vektordatensätze
- Index-Neuaufbauten — Die Neuindizierung von Millionen von Vektoren nach einem Knotenwechsel dauerte Stunden Ausfallzeit
- Multi-AZ-Dauerhaftigkeit — Einzonen-Speicher konnte Ausfälle von Verfügbarkeitszonen nicht überstehen
Unsere Lösung
Wir haben Milvus auf Kubernetes (EKS) mit horizontaler Pod-Autoskalierung für Abfragknoten, Cluster-Autoscaler für Rechenleistung und Amazon S3 als persistenten Speicher-Backend bereitgestellt — das Risiko von Datenverlust eliminiert und die Speicherkosten um ~80% reduziert.
Architektur
- Orchestrierung: Amazon EKS (Elastic Kubernetes Service)
- Rechenleistung: EC2-Instanzen (gemischte Instanztypen) verwaltet durch Cluster-Autoscaler
- Vektor-Datenbank: 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
- Nachrichtenwarteschlange: Nachrichtenstreaming für Milvus-Log-Pipeline
- Überwachung: Prometheus + Grafana für Milvus-Metriken und Autoskalierungssignale
Milvus-Verteilte Architektur auf Kubernetes
Komponentenbereitstellung
Milvus läuft im verteilten Modus mit dedizierten Knotentypen, die jeweils als Kubernetes-Workload mit unabhängiger Skalierung bereitgestellt werden:
- Proxy-Knoten — Bearbeiten Client-Verbindungen und Anforderungsrouting
- Abfragknoten — Führen Vektorsuchen durch und laden Segmente in den Speicher
- Datenknoten — Bearbeiten Schreibpfade und spülen Segmente nach S3
- Indexknoten — Erstellen Vektorindizes und schreiben nach S3
- Koordinator — Cluster-Koordination und Zeitstempelzuweisung
- etcd — Metadatenspeicherung und Dienstentdeckung
- Nachrichtenwarteschlange — Log-Streaming und Write-Ahead-Log
Horizontale Pod-Autoskalierung (HPA)
Abfragknoten-Autoskalierung
Abfragknoten sind das primäre Skalierungsziel — sie laden Vektorsequenzen in den Speicher und führen Suchen durch. Die Skalierung wird durch mehrere Metriken gesteuert, einschließlich CPU-Auslastung, Speicherauslastung, Abfragewarteschlangentiefe und P99-Abfragelatenz. Die HPA ist mit geeigneten Min/Max-Replikaten konfiguriert, schnellem Hochskalieren zur Bewältigung von Spitzen und allmählichem Herunterskalieren, um Flattern zu vermeiden.
Indexknoten-Autoskalierung
Indexknoten skalieren basierend auf ausstehenden Indexaufbauaufträgen — sie skalieren hoch, wenn die Bauwarteschlange ausstehende Elemente hat, und skalieren herunter, wenn sie im Leerlauf sind.
EC2-Cluster-Autoscaler
Instanzstrategie
- Knotengruppen: Mehrere Knotengruppen mit unterschiedlichen Instanztypen zur Kostenoptimierung
- Abfraglast: Speicheroptimierte Instanzen für im Speicher befindliche Vektorsequenzen
- Indexlast: Rechenoptimierte Instanzen für CPU-intensive Indexerstellung
- Spot-Instanzen: Indexknoten und nicht-kritische Datenknoten laufen auf Spot-Instanzen für erhebliche Einsparungen
- On-Demand: Abfragknoten und Koordinatoren auf On-Demand-Instanzen für Stabilität
Skalierungsverhalten
Wenn HPA neue Pods erstellt, die nicht geplant werden können, stellt der Cluster-Autoscaler neue EC2-Instanzen in der entsprechenden Knotengruppe bereit. Neue Abfragknoten laden dann ihre zugewiesenen Segmente aus S3 in den Speicher und beginnen mit der Bearbeitung von Abfragen, wobei der gesamte Hochskalierungsprozess in Minuten abgeschlossen ist.
S3-gestützter persistenter Speicher
Warum S3 statt Blockspeicher
S3 bietet erhebliche Vorteile gegenüber Blockspeicher für Milvus:
- ~80% niedrigere Speicherkosten für große Datensätze
- 11 Neunen Dauerhaftigkeit mit integrierter Multi-AZ-Replikation
- Unbegrenzte Skalierung ohne manuelle Volumenanpassung
- Pod-unabhängig — Daten sind immer verfügbar, unabhängig vom Lebenszyklus von Pod oder Knoten
- Keine AZ-Bindung — Daten sind von jeder Verfügbarkeitszone aus zugänglich
Datenfluss mit S3
- Schreibpfad: Datenknoten puffern Einsätze im Speicher und spülen dann versiegelte Segmente nach S3
- Indexaufbau: Indexknoten lesen Segmente aus S3, erstellen Indizes und schreiben Indexdateien zurück nach S3
- Abfragepfad: Abfragknoten laden Segmente und Indizes aus S3 herunter, laden sie in den Speicher und bedienen Abfragen
- Wiederherstellung: Beim Neustart des Pods laden Abfragknoten die zugewiesenen Segmente aus S3 erneut herunter (kein Datenverlust)
S3-Leistungsoptimierung
- Segmentgrößenanpassung balanciert S3-Anfragekosten gegenüber Datenfrische
- Lokales SSD-Caching auf NVMe-Instanzspeicher vermeidet wiederholte S3-Lesevorgänge für heiße Segmente
- Parallele Downloads ermöglichen einen schnellen Start der Abfragknoten
- Lebenszyklusrichtlinien archivieren alte Daten in günstigere Speicherebenen
Überwachung & Beobachtbarkeit
Die Bereitstellung umfasst eine umfassende Überwachung über Prometheus und Grafana:
- Abfrageleistung — Latenzverteilung, QPS, Cache-Trefferquote
- Cluster-Übersicht — Knotenzahl, Pod-Status, Ressourcenauslastung
- Speichergesundheit — S3-Nutzung, Segmentanzahl, Flush-Raten
- Autoskalierungsereignisse — HPA-Ereignisse, Knotenskalierung, Pod-Planungslatenz
- Alarmierung — Automatisierte Alarme für hohe Latenz, OOM-Risiko, Flush-Fehler und Kapazitätsgrenzen
Hauptmerkmale
- Abfragknoten-HPA — Automatische Skalierung basierend auf CPU, Speicher, Latenz und Warteschlangentiefe
- EC2-Cluster-Autoscaler — Dynamische Knotenbereitstellung mit gemischten Instanztypen
- S3-Persistenz — 11 Neunen Dauerhaftigkeit, ~80% günstiger als Blockspeicher, übersteht AZ-Ausfälle
- Spot-Instanzen — Index- und Datenknoten auf Spot für signifikante Recheneinsparungen
- Lokaler SSD-Cache — NVMe-Caching eliminiert wiederholte S3-Lesevorgänge für heiße Segmente
- Wiederherstellung ohne Ausfallzeit — Pod-Neustarts laden Segmente aus S3 ohne Datenverlust neu
- Multi-AZ — S3-Speicher + Multi-AZ-Knotengruppen für vollständige AZ-Ausfalltoleranz
- Beobachtbarkeit — Prometheus + Grafana mit Milvus-spezifischen Metriken und Autoskalierungsübersicht
Ergebnisse
Technologie-Stack
caseStudyDetail.more Fallstudien
Entdecken Sie mehr unserer technischen Implementierungen
Catant HR- und Workforce-Management-Plattform
Catant ist eine modulare HR- und Workforce-Management-Plattform, die Unternehmen dabei unterstützt, Mitarbeiter, Gehaltsabrechnung, Anwesenheit und Compliance von einem einzigen Dashboard aus zu verwalten.
Kickly: KI-gestützte Projektplattform für Startups
Kickly ist eine KI-gestützte Projektmanagementplattform, die speziell für Startups entwickelt wurde. Sie kombiniert intelligente Aufgabenautomatisierung, Teamzusammenarbeit und Echtzeit-Fortschrittsverfolgung in einem Produkt.
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.