Información general

Los servicios de periferia de AWS son componentes importantes para crear aplicaciones web con alta disponibilidad. Además de su alta disponibilidad nativa gracias a su naturaleza distribuida, los servicios de periferia de AWS actúan como un punto de entrada a las aplicaciones web y pueden dirigir las solicitudes a las particiones disponibles en su infraestructura de origen (por ejemplo, zona o región de disponibilidad).

Decisiones de arquitectura

Una aplicación web de alta disponibilidad se puede diseñar de diversas formas, en función de sus requisitos en términos de SLO de disponibilidad, costo y complejidad. Como mínimo, debe tomar las siguientes decisiones técnicas en función de los requisitos de su empresa:

  • ¿Tiene una arquitectura en modo activo/activo o activo/pasivo?
  • ¿Tienes orígenes, AZ o regiones diferentes?
  • ¿Cuál es la lógica de enrutamiento entre los orígenes de la arquitectura en modo activo/activo? ¿Cuáles son los criterios de conmutación por error de la arquitectura en modo activo/pasivo?

Administración de errores de origen transitorios

CloudFront puede ayudarlo a mitigar el impacto de los errores 5xx transitorios que, en ocasiones, pueden afectar a una pequeña cantidad de solicitudes de usuarios. Con frecuencia, esto se debe a un origen sobrecargado con picos de tráfico repentinos o problemas transitorios de red. Puede mitigar los errores 5xx transitorios con CloudFront de diferentes formas.

Reintento. CloudFront se puede configurar para reintentar la conexión TCP hasta tres veces con un tiempo de espera de conexión configurable cuando no se pueda establecer una conexión con el origen. CloudFront también reintenta las solicitudes GET o HEAD idempotentes según el número de reintentos configurado.

Respuesta con contenido obsoleto. Si se producen un error en los reintentos con el origen, CloudFront ofrece de forma predeterminada una versión obsoleta del objeto si está disponible en la memoria caché, en lugar de devolver una respuesta de error. Este comportamiento se puede deshabilitar con la directiva Cache-Control: stale-if-error=0.

Conmutación por error de origen en un origen secundario. Puede configurar CloudFront para que genere un error en un origen secundario para la solicitud fallida específica mediante la funcionalidad de conmutación por error de origen. La conmutación por error de origen solo se aplica a las solicitudes GET o HEAD idempotentes. Tenga en cuenta que, si usa Lambda@Edge en los eventos de origen, CloudFront también ejecuta la función en caso de conmutación por error. En este escenario, puede inferir en la función de Lambda@Edge si la solicitud era para el origen principal o el secundario a fin de diferenciar su lógica. Para ello, configure el mismo encabezado personalizado de origen en ambos orígenes, pero con valores diferentes que Lambda@Edge pueda leer.

Conmutación por error correcta. Si la conmutación por error de origen en otro origen no es conveniente (por ejemplo, mantener otra infraestructura de origen), considere la posibilidad de llevar a cabo la conmutación por error en un archivo estático alojado en una ubicación diferente (por ejemplo, un bucket de S3) mediante la página de errores personalizados. Aunque de forma predeterminada se usa la misma página para todas las solicitudes que generan errores, si quiere crear una respuesta más dinámica, siga el tercer patrón de este blog.

Conmutación por error con estado durante interrupciones de origen

Conmutación por error según la política de Route 53

