Que es el Cloud (Nube) ? Comencemos por definir lo básico antes de adentrarnos a Servicios WAAP...
Servicio de Caching con NGINX
Que es Caching ?
En IT, el almacenamiento en caché (caching) se refiere al almacenamiento de información localmente para acelerar la comunicación entre un cliente, como un navegador web, y un servidor, como un servidor web. La caché puede ubicarse en el lado del cliente, en el lado del servidor o, como suele ser el caso, en ambos.
La performance de una Web hoy en día es algo que no puede ser obviado, todo ya es en tiempo real, por lo que la entrega de los datos sino es en el orden de los milisegundos algo no va bien...
Hoy en día existen varias plataformas para realizar aceleración Web, pero al momento de querer realizarlo de forma gratuita son pocas las opciones que nos quedan, por ello analicemos algo de NGINX...
La mayoría de las personas conocen y aprovechan las capacidades de proxy inverso de alto rendimiento de NGINX+; sin embargo, muchos no saben que también pueden aprovecharlo como una capa de almacenamiento en caché de alto rendimiento. En este artículo, abordaremos rápidamente los puntos destacados de estas capacidades, así como algunas consideraciones y opciones de configuración que quizás no conozca.
Como nos puede ayudar NGINX ?
NGINX Plus y NGINX son las mejores soluciones de equilibrio de carga utilizadas por sitios web de alto tráfico como Dropbox, Netflix y Zynga. Más de 350 millones de sitios web en todo el mundo que utilizan NGINX Plus y NGINX Open Source para entregar su contenido de forma rápida, confiable y segura.
Las caracteristicas mas destacables de NGINX son:
- Reverse proxy with caching
- IPv6
- Load balancing
- FastCGI support with caching
- WebSockets
- Handling of static files, index files, and auto-indexing
- TLS/SSL with SNI
En este artículo haremos foco en Reverse proxy with caching. No obstante, cabe destacar que NGINX ofrece una versión OpenSource y otra paga. A continuación, detallamos las principales diferencias entre ellos:
Fuente: https://www.nginx.com/products/nginx/compare-models/
Los principios básicos de NGINX Caching
El principio básico del almacenamiento en caché de contenido es descargar el trabajo repetitivo de los servidores ascendentes. Cuando el primer usuario solicita un elemento de contenido en el sitio web, su solicitud HTTP se reenvía a NGINX y desde allí al servidor ascendente en gris en el lado derecho.
La respuesta se reenvía al usuario remoto, pero si se puede almacenar en caché, NGINX almacena una copia de esa respuesta. Cuando otro usuario, aparece pidiendo el mismo contenido, NGINX puede servirlo directamente desde su caché local, en vez de enviar la solicitud al servidor ascendente.
Que puede cachear NGINX ?
El comportamiento básico de NGINX es almacenar en caché todas las solicitudes GET y HEAD que el servidor de origen indica que se pueden almacenar en caché, siempre que no haya encabezados Set-Cookie en la respuesta. Esto se debe a que los encabezados Set-Cookie generalmente incluyen datos únicos específicos en cada solicitud y de forma predeterminada, por lo que no sería apropiado almacenar en caché ese valor.
El almacenamiento en caché en NGINX no es sólo para HTTP. NGINX es mucho más que un simple proxy HTTP que reenvía solicitudes a servidores web ascendentes. Generalmente, esos servidores web ascendentes están ahí para interactuar con API como FastCGI o SCGI. NGINX puede hacerlo directamente de forma proxy, muy similar al proxy HTTP.
NGINX puede emplear sus técnicas de almacenamiento en caché para servidores proxy HTTP, servidores proxy FastCGI, servidores proxy uWSGI y servidores proxy SCGI. Todos funcionan de manera muy similar al proxy HTTP, con cachés almacenados en el disco y respuestas directas, lo que evita la necesidad de utilizar un proxy para estos servicios ascendentes.
Cabe destecar que todos los registros en caché, tienen un tiempo de vida definido por X-Accel-Expires, Cache Control y Expires.
Como funciona el proceso de Caching ?
A continuación detallamos como es el proceso de Caching en NGINX:
Cuando recibe una solicitud y consulta, se comienza leyendo una solicitud (cuadro superior izquierdo de la figura "Caching Process"), ensamblando la clave de caché con el URI sin formato y los demás parámetros que usar'a para identificar el recurso correspondiente a esa solicitud. Luego se verifica el caché en el disco accediendo a los metadatos en la memoria para ver si tenemos una copia nueva y válida de la respuesta para esa solicitud.
Si lo hacemos, eso cuenta como un golpe. Entonces NGINX puede responder directamente desde el caché. Responde desde el caché entregando el contenido desde el disco exactamente como NGINX entrega contenido estático. De esta forma, obtendrá el nivel de rendimiento, confiabilidad y escalabilidad para el que está diseñado NGINX. Con contenido estático, obtienes exactamente el mismo grado [de rendimiento] cuando entregas contenido desde la caché de contenido de NGINX.
Por otro lado, cuando comprobamos el caché, es posible que tengamos un error de caché. Esto significa que no tenemos el contenido en la caché o que el contenido de la caché no está actualizado y es necesario actualizarlo. Entonces, en el caso más simple, ese error significa que iríamos y solicitaríamos ese contenido del servidor de origen, recibiríamos la respuesta y verificaríamos si se puede almacenar en caché.
Si es así, lo transmitimos al disco tal como lo hace NGINX para cualquier respuesta grande manejada en modo proxy. Luego, una vez que [la respuesta] se transmite al disco, la copiamos en el caché y respondemos directamente desde el caché. Uno de los desafíos con este enfoque es si NGINX recibe múltiples solicitudes para el mismo contenido al mismo tiempo y todas resultan fallidas.
Además de que este tema da para conversar por mucho, sumamos nuestras capacidades y habilidades para implementar y gestionar este tipo de soluciones. De esta manera podemos acompañar a todo tipo de cliente, sin importar su tamaño, y librando de tiempo al equipo de TI.
Quieres saber mas acerca de nuestros servicios, contactanos completando el formulario debajo 👇
Fuente: Investigación interna, nuestra experiencia en este campo y servicios de F5.