Fundamento multirregional 4: Preparación operativa

Gestionar una carga de trabajo multirregional es una tarea compleja que conlleva desafíos operativos específicos de una arquitectura multirregional. Estos incluyen la Cuenta de AWS administración, la reorganización de los procesos de implementación, la creación de una estrategia de observabilidad multirregional, la creación y prueba de los procesos de recuperación y, posteriormente, la administración del costo. Una revisión de la preparación operativa (ORR) puede ayudar a los equipos a preparar una carga de trabajo para la producción, ya sea que se ejecute en una sola región o en varias regiones.

4.a: gestión Cuenta de AWS

Para implementar una carga de trabajo en todas las regiones Regiones de AWS, asegúrate de que haya paridad en todas las Servicio de AWS cuotas de una cuenta en todas las regiones. En primer lugar, identifique todos los elementos Servicios de AWS que forman parte de la arquitectura, analice el uso planificado en las regiones en espera y, a continuación, compare el uso planificado con el uso actual. En algunos casos, si la región en espera no se ha utilizado antes, puede consultar las cuotas de servicio predeterminadas para comprender el punto de partida. Luego, en todos los servicios que se utilizarán, solicite un aumento de cuota mediante la consola Service Quotas (es necesario iniciar sesión) o APIs.

Configure las funciones AWS Identity and Access Management (IAM) en cada región para proporcionar a los operadores, las herramientas de automatización y Servicios de AWS los permisos adecuados para acceder a los recursos de la región en espera. Para lograr el aislamiento regional en las arquitecturas multirregionales, aísle las funciones por región. Asegúrese de que los permisos estén en vigor antes de poner en marcha una región en espera.

4.b: Prácticas de despliegue