Puede usar la política de enrutamiento de conmutación por error de Route 53 con comprobaciones de estado en el nombre del dominio de origen que está configurado como origen en CloudFront. Cuando el origen principal pasa a estar en mal estado, Route 53 lo detecta y, a continuación, comienza a resolver el nombre del dominio de origen con la dirección IP del origen secundario. CloudFront respeta el TTL de DNS de origen, lo que significa que el tráfico comenzará a fluir hacia el origen secundario dentro del TTL de DNS. La configuración óptima (comprobación rápida activada, un umbral de conmutación por error de 1 y un TTL de DNS de 60 segundos) implica que la conmutación por error tardará 70 segundos como mínimo en producirse. Cuando ocurre, todo el tráfico pasa al origen secundario, ya que se trata de una conmutación por error con estado. Tenga en cuenta que este diseño se puede ampliar aún más con el Controlador de recuperación de aplicaciones de Route 53 para lograr una conmutación por error de aplicaciones más sofisticada en varias regiones de AWS y zonas de disponibilidad y en las instalaciones. Este enfoque se puede combinar con la funcionalidad de conmutación por error de origen de CloudFront para las solicitudes GET o HEAD a fin de reducir los errores mientras Route 53 lleva a cabo la conmutación por error en el origen secundario. Este patrón se describe en este blog.

Cuando los diferentes orígenes no comparten el mismo nombre de dominio, como en el caso de los orígenes basados en S3, Route 53 no se puede usar de la forma propuesta anteriormente. En este escenario, necesita una función de Lambda@Edge configurada en el evento de la solicitud de origen para consultar qué origen seleccionar en Route 53 y, a continuación, cambiar el nombre del dominio de origen y usar el encabezado de host para redirigir la solicitud al origen seleccionado. Para obtener más información sobre esta implementación, lea el siguiente caso práctico de Contentful.

Conmutación por error con Global Accelerator

Las aplicaciones que utilizan Global Accelerator pueden beneficiarse de sus funcionalidades nativas de conmutación por error. Con Global Accelerator, su aplicación se puede implementar en una única región de AWS en varias zonas de disponibilidad o varias regiones de AWS. Global Accelerator supervisa el estado de los puntos de conexión de sus aplicaciones mediante comprobaciones de estado y dirige el tráfico de los puntos de conexión en mal estado en decenas de segundos.

Arquitecturas en modo activo/activo

Enrutamiento basado en la latencia

CloudFront se puede usar con la política basada en la latencia de Route 53 para dirigir las solicitudes de los usuarios a la región de AWS más cercana en la que haya replicado el origen en una arquitectura multirregional en modo activo/activo. Para ello, configure el nombre del dominio de origen en CloudFront con la política basada en la latencia en Route 53. Cuando CloudFront resuelve el nombre del dominio de origen para conectarse y enviar la solicitud al origen, Route 53 devuelve la IP de origen más cercana en función de la latencia. Tenga en cuenta que la ubicación desde la que CloudFront resuelve el nombre del dominio de origen depende de la configuración de la distribución y el tipo de tráfico. En general, el nombre del dominio se resuelve en la ubicación periférica en el caso de las solicitudes dinámicas y en las cachés de periferia regionales en el caso del contenido que se puede almacenar en caché. En este blog, se ofrece información que sirve de guía para una implementación multirregional en modo activo/activo para API Gateway.

Cuando los diferentes orígenes no comparten el mismo nombre de dominio, como en el caso de los orígenes basados en S3, Route 53 no se puede usar de la forma propuesta anteriormente. En este escenario, necesita una función de Lambda@Edge configurada en el evento de la solicitud de origen para dirigirla al origen más cercano. Para obtener más información sobre esta implementación, lea los siguientes blogs:

Enrutamiento avanzado

En determinados escenarios, el enrutamiento de solicitudes requiere una lógica de nivel de aplicación. Cuando la lógica es sencilla, como el enrutamiento a diferentes orígenes en función de la ruta (por ejemplo, dirigir /api1 al origen 1 y /api2 al origen 2), puede usar simplemente la capacidad nativa de comportamiento de la caché de CloudFront. Si la lógica es más sofisticada, la función de Lambda@Edge en el evento de la solicitud de origen le permite dirigir el tráfico en función de los atributos de nivel de aplicación, como la URL, las cookies, los encabezados, el país, etc. La lógica puede carecer de estado y estar totalmente integrada en el código de la función o puede almacenarse en una ubicación externa, como S3 o DynamoDB, desde donde Lambda@Edge obtiene la regla de enrutamiento para ejecutarla.

Recursos

¿Le resultó útil esta página?

 Comentarios