Milvus-automaattinen skaalaus Kubernetesissa EC2- ja S3-pohjaisella pysyvällä tallennustilalla
AI-alusta, jonka vektoridata (upotukset hakuun, suosituksiin ja RAG:iin) kasvoi nopeasti, tarvitsi Milvus-vektoritietokantansa skaalautumaan automaattisesti kyselykuorman ja datamäärän perusteella – kestävällä, kustannustehokkaalla tallennustilalla, joka ei häviäisi, vaikka podit käynnistyisivät uudelleen tai nodet korvattaisiin.
Keskustele Projektistasi
Haaste
Milvusin skaalaaminen tuotannossa aiheutti useita infrastruktuurin haasteita:
- Kiinteä kapasiteetti – Staattiset Milvus-käyttöönotot eivät kyenneet käsittelemään 10-kertaisia kyselykuormituspiikkejä ruuhka-aikoina
- Datan häviämisriski – Podien uudelleenkäynnistykset lyhytaikaisella tallennustilalla aiheuttivat indeksin uudelleenrakennuksia, jotka kestivät tunteja suurissa kokoelmissa
- Kustannustehottomuus – Ylimitoitus huippukuormaa varten tarkoitti maksamista joutokäynnissä olevasta laskentatehosta 70 % ajasta
- Tallennustilan kustannukset – Instansseihin sidotut block storage -volyymit olivat kalliita usean teratavun vektoritietojoukoille
- Indeksin uudelleenrakennukset – Miljoonien vektorien uudelleenindeksointi noden vaihdon jälkeen vei tunteja käyttökatkoa
- Multi-AZ kestävyys – Yhden AZ:n tallennustila ei selviytynyt saatavuusalueen vioista
Meidän Ratkaisumme
Otimmme käyttöön Milvuksen Kubernetesissa (EKS) Horizontal Pod Autoscalingin avulla kyselynodeille, Cluster Autoscalerin laskentateholle ja Amazon S3:n pysyvänä tallennustilan taustajärjestelmänä – poistamalla datan häviämisriskin ja vähentämällä tallennustilan kustannuksia noin 80 %.
Arkkitehtuuri
- Orkestrointi: Amazon EKS (Elastic Kubernetes Service)
- Laskentateho: EC2-instanssit (sekalaiset instanssityypit), joita Cluster Autoscaler hallinnoi
- Vector DB: Milvus käyttöön otettu Helm-chartin kautta hajautetussa tilassa
- Object Storage: Amazon S3 segmenttitiedostoille, indeksitiedostoille ja binlogin pysyvyydelle
- Metadata: etcd-klusteri Milvuksen koordinaatiota ja metadataa varten
- Message Queue: Viestivirta Milvus-lokiputkelle
- Monitorointi: Prometheus + Grafana Milvus-metriikoille ja autoskaalaussignaaleille
Milvusin hajautettu arkkitehtuuri Kubernetesissa
Komponenttien käyttöönotto
Milvus toimii hajautetussa tilassa erillisillä nodetyypeillä, joista jokainen on otettu käyttöön Kubernetes-työkuormana itsenäisellä skaalauksella:
- Proxy Nodes – Käsittelevät asiakasliitännät ja pyyntöjen reitityksen
- Query Nodes – Suorittavat vektorihakuja ja lataavat segmentit muistiin
- Data Nodes – Käsittelevät kirjoituspolkuja ja huuhtelevat segmentit S3:een
- Index Nodes – Rakentavat vektori-indeksejä ja kirjoittavat ne S3:een
- Coordinator – Klusterin koordinointi ja aikaleimojen allokointi
- etcd – Metadatatallennus ja palvelun löytäminen
- Message Queue – Lokivirta ja write-ahead log
Horizontal Pod Autoscaling (HPA)
Query Node -automaattinen skaalaus
Query nodet ovat ensisijainen skaalauskohde – ne lataavat vektorisegmentit muistiin ja suorittavat hakuja. Skaalaus perustuu useisiin metriikoihin, kuten CPU utilization, memory utilization, query queue depth ja P99 query latency. HPA on konfiguroitu sopivilla min/max-replikoilla, nopealla skaalauksella piikkien käsittelyyn ja asteittaisella skaalauksella flappingin välttämiseksi.
Index Node -automaattinen skaalaus
Index nodet skaalautuvat odottavien indeksin rakennustehtävien perusteella – skaalautuvat ylöspäin, kun rakennusjonossa on odottavia kohteita, ja takaisin alas, kun ne ovat joutokäynnillä.
EC2 Cluster Autoscaler
Instanssistrategia
- Node Groups: Useita noderyhmiä eri instanssityypeillä kustannusoptimointia varten
- Query Workload: Muistioptimoidut instanssit muistissa oleville vektorisegmenteille
- Index Workload: Laskentaoptimoidut instanssit CPU-intensiiviseen indeksin rakentamiseen
- Spot Instances: Index nodet ja ei-kriittiset data nodet ajetaan spot-instansseilla merkittäviä säästöjä varten
- On-Demand: Query nodet ja koordinaattorit on-demand-instansseilla vakauden varmistamiseksi
Skaalauskäyttäytyminen
Kun HPA luo uusia podeja, joita ei voida ajoittaa, Cluster Autoscaler varaa uusia EC2-instansseja asianomaiseen noderyhmään. Uudet query nodet lataavat sitten niille osoitetut segmentit S3:sta muistiin ja alkavat palvella kyselyjä, ja koko skaalausprosessi valmistuu minuuteissa.
S3-pohjainen pysyvä tallennustila
Miksi S3 block storage -palvelun sijaan
S3 tarjoaa merkittäviä etuja block storage -palveluun verrattuna Milvukselle:
- ~80 % alhaisemmat tallennuskustannukset suurille tietojoukoille
- 11-nines kestävyys sisäänrakennetun multi-AZ-replikoinnin avulla
- Rajoittamaton skaalaus ilman manuaalista volyymin koon muuttamista
- Pod-riippumaton – Data aina saatavilla podin tai noden elinkaaresta riippumatta
- Ei AZ lock-iniä – Data saatavilla mistä tahansa saatavuusalueesta
Datan kulku S3:n kanssa
- Write Path: Data nodet puskuroivat lisäykset muistiin ja huuhtelevat sitten suljetut segmentit S3:een
- Index Build: Index nodet lukevat segmentit S3:sta, rakentavat indeksit ja kirjoittavat indeksitiedostot takaisin S3:een
- Query Path: Query nodet lataavat segmentit ja indeksit S3:sta, lataavat ne muistiin ja palvelevat kyselyjä
- Recovery: Podin uudelleenkäynnistyksen yhteydessä query nodet lataavat uudelleen osoitetut segmentit S3:sta (ei datan häviämistä)
S3:n suorituskyvyn optimointi
- Segmenttikoon säätö tasapainottaa S3-pyyntöjen kustannukset vs. datan tuoreus
- Paikallinen SSD-välimuistitus NVMe-instanssitallennustilassa välttää toistuvia S3-lukuja hot segmenteille
- Rinnakkaiset lataukset mahdollistavat nopean query noden käynnistyksen
- Elikaaripolitiikat arkistoivat vanhaa dataa edullisempiin tallennustasoihin
Monitorointi ja havaittavuus
Käyttöönotto sisältää kattavan monitoroinnin Prometheuksen ja Grafanan kautta:
- Query Performance – Viiveen jakautuminen, QPS, cache hit rate
- Cluster Overview – Noden määrä, podin tila, resurssien käyttö
- Storage Health – S3-käyttö, segmenttien määrät, huuhtelunopeudet
- Autoscaling Events – HPA-tapahtumat, noden skaalaus, podin ajoitusviive
- Alerting – Automaattiset hälytykset korkeasta latenssista, OOM-riskistä, huuhteluvioista ja kapasiteettirajoituksista
Avainominaisuudet
- Query Node HPA – Automaattinen skaalaus perustuen CPU:hun, muistiin, latenssiin ja jonon syvyyteen
- EC2 Cluster Autoscaler – Dynaaminen noden provisiointi sekalaisilla instanssityypeillä
- S3 Persistence – 11-nines kestävyys, ~80 % edullisempi kuin block storage, selviytyy AZ-vioista
- Spot Instances – Index ja data nodet spot-instansseilla merkittäviä laskentatehosäästöjä varten
- Local SSD Cache – NVMe-välimuistitus eliminoi toistuvat S3-lukuja hot segmenteille
- Zero-Downtime Recovery – Podin uudelleenkäynnistykset lataavat segmentit uudelleen S3:sta ilman datan häviämistä
- Multi-AZ – S3-tallennustila + multi-AZ-noderyhmät täydelliseen AZ-vikatoleranssiin
- Observability – Prometheus + Grafana Milvus-spesifeillä metriikoilla ja autoskaalauksen näkyvyydellä
Tulokset
Teknologiapino
caseStudyDetail.more Tapaustutkimukset
Tutustu lisää teknisiin toteutuksiimme
Catant HR & Workforce Management Platform
Catant on modulaarinen HR- ja työvoiman hallintajärjestelmä, joka auttaa yrityksiä hallitsemaan työntekijöitä, palkanlaskentaa, läsnäoloa ja vaatimustenmukaisuutta yhdestä kojelaudasta.
Kickly: Tekoälypohjainen projektialusta startupeille
Kickly on startupeille rakennettu tekoälypohjainen projektinhallinta-alusta, joka yhdistää älykkään tehtävien automatisoinnin, tiimiyhteistyön ja reaaliaikaisen edistymisen seurannan yhdeksi tuotteeksi.
Usein kysytyt kysymykset
MicrocosmWorks konfiguroi horizontal pod autoscalingin Milvusin sisäänrakennetun memory usage exporterin mukautetuilla mittareilla, laukaisten scale-out-tapahtumia, kun mikä tahansa kyselysolmu ylittää 75 % memory utilizationin. Kokoelman segmentit jaetaan automaattisesti uudelleen uusien solmujen kesken Milvusin segment managerin avulla, estäen minkään yksittäisen solmun muodostumasta pullonkaulaksi.
MicrocosmWorks valitsi S3-pohjaisen tallennustilan käyttäen MinIO:ta objektitallennuskerroksena, koska se erottaa tallennustilan laskennasta, mahdollistaen kyselysolmujen skaalautumisen itsenäisesti ilman uusien EBS-volyymien provisionointia. Tämä arkkitehtuuri vähentää tallennuskustannuksia noin 60 % verrattuna gp3 EBS-volyymeihin säilyttäen alle 100 ms:n segmenttien latausajat S3:sta.
MicrocosmWorks konfiguroi käyttöönoton replikaseteillä jokaiselle Milvus-komponentille, mukaan lukien kyselysolmut, indeksisolmut ja datasolmut, käyttäen pod disruption budjeteja varmistaen vähimmäissaatavuuden rullaavien päivitysten aikana. Koska kaikki pysyvä data sijaitsee S3:ssa, vikaantuneen solmun korvaaja voi välittömästi käyttää kaikkia segmenttejä ilman tiedonsiirtoa.
MicrocosmWorks havaitsi, että r6i.2xlarge-instanssit tarjoavat optimaalisen hinta-suorituskykysuhteen Milvus-kyselykuormituksille, tarjoten 64 Gt muistia muistissa tapahtuvalle segmenttien välimuistille kilpailukykyiseen spot-hintaan. GPU-kiihdytettyä indeksin rakentamista varten g5.xlarge-instanssit, joissa on NVIDIA A10G GPU:t, lyhensivät indeksin rakennusaikoja 8-kertaisesti verrattuna vain CPU:ta käyttäviin rakennuksiin.
MicrocosmWorks toteuttaa Kubernetes-infrastruktuuriprojekteja hintaan 30–50 $/tunti. Milvus-automaattisesti skaalautuvan käyttöönoton, joka sisältää Helm chart -mukautuksen, HPA-konfiguraation, S3-integraation ja valvontajärjestelmän asennuksen, vaatii tyypillisesti 150–250 tuntia. Jatkuva hallinnoitu tuki klusterin optimointiin ja päivityksiin on saatavilla samalla tuntihinnalla.
Valmis Muuttamaan Liiketoimintaasi?
Keskustellaan siitä, miten voimme soveltaa vastaavia ratkaisuja haasteisiisi.