Las capacidades multirregionales pueden complicar el despliegue de una carga de trabajo en varias regiones. Debe asegurarse de realizar la implementación en una región a la vez. Por ejemplo, si utiliza un enfoque activo-pasivo, primero debe realizar el despliegue en la región principal y, después, en la región en espera. AWS CloudFormationle ayuda a implementar la infraestructura en una o varias regiones y se puede personalizar en función de sus necesidades. AWS CodePipelinele ayuda a crear una cartera integration/continuous delivery (CI/CD (continua), que incluye acciones interregionales que permiten el despliegue en regiones distintas de la región en la que se encuentra la cartera. Esto, combinado con estrategias de despliegue sólidas, como la azul/verde, permite un despliegue con un tiempo de inactividad mínimo o nulo.

Sin embargo, el despliegue de capacidades con estado puede resultar más complejo cuando el estado de la aplicación o los datos no se externalizan a un almacén persistente. En estas situaciones, adapte cuidadosamente el proceso de implementación para que se adapte a sus necesidades. Diseñe el proceso y el proceso de despliegue para que se desplieguen en una región a la vez, en lugar de desplegarlos en varias regiones simultáneamente. Esto reduce la posibilidad de que se produzcan errores correlacionados entre las regiones. Para obtener más información sobre las técnicas que Amazon utiliza para automatizar las implementaciones de software, consulta el artículo de AWS Builders' Library sobre cómo automatizar las implementaciones seguras y sin intervención.

4.c: Observabilidad

Cuando diseñe para varias regiones, considere cómo va a monitorear el estado de todos los componentes de cada región para obtener una visión holística de la salud regional. Esto podría incluir el monitoreo de las métricas para detectar el retraso en la replicación, lo que no es una consideración para una carga de trabajo de una sola región.

Al crear una arquitectura multirregional, considere la posibilidad de observar también el rendimiento de la carga de trabajo desde las regiones en espera. Esto incluye realizar controles de salud y realizar canarios (pruebas sintéticas) desde la región de reserva para obtener una visión externa del estado de salud de la región principal. Además, puede usar Amazon CloudWatch Internet Monitor para comprender el estado de la red externa y el rendimiento de sus cargas de trabajo desde la perspectiva del usuario final. La región principal debe tener la misma observabilidad para monitorear la región en espera.

Los canarios de la región de reserva deberían supervisar las métricas de experiencia de los clientes para determinar el estado general de la carga de trabajo. Esto es necesario porque si hay un problema en la región principal, la observabilidad en la principal podría verse afectada y afectar a la capacidad de evaluar el estado de la carga de trabajo.

En ese caso, observar fuera de esa región puede proporcionar información. Estas métricas deben agruparse en paneles de control disponibles en cada región y en alarmas que se creen en cada región. Como CloudWatchse trata de un servicio regional, es obligatorio disponer de alarmas en ambas regiones. Estos datos de supervisión se utilizarán para realizar la llamada de conmutación por error de una región principal a una en espera.

4.d: Procesos y procedimientos

El mejor momento para responder a la pregunta «¿Cuándo debo realizar la conmutación por error?» pasará mucho tiempo antes de que lo necesites. Defina planes de recuperación que incluyan a las personas, los procesos y la tecnología mucho antes de que se produzca un problema y pruébelos periódicamente. Decida un marco de decisión de recuperación. Si hay un proceso de recuperación bien practicado y se conoce bien el tiempo de recuperación, puede optar por iniciar el proceso de recuperación mediante una conmutación por error que cumpla con el objetivo de RTO. Este momento puede ocurrir inmediatamente después de que se detecte un problema con la aplicación en la región principal, o puede ocurrir más adelante, cuando se hayan agotado las opciones de recuperación de la aplicación de la región.

La acción de conmutación por error en sí misma debería estar automatizada al cien por cien, pero la decisión de activar la conmutación por error la deben tomar personas, normalmente un número reducido de personas predeterminadas de la organización. Estas personas deberían tener en cuenta la pérdida de datos y la información sobre el evento. Además, los criterios para una conmutación por error deben estar claramente definidos y ser entendidos globalmente en la organización. Para definir y completar estos procesos, puede utilizar AWS Systems Manager manuales de ejecución, que permiten una end-to-end automatización completa y garantizan la coherencia de los procesos que se ejecutan durante las pruebas y la conmutación por error.

Estos manuales deberían estar disponibles en las regiones principal y en espera para iniciar los procesos de conmutación por error o conmutación por recuperación. Cuando esta automatización esté implementada, defina y siga una cadencia de pruebas regular. Esto garantiza que, cuando se produzca un evento real, la respuesta siga un proceso bien definido y practicado en el que la organización confíe. También es importante tener en cuenta las tolerancias establecidas para los procesos de reconciliación de datos. Confirme que el proceso propuesto cumpla con los requisitos de RPO/RTO establecidos.

4.e: Pruebas

Tener un enfoque de recuperación no probado equivale a no tener un enfoque de recuperación. Un nivel básico de prueba sería ejecutar un procedimiento de recuperación para cambiar la región operativa de la aplicación. A veces, esto se denomina enfoque de rotación de aplicaciones. Le recomendamos que desarrolle la capacidad de cambiar de región a su postura operativa normal; sin embargo, esta prueba por sí sola no es suficiente.

Las pruebas de resiliencia también son fundamentales para validar el enfoque de recuperación de una aplicación. Esto implica detectar escenarios de error específicos, comprender cómo reaccionan la aplicación y el proceso de recuperación y, a continuación, implementar las medidas de mitigación necesarias si la prueba no se llevó a cabo según lo planeado. Probar el procedimiento de recuperación sin errores no le indicará cómo se comporta la aplicación en su conjunto cuando se producen errores. Debe desarrollar un plan para evaluar su recuperación en función de los escenarios de error esperados. AWS Fault Injection Serviceproporciona una lista cada vez mayor de escenarios para que pueda empezar.

Esto es especialmente importante en el caso de las aplicaciones de alta disponibilidad, en las que se requieren pruebas rigurosas para garantizar el cumplimiento de los objetivos de continuidad empresarial. Las pruebas proactivas de las capacidades de recuperación reducen el riesgo de fallas en la producción, lo que genera confianza en que la aplicación puede alcanzar el tiempo de recuperación limitado deseado. Las pruebas periódicas también aumentan la experiencia operativa, lo que permite al equipo recuperarse de forma rápida y fiable de las interrupciones cuando se producen. Poner en práctica el elemento humano, o proceso, de su enfoque de recuperación es tan importante como los aspectos técnicos.

4.f: Coste y complejidad

Las implicaciones económicas de una arquitectura multirregional se deben al aumento del uso de la infraestructura, la sobrecarga operativa y el tiempo dedicado a los recursos. Como se mencionó anteriormente, el costo de infraestructura en una región en espera es similar al costo de infraestructura en una región principal cuando se realiza el aprovisionamiento previo, por lo que duplica el costo total. Aprovisione la capacidad de forma que sea suficiente para las operaciones diarias y, al mismo tiempo, reserve suficiente capacidad de búfer para tolerar los picos de demanda. A continuación, configure los mismos límites en cada región.

Además, si va a adoptar una arquitectura activa-activa, es posible que tenga que realizar cambios en el nivel de la aplicación para ejecutarla correctamente en una arquitectura multirregional. El diseño y la operación de estos cambios pueden requerir mucho tiempo y recursos. Como mínimo, las organizaciones deben dedicar tiempo a comprender las dependencias técnicas y empresariales de cada región y a diseñar los procesos de conmutación por error y recuperación.

Los equipos también deberían realizar los ejercicios habituales de conmutación por error y conmutación por recuperación para sentirse cómodos con los manuales de instrucciones que se utilizarían durante un evento. Si bien estos ejercicios son cruciales para obtener los resultados esperados de una inversión en varias regiones, representan un coste de oportunidad y suponen una pérdida de tiempo y recursos para otras actividades.

4.g: Estrategia organizativa de conmutación por error multirregional

Regiones de AWS proporcionan límites de aislamiento de fallas que eviten las fallas correlacionadas y contengan el impacto de las Servicio de AWS deficiencias, cuando se producen, en una sola región. Puede usar estos límites de falla para crear aplicaciones multirregionales que consistan en réplicas independientes y aisladas de fallas en cada región para limitar los escenarios de destino compartido. Esto le permite crear aplicaciones multirregionales y utilizar una variedad de enfoques (desde el backup y la restauración hasta la versión piloto o activo-activa) para implementar su arquitectura multirregional. Sin embargo, las aplicaciones no suelen funcionar de forma aislada, así que considere tanto los componentes que utilizará como sus dependencias como parte de su estrategia de conmutación por error. Por lo general, varias aplicaciones funcionan juntas para respaldar una historia de usuario, que es una capacidad específica que se ofrece a un usuario final, como publicar una imagen y un subtítulo en una aplicación de redes sociales o realizar una compra en un sitio de comercio electrónico. Por ello, debe desarrollar una estrategia organizativa de conmutación por error multirregional que proporcione la coordinación y la coherencia necesarias para que su enfoque sea exitoso.

Hay cuatro estrategias de alto nivel entre las que las organizaciones pueden elegir para guiar un enfoque multirregional. Estas se enumeran desde el enfoque más detallado hasta el más amplio:

• Conmutación por error a nivel de componentes

• Conmutación por error de aplicaciones individuales

• Conmutación por error en el gráfico de dependencias

• Conmutación por error de toda la cartera de aplicaciones

Cada estrategia tiene ventajas y desventajas y aborda diferentes desafíos, como la flexibilidad en la toma de decisiones sobre la conmutación por error, la capacidad de probar las combinaciones de la conmutación por error, la presencia de un comportamiento modal y la inversión organizacional en la planificación y la implementación. Para analizar cada estrategia con más detalle, consulte la entrada del AWS blog Cómo crear una estrategia organizacional de conmutación por error multirregional.

Guía clave

• Revise todas Servicio de AWS las cuotas para asegurarse de que son iguales en todas las regiones en las que operará la carga de trabajo.

• El proceso de despliegue debe centrarse en una región a la vez, en lugar de incluir a varias regiones simultáneamente.

• Las métricas adicionales, como el retraso en la replicación, son específicas de los escenarios multirregionales y deben supervisarse.

• Amplíe la supervisión de la carga de trabajo más allá de la región principal. Supervise las métricas de experiencia del cliente de cada región y mida estos datos desde fuera de cada región en la que se ejecute una carga de trabajo.

• Pruebe la conmutación por error y la conmutación por recuperación con regularidad. Implemente un único manual para los procesos de conmutación por error y conmutación por recuperación y utilícelo tanto para las pruebas como para los eventos en directo. Los manuales de ejecución para las pruebas y los eventos en directo no deberían ser diferentes.

• Comprenda las ventajas y desventajas de las estrategias de conmutación por error. Implemente un gráfico de dependencias o una estrategia de cartera de aplicaciones completa.