REL 10: Cómo utilizar el aislamiento de errores para proteger su carga de trabajo

Los límites del aislamiento de errores restringen los efectos de un error dentro de la carga de trabajo a una cantidad limitada de componentes. Los componentes que se encuentren por fuera de los límites no se ven afectados por el error. La implementación de varios límites de aislamiento de errores le permite restringir el impacto de los errores en su carga de trabajo.

Recursos

AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)
Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)
AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure (NET339)
What is AWS Outposts?
Global Tables: Multi-Region Replication with DynamoDB
AWS Local Zones FAQ
AWS Global Infrastructure
The Amazon Builders' Library: Workload isolation using shuffle-sharding

Prácticas recomendadas:

• Implemente la carga de trabajo en varias ubicaciones: Distribuya los datos y los recursos de la carga de trabajo en varias zonas de disponibilidad o, cuando sea necesario, en distintas regiones de AWS. Estas ubicaciones pueden ser tan variadas como se necesite.

• Automatice la recuperación de componentes restringidos a una sola ubicación: Si los componentes de una carga de trabajo solo se pueden ejecutar en una única zona de disponibilidad o en el centro de datos en las instalaciones, debe implementar la capacidad de efectuar una reconstrucción completa de la carga de trabajo dentro de sus objetivos de recuperación definidos.

• Utilice arquitecturas de mamparo: Al igual que los mamparos de un barco, este patrón garantiza que un error sea contenido dentro de un pequeño subconjunto de solicitudes o usuarios para que el número de las solicitudes dañadas sea limitado y la mayoría de ellas pueda continuar sin errores. Los mamparos para datos generalmente se denominan particiones, mientras que los mamparos para servicios se conocen como células.

Plan de mejora

Implemente la carga de trabajo en varias ubicaciones

Utilice varias zonas de disponibilidad y regiones de AWS: Distribuya los datos y los recursos de la carga de trabajo en varias zonas de disponibilidad o, cuando sea necesario, en distintas regiones de AWS. Estas ubicaciones pueden ser tan variadas como se necesite.

• Los servicios regionales se implementan inherentemente en las zonas de disponibilidad.
  • Esto incluye Amazon S3, Amazon DynamoDB y AWS Lambda (cuando no está conectado a una VPC)
• Implemente su contenedor, instancia y cargas de trabajo basadas en funciones en varias zonas de disponibilidad. Utilice almacenes de datos multizona, incluidas las cachés: Use las características de EC2 Auto Scaling, colocación de tareas de ECS, configuración de la función AWS Lambda cuando se ejecute en su VPC y clústeres de ElastiCache.
  • Utilice subredes que se encuentren en zonas de disponibilidad separadas cuando implemente grupos de Auto Scaling.
    Example: Distributing instances across Availability Zones
    Amazon ECS task placement strategies
    Configuring an AWS Lambda function to access resources in an Amazon VPC
    Choosing Regions and Availability Zones
  • Utilice subredes en zonas de disponibilidad separadas cuando implemente grupos de Auto Scaling.
    Example: Distributing instances across Availability Zones
  • Utilice los parámetros de colocación de tareas de ECS, con la especificación de grupos de subred de base de datos.
    Amazon ECS task placement strategies
  • Use subredes en múltiples zonas de disponibilidad cuando configure una función para que se ejecute en su VPC.
    Configuring an AWS Lambda function to access resources in an Amazon VPC
  • Use múltiples zonas de disponibilidad con clústeres de ElastiCache.
    Choosing Regions and Availability Zones

Si su carga de trabajo debe implementarse en varias regiones, elija una estrategia de varias regiones: La mayoría de las necesidades de confiabilidad se pueden satisfacer dentro de una sola región de AWS mediante una estrategia de múltiples zonas de disponibilidad. Use una estrategia de varias regiones cuando sea necesario para satisfacer sus necesidades comerciales.
AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)

• La copia de seguridad en otra región de AWS puede agregar otra capa de seguridad para que los datos estén disponibles cuando sea necesario.
• Algunas cargas de trabajo tienen requisitos reglamentarios que requieren el uso de una estrategia de múltiples regiones

Evalúe AWS Outposts para su carga de trabajo: Si su carga de trabajo requiere baja latencia en su centro de datos en las instalaciones o tiene requisitos locales de procesamiento de datos. Ejecute los servicios y la infraestructura de AWS en las instalaciones por medio de AWS Outposts
What is AWS Outposts?

