Tenemos una configuración bastante simple que nos causa grandes dolores de cabeza:
ANY /api/{proxy+} a un servicio/tareas de Fargate accesible a través de Cloud Mapawsvpc . Sin escalado automático. Min saludable: 100%, Max: 200%.SRV con TTL 60 Recibimos un HTTP 503 Service Unavailable intermitente no disponible para algunas de nuestras solicitudes. Una nueva implementación (con reimplementación de tareas) aumenta la tasa, pero incluso después de 10 a 15 minutos, siguen ocurriendo de manera intermitente.
En Cloud Watch vemos las solicitudes 503 fallidas
2020-06-05T14:19:01.810+02:00 xx.117.163.xx - - [05/Jun/2020:12:19:01 +0000] "GET ANY /api/{proxy+} HTTP/1.1" 503 33 Np24bwmwsiasJDQ=pero parece que no llegan a una instancia de back-end viva.
Habilitamos los registros de flujo de VPC y parece que HTTP API Gateway quiere enrutar algunas solicitudes a tareas detenidas, incluso después de que hayan pasado mucho tiempo (mucho más de 60 s).
Más desconcertante: si mantenemos el sistema ocupado, la tasa cae casi a cero. De lo contrario, después de un período más largo de inactividad, los errores intermitentes parecen volver a ocurrir.
Estaba enfrentando estos problemas y los resolví configurando mi ALB como interno , en lugar de orientado a Internet (con respecto al esquema ). Espero que pueda ayudar a alguien con el mismo problema.
Contexto: el entorno es API Gateway + ALB (ECS)
Actualizar El primer ALB que configuré fue para administrar mis servicios backend. Recientemente, también hice otro ALB (para tratar con mis instancias de front-end), en este caso, expuse una IP pública (en lugar de solo una privada). Esto podría lograrse cambiando el esquema a Internet , al principio pensé que esto traería el mismo problema que tenía antes, luego pensé que era algo bastante simple. Solo necesitaba agregar una política para permitir el tráfico desde Internet al ALB que creé.
Aunque nunca pudimos identificar realmente el problema, llegamos a la conclusión de que se trataba de una combinación de
Reemplazar API Gateway con la funcionalidad Cloudfront e introducir un balanceador de carga de aplicaciones de AWS cambió el método para el descubrimiento de servicios: en lugar de una zona de Route 53, el ELB administra las tareas ECS/Fargate disponibles por su cuenta. Esto salvó este problema para nosotros además de algunos otros menores.
Lo que funcionó para mí fue, además de configurar el esquema de mi ALB como interno como lo hizo xaalves , también poner el ALB en una subred aislada o privada . Anteriormente tenía mi ALB en subredes públicas . La experiencia de bentolor me hizo pensar que algún tipo de resolución de DNS se estaba descontrolando y, efectivamente, ese parecía ser el caso. Ahora el 100% de mis llamadas HTTP se completan con éxito.