Создание Zilliz Cloud за 18 месяцев: уроки, извлеченные при создании масштабируемого сервиса векторного поиска в публичном облаке
Предисловие
Векторные базы данных стали одним из ведущих трендов в индустрии баз данных в 2023 году. В этом посте подробно описывается создание Zilliz Cloud, полностью управляемого сервиса на базе Milvus, самой широко используемой векторной базы данных с открытым исходным кодом, разработанного с нуля за восемнадцать месяцев. За это время мы с нуля разработали комплексный облачный сервис и справились с десятикратным ростом трафика, вызванным быстрым распространением больших языковых моделей (LLM). Эта ретроспектива посвящена ключевым проектным решениям и бесценным выводам, полученным в ходе нашего пути.
Выделенный кластер Zilliz Cloud — начало пути
Если вернуться в май 2022 года, векторная база данных с открытым исходным кодом Milvus 2.0 наконец начала стабилизироваться после нескольких крупных итераций. В разговорах с нашими пользователями необходимость стабильной, коммерчески размещаемой версии постоянно всплывала как повторяющийся запрос. Для Zilliz, коммерческой компании, стоящей за Milvus, момент казался идеальным для начала коммерциализации: у нас была опытная команда инженеров, зрелый продукт и преданная пользовательская база с насущными потребностями. С учетом этого мы поставили амбициозную цель: запустить наш продукт в течение шести месяцев.
Приступая к проекту, мы оценили наши текущие возможности и цели:
- Наша базовая технология — облачно-нативная векторная база данных с открытым исходным кодом, спроектированная с разделением хранения и вычислений и микросервисной архитектурой, — создана для бесшовной интеграции в кластер Kubernetes (K8s). Эта облачно-нативная архитектура позволяет нам быстро адаптироваться к облачным производственным средам.
Рисунок 1: Архитектура Milvus
Поскольку мы использовали Kubernetes Operator, у нас была возможность быстро развертывать сервисы на основных публичных облачных платформах, таких как AWS и GCP; это подтвердили несколько пользователей, успешно внедривших свои производственные сервисы в публичном облаке.
Наша платформа включала базовые функции наблюдаемости, такие как мониторинг и журналирование, однако ей не хватало критически важных функций оповещения для production-среды.
Помимо ранее упомянутых элементов, как сервису нам не хватало нескольких критически важных компонентов, включая, помимо прочего, аутентификацию входа пользователей, учет использования и выставление счетов, платежные механизмы, сетевую инфраструктуру, безопасность, веб-консоль, поддержку OpenAPI, планирование ресурсов и управление рабочими процессами.
Определить, какие ключевые модули необходимо создать в течение шести месяцев, было непростой задачей. В ответ мы провели критическую самооценку: как наиболее эффективно использовать доступные ресурсы? Можем ли мы свести наш подход к созданию компактной, но полностью функциональной версии? Эти ключевые вопросы направили наши размышления и в итоге сформировали набор основополагающих принципов проектирования:
Максимально использовать зрелые сторонние продукты, чтобы не изобретать велосипед:
Делая акцент на быстром выходе на рынок, мы стратегически опирались на устоявшиеся облачные и сторонние сервисы. Мы использовали ключевые сервисы AWS, такие как EKS, EC2, S3, EBS и ALB, а также управляемые AWS Kafka и RDS в качестве основы нашей инфраструктуры. Этот подход не только удовлетворил наши немедленные потребности, но и показал, что такие компоненты предлагают экономически эффективный путь для будущей адаптации к мультиоблачной среде, тем самым ускоряя темпы наших инноваций. Столкнувшись с проблемами совместимости между очередями сообщений GCP/Azure и управляемыми сервисами Kafka, мы разработали собственную распределенную систему журналирования на базе Apache Bookkeeper. Отсутствие надежных, open-source или облачно-нативных решений для распределенного журналирования подтолкнуло нас к этой инициативе. Мотивированные этим пробелом, мы рассматриваем возможность открыть исходный код нашего решения, надеясь, что оно поможет другим в создании облачных сервисов.
Сторонние SaaS-провайдеры сыграли важную роль в ускорении разработки нашей платформы. Например, мы внедрили Stripe для управления обработкой платежей, решая сложные требования к учету потребления и налогообложению. Чтобы обеспечить подключение к мультиоблачным маркетплейсам, мы интегрировали Sugar.io. Кроме того, мы оценили платформы биллинговых сервисов, такие как Orb и Metronome, чтобы улучшить наши биллинговые операции. Auth0 был нашим выбранным продуктом для управления учетными записями и функциональности входа; мы также расширили нашу функциональность аутентификации и входа, добавив поддержку входа через Google. Мы создали нашу операционную систему оповещений на PagerDuty, выбранную за быструю интеграцию с нашими существующими инструментами мониторинга и универсальность в настройке правил уведомлений.
Сущности не следует умножать без необходимости
Руководствуясь философией бритвы Оккама, мы приняли минималистичный подход к дизайну, который проявился в различных аспектах продукта:
Простота архитектуры: Изначально наш дизайн включал более 60 микросервисов, что создавало значительные трудности в координации разработки и тестирования. Чтобы упростить нашу архитектуру, мы сократили их количество до менее чем десяти ключевых микросервисов, включая user, billing, CloudService, resources, metadata и scheduling. Это сокращение прояснило зависимости и снизило нагрузку на тестирование.
Функциональная простота: В первоначальной итерации акцент Zilliz Cloud был сделан на ключевых пользовательских функциях, таких как регистрация, развертывание кластеров и биллинг, при этом мы сознательно отложили менее срочные функции, такие как масштабирование и резервное копирование, чтобы снизить рабочую нагрузку. Примечательным было наше стремление создать надежный цикл обратной связи, изначально обеспечивая обратную связь по электронной почте, а затем дополнив ее интеграцией с Zendesk, чтобы оперативная и качественная обратная связь могла направлять нас в дальнейших улучшениях.
Простота дизайна: Дизайн нашего облачного сервиса отдавал приоритет эффективной коммуникации и потенциалу вовлечения пользователей, требуя дисциплинированного и сфокусированного подхода. Использование быстрого A/B-тестирования позволило нам оперативно проверять функции и адаптироваться на основе метрик вовлеченности пользователей.
Предвидьте вызовы второго дня с первого дня:
В динамичном ландшафте облачных сервисов способность быстро развиваться без ущерба для надежности пользовательских интерфейсов и сервисов имеет первостепенное значение. Этот сложный маневр напоминает «замену реактивных двигателей в воздухе». Для внешнего наблюдателя сервис работает безупречно, в то время как внутри идет энергичный цикл инноваций и улучшений. Крайне важно применять подход к разработке, ориентированный на конечную цель.
Поддержка мультиоблачности: Изначально сосредоточенный на AWS, наш подход всегда отдавал приоритет независимости от конкретного облака. Мы всесторонне оценивали провайдеров, таких как GCP и Alibaba Cloud, чтобы обеспечить совместимость в различных публичных облаках. Благодаря кастомизации open-source проекта Crossplane мы разработали слой «cloud adapter», снизив затраты, связанные с поддержкой мультиоблачности. Этот дизайн обеспечил быструю интеграцию с GCP всего за один месяц и упростил интеграцию с другими публичными облачными провайдерами.
Безопасность: Хотя разработчики AIGC-приложений могут отдавать приоритет чему-то иному, нежели безопасность, Zilliz Cloud Services придает первостепенное значение безопасности данных. Строго придерживаясь облачных стандартов IAM, мы тщательно контролируем права доступа к данным и применяем шифрование для всех данных как при передаче, так и в состоянии покоя. Делая акцент на сетевой изоляции для оптимальной производительности, мы выбрали сетевые add-ons AWS EKS за их эффективность и удобство использования. Разграничение границ взаимодействия между слоями данных и управления привело к значительной экономии затрат при развертывании нашего продукта BYOC.
Пулинг ресурсов: Zilliz Cloud Services применяет «закон облачной коммутативности», отдавая приоритет эластичной масштабируемости за счет пулинга ресурсов. Разделяя хранение и вычисления и используя динамическую балансировку нагрузки, мы обеспечиваем эффективное использование облачных ресурсов. Такой подход позволяет нам резервировать ресурсы только при необходимости, значительно повышая эффективность использования Spot Instances и функций Lambda при одновременном снижении затрат.
Удобство для эксплуатации: Zilliz Cloud разработан с учетом потребностей разработчиков и операционного персонала, в отличие от других векторных баз данных. Обладая комплексным GUI и продвинутыми возможностями мониторинга, платформа предлагает аварийное восстановление в трех AZ и соблюдает строгие SLA, обеспечивая стабильность и надежность для производственных сред.
Руководствуясь нашими ключевыми принципами проектирования, мы достигли важного рубежа, запустив наш коммерческий продукт для векторного поиска всего за шесть месяцев и в процессе получив первую группу seed-клиентов. Ниже вы найдете архитектурную диаграмму нашего первого релиза.
Рисунок 2- Архитектура Zilliz Cloud
Serverless: снижение стоимости привлечения нового пользователя с $300 до $5
Рост часто происходит в неожиданные моменты. После трех месяцев стабильного роста наших SaaS-сервисов рост Zilliz Cloud, подпитанный взрывной популярностью AutoGPT, достиг пика. Представление о векторных базах данных как о долговременной памяти для больших языковых моделей постепенно получило признание, что привело к быстрому увеличению пользовательской базы Zilliz, при этом число новых кластеров, добавляемых ежедневно, быстро достигло сотен.
Однако этот рост принес Zilliz две основные проблемы: стабильность и стоимость. Хотя мы всегда уделяли внимание масштабируемости, внезапные всплески высокого трафика почти парализовали все наши сервисы, и только основная база данных осталась невредимой. API, предоставляемые облачными провайдерами, подвергались throttling, а наша система хранения логов Loki дважды переполнялась всего за несколько дней, из-за чего многие сервисы были вынуждены прерывать работу из-за нехватки ресурсов.
Кроме того, первоначальная стратегия бесплатного пробного периода, принятая Zilliz Cloud, которая предлагала новым пользователям $300 Credits для знакомства со всеми функциями, привела к резкому росту затрат по мере увеличения числа пользователей (большинство из которых просто пробовали сервис), заставив нас переосмыслить нашу бизнес-модель. Эти болезненные точки побудили нас запустить Zilliz Cloud Serverless — продукт более гибкий, с более низким порогом входа и лучше подходящий для пользователей AIGC, которые только начинают свой путь с векторными базами данных.
Святой Грааль все еще где-то там: укрощение масштабируемости, стоимости и задержки для разработки RAG-приложений
Для сценария использования Retrieval-Augmented Generation (RAG) идеальное решение бесплатного уровня должно учитывать следующее:
Рисунок 3: Укрощение масштабируемости, стоимости и задержки в RAG-приложении
Масштабируемость — она включает два ключевых аспекта:
На уровне отдельного tenant система должна динамически масштабироваться для эффективной обработки данных. Такое динамическое масштабирование требует, чтобы векторная база данных была достаточно универсальной, чтобы адаптироваться к колеблющимся объемам данных у разных tenants, независимо от того, обрабатывают ли они небольшие или большие наборы данных. Стабильно устойчивое время отклика на запросы должно поддерживаться независимо от размера обрабатываемых данных.
При управлении большим количеством tenants система должна эффективно поддерживать масштабирование вплоть до миллионов tenants. В частности, она должна интеллектуально различать и учитывать «горячие» (очень активные) и «холодные» (менее активные) паттерны использования, обеспечивая оптимальное распределение ресурсов и стабильность производительности по всем направлениям.
Стоимость — Контроль затрат для бесплатного уровня имеет решающее значение. В идеале стоимость должна оставаться ниже $1, предоставляя при этом достаточно ресурсов для поддержки 1 миллиона 768-мерных векторов. Однако при использовании векторной индексации в памяти цена обработки 1 миллиона 768-мерных векторов может легко превысить $10. Хотя такая стоимость может быть приемлемой для SaaS-компаний, ориентированных на корпоративные сервисы, она чрезмерна для потребительских ToC-приложений.
Низкая задержка — Хотя сценарии использования RAG могут быть не столь чувствительны к задержке, как области поиска и рекомендаций, производительность векторного поиска значительно влияет на "Time-to-first-token." Поэтому поддержание низкой задержки имеет решающее значение для улучшения пользовательского опыта и отзывчивости системы.
Первоначальное предложение Zilliz Cloud продемонстрировало выдающуюся масштабируемость при обработке больших объемов данных и достижении низкой задержки, превзойдя ожидания пользователей. Даже с учетом управления многочисленными арендаторами и контроля затрат решение на выделенном кластере не смогло полностью удовлетворить требования пользователей. Чтобы исправить это, мы разработали 'Zilliz Serverless Tier,' модель сервиса, специально предназначенную для снижения входного барьера для индивидуальных пользователей AIGC. Этот уровень предлагает наиболее экономически эффективные решения для хранения и масштабируемость, чтобы эффективно решать упомянутые выше проблемы.
Бессерверная архитектура Zilliz Cloud
Figure 4- The Zilliz Cloud Serverless Architecture
Zilliz Cloud Serverless вводит концепцию логических кластеров, где каждый логический кластер соответствует базе данных в физическом кластере. Мы обеспечиваем логическую изоляцию всех арендаторов внутри одного физического кластера с помощью механизмов аутентификации на основе базы данных и API-ключей. Во время запросов система маршрутизирует запросы на основе API-ключей, чтобы определить данные, к которым пользователям необходимо получить доступ, используя proxy-узлы для маршрутизации.
Операции записи данных сначала отправляются в пул log-узлов, которые затем записывают данные в сервис Write-Ahead Logging (WAL), периодически реорганизуя данные и сбрасывая их в объектное хранилище. CompactionService — это pooling-сервис, отвечающий за объединение небольших сегментов данных в более крупные и удаление удаленных записей, оптимизируя пространство хранения и скорость доступа. Index Service отвечает за построение индексов на необработанных данных, которые затем загружаются query-узлами для обеспечения эффективности запросов.
Во время операций запросов наша стратегия предусматривает кэширование всех данных на локальные диски Query Nodes и выполнение локальной подкачки между памятью и диском. Эта методология значительно снижает затраты на хранение для пользователей Serverless более чем в десять раз по сравнению с индексацией на основе памяти. Однако основная задача заключается в эффективном управлении ресурсами, чтобы предотвратить перегрузку query-узлов, вызванную проблемами tenant hotspot и noisy neighbors. Это особенно важно, поскольку каждый Query Node должен обрабатывать загрузку данных от нескольких арендаторов.
Чтобы повысить стабильность системы, мы внедрили следующие три важных механизма:
Distributed Quota: Этот механизм, основанный на централизованном сервисе квот, динамически распределяет квоты ресурсов и корректирует их в зависимости от нагрузки query-узлов. Это динамическое распределение помогает обеспечить справедливое потребление ресурсов каждым арендатором.
Distributed Quota: Этот механизм, основанный на централизованном сервисе квот, динамически распределяет квоты ресурсов и корректирует их в зависимости от нагрузки query-узлов. Это помогает обеспечить справедливое потребление ресурсов каждым арендатором.
Динамическое масштабирование ресурсов на основе метрик: Мы внедрили модуль Cloud Resource Scheduler, который комплексно управляет памятью, диском, нагрузками CPU и очередями запросов. Он обеспечивает динамическое масштабирование физических ресурсов для удовлетворения меняющихся потребностей в ресурсах в различных сценариях.
Многоуровневое планирование: Мы создали фреймворк планирования ресурсов, который работает на различных уровнях, охватывая физическую изоляцию через группировку ресурсов, балансировку нагрузки внутри этих групп ресурсов, а также управление очередями запросов и планирование кэша на уровне узла. Такой подход гарантирует справедливое распределение ресурсов между несколькими арендаторами, одновременно снижая риск монополизации ресурсов каким-либо одним арендатором.
Благодаря нашему сервису Serverless мы успешно снизили стоимость пробного использования для отдельных пользователей до $5, поддержав десятки тысяч разработчиков AIGC. В предстоящем релизе Zilliz Cloud мы дополнительно улучшаем наше решение Serverless, чтобы сделать его еще более экономичным и эластичным. В этой новой версии каждый пользователь Serverless сможет обрабатывать данные от миллионов арендаторов в одной коллекции, обеспечивая изоляцию данных и при этом значительно снижая затраты на хранение в десять раз по сравнению с текущим решением. Мы продолжим подробно рассматривать технические детали Zilliz Cloud Serverless в будущих статьях.
Шесть уроков, которые мы извлекли из создания облачного сервиса на основе open-source VectorDB
Осознание ограничений облака: Даже с облачно-нативными системами, такими как Milvus, переход к облачному SaaS сопряжен со значительными трудностями. Это выходит за рамки простого развертывания на EC2 и EBS. В области open-source баз данных пользователям необходимо глубоко понимать тонкости продукта, чтобы достигать горизонтального масштабирования, восстановления после сбоев и оптимизации производительности посредством тщательной настройки параметров. Настоящая сложность облачных сервисов заключается в упрощении операций при сохранении высокой надежности и эластичности. Учет специфических ограничений облачной среды, таких как лимиты скорости S3 и ограничения частоты вызовов OpenAPI, критически важен для полного использования потенциала эластичности и масштабируемости облачных вычислений.
Осмотрительное внедрение функций: Хотя постоянное добавление новых функций на ранних этапах развития продукта может казаться привлекательным способом привлечения клиентов, приоритет следует отдавать решению реальных болевых точек пользователей. Поддержание опережения примерно в шесть месяцев для функций open-source продукта по сравнению с SaaS-версией является хорошим компромиссом. Это опережение гарантирует, что такие функции пройдут тщательное тестирование и улучшение, прежде чем будут выведены для предоставления сервиса.
Устанавливайте соответствующие ограничения: Ни один продукт не безупречен. Возьмем, к примеру, S3. Несмотря на его лаконичный интерфейс и глубокую проработку, разработчики могут максимально раскрыть его ценность только в определенных ситуациях. В отличие от свободы, которой обладают open-source продукты, SaaS-продукты требуют более строгих ограничений, чтобы защищать себя. Эти ограничения являются неотъемлемой частью продукта и служат руководством и обучением для пользователей. Разумные ограничения могут направлять пользователей к более грамотному использованию продукта, повышая общую ценность и пользовательский опыт.
Выбор облачно-независимых сервисов-зависимостей: Рассмотрение возможности внедрения облачно-независимых сервисов-зависимостей, таких как управляемые сервисы S3, EC2 и K8s, которые широко доступны на основных облачных платформах, может дать существенные преимущества с точки зрения снижения затрат и упрощения сложностей мультиоблачного внедрения. В качестве альтернативы выбор SaaS-сервисов, которые изначально поддерживают мультиоблачное использование, может упростить процесс. Несмотря на возможные различия в реализации у разных поставщиков облачных услуг, раннее создание слоя адаптации к мультиоблачности может эффективно минимизировать дублирующие усилия по разработке и повысить общую эффективность.
Сосредоточьтесь на Cloud FinOps: В публичном облаке на первый взгляд доступные ресурсы могут неожиданно привести к высоким затратам. Например, до проведения анализа счетов мы еще не предполагали, что стоимость сетевой пропускной способности ALB может составлять значительную часть общих расходов. Чтобы оптимизировать затраты и максимально повысить производительность, крайне важно тщательно понимать производительность различных типов инстансов и сервисов. Например, каждый облачный диск GP3 предлагает 3000 IOPS; объединение нескольких дисков на одной машине и настройка RAID позволяют существенно увеличить пропускную способность диска, тем самым избегая крупных счетов за дополнительные IOPS.
Осознайте значимость Open API: По мере роста внедрения Agents роль Open API и связанной документации становится все более важной. Традиционные облачные сервисы опираются на веб-консоли и графические интерфейсы для предоставления функциональности, но будущие взаимодействие и интеграция облачных сервисов будут все больше зависеть от OpenAPI. Уровень автоматизации сервисов, дружественность к Agent и наблюдаемость стали ключевыми критериями оценки будущих облачных сервисов.
Эпилог
Оглядываясь на последние 18 месяцев, мы прошли исключительно захватывающий и сложный путь, на котором время, казалось, шло втрое быстрее. Этот быстрый прогресс можно объяснить несколькими ключевыми факторами: во-первых, появление LLMs резко повысило нашу эффективность в написании кода. Во-вторых, быстрое и единодушное признание пользователями ценности сценариев использования RAG стало основным сценарием применения векторного поиска для привлечения новых пользователей. Наконец, мы должны поблагодарить всех поставщиков open-source, SaaS и облачных сервисов, от которых мы зависим; их исключительные сервисы помогли ускорить этот путь.
Мы особенно благодарны преданным пользователям Zilliz Cloud и Milvus. Ваши тщательные и терпеливые отзывы дали нам бесценные советы и ориентиры. Будь то в сферах SaaS или Serverless, мы твердо верим, что все, что мы сделали, — это лишь начало. Стремление к экономической эффективности, производительности, масштабируемости и удобству для пользователей не знает границ.
Благодарности
Я хочу выразить искреннюю благодарность нашим преданным пользователям, чья поддержка сыграла важнейшую роль в развитии Zilliz Cloud. Ваша поддержка была крайне важна для того, чтобы мы могли поделиться нашим путем создания Zilliz Cloud, предложив идеи, которые могут быть полезны другим, кто хочет развивать свой облачный сервис. Особое признание — 300+ участникам сообщества Milvus за их неустанную работу и нашему CEO, Charles, за его неизменную поддержку наших инновационных технических инициатив.
Если вы заинтересованы в изучении сервисов векторного поиска, мы приглашаем вас зарегистрироваться в Zilliz Cloud. Новые пользователи получат $100 бесплатных кредитов для начала работы.
Читать далее
Zilliz Cloud Audit Logs Goes GA: Security, Compliance, and Transparency at Scale
Zilliz Cloud Audit Logs are now GA, giving enterprises real-time visibility, compliance-ready trails, and stronger security across AWS, GCP, and Azure.
Why Context Engineering Is Becoming the Full Stack of AI Agents
Discover how context engineering unifies prompts, RAG, and tools to build smarter, production-ready AI agents powered by Milvus.
Announcing the General Availability of Zilliz Cloud BYOC on Google Cloud Platform
Zilliz Cloud BYOC on GCP offers enterprise vector search with full data sovereignty and seamless integration.