Автомасштабування Milvus на Kubernetes з EC2 та постійним сховищем на базі S3
Платформі AI зі швидко зростаючими векторними даними (ембединги для search, recommendations та RAG) була потрібна їхня векторна база даних Milvus, щоб вона автоматично масштабувалася на основі навантаження запитів та обсягу даних — з надійним, економічно ефективним сховищем, яке не було б втрачено в разі перезапуску подів або заміни нод.
Обговоріть Ваш Проєкт
Виклик
Запуск Milvus у великому масштабі в продакшені представив кілька інфраструктурних викликів:
- Фіксована потужність — Статичні розгортання Milvus не могли впоратися з 10-кратними піками навантаження запитів під час пікових годин
- Ризик втрати даних — Перезапуски подів на ефемерному сховищі спричиняли переіндексацію, що займало години на великих колекціях
- Неефективність витрат — Надмірне резервування для пікового навантаження означало оплату простою обчислювальної потужності 70% часу
- Вартість сховища — Томи блокового сховища, прив'язані до інстансів, були дорогими для багатотерабайтних векторних наборів даних
- Перебудови індексів — Переіндексація мільйонів векторів після заміни ноди займала години простою
- Надійність Multi-AZ — Сховище Single-AZ не могло витримати збоїв зони доступності
Наше Рішення
Ми розгорнули Milvus на Kubernetes (EKS) з Horizontal Pod Autoscaling для нод запитів, Cluster Autoscaler для обчислень та Amazon S3 як бекенд постійного сховища — усуваючи ризик втрати даних та зменшуючи витрати на сховище приблизно на 80%.
Архітектура
- Оркестрація: Amazon EKS (Elastic Kubernetes Service)
- Обчислення: Інстанси EC2 (змішані типи інстансів), керовані Cluster Autoscaler
- Векторна БД: Milvus, розгорнутий за допомогою Helm chart у розподіленому режимі
- Об'єктне сховище: Amazon S3 для файлів сегментів, файлів індексів та стійкості binlog
- Метадані: Кластер etcd для координації Milvus та метаданих
- Черга повідомлень: Потокова передача повідомлень для конвеєра журналів Milvus
- Моніторинг: Prometheus + Grafana для метрик Milvus та сигналів автомасштабування
Розподілена архітектура Milvus на Kubernetes
Розгортання компонентів
Milvus працює в розподіленому режимі з виділеними типами нод, кожна розгорнута як навантаження Kubernetes з незалежним масштабуванням:
- Проксі-ноди — Обробляють клієнтські з'єднання та маршрутизацію запитів
- Ноди запитів — Виконують векторний пошук та завантажують сегменти в пам'ять
- Ноди даних — Обробляють шляхи запису та скидають сегменти в S3
- Ноди індексів — Будують векторні індекси та записують в S3
- Координатор — Координація кластера та виділення часових міток
- etcd — Зберігання метаданих та виявлення сервісів
- Черга повідомлень — Потокова передача журналів та write-ahead log
Horizontal Pod Autoscaling (HPA)
Автомасштабування нод запитів
Ноди запитів є основною ціллю для масштабування — вони завантажують векторні сегменти в пам'ять та виконують пошук. Масштабування керується кількома метриками, включаючи використання CPU, використання пам'яті, глибину черги запитів та P99 затримку запитів. HPA налаштовується з відповідними мінімальною/максимальною кількістю реплік, швидким масштабуванням вгору для обробки піків та поступовим масштабуванням вниз, щоб уникнути коливань.
Автомасштабування нод індексів
Ноди індексів масштабуються на основі незавершених завдань побудови індексів — масштабуючись вгору, коли в черзі побудови є незавершені елементи, та масштабуючись назад, коли вони простоюють.
EC2 Cluster Autoscaler
Стратегія інстансів
- Групи нод: Кілька груп нод з різними типами інстансів для оптимізації витрат
- Навантаження запитів: Інстанси, оптимізовані для пам'яті, для векторних сегментів у пам'яті
- Навантаження індексування: Інстанси, оптимізовані для обчислень, для CPU-інтенсивної побудови індексів
- Spot-інстанси: Ноди індексів та некритичні ноди даних працюють на spot-інстансах для значної економії
- On-Demand: Ноди запитів та координатори на on-demand інстансах для стабільності
Поведінка масштабування
Коли HPA створює нові поди, які не можуть бути заплановані, Cluster Autoscaler надає нові інстанси EC2 у відповідній групі нод. Нові ноди запитів потім завантажують свої призначені сегменти з S3 у пам'ять і починають обслуговувати запити, при цьому весь процес масштабування вгору завершується за лічені хвилини.
Постійне сховище на базі S3
Чому S3 замість блокового сховища
S3 надає значні переваги перед блоковим сховищем для Milvus:
- Приблизно на 80% нижча вартість сховища для великих наборів даних
- Надійність 11-дев'яток з вбудованою реплікацією Multi-AZ
- Необмежене масштабування без ручного зміни розміру тому
- Незалежність від подів — Дані завжди доступні незалежно від життєвого циклу пода або ноди
- Без прив'язки до AZ — Дані доступні з будь-якої зони доступності
Потік даних з S3
- Шлях запису: Ноди даних буферизують вставки в пам'яті, потім скидають запечатані сегменти в S3
- Побудова індексу: Ноди індексів читають сегменти з S3, будують індекси та записують файли індексів назад в S3
- Шлях запиту: Ноди запитів завантажують сегменти та індекси з S3, завантажують у пам'ять та обслуговують запити
- Відновлення: При перезапуску пода ноди запитів повторно завантажують призначені сегменти з S3 (без втрати даних)
Оптимізація продуктивності S3
- Налаштування розміру сегмента балансує витрати на запити S3 та актуальність даних
- Локальне кешування SSD на сховищі інстансів NVMe уникає повторних читань з S3 для гарячих сегментів
- Паралельні завантаження забезпечують швидкий запуск ноди запитів
- Політики життєвого циклу архівують старі дані на дешевші рівні сховища
Моніторинг та спостережуваність
Розгортання включає комплексний моніторинг за допомогою Prometheus та Grafana:
- Продуктивність запитів — Розподіл затримки, QPS, коефіцієнт влучень кешу
- Огляд кластера — Кількість нод, статус подів, використання ресурсів
- Стан сховища — Використання S3, кількість сегментів, швидкість скидання
- Події автомасштабування — Події HPA, масштабування нод, затримка планування подів
- Оповіщення — Автоматичні оповіщення про високу затримку, ризик OOM, збої скидання та ліміти потужності
Ключові особливості
- HPA нод запитів — Автоматичне масштабування на основі CPU, пам'яті, затримки та глибини черги
- EC2 Cluster Autoscaler — Динамічне надання нод зі змішаними типами інстансів
- Стійкість S3 — Надійність 11-дев'яток, приблизно на 80% дешевше, ніж блокове сховище, витримує збої AZ
- Spot-інстанси — Ноди індексів та даних на spot-інстансах для значної економії обчислювальної потужності
- Локальний SSD кеш — Кешування NVMe усуває повторні читання з S3 для гарячих сегментів
- Відновлення без простоїв — Перезапуски подів перезавантажують сегменти з S3 без втрати даних
- Multi-AZ — Сховище S3 + групи нод Multi-AZ для повної відмовостійкості AZ
- Спостережуваність — Prometheus + Grafana з метриками, специфічними для Milvus, та видимістю автомасштабування
Результати
Технологічний Стек
caseStudyDetail.more Кейси
Ознайомтесь з іншими нашими технічними впровадженнями
Обробка рахунків-фактур за допомогою AI, OCR та інтеграції з QuickBooks
Середній бізнес, який щомісяця обробляє сотні рахунків-фактур від постачальників, потребував усунення ручного введення даних шляхом автоматичного вилучення даних рахунків-фактур за допомогою AI/OCR та їх прямої синхронізації з QuickBooks для ведення бухгалтерського обліку та відстеження платежів.
Вставка реклами на стороні клієнта (CSAI) з парсингом маркерів SCTE-35 та інтеграцією багатоплатформного плеєра
Платформа потокового відео потребувала впровадження вставки реклами на стороні клієнта (CSAI) для веб-, мобільних програм та програм для підключених телевізорів — що забезпечує персоналізований рекламний досвід на рівні пристрою з повною підтримкою взаємодії з рекламою (натискні оверлеї, супутні банери, кнопки пропуску), який не може забезпечити вставка на стороні сервера.
Часті запитання
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.
Готові Трансформувати Свій Бізнес?
Давайте обговоримо, як ми можемо застосувати подібні рішення для ваших завдань.