Determine si AWS Local Zones lo ayuda a brindar servicio a sus usuarios: Si tiene requisitos de baja latencia, vea si AWS Local Zones se encuentra cerca de sus usuarios. En caso afirmativo, úselo para implementar cargas de trabajo más cercanas a esos usuarios
AWS Local Zones FAQ

Automatice la recuperación de componentes restringidos a una sola ubicación

Implemente la autoreparación: Implemente sus instancias o contenedores con el escalado automático cuando sea posible. Si no puede usar el escalado automático, use la recuperación automática para instancias EC2 o implemente la automatización de autoreparación basada en eventos del ciclo de vida del contenedor de Amazon EC2 o ECS.

• Use grupos de Auto Scaling para instancias y cargas de trabajo de contenedor que no tienen requisitos para una sola dirección IP de instancia, dirección IP privada, dirección IP elástica y metadatos de instancia.
  What Is EC2 Auto Scaling?
  Service automatic scaling
  • Los datos de usuario de la configuración de inicio se pueden usar para implementar la automatización que puede autoreparar la mayoría de las cargas de trabajo.
• Utilice la recuperación automática de instancias EC2 para cargas de trabajo que requieren una única dirección de ID de instancia, dirección IP privada, dirección IP elástica y metadatos de instancia.
  Recover your instance.
  • La recuperación automática enviará alertas de estado de recuperación a un tema de SNS a medida que se detecte el error de la instancia.
• Utilice los eventos del ciclo de vida de la instancia EC2 o los eventos de ECS para automatizar la autoreparación cuando no se pueda utilizar el escalado automático o la recuperación de EC2.
  EC2 Auto Scaling lifecycle hooks
  Amazon ECS events
  • Utilice los eventos para invocar la automatización que reparará su componente de acuerdo con la lógica de proceso que necesite.

Utilice la recuperación automática de instancias EC2 para cargas de trabajo que requieren una única dirección de ID de instancia, dirección IP privada, dirección IP elástica y metadatos de instancia.
Recover your instance.

• La recuperación automática enviará alertas de estado de recuperación a un tema de SNS a medida que se detecte el error de la instancia.

Utilice los eventos del ciclo de vida de la instancia EC2 o los eventos de ECS para automatizar la autoreparación cuando no se pueda utilizar el escalado automático o la recuperación de EC2.
EC2 Auto Scaling lifecycle hooks
Amazon ECS events

• Utilice los eventos para invocar la automatización que reparará su componente de acuerdo con la lógica de proceso que necesite.

Utilice arquitecturas de mamparo

Utilice arquitecturas de mamparo: Al igual que los mamparos de un barco, este patrón garantiza que un error sea contenido dentro de un pequeño subconjunto de solicitudes o usuarios para que el número de las solicitudes dañadas sea limitado y la mayoría de ellas continúe sin errores. Los mamparos para datos generalmente se denominan particiones, mientras que los mamparos para servicios se conocen como células
Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)

Evalúe la arquitectura basada en células para su carga de trabajo: En una arquitectura basada en células, cada célula es una instancia completa e independiente del servicio y tiene un tamaño máximo fijo. A medida que aumenta la carga, las cargas de trabajo aumentan al agregar más células. Se utiliza una clave de partición en el tráfico entrante para determinar qué celda procesará la solicitud. Cualquier error se contiene en la celda individual en la que se produce, de manera que la cantidad de solicitudes dañadas se limita mientras que las otras celdas continúan funcionando sin errores. Es fundamental identificar la clave de partición adecuada para minimizar las interacciones entre las celdas y evitar la necesidad de involucrar servicios complejos de mapeo en cada solicitud. Los servicios que requieren una asignación compleja terminan simplemente trasladando el problema a los servicios de asignación, mientras que los servicios que requieren interacciones entre las células reducen la independencia de las células (y, por lo tanto, las supuestas mejoras de disponibilidad al hacerlo).

• En su publicación de blog de AWS, Colm MacCarthaigh explica cómo Amazon Route 53 utiliza el concepto de fragmentación aleatoria para aislar las solicitudes de los clientes en particiones
  Shuffle Sharding: Massive and Magical Fault Isolation