- Stripe mantuvo un 99.999% de disponibilidad mientras procesaba un volumen total de pagos de 1 billón de dólares en 2023
- El equipo de infraestructura de bases de datos de Stripe ofrece DocDB, una base de datos como servicio (DBaaS), como capa base de su API
- DocDB es una versión extendida de MongoDB Community, compuesta por varios servicios construidos internamente en Stripe
- Procesa más de 5 millones de consultas por segundo y almacena datos financieros críticos a escala de petabytes distribuidos en más de 2,000 shards de base de datos y más de 5,000 colecciones
- Stripe eligió MongoDB Community por la flexibilidad de su modelo documental y su capacidad para procesar datos en tiempo real a gran escala
- En 2011, MongoDB Atlas aún no existía, así que construyeron un clúster autogestionado de instancias de MongoDB ejecutándose en la nube
- El núcleo de DocDB es la Data Movement Platform
- Originalmente fue construida como una solución de escalado horizontal para superar las limitaciones del escalado vertical de MongoDB, pero luego se personalizó para varios propósitos
- Entre ellos, fusionar shards de bases de datos subutilizados para mejorar el aprovechamiento y la eficiencia, hacer actualizaciones mayores del motor de base de datos para aumentar la estabilidad, y migrar de multitenancy a single-tenancy para usuarios grandes
- La Data Movement Platform permite pasar de un pequeño número de shards de gran tamaño a un gran número de shards pequeños
- También permite migraciones transparentes para el cliente y cero tiempo de inactividad, lo que hace posible ofrecer un DBaaS altamente elástico
- DocDB puede dividir shards de base de datos cuando hay picos de tráfico, y cuando el tráfico baja puede consolidar miles de bases de datos mediante bin packing
Cómo construyeron la infraestructura de base de datos
- Cuando Stripe se lanzó en 2011, eligió MongoDB como su base de datos en línea por ofrecer mejor productividad para desarrolladores que una base de datos relacional estándar
- Querían operar sobre MongoDB una infraestructura de base de datos robusta que priorizara la estabilidad de la API, pero no encontraron un DBaaS listo para usar que cumpliera con sus requisitos
- Cumplir con los más altos niveles de disponibilidad, durabilidad y rendimiento
- Exponer el mínimo de funciones de base de datos para evitar problemas autoinfligidos por consultas no optimizadas de las aplicaciones cliente
- Soportar escalabilidad horizontal mediante sharding
- Ofrecer soporte de primera clase para multitenancy con cuotas forzadas
- Proporcionar seguridad sólida mediante la aplicación de políticas de autorización
- La solución fue construir DocDB usando MongoDB como motor de almacenamiento subyacente: un DBaaS verdaderamente elástico y escalable, donde la migración de datos en línea es una pieza central
- Las aplicaciones de producto de Stripe acceden a los datos de la base de datos a través de una flota de servidores proxy de base de datos desarrollados internamente en Go para hacer cumplir confiabilidad, escalabilidad, control de permisos y control de acceso
- Ahí tomaron la decisión arquitectónica clave de usar sharding como mecanismo de escalado horizontal
- Miles de shards de base de datos, cada uno almacenando pequeños fragmentos de datos acumulados, hoy forman la base de todos los productos de Stripe
- Cuando una aplicación envía una consulta al servidor proxy de base de datos, este analiza la consulta, la enruta a uno o más shards, combina los resultados y los devuelve a la aplicación
- El servidor proxy de base de datos depende de un servicio de metadatos de chunks para mapear los chunks a los shards de base de datos, lo que le permite encontrar fácilmente los shards relevantes para una consulta dada
- Los eventos de cambio producidos por escrituras a la base de datos se envían a un sistema de streaming de software y finalmente se almacenan en object storage a través de un pipeline de captura de datos de cambios (CDC)
- El equipo de Stripe aprovisiona, a nivel de las aplicaciones de producto, contenedores lógicos de datos llamados bases de datos lógicas usando un control plane interno de base de datos documental, que incluyen una o más colecciones de DocDB compuestas por documentos con un propósito relacionado
- Los datos de estas colecciones de DocDB se distribuyen en varias bases de datos (bases de datos físicas), cada una almacenando pequeños chunks de la colección
- Las bases de datos físicas de DocDB residen en shards desplegados como replica sets compuestos por un nodo primario y varios nodos secundarios con replicación y failover automático
Cómo diseñaron la Data Movement Platform
- Para construir un producto DBaaS horizontalmente escalable y altamente elástico que pudiera crecer y reducirse según las necesidades de las aplicaciones de producto, necesitaban la capacidad de migrar datos entre shards de base de datos con cero tiempo de inactividad y de una manera transparente para el cliente
- Se trata de un problema complejo de sistemas distribuidos, aún más complicado por los requisitos únicos de los datos financieros críticos
- Consistencia e integridad de los datos: era necesario garantizar que los datos migrados mantuvieran consistencia e integridad tanto en el shard de origen como en el shard de destino
- Disponibilidad: no era aceptable un tiempo de inactividad prolongado durante la migración de datos, porque millones de empresas dependen de Stripe para aceptar pagos de sus clientes las 24 horas del día
- El objetivo era mantener las etapas clave del proceso de migración por debajo del tiempo de failover planificado del primario de la base de datos, que normalmente toma unos pocos segundos, y dentro del presupuesto de reintentos de las aplicaciones de producto
- Granularidad y adaptabilidad: a la escala de Stripe, debía ser posible migrar cualquier número de chunks de datos desde cualquier número de fuentes hacia shards de destino
- No debía haber límite en la cantidad de migraciones de chunks en curso dentro de la flota, ni tampoco en cuántas migraciones podía involucrar un shard específico en un momento dado
- Además, como una parte considerable de los shards contiene datos a escala de terabytes, también debía ser posible migrar chunks de distintos tamaños con alto throughput
- Sin impacto de rendimiento sobre el shard de origen: al migrar chunks de base de datos entre shards, el objetivo era preservar el rendimiento y el throughput del shard de origen para no afectar negativamente el desempeño ni la capacidad disponible para las consultas de los usuarios
- Para resolver estos requisitos, construyeron una plataforma de movimiento de datos que invoca servicios diseñados específicamente para gestionar migraciones de datos en línea entre shards de base de datos
- El componente Coordinator de la plataforma de movimiento de datos se encarga de orquestar las distintas etapas relacionadas con la migración de datos en línea e invoca los servicios correspondientes para ejecutar cada fase descrita a continuación
Paso 1: registrar la migración del chunk
- Primero registran en el servicio de metadatos de chunks la intención de migrar un chunk de base de datos desde un shard de origen hacia cualquier shard de destino
- Después construyen índices en el shard de destino para el chunk que será migrado
Paso 2: importación masiva de datos
- Luego cargan los datos en uno o más shards de base de datos usando un snapshot del chunk del shard de origen en el tiempo T
- El servicio que realiza la importación masiva de datos admite varios filtros de datos e importa solo los chunks que cumplen con los criterios definidos
- Al principio parecía simple, pero enfrentaron límites de throughput al cargar datos de forma masiva en shards de DocDB
- Intentaron agrupar escrituras y ajustar parámetros del motor de DocDB para optimizar la ingesta masiva, pero sin mucho éxito
- Sin embargo, lograron un avance importante al aprovechar que DocDB usa una estructura de datos B-tree para ordenar la información, y buscaron formas de optimizar el orden de inserción
- Al ordenar los datos según el atributo de índice más común de la colección e insertarlos en ese orden, mejoraron mucho la localidad de escritura y aumentaron 10 veces el throughput de escritura
Paso 3: replicación asíncrona
- Después de importar los datos al shard de destino, comienzan a replicar escrituras desde el origen hacia el shard de destino para el chunk migrado a partir del tiempo T
- El sistema de replicación asíncrona lee los cambios producidos por escrituras en el shard de origen desde el sistema CDC y ejecuta las escrituras en el shard de destino
- El operation log, u oplog, es una colección especial de cada shard de DocDB que mantiene un registro de todas las operaciones que modifican datos en la base de datos de ese shard
- El oplog de todos los shards de DocDB se envía a Kafka, una plataforma de event streaming, y luego se conserva en un servicio de cloud object storage como Amazon S3
- Construyeron un servicio que usa los eventos del oplog en Kafka y Amazon S3 para replicar cambios desde uno o más shards DocDB de origen hacia uno o más shards DocDB de destino
- Al depender de los eventos del oplog del sistema CDC, evitan consumir el throughput de lectura disponible para consultas de usuario en el shard de origen, lo que evita degradar la velocidad de las consultas, y además no quedan limitados por el tamaño del oplog del shard de origen
- El servicio también fue diseñado para ser resiliente incluso si el shard de destino no está disponible, y puede iniciar, pausar y reanudar la sincronización desde checkpoints en cualquier momento
- El servicio de replicación también ofrece la capacidad de obtener el lag de replicación
- Los cambios del chunk en migración se replican en ambas direcciones, desde el shard de origen al de destino y viceversa, y el servicio de replicación etiqueta las escrituras que emite para evitar replicación asíncrona circular
- Esta fue una decisión de diseño intencional para dar flexibilidad de revertir el tráfico al shard de origen si surgían problemas al enrutar tráfico al shard de destino
Paso 4: verificación de exactitud
- Una vez que la replicación entre el shard de origen y el shard de destino está sincronizada, verifican de forma exhaustiva la integridad y exactitud de los datos comparando snapshots de un punto en el tiempo
- Esta fue una decisión de diseño tomada intencionalmente para no afectar el throughput de los shards
Paso 5: cambio de tráfico
- Cuando los datos del chunk ya fueron importados del origen al shard de destino y los cambios se están replicando activamente, el cambio de tráfico es orquestado por el Coordinator
- Para redirigir las rutas de lectura y escritura del chunk migrado, primero deben pausar brevemente el tráfico al shard de origen, actualizar la ruta en el servicio de metadatos de chunks y hacer que los servidores proxy redirijan lecturas y escrituras al shard de destino
- El protocolo de cambio de tráfico se basa en la idea de version gating
- En estado estable, cada servidor proxy adjunta un número de token de versión a las solicitudes dirigidas a los shards de DocDB
- Añadieron un parche personalizado a MongoDB para que los shards puedan verificar si el número de token de versión de una solicitud recibida desde el servidor proxy es más nuevo que el número de token de versión que conocen, y procesen solo las solicitudes que cumplen ese criterio
- Para actualizar la ruta del chunk, el Coordinator ejecuta los siguientes pasos:
- Primero incrementa el número de token de versión del shard DocDB de origen. El número de token de versión se almacena en un documento dentro de una colección especial de DocDB, y en ese momento se rechazan todas las lecturas y escrituras del chunk en el shard de origen
- Luego espera a que el servicio de replicación replique las escrituras pendientes desde el shard de origen
- Finalmente, actualiza la ruta del chunk en el servicio de metadatos de chunks para que apunte al shard de destino y al número de token de versión
- Una vez completado esto, los servidores proxy obtienen del servicio de metadatos de chunks la ruta actualizada del chunk y el número de token de versión más reciente
- Los servidores proxy usan la ruta actualizada del chunk para enrutar sus lecturas y escrituras hacia el shard de destino
- Todo el protocolo de cambio de tráfico tarda menos de 2 segundos en ejecutarse, y todas las lecturas y escrituras fallidas que llegaron al shard de origen se completan exitosamente al reintentarse
Paso 6: cancelar el registro de la migración del chunk
- Finalmente, marcan la migración como completada en el servicio de metadatos de chunks y eliminan los datos del chunk del shard de origen, con lo que termina el proceso de migración
Uso de la plataforma de movimiento de datos
- La capacidad de migrar chunks de datos en línea entre shards de DocDB ha ayudado a escalar horizontalmente la infraestructura de bases de datos de Stripe al ritmo de su crecimiento
- Los ingenieros del equipo de infraestructura de bases de datos pueden dividir shards de DocDB con solo hacer clic en un botón, según tamaño y throughput, lo que libera margen de almacenamiento y capacidad de procesamiento para los equipos de producto
- En 2023, usaron la plataforma de movimiento de datos para mejorar el aprovechamiento de la infraestructura de bases de datos
- En concreto, migraron 1.5 petabytes de datos de forma transparente para las aplicaciones de producto para hacer bin-packing de miles de bases de datos subutilizadas y reducir el número total de shards subyacentes de DocDB a aproximadamente tres cuartas partes
- También usaron la plataforma de movimiento de datos para actualizar la flota de infraestructura de bases de datos, haciendo forklift de los datos a una versión posterior de MongoDB en un solo paso, sin pasar por versiones mayores o menores intermedias
- El equipo de infraestructura de bases de datos de Stripe está enfocado en construir una base robusta y confiable que escale al ritmo del crecimiento de la economía de internet
- Actualmente están prototipando un sistema de gestión de temperatura que equilibra los datos proactivamente entre shards según tamaño y throughput, e invirtiendo en autoescalado de shards que responda dinámicamente a cambios en los patrones de tráfico
Aún no hay comentarios.