Cache invers (reverse-Cache)

Cache piloté par URL standard

Dans la plupart des sites Web, les objets sont nommés et identifiés de manière unique par leur URL qui est mappée à un seul fichier ou ressource dans le système de fichiers du serveur Web. Dans ce cas, une URL identifie une ressource unique dans tout l'Internet. C'est ainsi que le cache très standard identifie l'objet mis en cache. Cependant, pour certaines raisons, certains sites Web utilisent des stratégies de dénomination dynamique (ce qui ne signifie pas que le contenu lui-même est dynamique). Cela combat les caches standard et nécessite d'utiliser des techniques avancées de nommage de contenu.

URL canoniques

Lorsque les sites Web sont basés sur CDN, une seule ressource peut être adressée par plusieurs URL en fonction de son emplacement dans le CDN. De la même manière, les plates-formes vidéo et les plates-formes de mise à jour encodent de nombreuses informations sur les utilisateurs et d'autres informations contextuelles dans les URL. Pour cette raison, un grand nombre d'URL pointent vers un seul objet, ce qui empêche le cache basé sur une URL standard de fonctionner correctement.

En outre, certains sites Web ajoutent une chaîne de requête indésirable avec des compteurs ou même des valeurs aléatoires. Cette technique de destruction de cache est utilisée pour lutter contre les caches. La plupart des CMS utilisent cette astuce pour s'assurer que le contenu affiché est à jour.

Le mécanisme d'URL canonique permet de contourner ces problèmes et de forger un identifiant unique pour ces contenus. Grâce à cette technologie, le mécanisme de mise en cache standard et entièrement compatible avec HTTP reste applicable là où d'autres caches purement URL risqueraient d'échouer.

Mise en cache basée sur le contenu

Parfois, les données peuvent ne pas être récupérées par l'URL, car l'URL des objets change aléatoirement à chaque requête de manière à ce que même le mécanisme URL canonique échoue. En conséquence, des milliers ou même des millions d'URL différents pointent vers un seul objet.

Dans ce cas, un objet mis en cache ne peut plus être récupéré par une URL. Cependant, il est toujours possible de mettre en cache et de récupérer des objets en fonction de leur contenu, en utilisant la signature de contenu comme nom plutôt que comme URL changeant. C'est le mode Content Driven

En combinant le mode basé sur l'URL standard et le mode basé sur le contenu UBfast gère un cache hybride.

Stratégie de cache par domaine / par URL

La politique de cache est régie par un profil de cache Cache Profilequi rassemble tous les paramètres liés au stockage, à la durée de vie et au mécanisme de revalidation. À son tour, le profil de cache est attaché à un profil de gestionnaire de requêtes qui peut être sélectionné pour n'importe quelle partie de la requête HTTP. Cela permet de définir une politique de cache concernant les domaines, les URL ou toute autre information de requête HTTP telle que l'user-agent, le cookie, l'IP client, la géolocalisation etc.

Fraîcheur et contrôle du temps de vie

Par défaut, la fraîcheur ou la durée de vie des objets stockés dans le cache est contrôlée par les directives de contrôle de cache présentes dans l'entête$ de réponse HTTP. Cependant, il est possible de dépasser ces directives en définissant des paramètres de durée de vie ou de date d'expiration dans le profil de cache. A l'inverse, il est également possible de forcer un objet à être strictement revalidé contre le serveur d'origine ou même de l'empêcher d'être stocké comme avec un contrôle de cache sans magasin

Query-string et règle de mise en cache des cookies

Les query-strings et les cookies sont des indications que l'objet demandé est dynamique et ne doit pas être stocké dans le cache. Une bonne heuristique consiste à ne pas mettre en cache de tels objets. Cependant, dans de nombreux cas, la requête d'objets statiques comporte des cookies et une query-string. UBfast permet de désactiver ces règles pour des URL données.

Utilisation du cache en tant que cache inverse

Le cache inversé (reverse-cache est utilisé lorsque UBfast est déployé en tant que proxy inverse reverse-proxy devant un serveur d'applications. Dans ce cas, le cache n'est plus utilisé pour économiser la bande passante. Il est plutôt utilisé pour décharger les serveurs d'applications.

Le cache est ensuite configuré pour fonctionner en mode sticky. Lorsqu'il est utilisé dans ce mode, un objet disponible dans le cache est servi sans aucune revalidation sur les serveurs d'applications. Ainsi, le serveur ne sera plus impliqué pour servir cet objet même pour la revalidation. Cela conduit à couper jusqu'à 80% des demandes et à soulager le serveur d'applications qui se consacre uniquement à la génération de contenu dynamique d'application.

Architecture de stockage de cache

Le cache de UBfast gère une architecture de stockage hybride multicouche, allant d'un stockage interne compact très rapide à un système de stockage distribué. L'architecture de stockage est répartie sur 4 couches de stockage: compact, fast, big et tank.

Compact
Ce stockage réside dans la RAM. Cela permet d'utiliser le cache comme un cache inversé. Les petits objets sont envoyés avec un temps zéro au premier octet.
Big
Ce stockage est basé sur un ou plusieurs disques SSD ultra haute performance de 1 Tera Byte.
Big
Ce stockage est basé sur des disques SAS intégrés. Sa capacité moyenne est de 48 téraoctets.
Tank
Ce stockage est utilisé pour un stockage à long terme. Il est basé sur un système de stockage SAN dont la capacité est de plusieurs Peta Octets.

Les objets sont déplacés entre les niveaux de stockage par un démon de gestion des stockage (Storage Management daemon. La stratégie de gestion du stockage est basée sur l'utilisation des objets observés, tels que la fréquence de d'utilisation et les règles de configuration. Lorsque la plus grande couche de stockage disponible est pleine (la plupart du temps "big" ou "tank"), les données sont supprimées en fonction d'une stratégie LRU

Un cache petit mais efficient

La version compacte de UBfast s'exécute sur un seul disque SSD de 1 Téraoctets, c'est-à-dire avec seulement les couches de stockage compact et fast. C'est une taille assez petite pour un cache. Cependant, étant donné que le cache est piloté par une politique de cache très précise et très performante, il parvient à atteindre un taux de succès de 35% avec un cache très rentable.