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 mengkonfigurasi horizontal pod autoscaling dengan custom metrics daripada built-in memory usage exporter Milvus, mencetuskan scale-out events apabila mana-mana query node melebihi 75% memory utilization. Collection segments diedarkan semula secara automatik merentasi nod baharu menggunakan segment manager Milvus, menghalang mana-mana nod tunggal daripada menjadi bottleneck.
MicrocosmWorks memilih storan bersandarkan S3 menggunakan MinIO sebagai lapisan storan objek kerana ia menyahgandingkan storan daripada pengkomputeran, membolehkan nod pertanyaan untuk menskalakan secara bebas tanpa penyediaan volume EBS baharu. Seni bina ini mengurangkan kos storan sebanyak kira-kira 60% berbanding volume EBS gp3 sambil mengekalkan masa muat segmen bawah 100ms dari S3.
MicrocosmWorks mengkonfigurasi penempatan tersebut dengan replica sets untuk setiap komponen Milvus, termasuk query nodes, index nodes, dan data nodes, dengan pod disruption budgets bagi memastikan ketersediaan minimum semasa rolling updates. Memandangkan semua data kekal berada dalam S3, pengganti nod yang gagal dapat serta-merta mengakses semua segmen tanpa penghijrahan data.
MicrocosmWorks mendapati bahawa instance r6i.2xlarge menyediakan nisbah kos-ke-prestasi yang optimum untuk beban kerja pertanyaan Milvus, menawarkan memori 64GB untuk caching segmen dalam memori pada spot price yang kompetitif. Untuk pembinaan indeks yang dipercepatkan GPU, instance g5.xlarge dengan GPU NVIDIA A10G mengurangkan masa pembinaan indeks sebanyak 8x berbanding dengan pembinaan hanya CPU.
MicrocosmWorks menyampaikan projek infrastruktur Kubernetes pada kadar $30-$50/jam, dengan pelaksanaan Milvus autoscaling termasuk penyesuaian Helm chart, konfigurasi HPA, integrasi S3, dan persediaan pemantauan biasanya memerlukan 150-250 jam. Sokongan terurus berterusan untuk pengoptimuman dan peningkatan kluster tersedia pada kadar jam yang sama.
Bersedia untuk Mentransformasi Perniagaan Anda?
Mari bincangkan bagaimana kami boleh mengaplikasikan penyelesaian serupa untuk cabaran anda.