Estrategias de enrutamiento de DynamoDB

Quizá la parte más compleja de la implementación de una tabla global sea administrar el enrutamiento de las solicitudes. Las solicitudes deben pasar primero de un usuario final a una región elegida y enrutada de alguna manera. La solicitud se encuentra con una pila de servicios en esa región, incluida una capa de computación que quizá consista en un equilibrador de carga respaldado por una función de AWS Lambda, un contenedor o un nodo de Amazon Elastic Compute Cloud (Amazon EC2) y posiblemente otros servicios, incluida otra base de datos. Esa capa de computación se comunica con DynamoDB. Debe hacerlo mediante la utilización del punto de conexión local correspondiente a esa Región. Los datos de la tabla global se replican en las demás regiones participantes y cada región dispone de una pila similar de servicios en torno a su tabla de DynamoDB.

La tabla global proporciona a cada pila de las distintas regiones una copia local de los mismos datos. Podría considerar la posibilidad de diseñar para una única pila en una única Región y prever la realización de llamadas remotas al punto de conexión de DynamoDB de una Región secundaria si se produce algún problema con la tabla de DynamoDB local. No es una práctica recomendada. Si DynamoDB provoca un problema en una región (o, más probablemente, otra parte de la pila u otro servicio que dependa de DynamoDB), es mejor dirigir al usuario final a otra región para que lo procese y utilice la capa de computación de esa otra región, que se comunicará con su punto de conexión local de DynamoDB. Este enfoque evita por completo la región problemática. Para garantizar la resiliencia, es necesaria la replicación entre varias regiones: la replicación de la capa de computación y la capa de datos.

Existen numerosas técnicas alternativas para enrutar una solicitud de un usuario final a una región para que se procese. La elección óptima depende de su modo de escritura y de sus consideraciones de conmutación por error. En esta sección se analizan cuatro opciones: basada en el cliente, capa de computación, Route 53 y Global Accelerator.

Enrutamiento de solicitudes basado en el cliente

Con el enrutamiento de solicitudes basado en el cliente, que se ilustra en el diagrama siguiente, el cliente del usuario final (una aplicación, una página web con JavaScript u otro cliente) hace un seguimiento de los puntos de conexión de la aplicación válidos (por ejemplo, un punto de conexión de Amazon API Gateway en lugar de un punto de conexión literal de DynamoDB) y utiliza su propia lógica integrada para elegir la región con la que comunicarse. Podría elegir según una selección al azar, de las latencias más bajas observadas, de las mediciones de ancho de banda más altas observadas o de comprobaciones de estado hechas localmente.

Como ventaja, el enrutamiento de solicitudes basado en el cliente es que puede adaptarse a factores como las condiciones reales de tráfico del internet público, para cambiar de región si detecta que el rendimiento disminuye. El cliente debe conocer todos los posibles puntos de conexión, pero lanzar un nuevo punto de conexión regional no es algo frecuente.

Con el modo de escritura en cualquier región, un cliente puede seleccionar de manera unilateral su punto de conexión preferido. Si su acceso a una región se ve afectado, el cliente puede enrutarse a otro punto de conexión.

Con el modo de escritura en una región, el cliente necesitará un mecanismo para enrutar sus escrituras a la región activa en ese momento. Podría ser algo tan básico como comprobar empíricamente qué región acepta actualmente escrituras (se debe tener en cuenta cualquier rechazo de escritura y conmutar por error a una alternativa) o tan complejo como llamar a un coordinador global para consultar el estado actual de la aplicación (quizás basado en el control de enrutamiento del Controlador de recuperación de aplicaciones [ARC] de Amazon, que proporciona un sistema basado en cuórum de cinco regiones para mantener el estado global para necesidades como esta). El cliente puede decidir si las lecturas pueden ir a cualquier región para obtener una coherencia puntual o si deben dirigirse a la región activa para obtener una coherencia sólida. Para obtener más información, consulte Funcionamiento de Route 53.

Con el modo de escritura en su región, el cliente necesita determinar la región de origen correspondiente al conjunto de datos con el que trabaja. Por ejemplo, si el cliente corresponde a una cuenta de usuario y cada cuenta de usuario está asignada a una región, el cliente puede solicitar el punto de conexión adecuado a un sistema de inicio de sesión global.

Por ejemplo, una empresa de servicios financieros que ayuda a los usuarios a administrar las finanzas de su empresa a través de la web podría utilizar tablas globales con un modo de escritura en su región. Cada usuario debe iniciar sesión en un servicio central. Ese servicio devuelve las credenciales y el punto de conexión de la región en la que funcionarán esas credenciales. Las credenciales son válidas durante un período breve. Transcurrido ese tiempo, la página web negocia automáticamente un nuevo inicio de sesión, lo que brinda la oportunidad de redirigir potencialmente la actividad del usuario a una nueva región.

Enrutamiento de solicitudes de la capa de computación

