Cloudflare a mis à jour Smart Tiered Cache pour résoudre un problème fréquent lorsque le serveur d’origine se trouve sur AWS, Google Cloud, Microsoft Azure ou Oracle Cloud. La plateforme permet désormais d’indiquer la région où l’application est réellement hébergée, même lorsque l’adresse IP du service est anycast et semble présente à plusieurs endroits simultanément.

La nouvelle fonctionnalité empêche une requête de parcourir inutilement des continents avant d’atteindre l’origine. Jusqu’à présent, Cloudflare pouvait détecter qu’une IP répondait avec une faible latence depuis plusieurs localisations, mais ne pouvait pas toujours déterminer l’emplacement exact du backend final. Face à cette ambiguïté, il utilisait plusieurs niveaux supérieurs de cache, une décision sûre mais qui réduisait la concentration des requêtes et, par conséquent, l’efficacité du système.

Smart Tiered Cache pour les clouds publics : les clés en 20 secondes

• Cloudflare permet d’indiquer la région cloud où se trouve l’origine.
• La fonction supporte initialement AWS, Google Cloud, Azure et Oracle Cloud.
• Accessible pour les plans Free, Pro, Business et Enterprise, sans coût supplémentaire.
• Smart Tiered Cache sélectionne un niveau supérieur principal proche de la région indiquée.
• Attribue aussi une localisation alternative dans un autre point de présence.
• Ce changement vise à éviter des parcours comme Asie-États-Unis-Asie pour atteindre une origine asiatique.
• La configuration peut se faire depuis le panneau d’administration, via l’API ou Terraform.
• Cloudflare maintient à jour les plages d’adresses IP des fournisseurs cloud.
• La sélection des niveaux supérieurs se recalculé à partir de mesures de latence.
• L’indication régionale ne déplace pas les données ni ne modifie la région contractée avec le fournisseur.

Tiered Cache organise les centres de données de Cloudflare selon une hiérarchie. Lorsqu’un nœud proche de l’utilisateur ne possède pas la ressource stockée, il consulte d’abord un autre nœud supérieur. Seul ce niveau peut requérir le contenu directement au serveur d’origine si aucune copie n’est disponible.

Ce regroupement évite que de nombreux centres de données n’établissent des connexions indépendantes vers la même infrastructure. L’objectif est d’augmenter le taux de hits en cache, réduire le trafic vers l’origine et diminuer le nombre de connexions à maintenir ouvertes par le serveur.

Le problème de la recherche d’un origine cloud via la latence

Lancé en 2021, Smart Tiered Cache repose sur une idée simple : mesurer la latence entre le réseau Cloudflare et l’origine, puis choisir comme niveau supérieur le centre de données le mieux connecté.

Le système fonctionne bien lorsque l’IP appartient à un serveur situé dans un endroit identifiable. Par exemple, si une origine est à Madrid, les tests depuis différents centres de données devraient montrer une tendance suffisante pour sélectionner un site proche.

La situation change avec les services publics de nuage. Les équilibrages de charge, points d’entrée régionaux et autres composants peuvent utiliser l’anycast ou des architectures régionales où une même IP répond depuis plusieurs emplacements du réseau du fournisseur.

La mesure ne peut plus forcément aboutir au serveur où tourne réellement l’application. Elle peut s’arrêter au point d’entrée le plus proche chez AWS, Azure, Google Cloud ou Oracle, qui transfère la requête par son réseau privé vers le backend.

Ainsi, une IP associée à une application déployée à Singapour peut sembler très proche depuis Chicago. Le centre de données américain arrive rapidement à la frontière du fournisseur cloud, mais cela ne signifie pas que le contenu s’y trouve réellement.

Si Cloudflare choisissait Chicago comme niveau supérieur, une requête effectuée par un utilisateur asiatique pourrait suivre ce parcours :

1. L’utilisateur se connecte à un nœud Cloudflare proche en Asie.
2. Ce nœud envoie une erreur de cache au niveau supérieur situé à Chicago.
3. Chicago demande le contenu au service cloud.
4. Le réseau du fournisseur transporte la requête jusqu’au backend à Singapour.
5. La réponse parcourt le trajet inverse.

Cet effet, appelé hairpinning, implique un trajet transcontinental qui n’apporte aucune réelle valeur. Selon les routes, cela peut ajouter des centaines de millisecondes et augmenter le trafic entre régions.

Pour éviter cette situation, Smart Tiered Cache ne fixait pas une IP ambiguë à un seul niveau supérieur, mais utilisait plusieurs, ce qui réduisait le risque de mal choisir une localisation. La cache fonctionnait toujours, mais le contenu était plus diffus, augmentant la probabilité que différents nœuds consultent directement l’origine.

La documentation de Cloudflare confirme désormais que les origines sur AWS, Google Cloud, Azure et Oracle peuvent utiliser une indication régionale pour que Smart Tiered Cache sélectionne un centre de données principal proche et un autre en localisation différente.

Une piste régionale pour améliorer le routage par Cloudflare

La solution consiste à fournir une indication explicite, comme aws:us-east-1 ou gcp:europe-west1. Cloudflare n’a plus besoin de deviner la localisation à partir du comportement d’une IP anycast : il connaît désormais le fournisseur et la région de référence.

Depuis le panneau d’administration, cette option se trouve dans Caching > Tiered Cache > Origin Configuration. L’administrateur localise l’IP ou le nom de l’origine, sélectionne Set Region Hint et choisit le fournisseur ainsi que la région.

