Автомасштабування 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 налаштувала horizontal pod autoscaling за допомогою користувацьких метрик з вбудованого memory usage exporter Milvus, спричиняючи події scale-out, коли будь-який query node перевищує 75% memory utilization. Сегменти колекції автоматично перерозподіляються між новими вузлами, використовуючи Milvus's segment manager, запобігаючи тому, щоб будь-який окремий вузол став вузьким місцем.
MicrocosmWorks обрала сховище на базі S3, використовуючи MinIO як рівень об'єктного сховища, оскільки це відокремлює сховище від обчислень, дозволяючи вузлам запитів масштабуватися незалежно без виділення нових томів EBS. Ця архітектура зменшує витрати на зберігання приблизно на 60% порівняно з томами gp3 EBS, зберігаючи при цьому час завантаження сегментів з S3 менше 100 мс.
MicrocosmWorks налаштувала розгортання з репліка-сетами для кожного компонента Milvus, включаючи вузли запитів, індексні вузли та вузли даних, з pod disruption budgets, що забезпечують мінімальну доступність під час rolling updates. Оскільки всі постійні дані зберігаються в S3, заміна відмовившого вузла може негайно отримати доступ до всіх сегментів без міграції даних.
MicrocosmWorks виявила, що інстанси r6i.2xlarge забезпечують оптимальне співвідношення ціни та продуктивності для робочих навантажень запитів Milvus, пропонуючи 64GB пам'яті для кешування сегментів в оперативній пам'яті за конкурентною спотовою ціною. Для прискореного за допомогою GPU створення індексів, інстанси g5.xlarge з GPU NVIDIA A10G скоротили час створення індексів у 8 разів порівняно зі збиранням лише на CPU.
MicrocosmWorks реалізує інфраструктурні проєкти Kubernetes за ставками $30-$50/год, при цьому розгортання Milvus з автомасштабуванням, що включає налаштування Helm chart, конфігурацію HPA, інтеграцію з S3 та налаштування моніторингу, зазвичай потребує 150-250 годин. Постійна керована підтримка для оптимізації та оновлення кластера доступна за тими ж погодинними ставками.
Готові Трансформувати Свій Бізнес?
Давайте обговоримо, як ми можемо застосувати подібні рішення для ваших завдань.