Con el enrutamiento de solicitudes de la capa de computación (que se ilustra en el diagrama siguiente), el código que se ejecuta en dicha capa determina si procesar la solicitud de manera local o pasarla a una copia de sí mismo que se esté ejecutando en otra región. Cuando utilice el modo de escritura en una región, la capa de computación podría detectar que no es la región activa y permitir las operaciones de lectura locales mientras reenvía todas las operaciones de escritura a otra región. Este código de la capa de computación debe conocer la topología de los datos y las reglas de enrutamiento, y aplicarlas de manera fiable según la última configuración que especifique qué regiones están activas para los datos determinados. La pila de software externa en la región no tiene por qué conocer cómo el microservicio enruta las solicitudes de lectura y de escritura. En un diseño sólido, la región receptora valida si es la principal actual para la operación de escritura. Si no lo es, genera un error que indica que es necesario corregir el estado global. La Región receptora también podría almacenar en búfer la operación de escritura durante un tiempo si la región principal está en proceso de cambiar. En todos los casos, la pila de computación de una región escribe solo en su punto de conexión de DynamoDB local, pero las pilas de computación podrían comunicarse entre sí.

The Vanguard Group utiliza un sistema denominado Herramienta de orquestación y estado global (GOaST) y una biblioteca denominada Biblioteca multirregión global (GMRlib) para este proceso de enrutamiento, tal como se presentó en re:Invent 2022. Utilizan un modelo principal único del tipo “seguir el sol”. La GOaST mantiene el estado global, similar al control de enrutamiento de ARC que se analizó en la sección anterior. Utiliza una tabla global para saber cuál es la región principal y cuándo está prevista la próxima transición de región principal. Todas las operaciones de lectura y escritura pasan por la GMRlib, que se coordina con la GOaST. La GMRlib permite que las operaciones de lectura se hagan de manera local, con baja latencia. En el caso de las operaciones de escritura, la GMRlib verifica si la región local es la principal actual. Si es así, la operación de escritura se completa directamente. De lo contrario, la GMRlib reenvía la tarea de escritura a la GMRlib de la región principal. La biblioteca receptora confirma que también se considera la región principal y, si no lo es, genera un error, lo que indica un retraso de propagación con el estado global. Este enfoque proporciona un beneficio de validación al no escribir directamente en un punto de conexión de DynamoDB remoto.

Enrutamiento de solicitudes de Route 53

El Controlador de recuperación de aplicaciones (ARC) de Amazon es una tecnología de servicio de nombres de dominio (DNS). Con Route 53, el cliente solicita su punto de conexión mediante la búsqueda de un nombre de dominio DNS conocido y Route 53 le devuelve la dirección IP correspondiente a los puntos de conexión regionales que considere más adecuados. Esto se explica en el siguiente diagrama. Route 53 tiene una lista larga de políticas de enrutamiento que utiliza para determinar la región adecuada. También puede hacer un enrutamiento de conmutación por error para desviar el tráfico de las regiones que no superen las comprobaciones de estado.

Con el modo de escritura en cualquier región, o si se combina con el enrutamiento de solicitudes de la capa de computación en el backend, Route 53 puede tener pleno acceso para devolver la región a partir de cualquier regla interna compleja, como la región más próxima a la red, la más próxima geográficamente o cualquier otra opción.

Con el modo de escritura en una región, puede configurar Route 53 para que devuelva la región activa en ese momento (mediante Route 53 ARC). Si el cliente quiere conectarse a una región pasiva (por ejemplo, para operaciones de lectura), puede buscar otro nombre de DNS.

En lo que respecta al modo de escritura en su región, es mejor evitar Route 53 a menos que también utilice el enrutamiento de solicitudes de la capa de computación.

Enrutamiento de solicitudes de Global Accelerator

Con AWS Global Accelerator, como se muestra en el diagrama siguiente, un cliente busca el nombre de dominio conocido en Route 53. No obstante, en lugar de obtener una dirección IP que corresponda a un punto de conexión regional, el cliente recibe una dirección IP estática anycast que enruta a la ubicación periférica de AWS más cercana. A partir de esa ubicación periférica, todo el tráfico se enruta en la red privada de AWS y hacia algún punto de conexión (como un equilibrador de carga o API Gateway) en una región elegida por las reglas de enrutamiento que se mantienen en Global Accelerator. En comparación con el enrutamiento basado en las reglas de Route 53, el enrutamiento de solicitudes de Global Accelerator tiene latencias más bajas porque reduce la cantidad de tráfico en el Internet público. Además, como Global Accelerator no depende del vencimiento de TTL del DNS para cambiar las reglas de enrutamiento, puede ajustar el enrutamiento con mayor rapidez.

Con el modo de escritura en cualquier región, o si se combina con el enrutamiento de solicitudes de la capa de computación en el backend, Global Accelerator funciona a la perfección. El cliente se conecta a la ubicación periférica más cercana y no tiene por qué preocuparse de qué región recibe la solicitud.

Con la escritura en una región, las reglas de enrutamiento de Global Accelerator deben enviar las solicitudes a la región activa en ese momento. Puede utilizar comprobaciones de estado que informen artificialmente de un error en cualquier región que su sistema global no considere la activa. Al igual que con DNS, se puede utilizar un nombre de dominio DNS alternativo para enrutar las solicitudes de lectura si las solicitudes pueden proceder de cualquier región.

En lo que respecta modo de escritura en su región, es mejor evitar Global Accelerator a menos que también utilice el enrutamiento de solicitudes de la capa de computación.