Présentation de Cloud CDN

Cloud CDN (réseau de diffusion de contenu) exploite le réseau périphérique mondial de Google pour diffuser des contenus au plus près des utilisateurs afin d'accélérer les sites Web et les applications.

Cloud CDN fonctionne avec l'équilibrage de charge HTTP(S) externe afin de diffuser du contenu auprès de vos utilisateurs. L'équilibreur de charge HTTP(S) externe fournit les adresses IP d'interface et les ports qui reçoivent les requêtes, ainsi que les backends qui y répondent.

Le contenu Cloud CDN peut provenir de différents types de backends :

Dans Cloud CDN, ces backends sont également appelés serveurs d'origine. La figure suivante montre comment les réponses des serveurs d'origine s'exécutant sur des instances de VM transitent par un équilibreur de charge HTTP(S) avant d'être distribuées par Cloud CDN.

Les réponses transitent via Cloud CDN des serveurs d'origine vers les clients
Flux de réponse Cloud CDN

Fonctionnement de Cloud CDN

Lorsqu'un utilisateur demande du contenu à un équilibreur de charge HTTP(S), la requête parvient à un Google Front End (GFE), qui est situé à la périphérie du réseau de Google, aussi proche que possible de l'utilisateur.

Si le mappage d'URL de l'équilibreur de charge achemine le trafic vers un service de backend ou un bucket backend dans lequel Cloud CDN est configuré, le GFE utilise Cloud CDN.

Succès de cache (hit) et défaut de cache (miss)

Un cache est un groupe de serveurs qui stocke et gère le contenu afin que les futures demandes de ce contenu puissent être diffusées plus rapidement. Le contenu mis en cache est une copie du contenu pouvant être mis en cache, stocké sur les serveurs d'origine.

Si le GFE consulte le cache Cloud CDN et trouve une réponse mise en cache pour la requête de l'utilisateur, il l'envoie à l'utilisateur. C'est ce qu'on appelle un succès de cache (hit). Lorsqu'un succès de cache (hit) se produit, le GFE recherche le contenu d'après la clé de cache et répond directement à l'utilisateur, ce qui réduit le délai aller-retour et évite au serveur d'origine de traiter la requête.

Lors de la première demande d'un contenu, le GFE ne peut pas répondre à la requête à partir du cache. C'est ce qu'on appelle un défaut de cache (miss). Lorsqu'un défaut de cache (miss) se produit, le GFE peut tenter d'extraire le contenu d'un cache proche. Si celui-ci dispose du contenu, le GFE l'envoie au premier cache via un remplissage de cache à cache. Sinon, le GFE transfère la requête à l'équilibreur de charge HTTP(S).

L'équilibreur de charge transfère ensuite la requête à l'un de vos serveurs d'origine. Lorsque le cache reçoit le contenu, celui-ci est transféré à l'utilisateur par le GFE.

La figure suivante montre un succès de cache (hit) et un défaut de cache (miss) :

  1. Les serveurs d'origine exécutés sur des instances de VM envoient des réponses HTTP(S).
  2. L'équilibreur de charge HTTP(S) externe distribue les réponses à Cloud CDN.
  3. Cloud CDN envoie les réponses aux utilisateurs finaux.
La réponse initiale est diffusée par le serveur d'origine, et les réponses suivantes sont diffusées par le GFE à partir du cache
Succès de cache (hit) et défaut de cache (miss)

Sortie de cache et remplissage de cache

Si la réponse du serveur d'origine à cette requête peut être mise en cache, Cloud CDN stocke la réponse dans le cache Cloud CDN en prévision des futures requêtes.

Le transfert de données d'un cache vers un client est appelé sortie de cache. Le transfert de données vers un cache est appelé remplissage de cache. Comme l'illustre la figure suivante, le remplissage de cache peut provenir d'un autre cache Cloud CDN ou du serveur d'origine.

