Latencia de Amazon CloudFront

Estoy experimentando con AWS S3 y CloudFront para una aplicación web que estoy desarrollando.

En la aplicación, les permito a los usuarios subir archivos al cubo S3 (usando AWS SDK) y ponerlos a disposición a través de CloudFront CDN, pero el problema es que incluso cuando los archivos se cargan y preparan en el contenedor S3 demoran aproximadamente un minuto o 2 para estar disponible en la URL de CDN de CloudFront, ¿es esto normal?

CloudFront intenta recuperar contenido no guardado del servidor de origen en tiempo real. No hay un “retraso de replicación” o un problema similar porque CloudFront es un CDN de extracción. Cada ubicación de borde de CloudFront solo conoce la existencia y configuración de su sitio; no sabe acerca de su contenido hasta que recibe solicitudes para ello. Cuando eso sucede, CloudFront edge obtiene el contenido solicitado del servidor de origen y lo almacena en la memoria caché, según corresponda, para atender solicitudes posteriores.

El problema que está ocurriendo aquí está relacionado con un concepto a veces llamado “almacenamiento en caché negativo”, almacenando en caché el hecho de que una solicitud no funcionará, que normalmente se realiza para evitar el origen de lo que se almacena en caché con solicitudes que probablemente fallen. de todas formas.

De forma predeterminada, cuando su origen devuelve un código de estado HTTP 4xx o 5xx, CloudFront almacena en caché estas respuestas de error durante cinco minutos y luego envía la siguiente solicitud del objeto a su origen para ver si el problema que causó el error se ha resuelto y el solicitado objeto ahora está disponible.

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html

Si el navegador, o cualquier otra cosa, intenta descargar el archivo de ese borde de CloudFront en particular antes de que se complete la carga en S3, S3 devolverá un error, y CloudFront – en esa ubicación de borde – almacenará ese error en caché y recordará, por los próximos 5 minutos, no te molestes en intentarlo de nuevo.

Sin embargo, no se preocupe: este temporizador es configurable, por lo que si el navegador lo está haciendo por debajo del capó y fuera de su control, aún así debería poder repararlo.

Puede especificar la duración del almacenamiento en caché de errores, el TTL mínimo de almacenamiento en caché de errores, para cada código de estado 4xx y 5xx que cachee CloudFront. Para un procedimiento, vea Configurar comportamiento de respuesta de error .

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html


Para configurar esto en la consola :

  • Al ver la configuración de distribución, haga clic en la pestaña Error Pages .

  • Para cada error en el que desee personalizar el tiempo, comience por hacer clic en Create Custom Error Response .

  • Elija el código de error que desea modificar de la lista desplegable, como 403 (Prohibido) o 404 (No encontrado): la configuración de su depósito determina qué código S3 devuelve para los objetos faltantes, por lo que si no está seguro, cambie 403 luego repite el proceso y cambia 404.

  • Set Error Caching Minimum TTL (seconds) a 0

  • Dejar Customize Error Response establecida en No (si se establece en Yes , esta opción habilita el contenido personalizado de respuesta en los errores, que no es lo que desea. La activación de esta opción está fuera del scope de esta pregunta).

  • Haga clic en Create . Esto lo lleva de vuelta a la vista anterior, donde verá Error Caching Minimum TTL para el código que acaba de definir.

Repita estos pasos para cada código de respuesta HTTP que desee cambiar del comportamiento predeterminado (que es el tiempo de espera de 300 segundos, mencionado anteriormente).

Cuando haya realizado todos los cambios que desea, regrese a la pantalla principal de la consola de CloudFront donde se enumeran las distribuciones. Espere a que el estado de distribución cambie de In Progress a Deployed (por lo general, aproximadamente 20 minutos para que los cambios se extiendan a todos los bordes) y pruebe.

¿Se están escribiendo estos nuevos archivos en S3 por primera vez o son actualizaciones de archivos existentes? S3 proporciona coherencia de lectura tras escritura para los objetos nuevos, y dado el modelo de extracción de CloudFront, no debería tener este problema con los nuevos archivos escritos en S3. Si es así, entonces abriría un boleto con AWS.

Si se trata de actualizaciones de archivos existentes, entonces tiene que lidiar tanto con la consistencia final de S3 como con la caducidad del caché de CloudFront. Ambos podrían causar este tipo de comportamiento.

Como se observa en su comentario, parece que google chrome está jugando con su estrategia de carga / vista previa:

  1. Chrome solicita la URL que actualmente no tiene el contenido.
  2. la solicitud está en caché en la nube con respuesta no válida
  3. tu cargas el archivo a S3
  4. cuando obtiene una vista previa del archivo cargado, la nube responde con la respuesta en caché (paso 2).
  5. una vez que el caché de la nube caduca, la nube llega al origen y el problema ya no se puede reproducir.
    Intereting Posts