Descripción general de Cloud CDN

Cloud CDN (red de distribución de contenidos) usa la red perimetral global de Google para entregar contenido más cerca de los usuarios, lo que acelera los sitios web y aplicaciones.

Cloud CDN funciona con el balanceo de cargas de HTTP(S) externo para entregar contenido a los usuarios. El balanceador de cargas de HTTP(S) externo proporciona los puertos y las direcciones IP de frontend que reciben solicitudes y los backends que responden a ellas.

El contenido de Cloud CDN se puede obtener de varios tipos de backends:

En Cloud CDN, estos backends también se denominan servidores de origen. En la siguiente figura, se muestra cómo las respuestas de los servidores de origen que se ejecutan en las instancias de VM fluyen a través de un balanceador de cargas de HTTP(S) antes de que Cloud CDN las entregue.

Las respuestas fluyen desde los servidores de origen a través de Cloud CDN hasta llegar a los clientes.
Flujo de respuesta de Cloud CDN

Cómo funciona Cloud CDN

Cuando un usuario solicita contenido desde un balanceador de cargas de HTTP(S) externo, la solicitud llega a Google Front End (GFE), que está en el perímetro de la red de Google, lo más cerca posible del usuario.

Si el mapa de URL del balanceador de cargas enruta el tráfico a un servicio o bucket de backend con Cloud CDN configurado, GFE usa Cloud CDN.

Aciertos de caché y errores de caché

Una caché es un grupo de servidores que almacena y administra contenido para que las solicitudes futuras de ese contenido se puedan entregar más rápido. El contenido almacenado en caché es una copia del contenido que se puede almacenar en caché y que se almacena en servidores de origen.

Si GFE busca en la caché de Cloud CDN y encuentra una respuesta almacenada en caché para la solicitud del usuario, GFE envía esa respuesta al usuario. Esto se conoce como acierto de caché. Cuando ocurre un acierto de caché, GFE busca el contenido mediante su clave de caché y responde directamente al usuario, lo que acorta el tiempo de ida y vuelta, y evita que el servidor de origen tenga que procesar la solicitud.

Un acierto parcial se produce cuando una solicitud se entrega de forma parcial desde la caché y de forma parcial desde un backend. Esto puede suceder si solo se almacena una parte del contenido solicitado en una caché de Cloud CDN, como se describe en Compatibilidad con solicitudes de rango de bytes.

La primera vez que se solicita un contenido, GFE determina que no puede entregar la solicitud desde la caché. Esto se denomina error de caché. Cuando se produce un error de caché, GFE reenvía la solicitud al balanceador de cargas HTTP(S) externo. El balanceador de cargas, entonces, reenvía la solicitud a uno de los servidores de origen. Cuando la caché recibe el contenido, GFE lo reenvía al usuario.

Si la respuesta del servidor de origen a esta solicitud se puede almacenar en caché, se almacena la respuesta en la caché de Cloud CDN para futuras solicitudes. La transferencia de datos de una caché a un cliente se denomina salida de caché. La transferencia de datos a una caché se denomina llenado de caché.

En la siguiente figura, se muestra un acierto de caché y un error de caché:

  1. Los servidores de origen que se ejecutan en instancias de VM envían respuestas HTTP(S).
  2. El balanceador de cargas de HTTP(S) externo distribuye las respuestas a Cloud CDN.
  3. Cloud CDN distribuye las respuestas a los usuarios finales.
El servidor de origen entrega la respuesta inicial, mientras que GFE entrega las respuestas subsiguientes a partir de la caché
Acierto de caché y error de caché

Para conocer los costos relacionados con los aciertos de caché y los errores de caché, consulta Precios.

Sin redireccionamiento de URL

Cloud CDN no realiza ningún redireccionamiento de URL. La caché de Cloud CDN se encuentra en GFE. Esto implica lo siguiente:

  • Ya sea que Cloud CDN esté habilitado o no, la URL que solicita un cliente sigue siendo la misma.
  • Ya sea que haya un acierto de caché o no, la URL sigue siendo la misma.

