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 mga query node, Cluster Autoscaler para sa compute, at Amazon S3 bilang persistent storage backend — na nag-aalis ng panganib sa pagkawala ng data at nagpapababa ng gastos sa storage ng humigit-kumulang 80%.

Arkitektura

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

Milvus Distributed Architecture sa Kubernetes

Deployment ng Komponente

Ang Milvus ay tumatakbo sa distributed mode na may dedikadong uri ng node, bawat isa ay naka-deploy bilang Kubernetes workload na may independent scaling:

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

Horizontal Pod Autoscaling (HPA)

Autoscaling ng Query Node

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

Autoscaling ng Index Node

Ang mga index node ay nag-i-scale batay sa mga pending na index build job — nag-i-scale up kapag ang build queue ay may pending items at nag-i-scale down kapag idle.

EC2 Cluster Autoscaler

Diskarte sa Instance

• Node Groups: Maraming node group na may iba't ibang uri ng instance para sa pag-optimize ng gastos
• 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 mga index node at non-critical data node ay tumatakbo sa spot instances para sa malaking tipid
• On-Demand: Ang mga query node at coordinator sa on-demand instances para sa stability

Pag-uugali ng Scaling

Kapag ang HPA ay lumilikha ng mga bagong pods na hindi ma-schedule, ang Cluster Autoscaler ay nagpo-provision ng mga bagong EC2 instance sa naaangkop na node group. Ang mga bagong query node ay naglo-load ng kanilang nakatalagang segment mula sa S3 sa memory at nagsisimulang magsilbi ng mga query, na may kabuuang proseso ng scale-up na nakukumpleto sa loob ng ilang minuto.

S3-Backed Persistent Storage

Bakit S3 Sa Halip na Block Storage

Nagbibigay ang S3 ng malaking bentahe kaysa sa block storage para sa Milvus:

• ~80% na 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 — Laging available ang data anuman ang lifecycle ng pod o node
• No AZ lock-in — Maaaring ma-access ang data mula sa anumang availability zone

Daloy ng Data sa S3

1. Write Path: Ang mga data node ay nagba-buffer ng inserts sa memory, pagkatapos ay nagpa-flush ng mga sealed segment sa S3
2. Index Build: Ang mga index node ay nagbabasa ng mga segment mula sa S3, nagtatayo ng indexes, at nagsusulat ng mga index file pabalik sa S3
3. Query Path: Ang mga query node ay nagda-download ng mga segment at indexes mula sa S3, naglo-load sa memory, at nagbibigay ng mga query
4. Recovery: Sa pagre-restart ng pod, ang mga query node ay muling nagda-download ng mga nakatalagang segment mula sa S3 (walang pagkawala ng data)

Pag-optimize ng Performance ng S3

• Segment size tuning ay nagbabalanse sa mga gastos sa S3 request laban sa pagiging bago ng data
• Local SSD caching sa NVMe instance storage ay iniiwasan ang paulit-ulit na S3 reads para sa hot segments
• Parallel downloads ay nagbibigay-daan sa mabilis na pagsisimula ng query node
• Lifecycle policies ay nag-aarkibo ng lumang data sa mas murang storage tiers

Pagsubaybay at Observability

Kasama sa deployment ang komprehensibong pagsubaybay sa pamamagitan ng Prometheus at Grafana:

• Query Performance — Latency distribution, QPS, cache hit rate
• Cluster Overview — Bilang ng node, status ng pod, paggamit ng resource
• Storage Health — Paggamit ng S3, bilang ng segment, flush rates
• Autoscaling Events — Mga event ng HPA, pag-scale ng node, pod scheduling latency
• Alerting — Awtomatikong alerto para sa mataas na latency, OOM risk, flush failures, at capacity limits

Mga Pangunahing Katangian

1. Query Node HPA — Awtomatikong scaling batay sa CPU, memory, latency, at queue depth
2. EC2 Cluster Autoscaler — Dynamic na pagpo-provision ng node na may mixed instance types
3. S3 Persistence — 11-nines durability, ~80% na mas mura kaysa sa block storage, nakakaligtas sa AZ failures
4. Spot Instances — Index at data nodes sa spot para sa malaking tipid sa compute
5. Local SSD Cache — Ang NVMe caching ay nag-aalis ng paulit-ulit na S3 reads para sa hot segments
6. Zero-Downtime Recovery — Nagre-reload ang mga pod restart ng mga segment mula sa S3 nang walang pagkawala ng data
7. Multi-AZ — S3 storage + multi-AZ node groups para sa full AZ failure tolerance
8. Observability — Prometheus + Grafana na may Milvus-specific metrics at autoscaling visibility