Rethinking latency-sensitive DynamoDB apps for multicloud, multiregion deployment Todo el proceso de entrega de un anuncio se produce dentro de 200 a 300 milisegundos.Nuestras búsquedas de bases de datos deben completarse en milisegundos de un solo dígito.Con miles de millones de transacciones diarias, la base de datos debe ser rápida, escalable y fiable.Si se reduce, nuestra infraestructura de anuncios deja de funcionar”. – Todd Coleman, cofundador técnico y arquitecto jefe de Yieldmo Todo el proceso de entrega de un anuncio se produce dentro de 200 a 300 milisegundos.Nuestras búsquedas de bases de datos deben completarse en milisegundos de un solo dígito.Con miles de millones de transacciones diarias, la base de datos debe ser rápida, escalable y fiable.Si se reduce, nuestra infraestructura de anuncios deja de funcionar”. – Todd Coleman, cofundador técnico y arquitecto jefe de Yieldmo El negocio de la publicidad en línea de Yieldmo depende del procesamiento de cientos de miles de millones de solicitudes de anuncios diarios con respuestas de latencia subsecundaria. Los servicios de la compañía inicialmente dependían de DynamoDB, que el equipo valoraba por su simplicidad y estabilidad. Sin embargo, los costes de DynamoDB se volvían insostenibles a escala y el equipo necesitaba flexibilidad multicloud a medida que Yieldmo se expandió a nuevas regiones. En un discurso reciente en Todd Coleman, cofundador técnico y arquitecto jefe de Yieldmo, compartió los desafíos técnicos que enfrentaba la compañía y por qué el equipo finalmente avanzó con la API compatible con DynamoDB de ScyllaDB. Cumbre de Monster Scale Puedes ver su conversación completa más abajo o seguir leyendo para un repaso. https://youtu.be/sk0mIiaOwM8?embedable=true LAG = Negocios perdidos Yieldmo es una plataforma de publicidad en línea que conecta a editores y anunciantes en tiempo real como una carga de página. Casi cada solicitud de anuncio desencadena una consulta de base de datos que recupera insights de aprendizaje automático e información de identidad del dispositivo. Ejecutar licitaciones efectivas Ayudar a los socios a decidir si ofrecer Seguir qué anuncios ya han mostrado a un dispositivo para que los anunciantes puedan gestionar los límites de frecuencia y optimizar la entrega de anuncios Todo el canal de anuncios se completa en tan solo 200 a 300 milisegundos, con la mayor parte de ese tiempo consumido por los socios evaluando y colocando ofertas. Cuando un usuario visita un sitio web, se envía una solicitud de anuncio a Yieldmo. La plataforma de Yieldmo analiza la solicitud. Solicita anuncios potenciales de sus socios. Se lleva a cabo una subasta para determinar la oferta ganadora. La búsqueda de la base de datos debe ocurrir antes de cualquier llamada a los socios. Y estas búsquedas deben completarse con latencias de milisegundos de un solo dígito. Coleman explicó: “Con miles de millones de transacciones diarias, la base de datos debe ser rápida, escalable y confiable. DynamoDB crece dolor La infraestructura de producción de Yieldmo se ejecuta en AWS, por lo que DynamoDB fue una elección lógica a medida que el equipo construyó su aplicación. En primer lugar, DynamoDB se estaba volviendo cada vez más caro a medida que el negocio se expandía.En segundo lugar, la compañía quería la opción de ejecutar servidores de anuncios en proveedores de nube más allá de AWS. Coleman compartió: “En algunas regiones, por ejemplo, los centros de datos de la Costa Este de Estados Unidos, AWS y GCP [Google Cloud Platform] están lo suficientemente cerca que la latencia es mínima. Allí, no hay problema en llegar a nuestra base de datos DynamoDB desde un servidor de anuncios que ejecuta en GCP. Sin embargo, cuando intentamos lanzar un clúster de anuncios basado en GCP en Ámsterdam mientras accedíamos a DynamoDB en Dublín, la latencia era demasiado alta. Alternativas de DynamoDB El equipo de Yieldmo comenzó a explorar alternativas a DynamoDB que se ajustaran a sus cargas de trabajo de bases de datos extremadamente pesadas de lectura. Un flujo continuo de datos en tiempo real de sus socios, esencial para combinar los datos de Yieldmo con los de sus socios. Actualizaciones de lotes impulsadas por conocimientos de aprendizaje automático derivados de sus datos históricos Dado este equilibrio de lecturas de alta frecuencia y escritos estructurados, estaban buscando una base de datos que pudiera manejar acceso a gran escala, de baja latencia, al tiempo que gestionaba eficientemente las actualizaciones simultáneas sin degradación en el rendimiento. El equipo primero consideró permanecer con DynamoDB y agregar una capa de caché. Sin embargo, encontraron que el caché no podía solucionar el problema de latencia geográfica y las omisiones de caché serían aún más lentas con esta opción. También exploraron Aerospike, que ofreció soporte de velocidad y cross-cloud. sin embargo, aprendieron que la indexación en memoria de Aerospike habría requerido un clúster prohibitivamente grande y caro para manejar el gran número de objetos de datos pequeños de Yieldmo. Luego descubrieron ScyllaDB, que también proporcionó soporte de velocidad y cross-cloud, pero con una API compatible con DynamoDB (Alternator) y costes más bajos. Coleman compartió, “ScyllaDB soportaba las implementaciones en la nube, requería un número de servidores gestionables y ofrecía costes competitivos. Lo mejor de todo, su API era compatible con DynamoDB, lo que significa que podíamos migrar con cambios mínimos en el código. Evaluación, migración y resultados de ScyllaDB Para comenzar a evaluar cómo funcionaba ScyllaDB en su entorno, el equipo migró un subconjunto de servidores de anuncios en una sola región. Esto implicaba migrar varios terabytes mientras mantenía actualizaciones en tiempo real. Procesalmente, tenían la herramienta de migración basada en Spark de ScyllaDB para copiar datos históricos, paralizaron los trabajos de lotes de ML y aprovecharon su arquitectura Kafka para reproducir los escritos recientes en ScyllaDB. Movimiento de una sola tabla DynamoDB con ~28 mil millones de objetos (~3,3 TB) tomó aproximadamente 10 horas. El siguiente paso fue migrar todos los datos a través de cinco regiones de AWS. Esta fase tomó aproximadamente dos semanas.Después de evaluar el rendimiento, Yieldmo promovió ScyllaDB al estado primario y finalmente dejó de escribir a DynamoDB en la mayoría de las regiones. Reflexionando sobre la migración casi un año después, Coleman resumió: “El mayor beneficio es la flexibilidad multicloud, pero incluso sin eso, la migración valía la pena. Los costos de la base de datos se redujeron aproximadamente a la mitad en comparación con DynamoDB, incluso con el precio de la capacidad reservada, y hemos visto mejoras modestas en la latencia. ScyllaDB ha demostrado ser fiable: su equipo monitora nuestros clusters, nos alerta de problemas y nos asesora sobre la escalación. Cómo ScyllaDB se compara con DynamoDB
