Pensakalaan Otomatis Milvus di Kubernetes dengan Penyimpanan Persisten yang Didukung EC2 dan S3
Sebuah platform AI dengan data vektor yang berkembang pesat (embeddings untuk pencarian, rekomendasi, dan RAG) memerlukan database vektor Milvus mereka untuk penskalaan otomatis berdasarkan beban kueri dan volume data — dengan penyimpanan yang tahan lama dan hemat biaya yang tidak akan hilang jika pods dimulai ulang atau nodes diganti.
Diskusikan Proyek Anda
Tantangan
Menjalankan Milvus pada skala produksi menghadirkan beberapa tantangan infrastruktur:
- Kapasitas Tetap — Deployments Milvus statis tidak dapat menangani lonjakan beban kueri 10x selama jam sibuk
- Risiko Kehilangan Data — Pod restarts pada penyimpanan ephemeral menyebabkan pembangunan ulang indeks memakan waktu berjam-jam pada koleksi besar
- Inefisiensi Biaya — Over-provisioning untuk beban puncak berarti membayar komputasi yang tidak terpakai 70% dari waktu
- Biaya Penyimpanan — Volume block storage yang terikat pada instance mahal untuk dataset vektor multi-terabyte
- Pembangunan Ulang Indeks — Pengindeksan ulang jutaan vektor setelah penggantian node membutuhkan waktu henti berjam-jam
- Ketahanan Multi-AZ — Penyimpanan Single-AZ tidak dapat bertahan dari kegagalan zona ketersediaan
Solusi Kami
Kami menerapkan Milvus di Kubernetes (EKS) dengan Horizontal Pod Autoscaling untuk query nodes, Cluster Autoscaler untuk komputasi, dan Amazon S3 sebagai backend penyimpanan persisten — menghilangkan risiko kehilangan data dan mengurangi biaya penyimpanan hingga ~80%.
Arsitektur
- Orkestrasi: Amazon EKS (Elastic Kubernetes Service)
- Komputasi: instance EC2 (tipe instance campuran) yang dikelola oleh Cluster Autoscaler
- Vector DB: Milvus diterapkan melalui Helm chart dalam mode terdistribusi
- Penyimpanan Objek: Amazon S3 untuk file segmen, file indeks, dan persistensi binlog
- Metadata: etcd cluster untuk koordinasi dan metadata Milvus
- Antrian Pesan: Message streaming untuk pipeline log Milvus
- Pemantauan: Prometheus + Grafana untuk metrik Milvus dan sinyal autoscaling
Arsitektur Terdistribusi Milvus di Kubernetes
Penerapan Komponen
Milvus berjalan dalam mode terdistribusi dengan tipe node khusus, masing-masing diterapkan sebagai workload Kubernetes dengan penskalaan independen:
- Node Proksi — Menangani koneksi klien dan perutean permintaan
- Node Kueri — Mengeksekusi pencarian vektor dan memuat segmen ke dalam memori
- Node Data — Menangani jalur penulisan dan mem-flush segmen ke S3
- Node Indeks — Membangun indeks vektor dan menulis ke S3
- Koordinator — Koordinasi cluster dan alokasi timestamp
- etcd — Penyimpanan metadata dan penemuan layanan
- Antrian Pesan — Log streaming dan write-ahead log
Pensakalaan Otomatis Pod Horisontal (HPA)
Pensakalaan Otomatis Node Kueri
Node kueri adalah target penskalaan utama — mereka memuat segmen vektor ke dalam memori dan mengeksekusi pencarian. Penskalaan didorong oleh beberapa metrik termasuk utilisasi CPU, utilisasi memori, kedalaman antrian kueri, dan latensi kueri P99. HPA dikonfigurasi dengan replika min/max yang sesuai, scale-up cepat untuk menangani lonjakan, dan scale-down bertahap untuk menghindari flapping.
Pensakalaan Otomatis Node Indeks
Node indeks melakukan penskalaan berdasarkan pekerjaan pembangunan indeks yang tertunda — melakukan scale-up ketika antrian pembangunan memiliki item yang tertunda dan scale-down kembali ketika idle.
Cluster Autoscaler EC2
Strategi Instance
- Grup Node: Beberapa grup node dengan tipe instance yang berbeda untuk optimisasi biaya
- Workload Kueri: Instance yang dioptimalkan memori untuk segmen vektor in-memory
- Workload Indeks: Instance yang dioptimalkan komputasi untuk pembangunan indeks yang intensif CPU
- Spot Instances: Node indeks dan node data non-kritis berjalan pada spot instances untuk penghematan signifikan
- On-Demand: Node kueri dan koordinator pada on-demand instances untuk stabilitas
Perilaku Penskalaan
Ketika HPA membuat pods baru yang tidak dapat dijadwalkan, Cluster Autoscaler menyediakan instance EC2 baru di grup node yang sesuai. Node kueri baru kemudian memuat segmen yang ditugaskan dari S3 ke memori dan mulai melayani kueri, dengan total proses scale-up selesai dalam hitungan menit.
Penyimpanan Persisten yang Didukung S3
Mengapa S3 daripada Block Storage
S3 memberikan keuntungan signifikan dibandingkan block storage untuk Milvus:
- Biaya penyimpanan ~80% lebih rendah untuk dataset besar
- Ketahanan 11-nines dengan replikasi multi-AZ bawaan
- Penskalaan tanpa batas tanpa perubahan ukuran volume manual
- Independen Pod — Data selalu tersedia terlepas dari siklus hidup pod atau node
- Tanpa penguncian AZ — Data dapat diakses dari zona ketersediaan mana pun
Aliran Data dengan S3
- Jalur Penulisan: Node data menyangga insert dalam memori, lalu mem-flush segmen tersegel ke S3
- Pembangunan Indeks: Node indeks membaca segmen dari S3, membangun indeks, dan menulis file indeks kembali ke S3
- Jalur Kueri: Node kueri mengunduh segmen dan indeks dari S3, memuat ke memori, dan melayani kueri
- Pemulihan: Saat pod dimulai ulang, node kueri mengunduh ulang segmen yang ditugaskan dari S3 (tanpa kehilangan data)
Optimisasi Kinerja S3
- Penyesuaian ukuran segmen menyeimbangkan biaya permintaan S3 versus kesegaran data
- Caching SSD Lokal pada penyimpanan instance NVMe menghindari pembacaan S3 berulang untuk segmen panas
- Unduhan Paralel memungkinkan startup node kueri yang cepat
- Kebijakan siklus hidup mengarsipkan data lama ke tier penyimpanan yang lebih murah
Pemantauan & Observabilitas
Deployment mencakup pemantauan komprehensif melalui Prometheus dan Grafana:
- Kinerja Kueri — Distribusi latensi, QPS, rasio hit cache
- Gambaran Umum Klaster — Jumlah node, status pod, utilisasi sumber daya
- Kesehatan Penyimpanan — Penggunaan S3, jumlah segmen, tingkat flush
- Peristiwa Pensakalaan Otomatis — Peristiwa HPA, penskalaan node, latensi penjadwalan pod
- Peringatan — Peringatan otomatis untuk latensi tinggi, risiko OOM, kegagalan flush, dan batas kapasitas
Fitur Utama
- HPA Node Kueri — Penskalaan otomatis berdasarkan CPU, memori, latensi, dan kedalaman antrian
- Cluster Autoscaler EC2 — Penyediaan node dinamis dengan tipe instance campuran
- Persistensi S3 — Ketahanan 11-nines, ~80% lebih murah daripada block storage, bertahan dari kegagalan AZ
- Spot Instances — Node indeks dan data pada spot untuk penghematan komputasi yang signifikan
- Cache SSD Lokal — Caching NVMe menghilangkan pembacaan S3 berulang untuk segmen panas
- Pemulihan Tanpa Downtime — Pod restarts memuat ulang segmen dari S3 tanpa kehilangan data
- Multi-AZ — Penyimpanan S3 + grup node multi-AZ untuk toleransi kegagalan AZ penuh
- Observabilitas — Prometheus + Grafana dengan metrik khusus Milvus dan visibilitas autoscaling
Hasil
Tumpukan Teknologi
caseStudyDetail.more Studi Kasus
Jelajahi lebih banyak implementasi teknis kami
Kickly: Platform Proyek Berbasis AI untuk Startup
Kickly adalah platform manajemen proyek berbasis AI yang dibangun untuk startup — menggabungkan otomatisasi tugas pintar, kolaborasi tim, dan pelacakan kemajuan real-time dalam satu produk.
Catant Platform HR & Workforce Management
Catant adalah platform HR & Workforce Management modular yang membantu perusahaan mengelola karyawan, penggajian, absensi, dan kepatuhan dari satu dasbor.
Pertanyaan yang Sering Diajukan
MicrocosmWorks mengkonfigurasi horizontal pod autoscaling dengan custom metrics dari memory usage exporter bawaan Milvus, memicu event scale-out ketika node query mana pun melebihi 75% utilisasi memori. Segmen koleksi secara otomatis didistribusikan ulang ke seluruh node baru menggunakan segment manager Milvus, mencegah satu node pun menjadi bottleneck.
MicrocosmWorks memilih penyimpanan berbasis S3 menggunakan MinIO sebagai lapisan *object storage* karena ia memisahkan penyimpanan dari *compute*, memungkinkan *query nodes* untuk melakukan penskalaan secara independen tanpa menyediakan volume EBS baru. Arsitektur ini mengurangi biaya penyimpanan sekitar 60% dibandingkan dengan volume EBS gp3 sambil mempertahankan waktu muat segmen di bawah 100 milidetik dari S3.
MicrocosmWorks mengkonfigurasi deployment dengan set replika untuk setiap komponen Milvus, termasuk node kueri, node indeks, dan node data, dengan anggaran gangguan pod yang memastikan ketersediaan minimum selama pembaruan bergulir. Karena semua data persisten berada di S3, penggantian node yang gagal dapat segera mengakses semua segmen tanpa migrasi data.
MicrocosmWorks menemukan bahwa instance r6i.2xlarge memberikan rasio cost-to-performance yang optimal untuk beban kerja kueri Milvus, menawarkan 64GB memory untuk in-memory segment caching dengan harga spot yang kompetitif. Untuk pembangunan indeks yang dipercepat GPU, instance g5.xlarge dengan GPU NVIDIA A10G mengurangi waktu pembangunan indeks hingga 8x dibandingkan dengan pembangunan yang hanya menggunakan CPU.
MicrocosmWorks menyediakan proyek infrastruktur Kubernetes dengan tarif $30-$50/jam, dengan penerapan Milvus autoscaling termasuk kustomisasi Helm chart, konfigurasi HPA, integrasi S3, dan penyiapan pemantauan yang biasanya memerlukan 150-250 jam. Dukungan terkelola berkelanjutan untuk optimisasi dan peningkatan klaster tersedia dengan tarif per jam yang sama.
Siap Mentransformasi Bisnis Anda?
Mari diskusikan bagaimana kami dapat menerapkan solusi serupa untuk tantangan Anda.