Etapa 2: Diseñar e implementar - Recomendaciones de AWS

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Etapa 2: Diseñar e implementar

En la etapa anterior, usted estableció sus objetivos de resiliencia. Ahora, en la etapa de diseño e implementación, usted anticipa los modos de falla e identifica las opciones de diseño. Utilice los objetivos que estableció en la etapa anterior para guiar sus elecciones de diseño.

Utilice límites de aislamiento de AWS fallas

En elNube de AWS, un límite de aislamiento de errores es un límite, como una zona de disponibilidadRegión de AWS, un plano de control o un plano de datos, que limita el efecto de una falla y ayuda a mejorar la resiliencia de las cargas de trabajo. Para cumplir los objetivos de resiliencia de una sola vezRegión de AWS, céntrese en evitar puntos únicos de fallo en sus arquitecturas. Si una zona de disponibilidad deja de estar disponible, se minimiza el impacto.

Las empresas emergentes deberían utilizar los servicios regionales siempre que sea posible. AWSgestiona la alta disponibilidad mediante el despliegue de aplicaciones y datos en varias zonas de disponibilidad para estos servicios. Por ejemplo, Amazon Simple Storage Service (Amazon S3) es un servicio regional que distribuye las solicitudes y los datos entre varias zonas de disponibilidad. Está diseñado para recuperarse automáticamente de un error en una zona de disponibilidad. Solo interactúa con el punto final regional del servicio.

Si no puede utilizar los servicios regionales en su diseño, utilice los servicios zonales AWS gestionados. AWSlos servicios zonales gestionados le ayudan a implementar sus aplicaciones en varias zonas de disponibilidad, lo que proporciona una alta disponibilidad. AWSestos servicios ofrecen capacidades de resiliencia integradas, como la opción de implementar aplicaciones en varias zonas de disponibilidad con un solo clic, redirigir el tráfico desde las zonas de disponibilidad restringidas, gestionar los fallos de hardware subyacentes y automatizar las copias de seguridad de los datos. Por ejemplo, Amazon Relational Database Service (Amazon RDS) es un servicio zonal que admite una configuración de clústeres Multi-AZ que, en caso de fallo, conmuta automáticamente por error a una instancia de base de datos en espera de otra zona de disponibilidad.

En el caso de los servicios zonales que no estén gestionados por completoAWS, debe utilizar los recursos de Elastic Load Balancing y Amazon EC2 Auto Scaling para implementar las aplicaciones en varias zonas de disponibilidad. Para las cargas de trabajo de producción, distribuya las aplicaciones en dos zonas de disponibilidad. Para las cargas de trabajo críticas orientadas al cliente, distribuya su aplicación en tres zonas de disponibilidad para mejorar la alta disponibilidad (HA).

También debe utilizar varios Cuentas de AWS límites adicionales de aislamiento de errores para separar los recursos de producción de los recursos de desarrollo y almacenamiento provisional. Esto proporciona a los desarrolladores e ingenieros una mayor agilidad para modificar los recursos, los permisos AWS Identity and Access Management (IAM) y los permisos de recursos, sin afectar accidentalmente a las cargas de trabajo de producción.

Defina una estrategia de recuperación ante desastres

Desde la perspectiva de la recuperación ante desastres (DR), una estrategia de copia de seguridad y restauración con recuperación rápida es adecuada para cumplir los objetivos de resiliencia establecidos en la etapa anterior. Las copias de seguridad lo protegen contra los escenarios de error más comunes, como la corrupción de los datos y las implementaciones con código incorrecto. Debe utilizarse AWS Backuppara automatizar de forma centralizada la protección de datos en todas las instalacionesServicios de AWS, tanto en la nube como en las instalaciones. Debe crear un manual para restaurar o volver a crear todos los componentes de la carga de trabajo y actualizar las dependencias. Es importante que incluya en el manual todos los procedimientos de recuperación ante desastres, incluidas la conmutación por error y la conmutación por recuperación.

Defina una estrategia de despliegue

La adopción de un proceso completo de integración y entrega continuas (CI/CD) añade complejidad durante las primeras etapas de una empresa emergente. Comience por crear la infraestructura como código (IaC) y utilice canalizaciones para implementarla. Esto sienta las bases para adoptar un proceso completo de integración y entrega continuas (CI/CD) a medida que la organización vaya madurando.

Utilice las funciones de implementación estándar o azul/verde para lanzar nuevas versiones de la aplicación. Una implementación de Canary lanza una versión de forma lenta e incremental. Cuando esté seguro, implementará la nueva versión y sustituirá la versión actual en su totalidad. Una estrategia de despliegue azul/verde consiste en crear dos entornos separados pero idénticos y ejecutar la versión actual de la aplicación en un entorno (azul) y la nueva versión de la aplicación en el otro entorno (verde). Esto permite reversiones rápidas con un impacto mínimo.

Mantenga todo el código de la aplicación, las configuraciones y el IaC en un repositorio gestionado y controlado por versiones. Cuando sea posible, utilice las capacidades de control de versiones integradas al implementar servicios gestionados, como el control de versiones de Amazon S3.

Cree dependencias blandas

Si tu aplicación depende de un tercero, cualquier problema relacionado con la dependencia puede afectar tu capacidad de operar o escalar según lo esperado. Siempre que sea posible, reduzca estas dependencias externas duras, especialmente en el caso de las cargas de trabajo que se escalan automáticamente. A medida que diseñe su producto para lanzarlo al mercado rápidamente, puede utilizar diversas herramientas y componentes de código abierto y de terceros. Para estas dependencias, diseñe el software con un modo a prueba de fallos predeterminado o un disyuntor. La aplicación puede utilizar recursos alternativos o funcionar con una funcionalidad reducida en lugar de fallar por completo.