Milvus Penskalaan Auto di Kubernetes dengan EC2 dan Storan Kekal Berasaskan S3
Platform AI dengan data vektor yang berkembang pesat (embeddings untuk carian, cadangan, dan RAG) memerlukan pangkalan data vektor Milvus mereka untuk berskala secara automatik berdasarkan beban pertanyaan dan volum data — dengan storan yang tahan lama dan cekap kos yang tidak akan hilang jika pod dimulakan semula atau nod diganti.
Bincangkan Projek Anda
Cabaran
Menjalankan Milvus pada skala dalam pengeluaran menimbulkan beberapa cabaran infrastruktur:
- Kapasiti Tetap — Penggunaan Milvus statik tidak dapat mengendalikan lonjakan beban pertanyaan 10x ganda semasa waktu puncak
- Risiko Kehilangan Data — Mulakan semula pod pada storan efemeral menyebabkan pembinaan semula indeks mengambil masa berjam-jam pada koleksi besar
- Ketidakcekapan Kos — Penyediaan berlebihan untuk beban puncak bermakna membayar untuk pengkomputeran terbiar 70% daripada masa
- Kos Storan — Jilid storan blok yang terikat pada instans adalah mahal untuk set data vektor berbilang terabait
- Pembinaan Semula Indeks — Pengindeksan semula berjuta-juta vektor selepas penggantian nod mengambil masa berjam-jam waktu henti
- Ketahanan Multi-AZ — Storan Single-AZ tidak dapat bertahan daripada kegagalan zon ketersediaan
Penyelesaian Kami
Kami telah menggunakan Milvus di Kubernetes (EKS) dengan Horizontal Pod Autoscaling untuk nod pertanyaan, Cluster Autoscaler untuk pengkomputeran, dan Amazon S3 sebagai backend storan kekal — menghapuskan risiko kehilangan data dan mengurangkan kos storan sebanyak ~80%.
Seni Bina
- Orkestrasi: Amazon EKS (Elastic Kubernetes Service)
- Pengkomputeran: Instans EC2 (jenis instans bercampur) yang diurus oleh Cluster Autoscaler
- Pangkalan Data Vektor: Milvus digunakan melalui Helm chart dalam mod teragih
- Storan Objek: Amazon S3 untuk fail segmen, fail indeks, dan kekekalan binlog
- Metadata: kluster etcd untuk koordinasi dan metadata Milvus
- Barisan Mesej: Penstriman mesej untuk saluran paip log Milvus
- Pemantauan: Prometheus + Grafana untuk metrik Milvus dan isyarat penskalaan auto
Seni Bina Teragih Milvus di Kubernetes
Penggunaan Komponen
Milvus berjalan dalam mod teragih dengan jenis nod khusus, setiap satu digunakan sebagai beban kerja Kubernetes dengan penskalaan bebas:
- Nod Proksi — Mengendalikan sambungan klien dan penghalaan permintaan
- Nod Pertanyaan — Melaksanakan carian vektor dan memuat segmen ke dalam memori
- Nod Data — Mengendalikan laluan tulis dan membuang segmen ke S3
- Nod Indeks — Membina indeks vektor dan menulis ke S3
- Penyelaras — Koordinasi kluster dan peruntukan cap waktu
- etcd — Storan metadata dan penemuan perkhidmatan
- Barisan Mesej — Penstriman log dan log tulis-hadapan
Pensakalaan Auto Pod Mendatar (HPA)
Pensakalaan Auto Nod Pertanyaan
Nod pertanyaan adalah sasaran penskalaan utama — ia memuat segmen vektor ke dalam memori dan melaksanakan carian. Penskalaan didorong oleh beberapa metrik termasuk penggunaan CPU, penggunaan memori, kedalaman barisan pertanyaan, dan kependaman pertanyaan P99. HPA dikonfigurasikan dengan replika min/maks yang sesuai, penskalaan naik pantas untuk mengendalikan lonjakan, dan penskalaan turun beransur-ansur untuk mengelakkan "flapping".
Pensakalaan Auto Nod Indeks
Nod indeks berskala berdasarkan kerja pembinaan indeks yang belum selesai — berskala naik apabila barisan pembinaan mempunyai item yang belum selesai dan berskala turun apabila terbiar.
Pensakalaan Auto Kluster EC2
Strategi Instans
- Kumpulan Nod: Berbilang kumpulan nod dengan jenis instans berbeza untuk pengoptimuman kos
- Beban Kerja Pertanyaan: Instans dioptimumkan memori untuk segmen vektor dalam memori
- Beban Kerja Indeks: Instans dioptimumkan pengkomputeran untuk pembinaan indeks intensif CPU
- Spot Instances: Nod indeks dan nod data tidak kritikal berjalan pada spot instances untuk penjimatan yang ketara
- On-Demand: Nod pertanyaan dan penyelaras pada instans atas permintaan untuk kestabilan
Tingkah Laku Penskalaan
Apabila HPA mencipta pod baharu yang tidak dapat dijadualkan, Cluster Autoscaler menyediakan instans EC2 baharu dalam kumpulan nod yang sesuai. Nod pertanyaan baharu kemudian memuat segmen yang ditugaskan dari S3 ke dalam memori dan mula melayani pertanyaan, dengan proses penskalaan naik keseluruhan selesai dalam beberapa minit.
Storan Kekal Berasaskan S3
Mengapa S3 Berbanding Storan Blok
S3 memberikan kelebihan ketara berbanding storan blok untuk Milvus:
- Kos storan ~80% lebih rendah untuk set data besar
- Ketahanan 11-nines dengan replikasi multi-AZ terbina dalam
- Penskalaan tanpa had tanpa mengubah saiz volum secara manual
- Bebas-pod — Data sentiasa tersedia tanpa mengira kitaran hayat pod atau nod
- Tiada penguncian AZ — Data boleh diakses dari mana-mana zon ketersediaan
Aliran Data dengan S3
- Laluan Tulis: Nod data menampan sisipan dalam memori, kemudian membuang segmen tertutup ke S3
- Pembinaan Indeks: Nod indeks membaca segmen dari S3, membina indeks, dan menulis fail indeks kembali ke S3
- Laluan Pertanyaan: Nod pertanyaan memuat turun segmen dan indeks dari S3, memuatkan ke dalam memori, dan melayani pertanyaan
- Pemulihan: Apabila pod dimulakan semula, nod pertanyaan memuat turun semula segmen yang ditugaskan dari S3 (tiada kehilangan data)
Pengoptimuman Prestasi S3
- Penalaan saiz segmen mengimbangi kos permintaan S3 berbanding kesegaran data
- Kaching SSD tempatan pada storan instans NVMe mengelakkan pembacaan S3 berulang untuk segmen panas
- Muat turun selari membolehkan permulaan nod pertanyaan yang pantas
- Dasar kitaran hayat mengarkibkan data lama ke peringkat storan yang lebih murah
Pemantauan & Kebolehlihatan
Penggunaan ini merangkumi pemantauan menyeluruh melalui Prometheus dan Grafana:
- Prestasi Pertanyaan — Pengedaran kependaman, QPS, kadar capaian cache
- Gambaran Keseluruhan Kluster — Kiraan nod, status pod, penggunaan sumber
- Kesihatan Storan — Penggunaan S3, kiraan segmen, kadar flush
- Acara Pensakalaan Auto — Acara HPA, penskalaan nod, kependaman penjadualan pod
- Pemberian Isyarat — Isyarat automatik untuk kependaman tinggi, risiko OOM, kegagalan flush, dan had kapasiti
Ciri-ciri Utama
- HPA Nod Pertanyaan — Penskalaan automatik berdasarkan CPU, memori, kependaman, dan kedalaman barisan
- Pensakalaan Auto Kluster EC2 — Penyediaan nod dinamik dengan jenis instans bercampur
- Kekekalan S3 — Ketahanan 11-nines, ~80% lebih murah daripada storan blok, bertahan daripada kegagalan AZ
- Spot Instances — Nod indeks dan data pada spot instances untuk penjimatan pengkomputeran yang ketara
- Cache SSD Tempatan — Kaching NVMe menghapuskan pembacaan S3 berulang untuk segmen panas
- Pemulihan Tanpa Henti Tugas — Pod dimulakan semula memuatkan semula segmen dari S3 tanpa kehilangan data
- Multi-AZ — Storan S3 + kumpulan nod multi-AZ untuk toleransi kegagalan AZ penuh
- Kebolehlihatan — Prometheus + Grafana dengan metrik khusus Milvus dan kebolehlihatan penskalaan auto
Keputusan
Timbunan Teknologi
caseStudyDetail.more Kajian Kes
Terokai lebih banyak pelaksanaan teknikal kami
Pemprosesan Invois Berkuasa AI dengan OCR dan Integrasi QuickBooks
Sebuah perniagaan bersaiz sederhana yang memproses ratusan invois vendor setiap bulan perlu menghapuskan kemasukan data manual dengan mengekstrak data invois secara automatik menggunakan AI/OCR dan menyegerakkannya terus ke dalam QuickBooks untuk tujuan simpan kira dan penjejakan pembayaran.
Penyisipan Iklan Sisi Klien (CSAI) dengan Penghuraian Penanda SCTE-35 & Integrasi Pemain Berbilang Platform
Sebuah platform penstriman video perlu melaksanakan Client-Side Ad Insertion (CSAI) merentasi aplikasi web, mudah alih, dan TV bersambung — membolehkan pengalaman iklan yang diperibadikan pada peringkat peranti dengan sokongan interaksi iklan penuh (lapisan tindanan boleh klik, sepanduk pendamping, butang langkau) yang tidak dapat disediakan oleh penyisipan sisi pelayan.
Soalan Lazim
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.
Bersedia untuk Mentransformasi Perniagaan Anda?
Mari bincangkan bagaimana kami boleh mengaplikasikan penyelesaian serupa untuk cabaran anda.