Prácticas recomendadas para el diseño de tablas globales de DynamoDB

Las tablas globales se crean en la huella global de Amazon DynamoDB para proporcionarle una base de datos totalmente administrada, multirregión y multiactiva que ofrece un rendimiento rápido y local, tanto de lectura como de escritura, para aplicaciones globales de escalado masivo. Con las tablas globales, sus datos se replican automáticamente en las regiones de AWS que elija. Como las tablas globales utilizan las API de DynamoDB existentes, no será necesario realizar ningún cambio en la aplicación. No hay costos iniciales ni compromisos por utilizar las tablas globales y solo pagará por los recursos que utilice.

Temas

• Recomendaciones para el diseño de tablas globales de DynamoDB
• Datos clave sobre el diseño de tablas globales de DynamoDB
• Casos de uso
• Modos de escritura con tablas globales
• Solicitud de enrutamiento con tablas globales
• Evacuación de una región con tablas globales
• Planificación de la capacidad de rendimiento para tablas globales
• Lista de comprobación de preparación para tablas globales y preguntas frecuentes

Recomendaciones para el diseño de tablas globales de DynamoDB

Un uso eficiente de las tablas globales requiere un análisis detenido de factores como su modo de escritura preferido, el modelo de enrutamiento y los procesos de evacuación. Debe instrumentar la aplicación en todas las regiones y estar preparado para ajustar el enrutamiento o realizar una evacuación para mantener el estado global. La recompensa es disponer de un conjunto de datos distribuidos globalmente con lecturas y escrituras de baja latencia y un acuerdo de nivel de servicio del 99,999 %.

Datos clave sobre el diseño de tablas globales de DynamoDB

• Existen dos versiones de las tablas globales: la versión actual versión 2019.11.21 (actual) de las tablas globales (a veces llamada V2) y Versión 2017.11.29 (heredada) de las tablas globales (a veces llamada V1). Esta guía se centra exclusivamente en la versión actual, V2.

• Sin el uso de tablas globales, DynamoDB es un servicio regional. Tiene una alta disponibilidad y es intrínsecamente resistente a los errores de la infraestructura de una región, incluido el error de una zona de disponibilidad (AZ) completa. Una tabla de DynamoDB de una sola región tiene un https://aws.amazon.com/dynamodb/sla/acuerdo de nivel de servicio (SLA) con una disponibilidad del 99,99 %.

• Con la utilización de tablas globales, DynamoDB permite que una tabla replique sus datos entre dos o más Regiones. Una tabla DynamoDB de varias regiones tiene un SLA de disponibilidad del 99,999 %. Con una planificación adecuada, las tablas globales pueden contribuir a crear una arquitectura que sea resistente y que resista los errores regionales.

• Las tablas globales emplean un modelo de replicación activa-activa. Desde la perspectiva de DynamoDB, la tabla en cada región tiene la misma capacidad para aceptar solicitudes de lectura y escritura. Después de recibir una solicitud de escritura, la tabla de réplica local replicará la escritura en otras regiones participantes en segundo plano.

• Los elementos se replican de forma individual. Los elementos actualizados en una misma transacción no pueden replicarse juntos.

• Cada partición de tabla de la región de origen replica sus escrituras en paralelo con las demás particiones. La secuencia de escrituras en la región remota puede no coincidir con la secuencia de escrituras que se produjo en la región de origen. Para obtener más información sobre las particiones de tablas, consulte la entrada de blog Escalado de DynamoDB: cómo afectan al rendimiento las particiones, las claves activas y la división por actividad.

• Un elemento que se acaba de escribir se propagará normalmente a todas las réplicas de tabla en cuestión de segundos. Las regiones cercanas tienden a propagarse más rápido.

• Amazon CloudWatch proporciona una métrica ReplicationLatency para cada par de regiones. El cálculo se basa en examinar los elementos que llegan y comparar su tiempo de llegada con su tiempo de escritura inicial y calcular un promedio. Los tiempos se almacenan en CloudWatch en la región de origen. La visualización de los tiempos promedios y máximos puede ayudar a determinar el retraso promedio y el peor de los casos en la replicación. No hay SLA por esta latencia.

