Milvus Autoscaling sa Kubernetes na may EC2 at S3-Backed Persistent Storage

Nag-deploy kami ng Milvus sa Kubernetes (EKS) na may Horizontal Pod Autoscaling para sa query nodes, Cluster Autoscaler para sa compute, at Amazon S3 bilang persistent storage backend — na nagtatanggal ng panganib ng pagkawala ng data at nagpapababa ng gastos sa storage ng ~80%.

Arkitektura

• Orchestration: Amazon EKS (Elastic Kubernetes Service)
• Compute: EC2 instances (mixed instance types) pinamamahalaan ng Cluster Autoscaler
• Vector DB: Milvus na-deploy sa pamamagitan ng Helm chart sa distributed mode
• Object Storage: Amazon S3 para sa segment files, index files, at binlog persistence
• Metadata: etcd cluster para sa Milvus coordination at metadata
• Message Queue: Message streaming para sa Milvus log pipeline
• Pagsubaybay: Prometheus + Grafana para sa Milvus metrics at autoscaling signals

Milvus Distributed Architecture sa Kubernetes

Pag-deploy ng Komponente

Tumatakbo ang Milvus sa distributed mode na may dedicated node types, bawat isa ay naka-deploy bilang isang Kubernetes workload na may independent scaling:

• Proxy Nodes — Humahawak ng koneksyon ng kliyente at request routing
• Query Nodes — Nagpapatupad ng vector searches at naglo-load ng mga segment sa memory
• Data Nodes — Humahawak ng write paths at nagpa-flush ng mga segment sa S3
• Index Nodes — Bumubuo ng vector indexes at nagsusulat sa S3
• Coordinator — Cluster coordination at paglalaan ng timestamp
• etcd — Metadata storage at service discovery
• Message Queue — Log streaming at write-ahead log

Horizontal Pod Autoscaling (HPA)

Query Node Autoscaling

Ang Query nodes ang pangunahing target sa scaling — naglo-load sila ng mga vector segment sa memory at nagpapatupad ng searches. Ang scaling ay hinihimok ng maraming metrics kabilang ang CPU utilization, memory utilization, query queue depth, at P99 query latency. Ang HPA ay na-configure na may naaangkop na min/max replicas, mabilis na scale-up para sa paghawak ng spikes, at unti-unting scale-down upang maiwasan ang flapping.

Index Node Autoscaling

Ang Index nodes ay nag-i-scale batay sa mga nakabinbing index build jobs — scaling up kapag ang build queue ay may nakabinbing items at scaling back down kapag idle.

EC2 Cluster Autoscaler

Diskarte sa Instance

• Node Groups: Maramihang node groups na may iba't ibang instance types para sa cost optimization
• Query Workload: Memory-optimized instances para sa in-memory vector segments
• Index Workload: Compute-optimized instances para sa CPU-intensive index building
• Spot Instances: Ang Index nodes at non-critical data nodes ay tumatakbo sa spot instances para sa malaking savings
• On-Demand: Ang Query nodes at coordinators sa on-demand instances para sa stability

Pag-uugali ng Scaling

Kapag gumawa ang HPA ng mga bagong pods na hindi mai-schedule, ang Cluster Autoscaler ay nagbibigay ng mga bagong EC2 instances sa naaangkop na node group. Pagkatapos, nilo-load ng mga bagong query nodes ang kanilang itinalagang segments mula sa S3 sa memory at nagsisimulang magsilbi ng mga queries, na ang kabuuang proseso ng scale-up ay natatapos sa loob ng ilang minuto.

S3-Backed Persistent Storage

Bakit S3 Imbes na Block Storage

Nagbibigay ang S3 ng malaking kalamangan kumpara sa block storage para sa Milvus:

• ~80% mas mababang gastos sa storage para sa malalaking datasets
• 11-nines durability na may built-in na multi-AZ replication
• Walang limitasyong scaling nang walang manual volume resizing
• Pod-independent — Palaging available ang data anuman ang pod o node lifecycle
• Walang AZ lock-in — Accessible ang data mula sa anumang availability zone

Daloy ng Data sa S3

1. Write Path: Ang Data nodes ay nagbu-buffer ng inserts sa memory, pagkatapos ay i-flush ang sealed segments sa S3
2. Paggawa ng Index: Ang Index nodes ay nagbabasa ng segments mula sa S3, bumubuo ng indexes, at nagsusulat ng index files pabalik sa S3
3. Query Path: Ang Query nodes ay nagda-download ng segments at indexes mula sa S3, naglo-load sa memory, at nagsisilbi ng queries
4. Pagbawi: Sa pag-restart ng pod, ang query nodes ay muling nagda-download ng itinalagang segments mula sa S3 (walang pagkawala ng data)

S3 Performance Optimization

• Pagsasaayos ng laki ng segment nagbabalanse ng S3 request costs vs. data freshness
• Lokal na SSD caching sa NVMe instance storage ay iniiwasan ang paulit-ulit na pagbasa sa S3 para sa hot segments
• Parallel downloads nagpapagana ng mabilis na query node startup
• Lifecycle policies nag-a-archive ng lumang data sa mas murang storage tiers

Pagsubaybay at Observability

Ang deployment ay may kasamang komprehensibong pagsubaybay sa pamamagitan ng Prometheus at Grafana:

• Pagganap ng Query — Latency distribution, QPS, cache hit rate
• Pangkalahatang Ideya ng Cluster — Bilang ng node, status ng pod, resource utilization
• Kalusugan ng Storage — S3 usage, bilang ng segment, flush rates
• Mga Kaganapan sa Autoscaling — Mga kaganapan ng HPA, node scaling, pod scheduling latency
• Pag-aabiso — Awtomatikong abiso para sa mataas na latency, OOM risk, flush failures, at capacity limits

Mga Pangunahing Tampok

1. Query Node HPA — Awtomatikong scaling batay sa CPU, memory, latency, at queue depth
2. EC2 Cluster Autoscaler — Dynamic node provisioning na may mixed instance types
3. S3 Persistence — 11-nines durability, ~80% mas mura kaysa block storage, nakaliligtas sa AZ failures
4. Spot Instances — Ang Index at data nodes sa spot para sa malaking compute savings
5. Lokal na SSD Cache — Ang NVMe caching ay nagtatanggal ng paulit-ulit na pagbasa sa S3 para sa hot segments
6. Zero-Downtime Recovery — Ang pag-restart ng Pod ay naglo-load muli ng segments mula sa S3 nang walang pagkawala ng data
7. Multi-AZ — S3 storage + multi-AZ node groups para sa kumpletong AZ failure tolerance
8. Observability — Prometheus + Grafana na may Milvus-specific metrics at autoscaling visibility