Lista de comprobación de preparación para tablas globales de DynamoDB

Determine si su caso de uso se beneficia más de un modo de coherencia MRSC o MREC. ¿Necesita una coherencia sólida, incluso con una latencia más alta y otras desventajas?

Determine cuántas y qué regiones deben participar en la tabla global. Si planea utilizar MRSC, decida si quiere que la tercera región sea una réplica o un testigo.

Determine el modo de escritura de la aplicación. No es lo mismo que el modo de coherencia. Para obtener más información, consulte Modos de escritura con tablas globales de DynamoDB.

Planifique su estrategia de Estrategias de enrutamiento de DynamoDB en función de su modo de escritura.

Defina Procesos de evacuación, según el modo de coherencia, el modo de escritura y la estrategia de enrutamiento.

Capture métricas sobre el estado, la latencia y los errores de cada región. Para obtener una lista de las métricas de DynamoDB, consulte la entrada de blog de AWS Supervisión de Amazon DynamoDB para el reconocimiento operativo, donde encontrará una lista de las métricas que debe examinar. También debe utilizar valores controlados sintéticos (solicitudes artificiales diseñadas para detectar errores; en inglés se llama “canary”, por el uso que se hacía de los canarios en las minas de carbón), así como la observación en directo del tráfico de los clientes. En las métricas de DynamoDB no aparecerán todas las incidencias.

Si utiliza MREC, establezca alarmas para los aumentos sostenidos de ReplicationLatency. Un aumento podría indicar un error de configuración accidental en el que la tabla global tiene diferentes opciones de escritura en distintas regiones, lo que da lugar a solicitudes replicadas con errores y a un aumento de las latencias. También podría indicar que existe una interrupción regional. Un buen ejemplo sería generar una alerta si el promedio reciente supera los 180 000 milisegundos. También puede vigilar si ReplicationLatency cae a 0, lo que indica que la replicación se ha estancado.

Asigne una configuración máxima de lectura y escritura suficiente para cada tabla global.

Identifique con antelación las razones para evacuar una región. Si la decisión implica una evaluación manual, documente todas las consideraciones. Este trabajo debe realizarse cuidadosamente con antelación, no bajo estrés.

Mantenga un manual de procedimientos para cada acción que deba llevarse a cabo cuando evacúe una región. Normalmente se requiere muy poco trabajo para las tablas globales, pero trasladar el resto de la pila puede resultar complejo.

Para obtener más información, consulte la entrada del blog de AWS Crear aplicaciones resilientes con tablas globales de Amazon DynamoDB: parte 4.

Pruebe periódicamente todos los aspectos del manual de procedimientos, incluidas las evacuaciones de región. Un manual de procedimientos no probado es un manual poco fiable.

Considere la posibilidad de utilizar AWS Resilience Hub para evaluar la resiliencia de toda la aplicación (incluidas las tablas globales). Proporciona una visión completa del estado de resiliencia general de su cartera de aplicaciones a través de su panel.

Considere la posibilidad de utilizar las comprobaciones de preparación de ARC para evaluar la configuración actual de la aplicación y realizar un seguimiento de cualquier desviación de las prácticas recomendadas.

Al escribir comprobaciones de estado para utilizarlas con Route 53 o Global Accelerator, haga una serie de llamadas que cubran todo el flujo de base de datos. Si limita la comprobación para confirmar únicamente que el punto de conexión de DynamoDB está activo, no se podrán cubrir muchos modos de error, como los errores de configuración de AWS Identity and Access Management (IAM), los problemas de implementación del código, los errores en la pila fuera de DynamoDB, las latencias de lectura o escritura superiores al promedio, etc.

El precio de una operación de escritura en una tabla de DynamoDB tradicional se calcula en unidades de capacidad de escritura (WCU, para tablas aprovisionadas) o unidades de solicitud de escritura (WRU) para tablas bajo demanda. Si escribe un elemento de 5 KB, se genera un cargo de 5 unidades. Una operación de escritura en una tabla global se cobra en unidades de capacidad de escritura replicada (rWCU, para las tablas aprovisionadas) o en unidades de solicitud de escritura replicada (rWRU, para las tablas bajo demanda). Las rWCU y las rWRU tienen el mismo precio que las WGU y las WRU.

Los cargos por rWCU y rWRU se producen en cada región en la que se escribe el elemento de manera directa o mediante replicación. Se aplican tarifas de transferencia de datos entre regiones.

La escritura en un índice secundario global (GSI) se considera una operación de escritura local y utiliza unidades de escritura normales.

No hay capacidad reservada disponible para las rWCU ni rWRU de momento. Adquirir capacidad reservada para WCU puede ser beneficioso para las tablas con GSI que consumen unidades de escritura.

Al agregar una nueva región a una tabla global, DynamoDB inicia la nueva región automáticamente y le cobra como si se tratara de una restauración de tabla, en función del tamaño de GB de la tabla. También cobra tarifas de transferencia de datos entre regiones.

Conjunto de regiones de EE. UU.: Este de EE. UU. (Norte de Virginia), Este de EE. UU. (Ohio), Oeste de EE. UU. (Oregón)

Conjunto de regiones de la Unión Europea: Europa (Irlanda), Europa (Londres), Europa (París), Europa (Fráncfort)