Tasa de aciertos de caché

La tasa de aciertos de caché es el porcentaje de veces que un objeto solicitado se entrega desde la caché. Si la tasa de aciertos de caché es de un 60%, significa que el objeto solicitado se entrega desde la caché el 60% de las veces y debe recuperarse del origen el 40% de las veces.

Para obtener información sobre cómo las claves de caché pueden afectar la tasa de aciertos de caché, consulta Usa claves de caché. Para obtener información sobre la solución de problemas, consulta La tasa de aciertos de caché es baja.

Consulta la tasa de aciertos de caché durante un período pequeño

Para ver la tasa de aciertos de caché en un período pequeño (los últimos minutos):

  1. En Google Cloud Console, ve a la página Cloud CDN.

    Ir a Cloud CDN

  2. Para cada origen, consulta la columna Tasa de aciertos de caché.

    n/a significa que el contenido con balanceo de cargas no se almacena en caché actualmente o no se solicitó recientemente.

Ve la tasa de aciertos de caché durante un período más largo

Para ver la tasa de aciertos de caché en un período de 1 hora a 30 días, haz lo siguiente:

  1. En Google Cloud Console, ve a la página Cloud CDN.

    Ir a Cloud CDN

  2. En la columna Balanceadores de cargas asociados, haz clic en el nombre del balanceador de cargas.
  3. Haz clic en la pestaña Monitoring.
  4. Selecciona un backend específico.
  5. Seleccione un período.
  6. Si la tasa de aciertos no es n/a, aparece una tasa de aciertos de caché en la parte inferior de la pestaña Supervisión.

Inserta contenido en la caché

El almacenamiento en caché es reactivo porque un objeto se almacena en una caché específica si una solicitud pasa por esa caché y si la respuesta puede almacenarse en caché. Un objeto almacenado en una caché no se replica de forma automática en otras memorias caché. El llenado de caché tiene lugar solo en respuesta a una solicitud iniciada por el cliente. No puedes precargar las memorias caché, salvo que las memorias caché individuales respondan a las solicitudes.

Cuando el servidor de origen admite solicitudes de rango de bytes, Cloud CDN puede iniciar varias solicitudes de llenado de caché en respuesta a una sola solicitud del cliente.

Entrega contenido desde una caché

Después de habilitar Cloud CDN, el almacenamiento en caché se produce de forma automática para todo el contenido que puede almacenarse en caché. El servidor de origen usa encabezados HTTP para indicar qué respuestas deben almacenarse en caché. También puedes controlar la capacidad de almacenamiento en caché mediante los modos de almacenamiento en caché.

Cuando usas un bucket de backend, el servidor de origen es Cloud Storage. Cuando usas instancias de VM, el servidor de origen es el software del servidor web que ejecutas en esas instancias.

Cloud CDN usa memorias caché en numerosas ubicaciones de todo el mundo. Debido a la naturaleza de las cachés, es imposible predecir si una solicitud en particular se entrega desde una caché. Sin embargo, puedes esperar que las solicitudes populares de contenido que se puede almacenar en caché se entreguen desde la caché la mayor parte del tiempo, lo que produce latencias, costos y cargas mucho menores en los servidores de origen.

Para obtener más información sobre lo que Cloud CDN almacena en caché y por cuánto tiempo, consulta la Descripción general del almacenamiento en caché.

Para ver qué entrega Cloud CDN desde una caché, puedes ver los registros.

Quita contenido de la caché

Para quitar un elemento de una caché, puedes invalidar el contenido almacenado en caché. Para obtener más información, consulta los siguientes vínculos:

Omite la caché

Para omitir Cloud CDN, puedes solicitar un objeto directamente desde un bucket de Cloud Storage o una VM de Compute Engine. Por ejemplo, una URL para un objeto de bucket de Cloud Storage será similar a lo que se muestra a continuación:

https://storage.googleapis.com/STORAGE_BUCKET/FILENAME

Expulsión y vencimiento

En el caso del contenido que se entrega desde una caché, se lo debe haber insertado en la caché y no se lo debe haber expulsado ni debe haber vencido.

