Fundamento multirregional 3: comprender las dependencias de su carga de trabajo

Una carga de trabajo específica puede tener varias dependencias en una región, como la Servicios de AWS utilizada, las dependencias internas, las dependencias de terceros, las dependencias de red, los certificados, las claves, los secretos y los parámetros. Para garantizar el funcionamiento de la carga de trabajo en un escenario de fallo, no debe haber dependencias entre la región principal y la región en espera; cada una debe poder funcionar de forma independiente. Para lograrlo, analice todas las dependencias de la carga de trabajo para asegurarse de que estén disponibles en cada región. Esto es necesario porque un error en la región principal no debería afectar a la región en espera. Además, debe comprender cómo funciona la carga de trabajo cuando una dependencia se encuentra en un estado degradado o no está disponible por completo, de modo que pueda diseñar soluciones que lo gestionen de forma adecuada.

3.a: Servicios de AWS

Al diseñar una arquitectura multirregional, es importante entender qué Servicios de AWS se utilizará, las características multirregionales de esos servicios y qué soluciones necesitará diseñar para lograr los objetivos multirregionales. Por ejemplo, Amazon Aurora y Amazon DynamoDB pueden replicar datos de forma asíncrona en una región en espera. Todas Servicio de AWS las dependencias deberán estar disponibles en todas las regiones desde las que se vaya a ejecutar la carga de trabajo. Para confirmar que los servicios que utilizas están disponibles en las regiones deseadas, consulta la lista Servicios de AWS por región.

3.b: Dependencias internas y de terceros

Asegúrese de que las dependencias internas de cada carga de trabajo estén disponibles en las regiones desde las que operan. Por ejemplo, si la carga de trabajo está compuesta por muchos microservicios, identifique todos los microservicios que componen una capacidad empresarial y compruebe que todos esos microservicios estén implementados en cada región desde la que opera la carga de trabajo. Como alternativa, defina una estrategia para gestionar adecuadamente los microservicios que dejen de estar disponibles.

No se recomiendan las llamadas interregionales entre microservicios dentro de una carga de trabajo, y se debe mantener el aislamiento regional. Esto se debe a que la creación de dependencias entre regiones aumenta el riesgo de que se produzcan errores correlacionados, lo que compensa los beneficios de las implementaciones regionales aisladas de la carga de trabajo. Las dependencias locales también pueden ser parte de la carga de trabajo, por lo que es importante entender cómo podrían cambiar las características de estas integraciones si cambiara la región principal. Por ejemplo, si la región en espera se encuentra más alejada del entorno local, el aumento de la latencia podría tener un impacto negativo.

Comprender las soluciones de software como servicio (SaaS), los kits de desarrollo de software (SDKs) y otras dependencias de productos de terceros, y poder analizar situaciones en las que estas dependencias se degradan o no están disponibles, proporcionará más información sobre cómo funciona y se comporta la cadena de sistemas en diferentes modos de falla. Estas dependencias pueden estar dentro del código de la aplicación, como la administración externa de secretos mediante el uso AWS Secrets Manager, o pueden implicar una solución de almacén de terceros (por ejemplo HashiCorp) o sistemas de autenticación que dependan de los inicios de sesión federados. AWS IAM Identity Center

Tener redundancia en lo que respecta a las dependencias puede aumentar la resiliencia. Si una solución SaaS o una dependencia de terceros utiliza la misma carga principal Región de AWS que la carga de trabajo, trabaje con el proveedor para determinar si su postura de resiliencia se ajusta a sus requisitos para la carga de trabajo.

Además, tenga en cuenta el destino compartido entre la carga de trabajo y sus dependencias, como las aplicaciones de terceros. Si las dependencias no están disponibles en (o desde) una región secundaria tras una conmutación por error, es posible que la carga de trabajo no se recupere por completo.

3.c: Mecanismo de conmutación por error

El DNS se suele utilizar como mecanismo de conmutación por error para desplazar el tráfico de la región principal a una región de reserva. Revise y analice de forma crítica todas las dependencias que implica el mecanismo de conmutación por error. Por ejemplo, si su carga de trabajo utiliza Amazon Route 53, entender que el plano de control está hospedado us-east-1 significa que está pasando a depender del plano de control de esa región específica. Esto no se recomienda como parte de un mecanismo de conmutación por error si la región principal también se us-east-1 debe a que crea un único punto de error. Si utiliza otro mecanismo de conmutación por error, debe tener un conocimiento profundo de los escenarios en los que la conmutación por error no funcionaría según lo esperado y, a continuación, planificar la contingencia o desarrollar un nuevo mecanismo si fuera necesario. Consulte la entrada del blog Creating Disaster Recovery Mechanisms Using Amazon Route 53 para obtener información sobre los enfoques que puede utilizar para realizar correctamente la conmutación por error.

Como se explicó en la sección anterior, todos los microservicios que forman parte de una capacidad empresarial deben estar disponibles en cada región en la que se despliegue la carga de trabajo. Como parte de la estrategia de conmutación por error, todos los microservicios que forman parte de la capacidad empresarial deben realizar la conmutación por error al mismo tiempo para evitar que se produzcan llamadas entre regiones. Como alternativa, si los microservicios se conmutan por error de forma independiente, existe la posibilidad de que se produzcan comportamientos no deseados, como la posibilidad de que los microservicios realicen llamadas entre regiones. Esto introduce latencia y puede provocar que la carga de trabajo deje de estar disponible durante los tiempos de espera de los clientes.

3.d: Dependencias de configuración

Los certificados, las claves, los secretos, las imágenes de Amazon Machine Images (AMIs), las imágenes de contenedores y los parámetros forman parte del análisis de dependencias necesario al diseñar una arquitectura multirregional. Siempre que sea posible, es mejor localizar estos componentes dentro de cada región para que estas dependencias no tengan un destino compartido entre las regiones. Por ejemplo, debe variar las fechas de caducidad de los certificados para evitar que un certificado que caduque (con las alarmas configuradas para «notificar con antelación») afecte a varias regiones.

Las claves y los secretos de cifrado también deben ser específicos de cada región. De esta forma, si se produce un error en la rotación de una clave o secreto, el impacto se limita a una región específica.

Por último, todos los parámetros de la carga de trabajo deben almacenarse localmente para que la carga de trabajo se recupere en la región específica.

Guía clave

• Una arquitectura multirregional se beneficia de la separación física y lógica entre las regiones. La introducción de dependencias entre regiones en la capa de aplicación reduce este beneficio. Evite este tipo de dependencias.

• Los controles de conmutación por error deberían funcionar sin depender de la región principal.

• La conmutación por error debe coordinarse a lo largo del recorrido del usuario para eliminar la posibilidad de que aumenten la latencia y la dependencia de las llamadas entre regiones.