La ilusión serverless
- Serverless se ha consolidado como una tendencia central en la tecnología cloud.
- Este paradigma permite que los desarrolladores se concentren en la lógica de negocio sin la carga de administrar servidores.
- Modelo de pago: pagas solo por lo que usas y la carga operativa se reduce prácticamente a cero.
- Han aparecido muchas bases de datos serverless, y compiten líderes establecidos como Elastic, Confluent y Pinecone junto con nuevos entrantes como Neon, WarpStream, Upstash y Turbopuffer.
Problemas de las bases de datos serverless actuales
- Muchas bases de datos serverless no son verdaderamente serverless.
- La mayoría de estos servicios se basan en una arquitectura cloud native, que es un diseño innovador para la era de los grupos de servidores.
- Operan clústeres de servidores y, mediante software complejo y la intervención humana, pronostican la carga y gestionan la capacidad.
- Esta ilusión termina causando problemas reales a los usuarios.
Efectos de una arquitectura ineficiente
- La desalineación arquitectónica no es un detalle técnico menor; provoca problemas reales para los usuarios.
- Los usuarios terminan pagando por costos de servidores ociosos, y los clústeres de servidores se mantienen en ejecución para cumplir con objetivos diversos.
- Problemas de escalabilidad: agregar nuevos servidores al clúster tarda varios minutos, por lo que no se pueden manejar picos de tráfico de manera instantánea.
- Elección limitada: al requerir gestión de infraestructura por cada región cloud, las opciones de región para los usuarios quedan restringidas.
Un modelo insostenible
- Las bases de datos serverless basadas en una arquitectura de clústeres de servidores no son sostenibles.
- Los proveedores deben invertir una suma considerable para operar esos clústeres de servidores, y eso puede traducirse en cambios de precios.
- Los usuarios ligeros terminan pagando tarifas desproporcionadas para sostener el sistema, y los usuarios exitosos enfrentan aumentos de precio inesperados.
La necesidad de una arquitectura serverless nativa
- En los inicios de la computación en la nube, la mayoría de las bases de datos de “cloud” eran bases de datos legacy.
- La arquitectura serverless nativa delega toda la gestión de infraestructura al proveedor cloud y utiliza funciones sin estado y servicios serverless en lugar de clústeres de servidores.
- Este enfoque trata la infraestructura cloud como una supercomputadora gigante, lo que habilita escalabilidad inmediata y un modelo de pago auténtico por solicitud.
- Prueba de Litmus: para verificar si una base de datos es verdaderamente serverless nativa, hay que validar que puedas desplegarla en una cuenta cloud sin aprovisionar un clúster de Kubernetes o una VM.
Presentación de LambdaDB
- LambdaDB es un nuevo motor de búsqueda construido como serverless nativo.
- Este sistema funciona como un conjunto de funciones y recursos serverless, separando por completo la lógica de base de datos de la infraestructura.
- Las solicitudes de los usuarios pasan por una puerta de enlace regional y se enrutan a Funciones de Control (Control Functions) o Funciones de Datos (Data Functions) según el tipo de solicitud.
- Funciones enterprise: LambdaDB incluye recuperación de punto en el tiempo y clonación sin copias (zero-copy cloning), sin requerir gestión de infraestructura.
Cómo funciona LambdaDB
- Arquitectura de LambdaDB: todos sus componentes se construyen con servicios cloud serverless.
- El gateway valida la clave API de la solicitud del usuario y enruta la petición a una función de control o a una función de datos.
- Las funciones de control manejan operaciones CRUD y solicitudes de administración de datos, mientras que las funciones de datos realizan las escrituras y lecturas reales.
- Ruta de escritura: la Writer Function registra la solicitud, la guarda en un búfer de escritura serverless persistente y luego responde al cliente.
La paradoja de la eficiencia de costos
- LambdaDB reduce los costos de cómputo frente a bases de datos basadas en clústeres de servidores.
- Aunque el precio unitario de Lambda sea mayor que el de una instancia EC2, el costo se reduce gracias a la redundancia necesaria para garantizar alta disponibilidad y tolerancia a fallas.
- Desperdicio de capacidad fija: la utilización promedio de cómputo en una empresa suele ser solo de 10% a 20%, por lo que el cómputo serverless puede ahorrar entre 50% y 90% de costos.
Rendimiento y escalabilidad
- Rendimiento y escalabilidad: LambdaDB validó su desempeño con una prueba que ingirió millones de vectores de 960 dimensiones.
- Latencia de escritura: con 10 upserts por segundo, la latencia mediana fue de 43 ms y se mantiene en un rango similar incluso cuando el tráfico se incrementa 100 veces.
- Latencia de consulta: la latencia de consulta se mantiene estable bajo distintas cargas, con un percentil 99 entre 172 ms y 210 ms.
- Esfuerzo de optimización: se optimiza de forma continua para mejorar la latencia de las funciones de consulta y, en paralelo, también mejora la infraestructura serverless.
Beneficios para clientes
- Reducción de costos: LambdaDB es más de 10 veces más barato al no tener servidores ociosos.
- Escalabilidad instantánea e ilimitada: LambdaDB puede escalar a miles de funciones paralelas en milisegundos.
- Inicio y escalado simple: permite construir aplicaciones de IA robustas y, a medida que el sistema crece, la arquitectura sigue siendo simple y eficiente en costos.
- Funciones enterprise: ofrece funcionalidades como recuperación de punto en el tiempo y clonación sin copias, sin complejidad ni costos extra.
Planes futuros y visión
- LambdaDB ya maneja cientos de millones de documentos y procesa millones de solicitudes cada día.
- Plan a largo plazo: planea soportar otros modelos de datos (relacional, stream, clave-valor, grafo, entre otros).
5 comentarios
La idea es buena, pero para reducir la latencia de consulta se necesita necesariamente estado. En comparación con MySQL, PostgreSQL, etc., el tiempo de latencia de consulta parece ser casi 100 veces mayor. Es casi como escribir y leer en el sistema de archivos.
Muchas gracias por sus buenos comentarios. El punto que mencionó sobre que se necesita
statepara reducir la latencia acierta exactamente el trade-off central de nuestra arquitectura.En primer lugar, con respecto a la latencia de consulta, en nuestros benchmarks el p99 (percentil 99) está alrededor de 130-210 ms. Supongo que cuando comentó que la diferencia era de 100 veces, probablemente se refería al peor caso mencionado en el texto: que durante un cold start puede tardar unos segundos. Como bien señaló, esta parte es claramente una desventaja de nuestra arquitectura, y como se indica en el texto, sucede en producción en menos del 0.01% (P99.99). En la mayoría del resto de consultas, el diseño aprovecha la memoria local y el disco de cada Lambda como caché para ofrecer un rendimiento estable.
Por ello, como usted indicó, puede que esta arquitectura no sea adecuada para sistemas de transacciones financieras de latencia ultrabaja, donde se deba garantizar que todas las consultas sean inferiores a 10 ms. Sin embargo, en la mayoría de las aplicaciones de búsqueda y recomendación basadas en IA, una latencia de 100-200 ms en P99 se considera un rendimiento suficientemente bueno, y creo que la ventaja de reducir en más de un 90% los costos de infraestructura y la carga operativa es mucho mayor.
Gracias de nuevo por su comentario tan detallado.
Como usted dijo, más que una base de datos universal, parece que sería una solución que podría utilizarse como "verdadero" serverless en situaciones específicas.
¡No esperaba que fuera a contestar en coreano! (¡Lo escribí demasiado cínico...)
Al principio pensé que era una idea revolucionaria. De hecho, el mayor problema de las DB serverless era que había un servidor real funcionando en un lugar donde eso no se veía. Cuando el tráfico se concentra, se produce una situación de caída hasta que se asigna ese servidor (más o menos 5 minutos). Por eso, las DB serverless existentes en la nube (AWS, etc.) son difíciles de usar a nivel de producción.
Quise probarlo. Pero la razón de mis dudas era que, si lo hacíamos, habría que implementar lógicas binarias de indexación, ordenamiento y demás como las que ya existen en mysql, postgresql; me pregunté qué tan difícil sería rehacer sobre Lambda un proyecto de DB de código abierto confiable. Así fue.
Como es un producto que ustedes están construyendo, espero muchos avances! ¡Muy buenas expectativas!
Sí, muchas gracias por sus buenos comentarios. Tal como mencionó, no es adecuado para casos de uso de RDB y puede entenderse como una posición de motor de búsqueda (Elasticsearch), vectorDB (Pinecone). Internamente también utilizamos Lucene, que ha sido comprobado durante mucho tiempo, para admitir funcionalidades como indexación, ordenación y agregación. ¡Gracias! :)