Expulsión y vencimiento son dos conceptos diferentes. Ambos afectan lo que se entrega, pero no se afectan directamente entre sí.

Expulsión

Si pruebas el almacenamiento en caché del contenido con una cantidad pequeña de solicitudes, es posible que notes que el contenido se expulsa.

Cada caché tiene un límite en relación con la cantidad de contenido que puede conservar. Sin embargo, Cloud CDN agrega contenido a las memorias caché, aun después de que se llenen. Para insertar contenido en una caché llena, la caché primero debe quitar algo a fin de hacer lugar. Esto se denomina expulsión. Las memorias caché suelen estar llenas, por lo que expulsan contenido de manera constante. Por lo general, expulsan contenido al que no se haya accedido de forma reciente, sin importar el plazo de vencimiento del contenido. El contenido expulsado puede haber vencido o puede no haberlo hecho. Establecer un plazo de vencimiento no afecta la expulsión.

Contenido poco popular es un contenido al que no accede en un tiempo. En un tiempo y Poco popular son términos que están relacionados con la mayoría de los otros elementos en la caché. Varios proyectos de Google Cloud comparten un grupo común de espacio de caché porque los proyectos se entregan desde el mismo conjunto de GFE. La popularidad relativa del contenido se compara entre varios proyectos, no solo dentro de un proyecto.

A medida que las memorias caché reciben más tráfico, también expulsan más contenido almacenado en caché.

Como sucede con las memorias caché a gran escala, el contenido puede expulsarse de forma impredecible, por lo que no se garantiza que una solicitud específica se entregue desde la caché.

Vencimiento

El contenido de las cachés HTTP(S) puede tener una fecha de vencimiento configurable. El plazo de vencimiento informa a la caché para que no entregue contenido antiguo, incluso si el contenido no se ha expulsado.

Por ejemplo, considera una URL con información actual. Las respuestas deben configurarse para que venzan en menos de una hora. De lo contrario, el contenido entregado podría incluir información antigua de la caché.

A fin de obtener más información para definir mejor los vencimientos, consulta Usa la configuración y las anulaciones de TTL.

Solicitudes que inicia Cloud CDN

Cuando el servidor de origen admite solicitudes de rango de bytes, Cloud CDN puede enviar varias solicitudes al servidor de origen en respuesta a una sola solicitud del cliente. Como se describe en Compatibilidad con solicitudes de rango de bytes, Cloud CDN puede iniciar dos tipos de solicitudes: solicitudes de validación y solicitudes de rango de bytes.

Configuración de la ubicación de datos de otros servicios de Cloud Platform

Usar Cloud CDN significa que los datos pueden almacenarse en ubicaciones de entrega fuera de la región o zona del servidor de origen. Esto es algo normal y demuestra cómo funciona el almacenamiento en caché HTTP en Internet. Según las Condiciones específicas del servicio de las Condiciones del Servicio de Google Cloud Platform, la configuración de la ubicación de datos que está disponible para ciertos servicios de Cloud Platform no se aplica a los datos de clientes principales del servicio de Cloud Platform correspondiente cuando se usa con otros productos y servicios de Google (en este caso, el servicio de Cloud CDN). Si no quieres este resultado, no uses el servicio de Cloud CDN.

Compatibilidad con certificados SSL administrados por Google

Puedes usar certificados administrados por Google cuando Cloud CDN está habilitado.

Google Cloud Armor con Cloud CDN

Google Cloud Armor con Cloud CDN tiene dos tipos de políticas de seguridad:

  • Políticas de seguridad perimetral. Estas políticas se pueden aplicar a tus servidores de origen con Cloud CDN habilitado. Se aplican a todo el tráfico, antes de la búsqueda de CDN.
  • Políticas de seguridad del backend. Estas políticas solo se aplican a las solicitudes de contenido dinámico, errores de caché y otras solicitudes que están destinadas a tu servidor de origen.

Para obtener más información, consulta la documentación de Google Cloud Armor.

¿Qué sigue?