Cloudflare heeft Smart Tiered Cache geüpdatet om een veelvoorkomend probleem op te lossen bij servers die zich bevinden op AWS, Google Cloud, Microsoft Azure of Oracle Cloud. Het platform stelt nu in staat om de regio waarin de applicatie echt is gehost, aan te geven, zelfs wanneer het IP-adres van de service anycast is en lijkt op meerdere locaties aanwezig te zijn.
De nieuwe functie voorkomt dat een verzoek onnodig door continenten reist voordat het bij de bron aankomt. Tot voor kort kon Cloudflare detecteren dat een IP met lage latency reageerde vanuit verschillende locaties, maar kon het niet altijd achterhalen waar de uiteindelijke backend zich bevond. In afwachting van die duidelijkheid gebruikte het systeem meerdere hogere caches, wat een veilige keuze was die de concentratie van verzoeken verminderde en daarmee de efficiëntie van het systeem beperkte.
Smart Tiered Cache voor publieke clouds: de kern in 20 seconden
- Cloudflare maakt het mogelijk om de cloud-regio waar de bron zich bevindt, te rapporteren.
- De functie ondersteunt aanvankelijk AWS, Google Cloud, Azure en Oracle Cloud.
- Beschikbaar voor de plannen Free, Pro, Business en Enterprise zonder extra kosten.
- Smart Tiered Cache kiest een hoofdlevel dicht bij de aangegeven regio.
- Daarnaast wijst het ook een alternatieve locatie aan op een andere aanwezigheidspunt.
- De wijziging is bedoeld om routes zoals Azië- Verenigde Staten-Azië te voorkomen bij het benaderen van Aziatische bronnen.
- De configuratie kan via het dashboard, de API of Terraform worden gedaan.
- Cloudflare houdt de IP-ranges van de cloudproviders actueel.
- De basis voor het kiezen van hogere niveaus wordt herberekend op basis van latencymetingen.
- De regionale indicatie verplaatst geen gegevens en verandert de contractuele regio bij de provider niet.
Tiered Cache organiseert de datacenters van Cloudflare in een hiërarchie. Wanneer een knooppunt dicht bij de gebruiker geen resource heeft, vraagt het eerst aan een hoger niveau. Alleen dat niveau kan de inhoud opvragen bij de bron als het ook niet in de cache ligt.
Deze aanpak voorkomt dat tientallen datacenters aparte verbindingen opzetten met dezelfde infrastructuur. Het verwachte resultaat is een hogere cache hit rate, minder verkeer naar de bron en minder openstaande verbindingen op de server.
Het probleem van het vinden van een cloud-bron via latentie
Smart Tiered Cache werd in 2021 geïntroduceerd met een relatief eenvoudige trem: de latentie meten vanaf het Cloudflare-netwerk tot de bron en het dichtstbijzijnde datacenter selecteren als hoger niveau.
Het systeem werkt goed wanneer het IP van een server duidelijk een locatie heeft. Bijvoorbeeld, als een bron in Madrid staat, zouden metingen vanaf verschillende datacenters een duidelijke voorkeur aangeven voor een locatie in de buurt.
De situatie wordt complexer bij publieke cloud-diensten. Load balancers, regionale gateways en andere componenten kunnen anycast gebruiken of regionale architecturen hanteren waarbij een IP-adres van meerdere plekken in het netwerk van de provider kan reageren.
De meting bereikt niet noodzakelijk de server waar de applicatie draait. Het kan eindigen bij het dichtstbijzijnde toegangspunt van AWS, Azure, Google Cloud of Oracle, dat de aanvraag daarna via zijn privé-netwerk naar de backend transporteert.
Zo kan een IP die gekoppeld is aan een applicatie in Singapore heel nabij lijken vanuit Chicago. Het Amerikaanse datacenter bereikt de edge van de cloudprovider snel, maar dat betekent niet dat de content daar ook ligt.
Als Cloudflare Singapore als hoofdniveau zou kiezen, kan een verzoek van een Aziatische gebruiker deze route volgen:
- De gebruiker maakt verbinding met een dicht bijzijnd Cloudflare-knooppunt in Azië.
- Het knooppunt meldt een cache-fout aan het hogere niveau in Singapore.
- Singapore vraagt de inhoud op bij de clouddienst.
- Het netwerk van de provider transporteert de aanvraag naar de backend in Singapore.
- De respons reist terug langs dezelfde route.
Dit fenomeen, bekend als hairpinning, introduceert een transcontinentale reis die geen waarde toevoegt. In sommige routes kan dit honderden milliseconden extra latency veroorzaken en het regionale verkeer verhogen.
Wanneer Smart Tiered Cache een ambigu IP herkent, vermijdt het dat deze aan één hoofdniveau wordt gekoppeld. In plaats daarvan gebruikt het meerdere niveaus, wat het risico op verkeerde locatiekeuze vermindert. De cache blijft functioneren, maar inhoud wordt meer gespreid en verschillende knooppunten kunnen vaker het origineel raadplegen.
| Type bron | Gebruikelijke beslissing |
|---|---|
| Unicast IP met duidelijke locatie | Niveau dicht bij de bron |
| Anycast IP zonder regionale info | Meerdere hogere niveaus |
| Publieke cloud met aangegeven regio | Dichtbij hoofdniveau en aparte alternatieve locatie |
| Aangepaste topologie | Configuratie door de klant prevails |
De documentatie van Cloudflare bevestigt dat bronnen op AWS, Google Cloud, Azure en Oracle nu een regionale indicatie kunnen krijgen, zodat Smart Tiered Cache een dicht bijzijnd hoofdcentrum en een ander alternatief in een andere locatie kan kiezen.
Een regionale aanwijzing voor betere routekeuze door Cloudflare
De oplossing bestaat erin een expliciete aanwijzing te geven, zoals aws:us-east-1 of gcp:europe-west1. Cloudflare hoeft geen hele locatie meer af te leiden uit het gedrag van een anycast IP: het weet welk provider en welke regio als referentie moet dienen.
In het dashboard vindt men deze optie onder Caching > Tiered Cache > Origin Configuration. De beheerder zoekt de IP of naam van de bron, selecteert Set Region Hint en kiest de provider en regio.
Deze instelling is ook via de API beschikbaar, waardoor automatisering mogelijk is. Cloudflare biedt ook beheer via Terraform, zodat de koppeling tussen bron en regio als code wordt vastgelegd.
De aanwijzing dwingt niet tot het gebruik van een specifiek datacenter. Cloudflare blijft de uiteindelijke beslissing nemen op basis van haar metingen en netwerkposities. De klant levert enkel de context die niet betrouwbaar uit IP-gegevens kan worden afgeleid.
Om die koppeling te bouwen downloadt het bedrijf elk paar uur de openbare IP-rangestanden van de ondersteunde providers. Deze bestanden geven aan welke prefixen bij welke regio horen en worden bijgewerkt bij wijzigingen, zoals nieuwe subnetten of herstructureringen.
Daarna worden die rangestanden vergeleken met een voortdurende meting op hogere niveaus. Volgens de technische uitleg van Cloudflare worden de latencydatas die worden gebruikt voor die selectie elke 15 minuten geüpdatet.
Elk subnet dat aan een regio is gekoppeld, krijgt een gewogen stem. De locatie met de sterkste indicatie wordt het hoofdniveau. Een alternatief wordt gekozen op een ander aanwezigheidspunt om te voorkomen dat een lokaal probleem beide routes beïnvloedt.
Wanneer er nog niet voldoende gegevens beschikbaar zijn, gebruikt het systeem aanvankelijk de geografische ligging om een van de dichtstbijzijnde hoofdknooppunten te selecteren. Naarmate er meer echte gegevens binnenkomen, vervangt het die schatting door een prestatiegebaseerde keuze.
Hoe Cloudflare herkent of een IP anycast is
Voordat een regionale aanwijzing wordt toegelaten, probeert Cloudflare te bepalen of het IP vanaf meerdere locaties reageert. Hiervoor gebruikt het de snelheid van het licht, een beperking die niet door routing zou kunnen worden beïnvloed.
Het bedrijf meet de latency van verschillende referentiepunten. Als de som van twee routes minder is dan de fysiek noodzakelijke reistijd tussen beide locaties, kan de respons niet van één enkele server komen.
Stel dat twee punten, afgelegen van elkaar, zeer snel reageren via dezelfde IP. Een bron op één locatie kan niet tegelijk zo dicht bij beide liggen; de meest waarschijnlijke verklaring is dat het adres vanaf meerdere locaties wordt geadverteerd.
Deze methode maakt het mogelijk om te onderscheiden of een IP unicast of anycast is, zonder te vertrouwen op verouderde geografische IP-gegevens die bijvoorbeeld de locatie van de administratieve inzamelingspunt kunnen aangeven in plaats van de werkelijke locatie van de service.
In het dashboard worden regional hints getoond voor bronnen die door Cloudflare als anycast zijn geïdentificeerd. Via de API kan het catalogus van ondersteunde providers en regio’s worden geraadpleegd. De documentatie vermeldt ook dat een aangepaste topologie prioriteit heeft, zodat regionale hints geen configuraties overschrijven die specifiek voor een eindklant zijn ingesteld.
Welke verbeteringen kan een app verwachten?
De impact hangt af van de architectuur, het verkeer en de hoeveelheid cachebare inhoud. Niet alle websites zullen een duidelijke vermindering van latency ondervinden.
De verbetering wordt het duidelijkst wanneer aan de volgende voorwaarden wordt voldaan:
- De bron bevindt zich achter een anycast- of regionale ambigu IP;
- De eerder gekozen locatie ver van de backend lag;
- Er is een aanzienlijke hoeveelheid cachebare inhoud;
- De service ontvangt verkeer uit meerdere regio’s;
- De bron ondersteunt veel herhaalde verzoeken door cache-fouten.
Door verzoeken te concentreren op een hoger niveau, vergroot de kans op een cache-kopie op dat niveau. Het vermindert ook de verbindingen en de datatransfers naar de cloudprovider, wat zowel de belasting op de backend als de egress-kosten kan verlagen.
Deze functie corrigeert niet een slecht cachebeleid. Als de antwoorden privé worden gemaakt, korte TTL’s krijgen of voortdurend per gebruiker veranderen, zal het hogere niveau weinig wijzen kunnen benutten.
Het vervangt ook geen multi-regio architectuur. De aanwijzing geeft slechts de locatie aan van een bron, maar verschuift niet automatisch het verkeer tussen meerdere cloudregio’s. Klanten met verschillende backends moeten hun pools, loadbalancers en cache policies correct beheren.
Veranderingen in IP of DNS kunnen ook leiden tot een wijziging in de selectie van een hoger niveau door Smart Tiered Cache. Tijdens die overgang kunnen tijdelijk meerdere MISS-meldingen worden gegenereerd terwijl de nieuwe cache wordt opgebouwd. Cloudflare raadt aan het veld CacheTieredFill in de logs te controleren om te zien of Tiered Cache heeft ingegrepen bij een verzoek.
De configuratiewijziging is klein: het volstaat om een regio op te geven. De technische impact kan echter groot zijn omdat het het systeem een belangrijke informatie geeft die voorheen werd verborgen door anycast-routing.
Cloudflare maakt van een bekende locatie een operationele indicator voor haar CDN. Het netwerk blijft dynamische beslissingen nemen, maar stopt met verwarde interpretaties van nabijheid tot de edge van een cloud met de fysieke nabijheid van de server waar de applicatie zich bevindt.
Veelgestelde vragen
Wat is Smart Tiered Cache?
Het is een Cloudflare-cachingtopologie die de toegang tot de bron concentreert op een automatisch geselecteerd hoger niveau, in plaats van dat alle datacenters rechtstreeks vragen.
Waarvoor dient de regionale indicatie?
Het geeft de werkelijke locatie van een backend door die zich bevindt achter een anycast- of regionale entry, die moeilijk te bepalen is via latentie.
Welke providers worden ondersteund?
De eerste versie ondersteunt AWS, Google Cloud, Microsoft Azure en Oracle Cloud.
Is er een extra kost verbonden?
Cloudflare geeft aan dat Smart Tiered Cache en regio-indicaties gratis worden aangeboden voor de plannen Free, Pro, Business en Enterprise.