Автомасштабування Milvus на Kubernetes з EC2 та постійним сховищем на базі S3
Платформі AI зі стрімко зростаючими векторними даними (вбудовування для пошуку, рекомендацій та RAG) потрібна була їхня векторна база даних Milvus, щоб автоматично масштабуватися на основі навантаження запитів і об'єму даних — з надійним, економічно ефективним сховищем, яке не буде втрачено, якщо перезавантажаться pod-и або будуть замінені вузли.
Обговоріть Ваш Проєкт
Виклик
Запуск Milvus у великих масштабах у виробничому середовищі створював кілька інфраструктурних викликів:
- Фіксована потужність — Статичні розгортання Milvus не могли впоратися з 10-кратними стрибками навантаження запитів у години пік
- Ризик втрати даних — Перезапуски pod-ів на тимчасовому сховищі призводили до перебудови індексів, що займало години на великих колекціях
- Неефективність витрат — Надмірне виділення ресурсів для пікового навантаження означало оплату простою обчислювальних ресурсів 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 з незалежним масштабуванням:
- Вузли Proxy — Обробляють клієнтські з'єднання та маршрутизацію запитів
- Вузли Query — Виконують векторний пошук та завантажують сегменти в пам'ять
- Вузли Data — Обробляють шляхи запису та скидають сегменти до S3
- Вузли Index — Створюють векторні індекси та записують їх до S3
- Coordinator — Координація кластера та виділення міток часу
- etcd — Зберігання метаданих та виявлення сервісів
- Черга повідомлень — Потокова передача логів та write-ahead log
Horizontal Pod Autoscaling (HPA)
Автомасштабування вузлів Query
Вузли Query є основною ціллю масштабування — вони завантажують векторні сегменти в пам'ять і виконують пошук. Масштабування керується кількома метриками, включаючи утилізацію CPU, утилізацію пам'яті, глибину черги запитів та затримку запитів P99. HPA налаштований з відповідними мінімальними/максимальними репліками, швидким масштабуванням для обробки пікових навантажень та поступовим зменшенням масштабу, щоб уникнути "флеппінгу".
Автомасштабування вузлів Index
Вузли Index масштабуються на основі завдань побудови індексу, що очікують — збільшуючи масштаб, коли черга побудови має очікуючі елементи, і зменшуючи його, коли простіює.
EC2 Cluster Autoscaler
Стратегія екземплярів
- Групи вузлів: Кілька груп вузлів з різними типами екземплярів для оптимізації витрат
- Робоче навантаження Query: Екземпляри, оптимізовані для пам'яті, для векторних сегментів, що знаходяться в пам'яті
- Робоче навантаження Index: Екземпляри, оптимізовані для обчислень, для інтенсивного використання CPU при побудові індексу
- Spot Instances: Вузли Index та некритичні вузли Data працюють на Spot Instances для значної економії
- On-Demand: Вузли Query та координатори на On-Demand екземплярах для стабільності
Поведінка масштабування
Коли HPA створює нові pod-и, які не можуть бути заплановані, Cluster Autoscaler забезпечує нові екземпляри EC2 у відповідній групі вузлів. Нові вузли запитів потім завантажують свої призначені сегменти з S3 в пам'ять і починають обслуговувати запити, при цьому весь процес масштабування завершується за лічені хвилини.
Постійне сховище на базі S3
Чому S3 замість блокового сховища
S3 надає значні переваги над блоковим сховищем для Milvus:
- Приблизно на 80% менша вартість сховища для великих наборів даних
- Надійність 11-дев'яток з вбудованою реплікацією Multi-AZ
- Необмежене масштабування без ручного зміни розміру томів
- Незалежність від Pod-ів — Дані завжди доступні незалежно від життєвого циклу pod-а або вузла
- Без прив'язки до AZ — Дані доступні з будь-якої зони доступності
Потік даних з S3
- Шлях запису: Вузли Data буферизують вставки в пам'яті, потім скидають запечатані сегменти до S3
- Побудова індексу: Вузли Index читають сегменти з S3, будують індекси та записують файли індексів назад до S3
- Шлях запиту: Вузли Query завантажують сегменти та індекси з S3, завантажують їх у пам'ять та обслуговують запити
- Відновлення: При перезапуску pod-а, вузли Query повторно завантажують призначені сегменти з S3 (без втрати даних)
Оптимізація продуктивності S3
- Налаштування розміру сегмента балансує витрати на запити S3 та актуальність даних
- Локальне кешування SSD на NVMe сховищі екземпляра запобігає повторним читанням з S3 для "гарячих" сегментів
- Паралельні завантаження забезпечують швидкий запуск вузлів запитів
- Політики життєвого циклу архівують старі дані на дешевші рівні сховища
Моніторинг та Спостережуваність
Розгортання включає комплексний моніторинг за допомогою Prometheus та Grafana:
- Продуктивність запитів — Розподіл затримок, QPS, коефіцієнт попадання в кеш
- Огляд кластера — Кількість вузлів, статус pod-ів, використання ресурсів
- Стан сховища — Використання S3, кількість сегментів, швидкість скидання
- Події автомасштабування — Події HPA, масштабування вузлів, затримка планування pod-ів
- Сповіщення — Автоматичні сповіщення про високу затримку, ризик OOM, збої скидання та обмеження потужності
Ключові особливості
- HPA вузлів Query — Автоматичне масштабування на основі CPU, пам'яті, затримки та глибини черги
- EC2 Cluster Autoscaler — Динамічне забезпечення вузлів зі змішаними типами екземплярів
- Надійність S3 — Надійність 11-дев'яток, приблизно на 80% дешевше, ніж блокове сховище, витримує збої AZ
- Spot Instances — Вузли Index та Data на Spot Instances для значної економії обчислювальних ресурсів
- Локальний кеш SSD — Кешування NVMe усуває повторні читання S3 для "гарячих" сегментів
- Відновлення без простоїв — Перезапуски pod-ів перезавантажують сегменти з S3 без втрати даних
- Multi-AZ — Сховище S3 + групи вузлів Multi-AZ для повної відмовостійкості AZ
- Спостережуваність — Prometheus + Grafana з метриками, специфічними для Milvus, та видимістю автомасштабування
Результати
Технологічний Стек
caseStudyDetail.more Кейси
Ознайомтесь з іншими нашими технічними впровадженнями
Платформа Catant для управління персоналом та робочою силою
Catant — це модульна платформа для управління персоналом та робочою силою, яка допомагає підприємствам керувати співробітниками, заробітною платою, відвідуваністю та відповідністю нормативним вимогам з однієї панелі керування.
Kickly: Платформа для проєктів на базі AI для стартапів
Kickly — це платформа для управління проєктами на базі AI, створена для стартапів, яка об'єднує інтелектуальну автоматизацію завдань, командну співпрацю та відстеження прогресу в реальному часі в одному продукті.
Часті запитання
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 годин. Постійна керована підтримка для оптимізації та оновлення кластера доступна за тими ж погодинними ставками.
Готові Трансформувати Свій Бізнес?
Давайте обговоримо, як ми можемо застосувати подібні рішення для ваших завдань.