Milvus Automatisk skalering på Kubernetes med EC2 og S3-understøttet vedvarende lagring
En AI-platform med hurtigt voksende vektordata (embeddings til søgning, anbefalinger og RAG) havde brug for, at deres Milvus-vektordatabase skalerede automatisk baseret på forespørgselsbelastning og datavolumen — med holdbar, omkostningseffektiv lagring, der ikke ville gå tabt, hvis pods genstartede, eller noder blev udskiftet.
Diskuter Dit Projekt
Udfordringen
At køre Milvus i stor skala i produktion præsenterede adskillige infrastrukturudfordringer:
- Fast Kapacitet — Statiske Milvus-implementeringer kunne ikke håndtere 10x spidser i forespørgselsbelastningen i spidsbelastningsperioder
- Risiko for Datatab — Pod-genstarter på midlertidig lagring forårsagede genopbygning af indekser, der tog timer på store samlinger
- Omkostningsineffektivitet — Over-provisionering til spidsbelastning betød at betale for inaktiv beregningskraft 70% af tiden
- Lageromkostninger — Bloklager-volumener bundet til instanser var dyre for multi-terabyte vektordatasæt
- Indeksgenopbygninger — Genindeksering af millioner af vektorer efter en nodeudskiftning tog flere timers nedetid
- Multi-AZ Holdbarhed — Single-AZ lagring kunne ikke overleve fejl i tilgængelighedszoner
Vores Løsning
Vi implementerede Milvus på Kubernetes (EKS) med Horizontal Pod Autoscaling til forespørgselsnoder, Cluster Autoscaler til beregningskraft og Amazon S3 som den vedvarende lagerbackend — hvilket eliminerede risikoen for datatab og reducerede lageromkostningerne med ~80%.
Arkitektur
- Orkestrering: Amazon EKS (Elastic Kubernetes Service)
- Beregning: EC2-instanser (blandede instanstyper) administreret af Cluster Autoscaler
- Vektor DB: Milvus implementeret via Helm chart i distribueret tilstand
- Objektlagring: Amazon S3 til segmentfiler, indekseringsfiler og binlog-persistens
- Metadata: etcd-cluster til Milvus-koordinering og metadata
- Beskedkø: Beskedstreaming til Milvus-logpipeline
- Overvågning: Prometheus + Grafana til Milvus-metrics og autoscaling-signaler
Milvus Distribueret Arkitektur på Kubernetes
Komponentimplementering
Milvus kører i distribueret tilstand med dedikerede nodetyper, hver implementeret som en Kubernetes-arbejdsbelastning med uafhængig skalering:
- Proxy-noder — Håndterer klientforbindelser og anmodningsrouting
- Forespørgselsnoder — Udfører vektorsøgninger og indlæser segmenter i hukommelsen
- Datanoder — Håndterer skriveveje og skyller segmenter til S3
- Indeksnoder — Bygger vektorindekser og skriver til S3
- Koordinator — Clusterkoordinering og tidsstempelallokering
- etcd — Metadatalagring og serviceopdagelse
- Beskedkø — Logstreaming og write-ahead log
Horizontal Pod Autoscaling (HPA)
Forespørgselsnode Autoscaling
Forespørgselsnoder er det primære skaleringsmål — de indlæser vektorsegmenter i hukommelsen og udfører søgninger. Skalering drives af flere metrics, herunder CPU-udnyttelse, hukommelsesudnyttelse, forespørgselskødybde og P99 forespørgselslatency. HPA'en er konfigureret med passende min/max replikaer, hurtig opskalering til håndtering af spidser og gradvis nedskalering for at undgå at flappe.
Indeksnode Autoscaling
Indeksnoder skalerer baseret på ventende indeksopbygningsjob — skalerer op, når opbygningskøen har ventende elementer, og skalerer ned, når de er inaktive.
EC2 Cluster Autoscaler
Instansstrategi
- Nodegrupper: Flere nodegrupper med forskellige instanstyper til omkostningsoptimering
- Forespørgselsarbejdsbelastning: Hukommelsesoptimerede instanser til in-memory vektorsegmenter
- Indeksarbejdsbelastning: Beregningsoptimerede instanser til CPU-intensive indeksopbygning
- Spot-instanser: Indeksnoder og ikke-kritiske datanoder kører på spot-instanser for betydelige besparelser
- On-Demand: Forespørgselsnoder og koordinatorer på on-demand instanser for stabilitet
Skaleringsadfærd
Når HPA opretter nye pods, der ikke kan planlægges, provisionerer Cluster Autoscaler nye EC2-instanser i den relevante nodegruppe. Nye forespørgselsnoder indlæser derefter deres tildelte segmenter fra S3 i hukommelsen og begynder at betjene forespørgsler, hvor den samlede opskaleringsproces afsluttes på få minutter.
S3-understøttet Vedvarende Lagring
Hvorfor S3 i stedet for Bloklagring
- ~80% lavere lageromkostninger for store datasæt
- 11-nines holdbarhed med indbygget multi-AZ replikering
- Ubegrænset skalering uden manuel volumenstørrelsesændring
- Pod-uafhængig — Data altid tilgængelige uanset pod- eller node-livscyklus
- Ingen AZ lock-in — Data tilgængelige fra enhver tilgængelighedszone
Dataflow med S3
- Skrivevej: Datanoder buffer-indføjelser i hukommelsen, skyller derefter forseglede segmenter til S3
- Indeksopbygning: Indeksnoder læser segmenter fra S3, opbygger indekser og skriver indekseringsfiler tilbage til S3
- Forespørgselsvej: Forespørgselsnoder downloader segmenter og indekser fra S3, indlæser i hukommelsen og betjener forespørgsler
- Genoprettelse: Ved pod-genstart gen-downloader forespørgselsnoder tildelte segmenter fra S3 (intet datatab)
S3 Ydeevneoptimering
- Justering af segmentstørrelse afbalancerer S3-anmodningsomkostninger vs. datafriskhed
- Lokal SSD-caching på NVMe instanslagring undgår gentagne S3-læsninger for varme segmenter
- Parallelle downloads muliggør hurtig opstart af forespørgselsnoder
- Livscykluspolitikker arkiverer gamle data til billigere lagringsniveauer
Overvågning & Observabilitet
Implementeringen inkluderer omfattende overvågning via Prometheus og Grafana:
- Forespørgselsydelse — Latensfordeling, QPS, cache hit rate
- Cluster Oversigt — Antal noder, pod-status, ressourceudnyttelse
- Lagerhelbred — S3-brug, segmentantal, flush-rater
- Autoscaling-begivenheder — HPA-begivenheder, nodedskalering, pod-planlægningslatens
- Advarsler — Automatiske advarsler for høj latens, OOM-risiko, flush-fejl og kapacitetsgrænser
Nøglefunktioner
- Forespørgselsnode HPA — Automatisk skalering baseret på CPU, hukommelse, latens og kødybde
- EC2 Cluster Autoscaler — Dynamisk node-provisionering med blandede instanstyper
- S3-persistens — 11-nines holdbarhed, ~80% billigere end bloklagring, overlever AZ-fejl
- Spot-instanser — Indeks- og datanoder på spot for betydelige beregningsbesparelser
- Lokal SSD-cache — NVMe-caching eliminerer gentagne S3-læsninger for varme segmenter
- Nul-nedetidsgenoprettelse — Pod-genstarter genindlæser segmenter fra S3 uden datatab
- Multi-AZ — S3-lagring + multi-AZ nodegrupper for fuld AZ-fejltolerance
- Observabilitet — Prometheus + Grafana med Milvus-specifikke metrics og autoscaling-synlighed
Resultater
Teknologistak
caseStudyDetail.more Casestudier
Udforsk flere af vores tekniske implementeringer
AI-drevet fakturabehandling med OCR og QuickBooks-integration
En mellemstor virksomhed, der månedligt behandler hundredvis af leverandørfakturaer, havde brug for at eliminere manuel dataindtastning ved automatisk at udtrække fakturadata ved hjælp af AI/OCR og synkronisere dem direkte til QuickBooks for bogføring og sporing af betalinger.
Klient-side annonceindsættelse (CSAI) med SCTE-35-markørparsing og integration af afspillere på flere platforme
En videostreamingplatform skulle implementere klient-side annonceindsættelse (CSAI) på tværs af web-, mobil- og connected TV-apps – hvilket muliggjorde personaliserede annonceringer på enhedsniveau med fuld support for annonceinteraktion (klikbare overlays, følgebannere, skip-knapper), som server-side indsættelse ikke kan tilbyde.
Ofte stillede spørgsmål
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.
Klar til at Transformere Din Virksomhed?
Lad os drøfte, hvordan vi kan anvende lignende løsninger til dine udfordringer.