Le remplissage de cache est un transfert de données d'un serveur d'origine vers un cache ou d'un cache vers un autre cache. La sortie de cache est un transfert de données d'un cache vers un client.
Remplissage et sortie de cache

Pour les succès de cache (hit), des frais vous sont facturés pour la bande passante de sortie de cache. Pour les défauts de cache (miss), y compris ceux ayant entraîné un remplissage de cache à cache, des frais vous sont également facturés pour la bande passante de remplissage de cache. Cela signifie que le coût des succès de cache (hit) est inférieur à celui des défauts de cache (miss). Pour en savoir plus sur la tarification, consultez la page Tarifs.

Aucune redirection d'URL

Cloud CDN n'effectue aucune redirection d'URL. Le cache Cloud CDN se situe auprès du GFE. Cela entraîne le comportement suivant :

  • Que Cloud CDN soit activé ou non, l'URL demandée par un client reste la même.
  • Qu'il y ait ou non un succès de cache (hit), l'URL reste la même.

Taux d'accès au cache

Le taux d'accès au cache représente le nombre de fois, exprimé en pourcentage, qu'un objet demandé est diffusé à partir du cache. Un taux d'accès au cache de 60 % indique que l'objet demandé est diffusé à partir du cache 60 % du temps et doit être récupéré à partir du serveur d'origine 40 % du temps.

Dans Google Cloud Console, le taux d'accès au cache est indiqué pour chaque origine dans la colonne Taux d'accès au cache.

Accéder à la page Cloud CDN

Le pourcentage affiché sur cette page correspond à un taux calculé sur une courte période (les quelques dernières minutes). Pour afficher le taux d'accès au cache sur une période allant de 1 heure à 30 jours, cliquez sur le nom du serveur d'origine, puis sur l'onglet Surveillance.

Pour découvrir comment les clés de cache peuvent affecter le taux d'accès au cache, consultez la page Utiliser des clés de cache. Pour obtenir des informations de dépannage, consultez la section Le taux d'accès au cache est faible.

Insérer du contenu dans le cache

La mise en cache est réactive : un objet est stocké dans un cache si une demande transite par ce cache et que la réponse peut être mise en cache. Un objet stocké dans un cache ne se réplique pas automatiquement dans d'autres caches ; le remplissage du cache ne se produit qu'en réponse à une requête initiée par le client. Vous ne pouvez pas précharger les caches, sauf en faisant en sorte que les caches individuels répondent aux requêtes.

Lorsque le serveur d'origine accepte les requêtes de plage d'octets, Cloud CDN peut lancer plusieurs requêtes de remplissage de cache en réponse à une requête client unique. La section Requêtes initiées par Cloud CDN contient de plus amples informations sur ces requêtes.

Diffuser du contenu à partir d'un cache

Une fois que vous avez activé Cloud CDN, la mise en cache est automatique pour tous les contenus pouvant être mis en cache. À l'aide d'en-têtes HTTP, le serveur d'origine indique les réponses qui doivent être mises en cache. Lorsque vous employez un bucket de backend, le serveur d'origine est Cloud Storage. Lorsque vous employez des instances de VM, le serveur d'origine est le logiciel serveur Web que vous exécutez sur ces instances. Pour en savoir plus sur les contenus mis en cache par Cloud CDN et la durée de mise en cache, consultez la page Présentation de la mise en cache.

Cloud CDN utilise des caches dans de nombreux emplacements dans le monde. En raison de la nature des caches, il est impossible de prévoir si une requête particulière sera diffusée à partir d'un cache. Cependant, vous pouvez supposer que les requêtes courantes de contenu pouvant être mis en cache seront le plus souvent diffusées à partir d'un cache, d'où une réduction significative des latences, des coûts et de la charge des serveurs d'origine.

Vous pouvez afficher les journaux pour voir le contenu que Cloud CDN diffuse à partir d'un cache.

Supprimer du contenu du cache

Pour supprimer un élément du cache, vous pouvez invalider un contenu mis en cache. Pour en savoir plus, consultez les pages suivantes :

