Construyendo Zilliz Cloud en 18 meses: lecciones aprendidas al crear un servicio escalable de búsqueda vectorial en la nube pública
Prefacio
Las bases de datos vectoriales han surgido como una tendencia líder en la industria de las bases de datos en 2023. Esta publicación detalla la creación de Zilliz Cloud, un servicio totalmente gestionado impulsado por Milvus, la base de datos vectorial de código abierto más adoptada, desarrollada desde cero durante dieciocho meses. A lo largo de este tiempo, desarrollamos un servicio en la nube integral desde cero y afrontamos un aumento de diez veces en el tráfico, impulsado por la rápida expansión de los Large Language Models (LLM). Esta retrospectiva se centra en compartir las decisiones críticas de diseño y los conocimientos invaluables adquiridos durante nuestro recorrido.
Zilliz Cloud Dedicated Cluster - Comienza el viaje
Retrocediendo el reloj hasta mayo de 2022, la base de datos vectorial de código abierto Milvus 2.0 finalmente comenzó a estabilizarse después de varias iteraciones importantes. A través de conversaciones con nuestros usuarios, la necesidad de una versión estable y alojada comercialmente surgió como una solicitud recurrente. Para Zilliz, la empresa comercial detrás de Milvus, el momento parecía perfecto para emprender la comercialización: teníamos un equipo experimentado de ingenieros, un producto en proceso de maduración y una base de usuarios dedicada con necesidades urgentes. Con esto en mente, establecimos un objetivo ambicioso: lanzar nuestro producto en un plazo de seis meses.
Al iniciar el proyecto, evaluamos nuestras capacidades y objetivos actuales:
- Nuestra tecnología principal, una base de datos vectorial de código abierto y nativa de la nube diseñada con desagregación de almacenamiento y cómputo y un marco de microservicios, está concebida para una integración fluida en un clúster de Kubernetes (K8s). Este marco nativo de la nube nos permite adaptarnos rápidamente a entornos de producción en la nube.
Figura 1: Arquitectura de Milvus
Debido a que utilizamos Kubernetes Operator, estábamos equipados para desplegar rápidamente servicios en las principales plataformas de nube pública, como AWS y GCP; esto fue confirmado por varios usuarios que han implementado con éxito sus servicios de producción en la nube pública.
Nuestra plataforma incluía funciones básicas de observabilidad, como monitorización y registro, pero necesitaba funciones cruciales de alertas para producción.
Además de los elementos mencionados anteriormente, como servicio, nos faltaban varios componentes críticos, incluidos, entre otros, autenticación de inicio de sesión de usuarios, medición y facturación, mecanismos de pago, redes, seguridad, una consola web, soporte para OpenAPI, programación de recursos y gestión de flujos de trabajo.
Determinar qué módulos esenciales construir en seis meses planteaba una tarea formidable. En respuesta, realizamos una autoevaluación crítica: ¿Cómo podríamos aprovechar los recursos disponibles de la manera más eficiente? ¿Podríamos sintetizar nuestro enfoque para crear una versión ligera pero totalmente funcional? Estas preguntas decisivas guiaron nuestra reflexión y, en última instancia, dieron forma a un conjunto de principios fundamentales de diseño:
Maximizar el uso de productos maduros de terceros para evitar reinventar la rueda:
Haciendo hincapié en una rápida preparación para el mercado, nos apoyamos estratégicamente en servicios en la nube y de terceros ya establecidos. Aprovechamos los servicios principales de AWS, como EKS, EC2, S3, EBS y ALB, junto con Kafka y RDS gestionados por AWS como columna vertebral de nuestra infraestructura. Este enfoque no solo facilitó nuestras necesidades inmediatas, sino que también reveló que dichos componentes ofrecen una vía rentable para una futura adaptación a un entorno multinube, acelerando así nuestro ritmo de innovación. Ante los problemas de compatibilidad entre las colas de mensajería de GCP/Azure y los servicios gestionados de Kafka, desarrollamos nuestro sistema de registro distribuido, basado en Apache Bookkeeper. La falta de soluciones de registro distribuido fiables, de código abierto o nativas de la nube impulsó este esfuerzo. Motivados por esta brecha, estamos considerando publicar nuestra solución como código abierto, con la esperanza de que ayude a otros a crear servicios en la nube.
Los proveedores SaaS de terceros fueron fundamentales para acelerar el desarrollo de nuestra plataforma. Por ejemplo, adoptamos Stripe para gestionar nuestro procesamiento de pagos, abordando complejos requisitos de medición y tributación. Para facilitar las conexiones con marketplaces multicloud, integramos Sugar.io. Además, evaluamos plataformas de servicios de facturación como Orb y Metronome para mejorar nuestras operaciones de facturación. Auth0 fue nuestro producto elegido para la gestión de cuentas y la funcionalidad de inicio de sesión; ampliamos aún más nuestra funcionalidad de autenticación e inicio de sesión para incluir soporte de inicio de sesión con Google. Establecimos nuestro sistema de alertas operativas en PagerDuty, seleccionado por su ágil integración con nuestras herramientas de monitoreo existentes y su versatilidad para personalizar reglas de notificación.
Las entidades no deben multiplicarse innecesariamente
Guiados por la filosofía de la navaja de Occam, adoptamos un enfoque de diseño minimalista que se manifestó en diversos aspectos del producto:
Simplicidad de la arquitectura: Inicialmente, nuestro diseño incluía más de 60 microservicios, lo que planteaba desafíos significativos en la coordinación del desarrollo y las pruebas. Para simplificar nuestra arquitectura, redujimos el número a menos de diez microservicios principales, incluidos user, billing, CloudService, resources, metadata y scheduling. Esta reducción aclaró las dependencias y redujo la carga de pruebas.
Simplicidad funcional: En su iteración inicial, el énfasis de Zilliz Cloud se puso en funcionalidades principales para el usuario, como el registro, el despliegue de clústeres y la facturación, mientras que deliberadamente pospusimos funciones menos urgentes como el escalado y las copias de seguridad para aliviar la carga de trabajo. Fue notable nuestro compromiso de establecer un ciclo de retroalimentación sólido, facilitando inicialmente la retroalimentación por correo electrónico y posteriormente aumentándola con la integración de Zendesk para garantizar que una retroalimentación rápida y de alta calidad pudiera guiarnos en futuras mejoras.
Simplicidad de diseño: Nuestro diseño de servicio en la nube priorizó la comunicación eficiente y el potencial de interacción con los usuarios, lo que requería un enfoque disciplinado y centrado. Aprovechar las pruebas A/B rápidas nos permitió validar funciones con rapidez y adaptarnos en función de las métricas de interacción de los usuarios.
Anticipa los desafíos del día 2 desde el día 1:
En el dinámico panorama de los servicios en la nube, la capacidad de evolucionar rápidamente sin sacrificar la fiabilidad de las interfaces de usuario y los servicios es primordial. Esta intrincada maniobra se asemeja a "cambiar los motores del avión en pleno vuelo." Para el observador externo, el servicio funciona sin problemas mientras internamente se desarrolla un vigoroso ciclo de innovación y mejora. Adoptar un enfoque de desarrollo con el fin en mente es crucial.
Soporte multicloud: Inicialmente centrados en AWS, nuestro enfoque siempre ha priorizado la independencia de la nube. Evaluamos exhaustivamente proveedores como GCP y Alibaba Cloud para garantizar la compatibilidad entre nubes públicas. Mediante personalizaciones al proyecto de código abierto Crossplane, desarrollamos una capa de 'adaptador de nube', reduciendo los costos asociados con el soporte multicloud. Este diseño facilitó una integración rápida con GCP en solo un mes y simplificó la integración con otros proveedores de nube pública.
Seguridad: Aunque los desarrolladores de aplicaciones AIGC pueden priorizar algo distinto de la seguridad, Zilliz Cloud Services otorga la máxima importancia a la seguridad de los datos. Cumpliendo estrictamente con los estándares de IAM en la nube, controlamos meticulosamente los permisos de acceso a los datos y empleamos cifrado para todos los datos, tanto en tránsito como en reposo. Al enfatizar el aislamiento de red para un rendimiento óptimo, seleccionamos los complementos de red EKS de AWS por su eficiencia y facilidad de uso. Delimitar las fronteras de interacción entre las capas de datos y control ha dado lugar a importantes ahorros de costos durante el lanzamiento de nuestro producto BYOC.
Agrupación de recursos: Zilliz Cloud Services adopta la "ley de conmutatividad de la nube", priorizando la escalabilidad elástica mediante la agrupación de recursos. Al separar el almacenamiento y la computación y emplear balanceo de carga dinámico, garantizamos una utilización eficiente de los recursos en la nube. Este enfoque nos permite reservar recursos solo cuando es necesario, mejorando significativamente la utilización de Spot Instances y funciones Lambda, al tiempo que reduce los costos.
Compatible con operaciones: Zilliz Cloud está diseñado pensando en los desarrolladores y el personal operativo, a diferencia de otras bases de datos vectoriales. Con una GUI completa y capacidades de monitoreo sofisticadas, la plataforma ofrece recuperación ante desastres en triple AZ y cumple con SLA estrictos, lo que garantiza estabilidad y fiabilidad para entornos de producción.
Guiados por nuestras filosofías de diseño centrales, logramos el hito de lanzar nuestro producto comercial de búsqueda vectorial en solo seis meses, asegurando nuestro grupo inicial de clientes semilla en el proceso. A continuación, encontrarás el diagrama arquitectónico de nuestro lanzamiento inaugural.
Figura 2- Arquitectura de Zilliz Cloud
Serverless: De $300 a $5 en costo de adquisición de nuevos usuarios
El crecimiento a menudo ocurre en momentos inesperados. Después de experimentar un crecimiento constante en nuestros servicios SaaS durante tres meses, el crecimiento de Zilliz Cloud, impulsado por la popularidad explosiva de AutoGPT, alcanzó un punto álgido. Ver las bases de datos vectoriales como memoria a largo plazo para los modelos de lenguaje grandes fue ganando aceptación gradualmente, lo que llevó a un rápido aumento de la base de usuarios de Zilliz, con el número de nuevos clústeres agregados diariamente alcanzando rápidamente los cientos.
Sin embargo, este crecimiento trajo dos desafíos principales para Zilliz: estabilidad y costo. Aunque siempre nos centramos en la escalabilidad, los picos repentinos de alto tráfico casi paralizaron todos nuestros servicios, y solo la base de datos central salió ilesa. Las APIs proporcionadas por los proveedores de servicios en la nube fueron limitadas, y nuestro sistema de almacenamiento de registros, Loki, se llenó dos veces en solo unos días, obligando a interrumpir muchos servicios debido a la falta de recursos.
Además, la estrategia inicial de prueba gratuita adoptada por Zilliz Cloud, que ofrecía $300 Credits a los nuevos usuarios para experimentar todas las funciones, provocó un fuerte aumento de los costos a medida que crecía el número de usuarios (la mayoría de los cuales estaban probando el servicio), obligándonos a replantearnos nuestro modelo de negocio. Estos puntos críticos nos impulsaron a lanzar Zilliz Cloud Serverless, un producto más flexible, con una barrera de entrada más baja y más adecuado para usuarios de AIGC que recién comienzan su recorrido con las bases de datos vectoriales.
El Santo Grial sigue ahí fuera: dominar la escalabilidad, el costo y la latencia para el desarrollo de aplicaciones RAG
Para el caso de uso de Retrieval-Augmented Generation (RAG) , la solución ideal de nivel gratuito debe considerar lo siguiente:
Figura 3: Dominando la escalabilidad, el costo y la latencia en aplicaciones RAG
Escalabilidad — Esto abarca dos aspectos clave:
A nivel de inquilino individual, el sistema debe escalar dinámicamente para procesar datos de manera efectiva. Esta escalabilidad dinámica requiere que la base de datos vectorial sea lo suficientemente versátil como para ajustarse a los volúmenes de datos fluctuantes de diferentes inquilinos, ya sea que procesen conjuntos de datos pequeños o grandes. Deben mantenerse tiempos de respuesta de consulta consistentemente estables, independientemente del tamaño de los datos que se estén manejando.
Al gestionar muchos inquilinos, el sistema debe admitir de manera eficiente la escalabilidad de hasta millones de inquilinos. Específicamente, debe diferenciar y adaptarse de forma inteligente a los patrones de uso 'hot' (altamente activos) y 'cold' (menos activos), garantizando una asignación óptima de recursos y una consistencia de rendimiento en todos los ámbitos.
Costo — El control de costos para el nivel gratuito es crucial. Idealmente, el costo debería mantenerse por debajo de $1, proporcionando al mismo tiempo recursos suficientes para admitir 1 millón de vectores de 768 dimensiones. Sin embargo, al depender de la indexación vectorial en memoria, el precio de gestionar 1 millón de vectores de 768 dimensiones puede superar fácilmente los $10. Si bien este costo puede ser aceptable para empresas SaaS orientadas a servicios empresariales, es excesivo para aplicaciones ToC dirigidas al consumidor.
Baja latencia — Aunque los casos de uso de RAG pueden no ser tan sensibles a la latencia como los dominios de búsqueda y recomendación, el rendimiento de la recuperación vectorial impacta significativamente en el "Time-to-first-token." Por lo tanto, mantener una baja latencia es crucial para mejorar la experiencia del usuario y la capacidad de respuesta del sistema.
La oferta inicial de Zilliz Cloud demostró una escalabilidad sobresaliente para manejar grandes volúmenes de datos y lograr baja latencia, superando las expectativas de los usuarios. Incluso con la gestión de numerosos inquilinos y el control de costos, la solución de clúster dedicado no llegó a satisfacer plenamente las demandas de los usuarios. Para remediarlo, desarrollamos el 'Zilliz Serverless Tier,' un modelo de servicio diseñado específicamente para reducir la barrera de entrada para usuarios individuales de AIGC. Este nivel ofrece las soluciones de almacenamiento más rentables y escalabilidad para abordar eficazmente los desafíos mencionados anteriormente.
La arquitectura serverless de Zilliz Cloud
Figura 4- La arquitectura serverless de Zilliz Cloud
Zilliz Cloud Serverless introduce el concepto de clústeres lógicos, donde cada clúster lógico corresponde a una base de datos en un clúster físico. Logramos el aislamiento lógico para todos los inquilinos dentro de un único clúster físico mediante mecanismos de autenticación basados en base de datos y clave API. Durante las consultas, el sistema enruta las solicitudes basándose en claves API para determinar los datos a los que los usuarios necesitan acceder, utilizando nodos proxy para el enrutamiento.
Las operaciones de escritura de datos se envían inicialmente a un grupo de nodos de registro, que luego escriben los datos en un servicio de Write-Ahead Logging (WAL), reorganizando periódicamente los datos y volcándolos al almacenamiento de objetos. CompactionService es un servicio de agrupación responsable de consolidar segmentos de datos más pequeños en otros más grandes y purgar entradas eliminadas, optimizando el espacio de almacenamiento y la velocidad de acceso. El Index Service es responsable de crear índices sobre datos sin procesar, que luego son cargados por los nodos de consulta para garantizar la eficiencia de las consultas.
Durante las operaciones de consulta, nuestra estrategia consiste en almacenar en caché todos los datos en los discos locales de los Query Nodes y ejecutar el intercambio de memoria a disco localmente. Esta metodología reduce significativamente los costos de almacenamiento para los usuarios Serverless en más de diez veces en comparación con la indexación basada en memoria. Sin embargo, un desafío principal reside en gestionar eficazmente los recursos para evitar la sobrecarga de los nodos de consulta causada por problemas de puntos calientes de inquilinos y vecinos ruidosos. Esto es particularmente crucial, ya que cada Query Node debe manejar la carga de datos de múltiples inquilinos.
Para mejorar la estabilidad del sistema, hemos introducido los siguientes tres mecanismos importantes:
Cuota distribuida: Este mecanismo, basado en un servicio de cuotas centralizado, asigna dinámicamente cuotas de recursos y las ajusta en función de la carga de los nodos de consulta. Esta asignación dinámica ayuda a garantizar un consumo justo de recursos para cada inquilino.
Cuota distribuida: Este mecanismo, basado en un servicio de cuotas centralizado, asigna dinámicamente cuotas de recursos y las ajusta en función de la carga de los nodos de consulta. Esto ayuda a garantizar un consumo justo de recursos para cada inquilino.
Escalado dinámico de recursos basado en métricas: Hemos incorporado un módulo Cloud Resource Scheduler, que gestiona de forma integral la memoria, el disco, las cargas de CPU y las colas de solicitudes. Permite el escalado dinámico de los recursos físicos para satisfacer demandas de recursos variables en diferentes escenarios.
Programación multinivel: Hemos establecido un marco de programación de recursos que opera en varios niveles, abarcando el aislamiento físico mediante la agrupación de recursos, el equilibrio de carga dentro de estos grupos de recursos y la gestión de colas de consultas y la programación de caché a nivel de nodo. Este enfoque garantiza una asignación equitativa de recursos entre múltiples inquilinos, al tiempo que mitiga el riesgo de que un solo inquilino monopolice los recursos.
A través de nuestro servicio Serverless, hemos reducido con éxito el costo de prueba para usuarios individuales a $5, apoyando a decenas de miles de desarrolladores de AIGC. En el próximo lanzamiento de Zilliz Cloud, estamos mejorando aún más nuestra solución Serverless para que sea todavía más rentable y elástica. En esta nueva versión, cada usuario de Serverless podrá manejar datos de millones de inquilinos en una sola colección, logrando aislamiento de datos y reduciendo significativamente los costos de almacenamiento por un factor de diez en comparación con la solución actual. Continuaremos profundizando en los detalles técnicos de Zilliz Cloud Serverless en futuros artículos.
Seis lecciones que aprendimos al crear un servicio en la nube a partir de una VectorDB de código abierto
Reconocer las limitaciones de la nube: Incluso con sistemas nativos de la nube como Milvus, la transición a SaaS en la nube plantea desafíos significativos. Va más allá de una simple implementación en EC2 y EBS. En el ámbito de las bases de datos de código abierto, los usuarios deben poseer una comprensión profunda de las complejidades del producto para lograr escalado horizontal, recuperación ante fallos y optimización del rendimiento mediante un ajuste meticuloso de parámetros. El verdadero desafío con los servicios en la nube reside en optimizar las operaciones mientras se mantiene una alta fiabilidad y elasticidad. Abordar restricciones específicas del entorno de la nube, como los límites de tasa de S3 y las limitaciones en la frecuencia de llamadas a OpenAPI, es crucial para capitalizar plenamente el potencial de elasticidad y escalabilidad de la computación en la nube.
Implementación prudente de funciones: Aunque añadir continuamente nuevas funciones en las primeras etapas del producto puede parecer tentador para atraer clientes, se debe priorizar abordar los verdaderos puntos de dolor de los usuarios. Mantener un plazo de aproximadamente seis meses para las funciones del producto de código abierto antes de la versión SaaS es un buen compromiso. Este plazo garantiza que estas funciones se sometan a pruebas y mejoras exhaustivas antes de implementarse para la prestación del servicio.
Establecer límites adecuados: Ningún producto es perfecto. Tomemos S3, por ejemplo. A pesar de su interfaz elegante y su amplio refinamiento, los desarrolladores solo pueden maximizar su valor en determinadas situaciones. A diferencia de la libertad que tienen los productos de código abierto, los productos SaaS requieren restricciones más estrictas para protegerse. Estas restricciones forman una parte integral del producto y sirven como orientación y educación para los usuarios. Las limitaciones razonables pueden guiar a los usuarios hacia un uso más inteligente del producto, mejorando el valor general y la experiencia del usuario.
Optar por servicios de dependencia agnósticos de la nube: Considerar la adopción de servicios de dependencia agnósticos de la nube como S3, EC2 y servicios gestionados de K8s, que están ampliamente disponibles en las principales plataformas en la nube, puede ofrecer beneficios sustanciales en términos de reducción de costos y simplificación de las complejidades de la adopción multinube. Alternativamente, optar por servicios SaaS que admitan de forma inherente el uso multinube puede agilizar el proceso. A pesar de las posibles variaciones en la implementación entre diferentes proveedores de servicios en la nube, el establecimiento temprano de una capa de adaptación multinube puede minimizar eficazmente los esfuerzos de desarrollo redundantes y mejorar la eficiencia general.
Céntrate en Cloud FinOps: En la nube pública, los recursos aparentemente asequibles pueden traducirse inesperadamente en costes elevados. Por ejemplo, antes de realizar un análisis de facturación, aún no habíamos previsto que los costes de ancho de banda de red de ALB pudieran constituir una parte significativa de los gastos generales. Para optimizar costes y maximizar las optimizaciones de rendimiento, es esencial comprender a fondo el rendimiento de los distintos tipos de instancias y servicios. Por ejemplo, cada disco en la nube GP3 ofrece 3000 IOPS; agrupar varios discos en una sola máquina y configurar RAID permite aumentar sustancialmente el rendimiento del disco, evitando así facturas elevadas por IOPS adicionales.
Reconoce la importancia de Open API: Con la creciente adopción de los Agents, el papel de Open API y la documentación relacionada se vuelve cada vez más importante. Los servicios en la nube tradicionales dependen de consolas web e interfaces gráficas para ofrecer funcionalidad, pero la futura interacción e integración de los servicios en la nube dependerá cada vez más de OpenAPI. El nivel de automatización del servicio, la compatibilidad con Agents y la observabilidad se han convertido en criterios de evaluación fundamentales para los futuros servicios en la nube.
Epílogo
Al mirar atrás a los últimos 18 meses, nos hemos embarcado en un viaje excepcionalmente emocionante y desafiante, en el que el tiempo parecía pasar al triple de velocidad. Este rápido progreso puede atribuirse a varios factores clave: En primer lugar, la llegada de los LLMs ha mejorado drásticamente nuestra eficiencia de codificación. En segundo lugar, el reconocimiento rápido y unánime por parte de los usuarios del valor de los casos de uso de RAG se ha convertido en el caso de uso principal para que la búsqueda vectorial adquiera nuevos usuarios. Por último, debemos agradecer a todos los proveedores de código abierto, SaaS y servicios en la nube de los que dependemos; sus servicios excepcionales han ayudado a acelerar este viaje.
Debemos un agradecimiento especial a los usuarios leales de Zilliz Cloud y Milvus. Sus comentarios meticulosos y pacientes nos han proporcionado consejos y orientación invaluables. Ya sea en los ámbitos de SaaS o Serverless, creemos firmemente que todo lo que hemos hecho es solo el comienzo. La búsqueda de rentabilidad, rendimiento, escalabilidad y facilidad de uso no conoce límites.
Agradecimientos
Quiero expresar un sincero agradecimiento a nuestros dedicados usuarios, cuyo apoyo ha sido fundamental en el desarrollo de Zilliz Cloud. Su ánimo ha sido crucial para compartir nuestro recorrido para construir Zilliz Cloud, ofreciendo perspectivas que pueden beneficiar a otros que quieren desarrollar su servicio en la nube. Un reconocimiento especial para los más de 300 colaboradores de la comunidad de Milvus por su incansable trabajo y a nuestro CEO, Charles, por su apoyo inquebrantable a nuestros innovadores esfuerzos técnicos.
Si te interesa explorar servicios de búsqueda vectorial, te invitamos a registrarte en Zilliz Cloud. Los nuevos registrados recibirán $100 en créditos gratuitos para comenzar.
Sigue leyendo
How to Improve Retrieval Quality for Japanese Text with Sudachi, Milvus/Zilliz, and AWS Bedrock
Learn how Sudachi normalization and Milvus/Zilliz hybrid search improve Japanese RAG accuracy with BM25 + vector fusion, AWS Bedrock embeddings, and practical code examples.
Data Deduplication at Trillion Scale: How to Solve the Biggest Bottleneck of LLM Training
Explore how MinHash LSH and Milvus handle data deduplication at the trillion-scale level, solving key bottlenecks in LLM training for improved AI model performance.
Selecting the Right ETL Tools for Unstructured Data to Prepare for AI
Learn the right ETL tools for unstructured data to power AI. Explore key challenges, tool comparisons, and integrations with Milvus for vector search.