Milvus Autoscaling pada Kubernetes dengan Storan Kekal Berasaskan EC2 dan S3
Sebuah 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, menjimatkan kos yang tidak akan hilang jika pod dimulakan semula atau nod diganti.
Bincangkan Projek Anda
Cabaran
Mengendalikan Milvus pada skala dalam pengeluaran menimbulkan beberapa cabaran infrastruktur:
- Kapasiti Tetap — Penggunaan Milvus statik tidak dapat mengendalikan lonjakan beban pertanyaan 10x semasa waktu puncak
- Risiko Kehilangan Data — Pod yang dimulakan semula pada storan sementara menyebabkan pembinaan semula indeks mengambil masa berjam-jam pada koleksi besar
- Ketidakcekapan Kos — Penyediaan berlebihan untuk beban puncak bermakna membayar untuk komputasi terbiar 70% daripada masa
- Kos Storan — Volum storan blok yang terikat pada instans adalah mahal untuk set data vektor multi-terabait
- Pembinaan Semula Indeks — Pengindeksan semula berjuta-juta vektor selepas penggantian nod mengambil masa henti berjam-jam
- Ketahanan Multi-AZ — Storan Single-AZ tidak dapat bertahan daripada kegagalan zon ketersediaan
Penyelesaian Kami
Kami menggunakan Milvus pada Kubernetes (EKS) dengan Horizontal Pod Autoscaling untuk nod pertanyaan, Cluster Autoscaler untuk komputasi, dan Amazon S3 sebagai bahagian belakang storan kekal — menghapuskan risiko kehilangan data dan mengurangkan kos storan sebanyak ~80%.
Seni Bina
- Orkestrasi: Amazon EKS (Elastic Kubernetes Service)
- Komputasi: Instans EC2 (jenis instans bercampur) diuruskan oleh Cluster Autoscaler
- Vector DB: Milvus digunakan melalui carta Helm dalam mod teragih
- Storan Objek: Amazon S3 untuk fail segmen, fail indeks, dan kekekalan binlog
- Metadata: Kluster etcd untuk penyelarasan dan metadata Milvus
- Gilir Pesanan: Penstriman mesej untuk saluran paip log Milvus
- Pemantauan: Prometheus + Grafana untuk metrik Milvus dan isyarat autoscaling
Seni Bina Teragih Milvus pada Kubernetes
Penggunaan Komponen
Milvus berjalan dalam mod teragih dengan jenis nod khusus, setiap satunya digunakan sebagai beban kerja Kubernetes dengan penskalaan bebas:
- Nod Proksi — Mengendalikan sambungan klien dan penghalaan permintaan
- Nod Pertanyaan — Melaksanakan carian vektor dan memuatkan segmen ke dalam memori
- Nod Data — Mengendalikan laluan tulis dan membersihkan segmen ke S3
- Nod Indeks — Membina indeks vektor dan menulis ke S3
- Penyelaras — Penyelarasan kluster dan peruntukan cap waktu
- etcd — Storan metadata dan penemuan perkhidmatan
- Gilir Pesanan — Penstriman log dan log tulis-hadapan
Horizontal Pod Autoscaling (HPA)
Autoscaling Nod Pertanyaan
Nod pertanyaan adalah sasaran penskalaan utama — ia memuatkan segmen vektor ke dalam memori dan melaksanakan carian. Penskalaan didorong oleh pelbagai metrik termasuk penggunaan CPU, penggunaan memori, kedalaman gilir pertanyaan, dan kependaman pertanyaan P99. HPA dikonfigurasi dengan replika min/maks yang sesuai, penskalaan naik pantas untuk mengendalikan lonjakan, dan penskalaan turun beransur-ansur untuk mengelakkan "flapping".
Autoscaling Nod Indeks
Nod indeks berskala berdasarkan kerja pembinaan indeks yang belum selesai — berskala naik apabila gilir pembinaan mempunyai item yang belum selesai dan berskala turun apabila terbiar.
EC2 Cluster Autoscaler
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 komputasi 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 on-demand 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 memuatkan segmen yang ditetapkan daripada S3 ke dalam memori dan mula melayan pertanyaan, dengan proses penskalaan naik keseluruhan selesai dalam beberapa minit.
Storan Kekal Berasaskan S3
Mengapa S3 Berbanding Storan Blok
S3 menyediakan kelebihan yang 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 AZ lock-in — Data boleh diakses dari mana-mana zon ketersediaan
Aliran Data dengan S3
- Laluan Tulis: Nod data menampan sisipan dalam memori, kemudian membersihkan segmen tertutup ke S3
- Pembinaan Indeks: Nod indeks membaca segmen daripada S3, membina indeks, dan menulis fail indeks kembali ke S3
- Laluan Pertanyaan: Nod pertanyaan memuat turun segmen dan indeks daripada S3, memuatkan ke dalam memori, dan melayan pertanyaan
- Pemulihan: Apabila pod dimulakan semula, nod pertanyaan memuat turun semula segmen yang ditetapkan daripada S3 (tiada kehilangan data)
Pengoptimuman Prestasi S3
- Penalaan saiz segmen mengimbangkan kos permintaan S3 berbanding kesegaran data
- Caching 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 & Kebolehperhatian
Penggunaan ini merangkumi pemantauan komprehensif melalui Prometheus dan Grafana:
- Prestasi Pertanyaan — Taburan kependaman, QPS, kadar capaian cache
- Gambaran Keseluruhan Kluster — Kiraan nod, status pod, penggunaan sumber
- Kesihatan Storan — Penggunaan S3, kiraan segmen, kadar pembersihan
- Peristiwa Autoscaling — Peristiwa HPA, penskalaan nod, kependaman penjadualan pod
- Pemberian Isyarat — Isyarat automatik untuk kependaman tinggi, risiko OOM, kegagalan pembersihan, dan had kapasiti
Ciri-ciri Utama
- HPA Nod Pertanyaan — Penskalaan automatik berdasarkan CPU, memori, kependaman, dan kedalaman gilir
- EC2 Cluster Autoscaler — 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 komputasi yang ketara
- Cache SSD Tempatan — Caching NVMe menghapuskan pembacaan S3 berulang untuk segmen panas
- Pemulihan Tanpa Henti — Pod yang dimulakan semula memuatkan semula segmen dari S3 tanpa kehilangan data
- Multi-AZ — Storan S3 + kumpulan nod multi-AZ untuk toleransi kegagalan AZ sepenuhnya
- Kebolehperhatian — Prometheus + Grafana dengan metrik khusus Milvus dan kebolehlihatan autoscaling
Keputusan
Timbunan Teknologi
caseStudyDetail.more Kajian Kes
Terokai lebih banyak pelaksanaan teknikal kami
Platform Pengurusan Sumber Manusia (HR) & Tenaga Kerja Catant
Catant ialah platform pengurusan HR dan tenaga kerja modular yang membantu perusahaan mengurus pekerja, gaji, kehadiran, dan pematuhan dari satu papan pemuka.
Kickly: Platform Projek Dikuasakan AI untuk Syarikat Pemula
Kickly ialah platform pengurusan projek dikuasakan AI yang dibina untuk syarikat pemula — menggabungkan automasi tugas pintar, kolaborasi pasukan, dan penjejakan kemajuan masa nyata dalam satu produk.
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.