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 konfigurerede horisontal pod autoscaling med brugerdefinerede metrics fra Milvus' indbyggede hukommelsesforbrugseksportør, der udløser scale-out-hændelser, når enhver query node overstiger 75 % hukommelsesudnyttelse. Indsamlingssegmenter omfordeles automatisk på tværs af nye noder ved hjælp af Milvus' segment manager, og forhindrer enhver enkelt node i at blive en flaskehals.
MicrocosmWorks valgte S3-baseret lagring ved at bruge MinIO som objektlagerlag, fordi det adskiller lagring fra beregning, hvilket tillader forespørgselsnoder at skalere uafhængigt uden at skulle klargøre nye EBS-volumener. Denne arkitektur reducerer lageromkostningerne med cirka 60% sammenlignet med gp3 EBS-volumener, samtidig med at segmentindlæsningstider fra S3 på under 100 ms opretholdes.
MicrocosmWorks konfigurerede implementeringen med replica sets for hver Milvus-komponent, inklusive query nodes, index nodes og data nodes, med pod disruption budgets, der sikrer minimum tilgængelighed under rolling updates. Da alle persistente data befinder sig i S3, kan en fejlslagen nodes erstatning øjeblikkeligt få adgang til alle segments uden datamigrering.
MicrocosmWorks fandt, at r6i.2xlarge instanser giver det optimale cost-to-performance ratio til Milvus query workloads, og tilbyder 64GB memory til in-memory segment caching til en konkurrencedygtig spot price. Til GPU-accelerated index building reducerede g5.xlarge instanser med NVIDIA A10G GPUs index build times med 8x sammenlignet med CPU-only builds.
MicrocosmWorks leverer Kubernetes-infrastrukturprojekter til priser på $30-$50/time, hvor en Milvus autoscaling-udrulning, inklusive Helm chart-tilpasning, HPA-konfiguration, S3-integration og overvågningsopsætning, typisk kræver 150-250 timer. Løbende administreret support til klyngeoptimering og opgraderinger er tilgængelig til de samme timepriser.
Klar til at Transformere Din Virksomhed?
Lad os drøfte, hvordan vi kan anvende lignende løsninger til dine udfordringer.