Pre-almacenamiento en caché de imágenes generadas dinámicamente para ubicaciones Edge múltiples en Amazon Cloudfront

Question

Actualmente estamos usando CloudFront en muchas ubicaciones perimetrales para mostrar imágenes de productos (cerca de medio millón) que cambian de tamaño dinámicamente en diferentes dimensiones de tamaño. Nuestra distribución de Cloudfront utiliza una secuencia de comandos php de origen EC2 para recuperar la imagen original de S3, transformarla dinámicamente en función de los criterios de consulta ofrecidos (ancho, alto, recorte, etc.) y transmitirla de nuevo a Cloudfront que lo almacena en caché en la ubicación de borde.

Sin embargo, los visitantes del sitio web que cargan una imagen que no está en caché son golpeados por esta transformación bastante pesada.

Nos gustaría tener la capacidad de 'precachear' nuestras imágenes (mediante el uso de un trabajo por lotes solicitando cada url de imagen) para que los usuarios finales no sean los primeros en golpear una imagen en un tamaño particular, etc. Desafortunadamente, dado que las imágenes solo se almacenan en la Ubicación perimetral asignada al servicio previo al almacenamiento en caché, los visitantes del sitio que utilizan otra Ubicación perimetral no obtendrán la imagen almacenada en caché y recibirán una secuencia de comandos de cambio de tamaño pesado en el servidor de origen.

La única solución que hemos llegado de la, donde cada borde Localización puede recuperar una imagen dentro de un tiempo de carga razonable, es la siguiente:

tenemos una distribución Cloudfront que apunta a un script php origen EC2. Pero en lugar de realizar la transformación de imagen descrita anteriormente, la secuencia de comandos de origen reenvía los parámetros de solicitud y cadena de consulta a otra distribución de Cloudfront. Esta distribución tiene una secuencia de comandos php EC2 de origen que realiza la transformación de la imagen. De esta manera, la imagen siempre se almacena en caché en la ubicación Edge cerca de nuestra instancia EC2 (Irlanda) evitando así realizar otra transformación cuando se solicita la imagen desde otra ubicación perimetral.

Así, por ejemplo, una solicitud en Suecia acierta/image/stream/id/12345, que la ubicación de borde sueca no tiene en caché, por lo que envía una solicitud al origen, que es la máquina EC2 en Irlanda . La página 'streaming' de EC2 carga/image/size/id/12345 desde otra distribución de Cloudfront, que llega a la ubicación de Irish Edge, que tampoco la almacena en caché. Luego envía una solicitud al origen, nuevamente la misma máquina EC2, pero a la página 'tamaño' que hace el cambio de tamaño. Después de esto, tanto la ubicación del borde en Suecia como en Irlanda tienen la imagen en caché.

Ahora, una solicitud de Francia solicita la misma imagen. French Edge Location no lo tiene en caché, por lo que llama al origen, que es la máquina EC2 en Irlanda, que llama a la segunda distribución de CF que vuelve a la irlandesa Edge Location. Esta vez tiene la imagen en caché y puede devolverla de inmediato. Ahora, la ubicación de borde francesa también tiene la imagen en caché, pero sin tener que haber llamado a la página de "cambio de tamaño", solo la página de "transmisión" con la imagen almacenada en caché en Irlanda.

Esto también significa que nuestro 'pre-caché de" servicio de lotes en Irlanda puede hacer petición contra el borde Localización irlandés y pre-caché de las imágenes antes de que sean solicitados por nuestros visitantes del sitio web.

Sabemos lo que parece un poco absurdo, pero con el deseo que tenemos de que el usuario final nunca tenga que esperar mucho tiempo mientras se redimensiona la imagen, parece ser la única solución tangible.

¿Hemos pasado por alto otra/mejor solución? Cualquier comentario a lo anterior?

Answer 1

No estoy seguro de que esto disminuya los tiempos de carga (si esto fue nuestra meta).

Sí, esta configuración ahorrará algo de "tiempo de transformación" pero, por otro lado, esto también creará una comunicación adicional entre los servidores.

I.E. Cliente llama POP francés >> Llamadas POP francesas Irlanda POP = Dos veces el tiempo de descarga (y algo) que puede ser más largo que el "tiempo de transformación" ...

Trabajo para Incapsula y hemos desarrollado nuestro propio un comportamiento único que analiza el proceso heurístico para manejar el almacenamiento en caché de contenido dinámico. (Brevemente documentados aquí: http://www.incapsula.com/the-incapsula-blog/item/414-advanced-caching-dynamic-through-learning)

Nuestras premisas es:

Mientras que un sitio web puede tener millones de objetos dinámicos, sólo algunos de los que están sujetos a la petición reiterada.

Siguiendo esta lógica, tenemos un algoritmo que aprende patrones de visitas, encuentra buenos "candidatos" para el almacenamiento en caché y luego los almacena en caché en un servidor redundante. (evitando así la "descarga doble" mencionada anteriormente)

El contenido se vuelve a analizar cada 5 minutos para conservar la frescura y el sistema heurístico realiza un seguimiento, para asegurarse de que el contenido siga siendo popular.

Esta es una explicación demasiado simplificada, pero demuestra la idea central, que es: averigüe qué es lo que más necesitan sus usuarios. Ingrese en todos los POP. Mantenga un registro para preservar la frescura y detectar tendencias.

Espero que esto ayude.

Answer 2

Sólo un pensamiento ...

Ejecutar dos cachés.

1. Uno en cada ubicación del borde,
2. Uno en el servidor (o ElastiCache si varios servidores) en Irlanda. No necesitan almacenarse en la memoria caché durante mucho más que unos minutos.

tiene una instancia de micro funcionando conectado a la tubería de datos o una cola,

Cuando la solicitud llega al servidor de origen, el retorno y la memoria caché del servidor de la imagen. También coloque la url en la cola.

Luego, haga que el daemon realice múltiples llamadas a cada ubicación de borde. En este punto, su servidor será golpeado de nuevo (ya que las otras ubicaciones de borde no tendrán la imagen), pero se lo servirá inmediatamente fuera de la memoria caché, sin necesidad de realizar la costosa transformación.

Si no está haciendo la transformación, y solo servir fuera de la memoria caché, no debería ser un gran problema.

lo tanto, el flujo sería así

Request -> Cloud Front -> EC2 -> Add to cache -> Response -> CloudFront Cache -> User 
    -      -> Queue new request at each edge location 
Request -> Cloud Front -> EC2 -> already cached -> Response -> CloudFront -> User 

que había necesidad de algún tipo de marcador para indicar que ha sido servida y ya se almacena en caché, de lo contrario iba a terminar en un bucle infinito.