• Si el mismo elemento se actualiza más o menos al mismo tiempo (en este intervalo de ReplicationLatency) en dos regiones diferentes y la segunda escritura se produce antes de que se replicara la primera, existe la posibilidad de que se produzcan conflictos de escritura. Las tablas globales resuelven estos conflictos con un mecanismo del último escritor gana, basado en la marca de tiempo de las escrituras. La primera escritura “pierde” frente a la segunda. Estos conflictos no se registran en CloudWatch ni en AWS CloudTrail.

• Cada elemento tiene una marca de tiempo de última escritura que se mantiene como una propiedad de sistema privada. El enfoque del último escritor gana se implementa mediante una escritura condicional que requiere que la marca de tiempo del elemento entrante sea mayor que la marca de tiempo del elemento existente.

• Una tabla global replicará todos los elementos en todas las regiones participantes. Si desea tener distintos ámbitos de replicación, puede crear diferentes tablas y dar a cada una de ellas diferentes regiones participantes.

• Se aceptarán escrituras en la región local aunque la región de réplica no tenga conexión o crezca ReplicationLatency. La tabla local sigue intentando replicar elementos en la tabla remota hasta que cada elemento lo consigue.

• En el improbable caso de que una región esté totalmente sin conexión, cuando más tarde vuelva a conectarse se volverán a intentar todas las réplicas salientes y entrantes pendientes. No es necesaria ninguna acción especial para volver a sincronizar las tablas. El mecanismo del último escritor gana garantiza que los datos acabarán siendo coherentes.

• En cualquier momento, puede agregar una nueva región a una tabla de DynamoDB. DynamoDB se encargará de la sincronización inicial y de la replicación continua. Si se elimina una región, incluso si es la original, solo se eliminará la tabla de dicha región.

• DynamoDB no dispone de un punto de conexión global. Todas las solicitudes se realizan a un punto de conexión regional, que a su vez accede a la instancia de tabla global que es local a esa región.

• Las llamadas a DynamoDB no deben realizarse entre regiones. La práctica recomendada es que la capa de computación de una región acceda directamente solo al punto de conexión local de DynamoDB correspondiente a esa región. Si se detectan problemas en una región, ya sea en la capa de DynamoDB o en la pila circundante, el tráfico del usuario final se debe enrutar hacia otra capa de computación alojada en una región distinta. Gracias a la replicación de tablas global, las distintas regiones dispondrán ya de una copia local de los mismos datos para trabajar localmente con ellos. En algunas circunstancias, la capa de computación de una región puede pasar la solicitud a la capa de computación de otra región para que la procese, pero no debe acceder directamente al punto de conexión de DynamoDB remoto. Para obtener más información sobre este caso de uso concreto, consulte Enrutamiento de solicitudes de la capa de computación.

Casos de uso

Las tablas globales ofrecen estos beneficios comunes:

• Lecturas con menor latencia. Puede colocar una copia de los datos más cerca del usuario final para reducir la latencia de red durante las lecturas. La memoria caché se mantiene tan actualizada como el valor de ReplicationLatency.

• Escrituras con menor latencia. Puede escribir en una región cercana para reducir la latencia de red y el tiempo necesario para realizar la escritura. El tráfico de escritura debe enrutarse cuidadosamente para garantizar que no haya conflictos. Las técnicas de enrutamiento se describen más detalladamente en Solicitud de enrutamiento con tablas globales.

• Mayor resiliencia y recuperación de desastres. Puede evacuar una región (alejar algunas o todas las solicitudes que vayan a esa región) en caso de que se degrade el rendimiento o se produzca una interrupción total, con un objetivo de punto de recuperación (RPO) y un objetivo de tiempo de recuperación (RTO) medidos en segundos. El uso de tablas globales también aumenta el SLA de DynamoDB del 99,99 % al 99,999 %.

• Migración de región sin problemas. Puede agregar una nueva región y eliminar la antigua para migrar una implementación de una región en otra, todo ello sin tiempo de inactividad en la capa de datos. Por ejemplo, puede utilizar las tablas globales de DynamoDB para que un sistema de administración de pedidos consiga un procesamiento con baja latencia de forma confiable a gran escala, a la vez que mantiene la resiliencia ante errores de AZ y de región.