Solicitud de enrutamiento con tablas globales
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. Las latencias asociadas al acceso entre regiones pueden ser 100 veces superiores a las del acceso local. Una serie de cinco solicitudes de ida y vuelta puede tardar milisegundos cuando se realiza localmente, pero segundos cuando cruza el planeta. Es mejor enrutar al usuario final a otra región para que se procese. Para garantizar la resiliencia, necesita la replicación entre varias regiones, con replicación tanto de la capa de computación como de 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, un cliente de usuario final, como una aplicación, una página web con JavaScript u otro cliente, realizará un seguimiento de los puntos de conexión de aplicación válidos. En este caso serán puntos de conexión de aplicación como Amazon API Gateway en lugar de puntos de conexión de DynamoDB literales. El cliente de usuario final utiliza su propia lógica incorporada para elegir con qué región se va a comunicar. Puede elegir en función de una selección aleatoria, de las latencias más bajas observadas, de las mediciones de ancho de banda más altas observadas o de comprobaciones de estado realizadas localmente.
La ventaja del enrutamiento de solicitudes basado en el cliente es que puede adaptarse a objetos, como las condiciones de tráfico reales del Internet público, para cambiar de región en caso de detectar un deterioro del rendimiento. 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 unilateralmente 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 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 Route 53, que proporciona un sistema basado en quó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, el código que se ejecuta en dicha capa decide si quiere procesar la solicitud localmente 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 puede 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 forma fiable según la última configuración que especifique qué regiones están activas para determinados datos. 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í.
En este escenario, supongamos que una empresa de servicios financieros utiliza un modelo principal único de “seguir el sol”. Utiliza un sistema y una biblioteca para este proceso de enrutamiento. Su sistema global mantiene el estado global, similar al control de enrutamiento Route 53 ARC de AWS. Utiliza una tabla global para saber cuál es la región principal y cuándo está previsto el próximo cambio de región principal. Todas las operaciones de lectura y escritura pasan por la biblioteca, que se coordina con su sistema. La biblioteca permite que las operaciones de lectura se realicen localmente, con baja latencia. En el caso de las operaciones de escritura, la aplicación comprueba si la región local es la principal actual. Si es así, la operación de escritura se completa directamente. De lo contrario, la biblioteca reenvía la tarea de escritura a la biblioteca que se encuentra en la región principal actual. 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 de Amazon Route 53 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. Route 53 tiene una lista de políticas de enrutamiento que utiliza para determinar la región adecuada. Route 53 también puede realizar enrutamientos de conmutación por error para alejar 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, Route 53 puede configurarse para que devuelva la región activa en ese momento ( mediante Route 53 ARC).
nota
Los clientes almacenan en caché las direcciones IP en la respuesta de Route 53 durante un tiempo indicado por la configuración de tiempo de vida (TTL) del nombre de dominio. Un TTL más largo amplía el objetivo de tiempo de recuperación (RTO) para que todos los clientes reconozcan el nuevo punto de conexión. Un valor de 60 segundos es típico para utilizar en la conmutación por error. No todo el software respeta perfectamente la caducidad TTL 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
Un cliente utiliza AWS Global Accelerator
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.
