Milvus-autoskaalaus Kubernetesissa EC2- ja S3-pohjaisella pysyvällä tallennuksella
AI-alusta, jolla on nopeasti kasvava vektoridata (upotukset hakua, suosituksia ja RAG:ia varten), tarvitsi Milvus-vektoritietokantansa skaalaamaan automaattisesti kyselykuorman ja datamäärän perusteella — kestävällä, kustannustehokkaalla tallennuksella, joka ei häviäisi, jos podit käynnistyisivät uudelleen tai solmut korvattaisiin.
Keskustele Projektistasi
Haaste
Milvuksen ajaminen tuotantoympäristössä suuressa mittakaavassa esitti useita infrastruktuurihaasteita:
- Kiinteä kapasiteetti — Staattiset Milvus-asennukset eivät pystyneet käsittelemään 10-kertaisia kyselykuormapiikkejä ruuhka-aikoina
- Datamenetyksen riski — Podien uudelleenkäynnistykset lyhytikäisellä tallennuksella aiheuttivat indeksin uudelleenrakennuksia, jotka kestivät tunteja suurissa kokoelmissa
- Kustannustehottomuus — Ylikapasiteetin varaaminen huippukuormitusta varten tarkoitti, että 70 % ajasta maksettiin käyttämättömästä laskentatehosta
- Tallennuskustannukset — Instansseihin sidotut lohkotallennustilavuudet olivat kalliita moniteratavuisille vektoridatasetille
- Indeksin uudelleenrakennukset — Miljoonien vektorien uudelleenindeksointi solmun korvaamisen jälkeen vei tunteja seisokkiaikaa
- Multi-AZ-kestävyys — Yhden AZ:n tallennus ei kestänyt saatavuusalueen vikoja
Meidän Ratkaisumme
Otamme käyttöön Milvus Kubernetesissa (EKS) vaakasuuntaisella podien autoskaalauksella kyselysolmuille, Cluster Autoscaler -työkalulla laskentateholle ja Amazon S3:lla pysyvänä tallennusalustana — eliminoiden datamenetyksen riskin ja vähentäen tallennuskustannuksia noin 80 %.
Arkkitehtuuri
- Orkestrointi: Amazon EKS (Elastic Kubernetes Service)
- Laskenta: EC2-instanssit (sekoitetut instanssityypit) hallinnoitu Cluster Autoscalerilla
- Vektoritietokanta: Milvus otettu käyttöön Helm-kaavion kautta hajautetussa tilassa
- Objektitallennus: Amazon S3 segmenttitiedostoille, indeksitiedostoille ja binlog-pysyvyydelle
- Metatiedot: etcd-klusteri Milvus-yhteensovittamiselle ja metatiedoille
- Viestijono: Viestien suoratoisto Milvus-lokiputkelle
- Valvonta: Prometheus + Grafana Milvus-metriikoille ja autoskaalaussignaaleille
Milvusin hajautettu arkkitehtuuri Kubernetesissa
Komponenttien käyttöönotto
Milvus toimii hajautetussa tilassa omistetuilla solmutyypeillä, jotka kukin otetaan käyttöön Kubernetes-työkuormana itsenäisellä skaalauksella:
- Proxy-solmut — Käsittelevät asiakasliitäntöjä ja pyyntöjen reititystä
- Kyselysolmut — Suorittavat vektorihakuja ja lataavat segmenttejä muistiin
- Datapisteet — Käsittelevät kirjoituspolkuja ja siirtävät segmenttejä S3:een
- Indeksisolmut — Rakentavat vektori-indeksejä ja kirjoittavat S3:een
- Koordinaattori — Klusterin koordinointi ja aikaleimojen allokointi
- etcd — Metatietojen tallennus ja palvelun löytö
- Viestijono — Lokien suoratoisto ja ennakkokirjoitusloki
Vaakasuuntainen podien autoskaalaus (HPA)
Kyselysolmujen autoskaalaus
Kyselysolmut ovat ensisijainen skaalauskohde — ne lataavat vektorisegmenttejä muistiin ja suorittavat hakuja. Skaalaus perustuu useisiin mittareihin, kuten CPU:n käyttöasteeseen, muistin käyttöasteeseen, kyselyjonon syvyyteen ja P99-kyselyviiveeseen. HPA on konfiguroitu asianmukaisilla min/max-replikoilla, nopealla skaalausylöspäin piikkien käsittelemiseksi ja asteittaisella skaalausalaspäin välttääkseen heilumista.
Indeksisolmujen autoskaalaus
Indeksisolmut skaalautuvat odottavien indeksin rakennustehtävien perusteella — skaalaus ylöspäin, kun rakennusjono sisältää odottavia kohteita, ja skaalaus alaspäin, kun ne ovat tyhjäkäynnillä.
EC2 Cluster Autoscaler
Instanssistrategia
- Solmuryhmät: Useita solmuryhmiä eri instanssityypeillä kustannusoptimointia varten
- Kyselytyökuorma: Muistioptimoidut instanssit muistiin ladattaville vektorisegmenteille
- Indeksityökuorma: Laskentaoptimoidut instanssit CPU-intensiiviselle indeksin rakennukselle
- Spot-instanssit: Indeksisolmut ja ei-kriittiset datanodet toimivat spot-instansseilla merkittäviä säästöjä varten
- On-Demand: Kyselysolmut ja koordinaattorit on-demand-instansseilla vakauden vuoksi
Skaalauskäyttäytyminen
Kun HPA luo uusia podeja, joita ei voida ajoittaa, Cluster Autoscaler hankkii uusia EC2-instansseja asianmukaisessa solmuryhmässä. Uudet kyselysolmut lataavat sitten niille osoitetut segmentit S3:sta muistiin ja alkavat palvella kyselyitä, ja koko skaalausprosessi valmistuu minuuteissa.
S3-pohjainen pysyvä tallennus
Miksi S3 lohkotallennuksen sijaan
S3 tarjoaa merkittäviä etuja lohkotallennukseen verrattuna Milvukselle:
- Noin 80 % alhaisemmat tallennuskustannukset suurille datasetille
- 11-nines-kestävyys sisäänrakennetulla multi-AZ-replikaatiolla
- Rajoittamaton skaalaus ilman manuaalista tilavuuden uudelleensijoitusta
- Pod-riippumaton — Data on aina saatavilla riippumatta podin tai solmun elinkaaresta
- Ei AZ-lukitusta — Data on saatavilla mistä tahansa saatavuusalueelta
Datavirta S3:n kanssa
- Kirjoituspolku: Datapisteet puskuroivat lisäyksiä muistiin ja siirtävät sitten suljetut segmentit S3:een
- Indeksin rakennus: Indeksisolmut lukevat segmenttejä S3:sta, rakentavat indeksejä ja kirjoittavat indeksitiedostoja takaisin S3:een
- Kyselypolku: Kyselysolmut lataavat segmenttejä ja indeksejä S3:sta, lataavat muistiin ja palvelevat kyselyitä
- Palautuminen: Podin uudelleenkäynnistyessä kyselysolmut lataavat niille osoitetut segmentit uudelleen S3:sta (ei datamenetystä)
S3-suorituskyvyn optimointi
- Segmenttikoon hienosäätö tasapainottaa S3-pyyntökustannuksia ja datan tuoreutta
- Paikallinen SSD-välimuisti NVMe-instanssivarastossa välttää toistuvat S3-luvut kuumille segmenteille
- Rinnakkaiset lataukset mahdollistavat nopean kyselysolmun käynnistyksen
- Elinkaarikäytännöt arkistoivat vanhat tiedot halvemmille tallennustasoille
Valvonta ja havainnointi
Käyttöönotto sisältää kattavan valvonnan Prometheuksen ja Grafanan kautta:
- Kyselysuorituskyky — Viivejakauma, QPS, välimuistin osumaprosentti
- Klusterin yleiskatsaus — Solmujen määrä, podien tila, resurssien käyttö
- Tallennuksen terveys — S3:n käyttö, segmenttien määrä, siirtotahti
- Autoskaalaustapahtumat — HPA-tapahtumat, solmujen skaalaus, podien ajoitusviive
- Hälytykset — Automaattiset hälytykset korkeasta viiveestä, OOM-riskistä, siirtovirheistä ja kapasiteettirajoista
Keskeiset ominaisuudet
- Kyselysolmun HPA — Automaattinen skaalaus CPU:n, muistin, viiveen ja jonon syvyyden perusteella
- EC2 Cluster Autoscaler — Dynaaminen solmujen hankinta sekoitetuilla instanssityypeillä
- S3-pysyvyys — 11-nines-kestävyys, noin 80 % halvempi kuin lohkotallennus, kestää AZ-vikoja
- Spot-instanssit — Indeksi- ja datanodet spotilla merkittäviä laskentasäästöjä varten
- Paikallinen SSD-välimuisti — NVMe-välimuisti eliminoi toistuvat S3-luvut kuumille segmenteille
- Nollaseisokkiajan palautuminen — Podin uudelleenkäynnistykset lataavat segmentit uudelleen S3:sta ilman datamenetystä
- Multi-AZ — S3-tallennus + multi-AZ-solmuryhmät täydellistä AZ-vikojen sietokykyä varten
- Havainnointi — Prometheus + Grafana Milvus-spesifisillä metriikoilla ja autoskaalausnäkyvyydellä
Tulokset
Teknologiapino
caseStudyDetail.more Tapaustutkimukset
Tutustu lisää teknisiin toteutuksiimme
AI-pohjainen laskujen käsittely OCR:n ja QuickBooks-integraation avulla
Keskisuuri yritys, joka käsitteli satoja toimittajalaskuja kuukausittain, halusi poistaa manuaalisen tiedonsyötön poimimalla laskutiedot automaattisesti AI/OCR:n avulla ja synkronoimalla ne suoraan QuickBooks-järjestelmään kirjanpitoa ja maksujen seurantaa varten.
Asiakaspuolen mainosten upotus (CSAI) SCTE-35-merkkien jäsennyksellä ja monialustaisen soittimen integroinnilla
Videoiden suoratoistoalustan piti toteuttaa Client-Side Ad Insertion (CSAI) verkko-, mobiili- ja Connected TV -sovellusten yli — mahdollistaen personoidut, laitekohtaiset mainoskokemukset täydellä mainosinteraktion tuella (klikkaavat peittokuvat, kumppanibannerit, ohituspainikkeet), joita server-side insertion ei voi tarjota.
Usein kysytyt kysymykset
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.
Valmis Muuttamaan Liiketoimintaasi?
Keskustellaan siitä, miten voimme soveltaa vastaavia ratkaisuja haasteisiisi.