Contournement de cache

Pour contourner Cloud CDN, vous pouvez demander un objet directement depuis un bucket Cloud Storage ou une VM Compute Engine. Par exemple, une URL pour un objet de bucket Cloud Storage doit se présenter sous la forme suivante :

https://storage.googleapis.com/your-storage-bucket/filename

Éviction et expiration

Pour que du contenu soit diffusé à partir d'un cache, il doit avoir été inséré dans le cache, il ne doit pas avoir été évincé, ni être arrivé à expiration.

L'éviction et l'expiration sont deux concepts différents. Ils affectent tous les deux le contenu diffusé, mais n'ont pas d'influence l'un sur l'autre.

Éviction

Chaque cache a une limite de capacité. Cependant, Cloud CDN ajoute du contenu aux caches même une fois qu’ils sont pleins. Pour intégrer du contenu, les caches déjà remplis suppriment d'abord du contenu pour libérer de l'espace. On parle alors d'éviction. Les caches étant souvent pleins, ils évincent constamment du contenu. Il s'agit généralement de contenu que personne n'a consulté récemment, quel que soit son délai d'expiration. Le contenu évincé peut également être arrivé à expiration, mais pas nécessairement. Définir un délai d'expiration n'affecte pas l'éviction.

Un contenu peu populaire est un contenu que personne n'a consulté récemment. Le sens exact de récemment et peu populaire dépend du volume des autres contenus inclus dans le cache. Plus les caches reçoivent du trafic, plus ils évincent du contenu mis en cache.

Comme avec tous les caches à grande échelle, le contenu peut être évincé de manière imprévisible. Nous ne pouvons donc pas garantir que toutes les requêtes seront diffusées depuis le cache.

Expiration

Vous pouvez configurer le délai d'expiration du contenu des caches HTTP(S). Cela permet de faire en sorte que le cache ne diffuse pas d'ancien contenu, même si celui-ci n'a pas été évincé.

Prenons l'exemple d'une URL correspondant à l'image d'une heure donnée. Le délai d'expiration de ses réponses devrait être d'une heure au maximum. Autrement, le contenu diffusé pourrait être une ancienne image d'un cache.

Requêtes initiées par Cloud CDN

Lorsque le serveur d'origine accepte les demandes de plage d'octets, Cloud CDN peut lui envoyer plusieurs demandes en réponse à une demande client unique. Comme décrit dans Compatibilité pour les demandes de plage d'octets, Cloud CDN peut initier deux types de demandes : les demandes de validation et les demandes de plage d'octets.

Paramètres de localisation de données d'autres services Cloud Platform

Lorsque vous utilisez Cloud CDN, il est possible que les données soient stockées dans des emplacements de diffusion situés en dehors de la région ou de la zone du serveur d'origine. Ceci est normal et correspond au mode de fonctionnement de la mise en cache HTTP sur Internet. En vertu des Conditions d'utilisation spécifiques du service Google Cloud Platform, les paramètres de localisation de données disponibles pour certains services Cloud Platform ne s'appliquent pas aux données client principales du service Cloud Platform correspondant lorsque celles-ci sont utilisées avec d'autres produits et services Google (dans ce cas, le service Cloud CDN). Si vous ne souhaitez pas ce résultat, veuillez ne pas utiliser le service Cloud CDN.

Compatibilité des certificats SSL gérés par Google

Vous pouvez utiliser des certificats SSL gérés par Google lorsque que Cloud CDN est activé.

Google Cloud Armor avec Cloud CDN

Si vous utilisez Google Cloud Armor avec Cloud CDN, les règles de sécurité ne sont appliquées que pour les requêtes de contenu dynamique, les défauts de cache (miss) ou d'autres requêtes destinées à votre serveur d'origine. Les succès de cache (hit) sont diffusés même si la règle de sécurité Google Cloud Armor en aval empêche cette requête d'atteindre le serveur d'origine.

Étapes suivantes