La solution de réseau de diffusion de contenu Cloud CDN 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'équilibreur de charge d'application externe global ou l'équilibreur de charge d'application classique pour diffuser du contenu à vos utilisateurs. L'équilibreur de charge d'application 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 1 montre comment les réponses des serveurs d'origine qui s'exécutent sur des instances de machine virtuelle (VM) transitent par un équilibreur de charge d'application externe avant d'être distribuées par Cloud CDN. Dans ce cas, le Google Front End (GFE) comprend Cloud CDN et l'équilibreur de charge d'application externe.
Fonctionnement de Cloud CDN
Lorsqu'un utilisateur demande du contenu à un équilibreur de charge d'application externe, la requête parvient à un GFE 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 ou un bucket de backend sur lesquels 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 stockent et gèrent du contenu afin que les futures requêtes portant sur 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.
Un appel partiel se produit lorsqu'une requête est diffusée partiellement à partir d'un cache et partiellement à partir d'un backend. Cela peut se produire si seule une partie du contenu demandé est stockée dans un cache Cloud CDN, comme décrit dans la section Compatibilité avec les requêtes de plage d'octets.
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 transfère la requête à l'équilibreur de charge d'application externe. 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.
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.
La figure 2 montre un succès de cache (hit) et un défaut de cache (miss) :
- Les serveurs d'origine exécutés sur des instances de VM envoient des réponses HTTP(S).
- L'équilibreur de charge d'application externe distribue les réponses à Cloud CDN.
- Cloud CDN envoie les réponses aux utilisateurs finaux.
Pour connaître les coûts liés aux succès de cache et aux défauts de cache, consultez la section Tarifs.
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.
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.
Afficher le taux d'accès au cache sur une courte période
Pour afficher le taux d'accès au cache sur une courte période (quelques minutes auparavant), procédez comme suit :
Dans Google Cloud Console, accédez à la page Cloud CDN.
Pour chaque origine, consultez la colonne Taux d'accès au cache.
n/a signifie que le contenu à équilibrage de charge n'est actuellement pas mis en cache ou n'a pas fait récemment l'objet d'une requête.
Afficher le taux d'accès au cache sur une période plus longue
Pour afficher le taux d'accès au cache sur une période allant d'une heure à 30 jours, procédez comme suit :
- Dans Google Cloud Console, accédez à la page Cloud CDN.
- Dans la colonne Nom de l'origine, cliquez sur le nom de l'origine.
- Cliquez sur l'onglet Surveillance.
- Facultatif: sélectionnez un backend spécifique.
Le taux d'accès au CDN est l'un des graphiques de surveillance disponibles. Un graphique affichant n/a signifie que le contenu n'est pas mis en cache ou n'a pas été demandé dans la période affichée.
Vous pouvez ajuster la période en sélectionnant une autre période. L'image suivante est un exemple de périodes que vous pouvez sélectionner:
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.
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. Le serveur d'origine utilise des en-têtes HTTP pour indiquer les réponses qui sont mises en cache. Vous pouvez également contrôler la mise en cache à l'aide des modes 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.
Cloud CDN utilise des caches répartis 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.
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.
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/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
Si vous testez la mise en cache du contenu avec un petit nombre de requêtes, vous remarquerez peut-être que le contenu est supprimé.
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. Plusieurs projets Google Cloud partagent un pool d'espace de cache commun, car les projets sont diffusés à partir du même ensemble de GFE. La popularité relative du contenu est comparée à plusieurs projets, et pas seulement au sein d'un même projet.
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.
Pour en savoir plus sur l'optimisation des délais d'expiration, consultez la page Utiliser les remplacements et les paramètres TTL.
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 la section 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 Cloud CDN est activé.
Google Cloud Armor avec Cloud CDN
Google Cloud Armor avec Cloud CDN présente deux types de règles de sécurité :
- Règles de sécurité périphérique. Ces règles peuvent être appliquées à vos serveurs d'origine compatibles avec Cloud CDN. Elles s'appliquent à tout le trafic, avant la recherche CDN.
- Règles de sécurité du backend. Ces règles 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.
Pour en savoir plus, consultez la documentation de Google Cloud Armor.
Étape suivante
- Pour découvrir comment activer Cloud CDN pour vos instances à équilibrage de charge HTTP(S) et vos buckets de stockage, consultez la page Utiliser Cloud CDN.
- Pour utiliser Cloud CDN avec Google Kubernetes Engine, consultez la page Configurer Cloud CDN via Ingress.
- Pour trouver des points de présence GFE, consultez la section Emplacements de cache.