Prácticas recomendadas y requisitos para la administración de tablas globales de DynamoDB
Mediante las tablas globales de Amazon DynamoDB, puede replicar los datos de la tabla en las regiones de AWS. Es importante que las réplicas de tabla y los índices secundarios de la tabla global tengan una configuración de capacidad de escritura idéntica para garantizar la replicación adecuada de los datos.
Para mayor claridad en el futuro, puede ser útil no poner la región en el nombre de ninguna tabla que algún día pueda convertirse en una tabla global.
aviso
El nombre de cada tabla global debe ser único en su cuenta de AWS.
Versión de tablas globales
Para determinar la versión de la tabla global que está utilizando, consulte Determinación de la versión de las tablas globales de DynamoDB utilizadas.
Requisitos para la administración de la capacidad
Una tabla global debe tener la capacidad de rendimiento configurada de dos maneras:
-
Modo de capacidad bajo demanda, medido en unidades de solicitud de escritura replicadas (rWRUs)
-
Modo de capacidad aprovisionada con escalado automático, medido en unidades de capacidad de escritura replicadas (rWCUs)
El uso del modo de capacidad aprovisionada con escalado automático o el modo de capacidad bajo demanda ayuda a garantizar que una tabla global tenga siempre capacidad suficiente para realizar escrituras replicadas en todas las regiones de la tabla global.
nota
Al cambiar de un modo de capacidad de tabla al otro modo de capacidad en cualquier región, se cambia el modo para todas las réplicas.
Despliegue de tablas globales
En AWS CloudFormation, cada tabla global se controla mediante una única pila en una única Región. Esto es independiente del número de réplicas. Cuando implemente la plantilla, CloudFormation creará o actualizará todas las réplicas como parte de una sola operación de pila. Por este motivo, no debe desplegar el mismo recurso de AWS::DynamoDB::GlobalTable en varias regiones. Hacerlo no es compatible y provocará errores.
Si despliega la plantilla de aplicación en varias regiones, puede usar condiciones para crear el recurso solo en una región. O bien, puede optar por definir recursos AWS::DynamoDB::GlobalTable en una pila independiente de la pila de aplicaciones y asegurarse de que solo se implementa en una región. Para obtener más información, consulte Tablas globales en CloudFormation.
A una tabla de DynamoDB se hace referencia mediante AWS::DynamoDB::Table y a una tabla global mediante AWS::DynamoDB::GlobalTable. En lo que respecta a CloudFormation, básicamente los convierte en dos recursos diferentes. Como resultado, un enfoque consiste en crear todas las tablas que puedan llegar a ser globales utilizando el constructo GlobalTable. Así podrá mantenerlas como tablas independientes para empezar y agregarlas más tarde a las regiones si es necesario.
Si tiene una tabla normal y desea convertirla mientras utiliza CloudFormation, un método recomendado es:
Establezca la política de eliminación para retenerla.
Elimine la tabla de la pila.
Convierta la tabla en una tabla global en la consola.
Importe la tabla global como un nuevo recurso a la pila.
nota
En este momento no se admite la replicación entre cuentas.
Uso de tablas globales como ayuda para gestionar una posible interrupción de la región
Tenga o sea capaz de crear rápidamente copias independientes de su pila de ejecución en regiones alternativas, cada una con acceso a su punto de conexión DynamoDB local.
Utilice Route53 o AWS Global Accelerator para dirigirse a la región en buen estado más cercana. Otra posibilidad es que el cliente conozca los múltiples puntos de conexión que puede utilizar.
Utilice comprobaciones de estado en cada región que podrán determinar de forma fiable si hay algún problema con la pila, incluido si DynamoDB se ha deteriorado. Por ejemplo, no se limite a hacer ping para saber que el punto de conexión de DynamoDB está activo. Realice realmente una llamada que garantice un flujo completo de la base de datos correctamente.
Si se produce un error en la comprobación de estado, el tráfico puede enrutarse a otras regiones (por ejemplo, actualizar la entrada DNS con Route53, hacer que Global Accelerator enrute de forma diferente o hacer que el cliente elija un punto de conexión distinto). Las tablas globales tienen un buen RPO (objetivo de punto de recuperación) porque los datos se sincronizan continuamente y un buen RTO (objetivo de tiempo de recuperación) porque ambas regiones mantienen siempre una tabla lista para el tráfico de lectura y escritura.
Para más información sobre las comprobaciones de estado, consulte Tipos de comprobaciones de estado.
nota
DynamoDB es un servicio esencial a partir del cual otros servicios crean con frecuencia sus operaciones de plano de control, por lo que es poco probable que se encuentre con un escenario en el que DynamoDB tenga un servicio degradado en una región mientras que otros servicios no se vean afectados.
Copia de seguridad de las tablas globales
A la hora de realizar copias de seguridad de las tablas globales, una copia de seguridad de las tablas de una región debería ser suficiente y no debería ser necesario realizar copias de seguridad de todas las tablas de todas las regiones. Si el propósito es poder recuperar datos eliminados o modificados erróneamente, debería ser suficiente con PITR en una región. Del mismo modo, si desea conservar una instantánea con fines históricos, como los requisitos normativos, debería ser suficiente con realizar una copia de seguridad en una región. Los datos de los que se ha realizado una copia de seguridad pueden replicarse en varias regiones a través de AWS Backup.
Réplicas y cálculo de unidades de escritura
Para la planificación, debe tomar el número de escrituras que realizará una región y agregarlo al número de escrituras que se realizan para cada región. Esto es fundamental, ya que cada escritura que se realiza en una región también debe realizarse en cada región de réplica. Si no tiene suficiente capacidad para gestionar todas las escrituras, se producirán excepciones de capacidad. Además, aumentarán los tiempos de espera de las réplicas interregionales.
Por ejemplo, suponga que espera 5 escrituras por segundo en la réplica de tabla en Ohio, 10 escrituras por segundo en la réplica de tabla en el Norte de Virginia y 5 escrituras por segundo en su réplica de tabla en Irlanda. En este caso, debería esperar consumir 20 rWCUs o rWRUs en cada región: Ohio, Norte de Virginia e Irlanda. En otras palabras, debería esperar consumir 60 rWCUs en total en las tres regiones.
Para obtener más información sobre la capacidad aprovisionada con escalado automático y DynamoDB, consulte Administración automática de la capacidad de rendimiento con la función Auto Scaling de DynamoDB.
nota
Si una tabla se ejecuta en modo de capacidad aprovisionada con escalamiento automático, se permite que la capacidad de escritura aprovisionada flote en esas configuraciones de escalamiento automático para cada región.