La même configuration est accessible via l’API, facilitant son intégration dans des processus automatisés. Cloudflare prévoit aussi de gérer cela avec Terraform, intégrant cette indication comme partie de l’infrastructure code.

Ce « pense-bête » ne force pas l’utilisation d’un centre de données spécifique. Cloudflare conserve la décision finale basée sur ses mesures et l’état de son réseau. La contribution du client se limite au contexte fourni, que l’IP seule ne peut généralement pas fournir de manière fiable.

Pour construire cette correspondance, la société télécharge toutes les quelques heures des fichiers publics avec les plages d’adresses IP des fournisseurs concernés. Ces fichiers indiquent quels préfixes sont associés à chaque région et intègrent les changements lorsque le cloud ajoute, supprime ou réattribue des sous-réseaux.

Ces plages sont croisées avec une base de niveaux supérieurs construite à partir de mesures continues. La documentation de Cloudflare précise que les données de latence utilisées pour cette sélection sont actualisées toutes les 15 minutes.

Chaque sous-réseau associé à une région reçoit une pondération. La localisation avec la meilleure note devient le niveau supérieur principal. Une autre est choisie dans un autre point de présence pour éviter qu’un incident local n’affecte simultanément les deux routes.

En l’absence de données suffisantes, le système privilégie d’abord une localisation géographique proche, puis affine la décision à mesure que de nouvelles mesures arrivent, en s’appuyant sur la performance réelle observée.

Comment Cloudflare détecte qu’une IP est anycast

Avant d’autoriser la configuration régionale via le panneau, Cloudflare tente d’évaluer si l’IP répond depuis plusieurs sites. Pour cela, il utilise une limite physique qui ne peut pas être contournée par le routage : la vitesse de la lumière.

Il mesure la latence depuis plusieurs centres de référence. Si la somme de deux trajets est inférieure au temps nécessaire en fibre optique pour parcourir la distance entre ces points, la réponse ne peut pas provenir d’un seul serveur.

Par exemple, si deux points séparés de milliers de kilomètres reçoivent une réponse très rapide depuis la même IP, un seul endroit ne pourrait pas être aussi proche de tous les deux. La conclusion probable est que cette IP est annoncée depuis plusieurs sites.

Ce procédé permet de distinguer une origine unicast d’une entrée anycast, sans dépendre uniquement de bases IP géographiques, souvent obsolètes ou qui indiquent le siège administratif plutôt la localisation réelle.

Dans le panneau, les pistes régionales apparaissent pour les origines identifiées comme anycast par Cloudflare. Par API, on peut consulter la liste des fournisseurs et régions supportés. La documentation précise aussi qu’une topologie personnalisée a priorité, une indication régionale ne la remplaçant pas si une configuration spécifique a été fixée pour un client Enterprise.

Quels bénéfices pour une application

L’impact dépendra de l’architecture, du volume de trafic et de la capacité de cache du site. Toutes ne verront pas forcément une réduction sensible de la latence.

L’amélioration se verra surtout lorsque plusieurs conditions sont réunies :

• l’origine repose derrière une IP anycast ou régionale ambiguë ;
• la localisation précédente était éloignée du backend ;
• le contenu cacheable est conséquent ;
• le service reçoit du trafic depuis plusieurs régions ;
• l’origine supporte un grand nombre de requêtes répétées à cause de cache échoué.

Concentrer les requêtes sur un niveau supérieur augmente la probabilité d’y trouver une copie, tout en diminuant le nombre de connexions et la quantité de transfert vers le fournisseur cloud, ce qui peut réduire la charge du backend et les coûts de sortie de données.

Cette fonction ne corrige pas une politique de cache inefficace : si les réponses sont marquées privées, ont une faible durée de vie ou changent souvent selon l’utilisateur, le niveau supérieur aura peu de chances de réutiliser le contenu.

Elle ne remplace pas une architecture multirégionale. La piste indique où se situe une origine, mais ne duplique pas une application ni ne déplace automatiquement le trafic entre plusieurs régions cloud. Les clients gérant plusieurs backend doivent maintenir leurs pools, équilibrages et politiques de cache activement.

Un changement d’IP ou d’enregistrements DNS peut aussi entraîner la sélection d’un autre niveau supérieur. Pendant cette transition, le nombre d’échecs (MISS) augmentera temporairement jusqu’à ce que la nouvelle cache se remplisse. Cloudflare recommande de vérifier le champ CacheTieredFill dans les logs pour confirmer si Tiered Cache a été impliqué dans la requête.

La configuration est simple : il suffit de déclarer une région. Son impact peut être considérable car il fournit au système une donnée que l’anycast ne pouvait pas révéler jusqu’ici.

Ainsi, Cloudflare transforme une localisation connue en une indication opérationnelle pour son CDN. La réseau continue de prendre des décisions dynamiques, mais évite de confondre proximité du bord avec proximité réelle du serveur d’application.

Questions fréquentes

Qu’est-ce que Smart Tiered Cache ?
Il s’agit d’une hiérarchie de cache de Cloudflare qui concentre l’accès à l’origine sur un niveau supérieur sélectionné automatiquement, plutôt que de laisser tous les centres de données consulter directement.

À quoi sert l’indication de région cloud ?
Elle sert à signaler explicitement la localisation réelle d’un backend situé derrière une adresse anycast ou difficile à localiser par latency.

Quels fournisseurs sont supportés ?
La première version est compatible avec AWS, Google Cloud, Microsoft Azure et Oracle Cloud.

Y a-t-il un coût supplémentaire ?
Cloudflare indique que Smart Tiered Cache et l’indication de région sont disponibles sans coût additionnel pour les plans Free, Pro, Business et Enterprise.