Conjunto de regiones de Asia-Pacífico: Asia-Pacífico (Tokio), Asia-Pacífico (Seúl) y Asia-Pacífico (Osaka).

Puede eliminar una tabla de réplica del mismo modo que eliminaría cualquier otra tabla. Al eliminar la tabla global se detiene la replicación en esa región y se elimina la copia de la tabla guardada en dicha región. No obstante, no se puede detener la replicación mientras se mantienen copias de la tabla como entidades independientes, ni tampoco se puede pausar.

Una tabla de MRSC se debe implementar exactamente en tres regiones. Para eliminar las réplicas, debe eliminar todas las réplicas y el testigo para que la tabla de MRSC pase a ser una tabla local.

Cada tabla global produce un flujo independiente basado en todas sus operaciones de escritura, independientemente de dónde hayan comenzado. Puede elegir consumir el flujo de DynamoDB en una región o en todas las regiones (de forma independiente). Si desea procesar operaciones de escritura locales pero no replicadas, puede agregar su propio atributo de región a cada elemento para identificar la región de escritura. A continuación, puede utilizar un filtro de eventos Lambda para llamar la función de Lambda solo para las operaciones de escritura en la región local. Esta acción ayuda en las operaciones de inserción y actualización, pero no en las de eliminación.

Las tablas globales configuradas para una coherencia final de varias regiones (MREC) replican los cambios al leer esos cambios desde un flujo de DynamoDB en una tabla de réplica y aplicarlos a todas las demás tablas de réplica. Por lo tanto, DynamoDB está habilitado de forma predeterminada en todas las réplicas de una tabla global de MREC y no se puede desactivar en esas réplicas. El proceso de replicación de MREC puede combinar varios cambios en un periodo breve en una sola operación de escritura replicada. Como resultado, el flujo de cada réplica puede contener registros ligeramente distintos. Los registros de DynamoDB Streams en las réplicas de MREC siempre se ordenan por elemento, pero el orden entre los elementos podría variar entre las réplicas.

Las tablas globales configuradas para una coherencia alta de varias regiones (tablas de MRSC) no utilizan DynamoDB Streams para la replicación, por lo que esta característica no está habilitada de manera predeterminada en las réplicas de MRSC. Puede habilitar DynamoDB Streams en una réplica de MRSC. Los registros de DynamoDB Streams en las réplicas de MRSC son idénticos para todas las réplicas y siempre se ordenan por elemento, pero el orden entre los elementos podría variar entre las réplicas.

Las operaciones transaccionales en las tablas de la MRSC generarán errores.

Las operaciones transaccionales en las tablas de MREC proporcionan garantías de atomicidad, coherencia, aislamiento y durabilidad (ACID) solo en la región en la que se creó la operación de escritura originalmente. No se admiten las transacciones entre regiones en las tablas globales. Por ejemplo, si tiene una tabla global de MREC con réplicas en las regiones Este de EE. UU. (Ohio) y Oeste de EE. UU. (Oregón) y hace una operación TransactWriteItems en la región Este de EE. UU. (Ohio), puede observar transacciones completadas de manera parcial en la región Oeste de EE. UU. (Oregón) a medida que los cambios se replican. Los cambios se replican en otras regiones solo cuando se han confirmado en la región de origen.

Si desea garantizar la durabilidad de los datos, DynamoDB ya proporciona esa protección. El servicio garantiza la durabilidad.

Si desea conservar una instantánea para los registros históricos (por ejemplo, para cumplir los requisitos normativos), la copia de seguridad en una región debería ser suficiente. Puede copiar la copia de seguridad a más regiones mediante AWS Backup.

Si desea recuperar datos eliminados o modificados erróneamente, utilice la recuperación en un momento dado (PITR) de DynamoDB en una región.

CloudFormation representa una tabla de DynamoDB y una tabla global como dos recursos independientes: AWS::DynamoDB::Table y AWS::DynamoDB::GlobalTable. Un enfoque consiste en crear todas las tablas que puedan ser potencialmente globales mediante el constructo GlobalTable, mantenerlas inicialmente como tablas independientes y agregar regiones después, si es necesario.

En CloudFormation, cada tabla global está controlada por una sola pila, en una sola región, independientemente del número de réplicas. Cuando implemente la plantilla, CloudFormation crea y actualiza todas las réplicas como parte de una sola operación de pila. No debe desplegar el mismo recurso AWS::DynamoDB::GlobalTable en varias regiones. Se producirán errores y no se admite. Si despliega la plantilla de aplicación en varias regiones, puede usar condiciones para crear el recurso AWS::DynamoDB::GlobalTable en una sola región. O bien, puede optar por definir recursos AWS::DynamoDB::GlobalTable en una pila que sea independiente de la pila de aplicaciones y asegurarse de que despliega en una sola región.

Si tiene una tabla normal y desea convertirla en una tabla global sin que CloudFormation deje de administrarla, establezca la política de eliminación en Retain, elimine la tabla de la pila, conviértala en una tabla global en la consola y, a continuación, importe la tabla global como un nuevo recurso a la pila. Para más información, consulte el repositorio de GitHub de AWS.

En este momento no se admite la replicación entre cuentas.