در 2021 ما قابلیت Smart Tiered Cache را عرضه کردیم. ایده ساده بود: برای هر origin پشت سایت شما، Cloudflare بر اساس تاخیرِ لحظه‌ای، تنها یک دیتاسنتر upper-tier به‌عنوان بهترین مسیر انتخاب می‌کند. یک سوئیچ را روشن می‌کنید و ما سریع‌ترین مسیر از شبکه خودمان تا origin شما را پیدا می‌کنیم. ⚡️

این روش زمانی خوب کار می‌کند که آدرس IP origin در یک مکان ثابت قرار داشته باشد. اما بسیاری از originهای ابر عمومی این‌طور نیستند: آن‌ها معمولاً پشت anycast یا front-endهای منطقه‌ای قرار دارند، به‌طوری‌که یک IP می‌تواند هم‌زمان برای چند دیتاسنتر Cloudflare «نزدیک» به‌نظر برسد و پروب‌های تاخیر نتوانند یک مقصد قطعی را تشخیص دهند. Smart Tiered Cache در این وضعیت محافظه‌کار عمل می‌کند: وقتی برندهٔ واضحی دیده نشود، به چند upper tier بازمی‌گردد. هیچ چیز خراب نمی‌شود، اما همان مزیتی که یک tier نزدیک می‌دهد — یعنی کارایی بالاتر کش — از بین می‌رود. 🔁

قابلیت جدید Smart Tiered Cache for Public Cloud Regions این مشکل را با اجازه دادن به شما برای فرستادن یک «region hint» حل می‌کند. با این hint، Cloudflare می‌تواند originهای ابر عمومی را به منطقهٔ صحیح نگاشت کند و حتی وقتی IP به‌دلیل anycast یا ابهام ظاهری قابل تعیین نیست، upper tier اولیه و fallbackهای بهتری انتخاب کند. 🎯

Smart Tiered Cache یکی از محبوب‌ترین توپولوژی‌های tiered cache بین مشتریان ما شده و برای همهٔ پلن‌ها رایگان است. بخشی از کار ما همیشه بهبود مداوم همین سرویس بوده تا برای انواع بیشتری از معماری‌های origin به‌خوبی کار کند.

مثالِ بهبودهایی که تا امروز آوردیم:

نوامبر 2024: Smart Tiered Cache for R2 — حالا Smart Tiered Cache به‌صورت خودکار نزدیک‌ترین upper tier به محلی که bucket‌های R2 واقعاً در آن هستند را انتخاب می‌کند و بدون پیکربندی اضافی تاخیر را کم می‌کند. 📦

ژانویه 2025: Smart Tiered Cache for Load Balancing — Smart Tiered Cache توسعه یافت تا برای یک pool از Load Balancing، یک upper tier بهینهٔ واحد انتخاب کند؛ به این ترتیب همهٔ originهای داخل آن pool از یک کش مشترک استفاده می‌کنند و hit ratio بهبود می‌یابد.

هدف کل این بهبودها ساده است: زیرساخت origin مشتری را بفهمیم و به‌صورت خودکار بهترین تصمیم را برای همان معماری بگیریم. 🧠

با وجود این پیشرفت‌ها، کاربران یک ایراد مشترک داشتند: وقتی origin پشت anycast یا regional unicast بود، Smart Tiered Cache قادر به تعیین مکان origin نبود و در نتیجه نمی‌توانست یک upper tier واحد و بهینه انتخاب کند. این یک مورد نادر نیست — originهای روی ابرهای عمومی که پشت anycast قرار دارند، بخش قابل‌توجهی از اینترنت را تشکیل می‌دهند.

امروز این شکاف را برای originهای میزبانی‌شده روی AWS، GCP، Azure و Oracle Cloud می‌بندیم. ✅

چرا originهای anycastِ ابری متفاوت‌اند؟

روش کار Smart Tiered Cache بر مبنای اندازه‌گیری تاخیر از هر دیتاسنتر Cloudflare به آدرس IP origin است. دیتاسنتری که کمترین تاخیر را نشان دهد به‌عنوان upper tier انتخاب می‌شود و همهٔ cache missها از آن عبور می‌کنند. تمرکز cache missها در یک دیتاسنتر، باعث افزایش cache hit ratio، کاهش تعداد اتصال‌ها به origin و پایین آمدن تاخیر در fetch از origin می‌شود.

اما بسیاری از ارائه‌دهندگان کلود از anycast یا regional unicast برای load balancerها و front-endهای منطقه‌ای استفاده می‌کنند. وقتی ما همین IPها را پروب می‌کنیم، آن IP ممکن است برای چندین دیتاسنتر هم‌زمان «نزدیک» به‌نظر برسد، زیرا IP نمایندهٔ front-end ارائه‌دهندهٔ کلود است و نه لزوماً یک مکان فیزیکی واحد. دیتاسنترهای مختلف Cloudflare ممکن است به لبه‌های مختلف شبکهٔ ارائه‌دهندهٔ کلود متصل شوند و سپس ارائه‌دهنده درخواست را داخل شبکهٔ خودش به بک‌اند واقعی منتقل کند. در این شرایط Smart Tiered Cache نمی‌تواند با اطمینان یک upper tier واحد انتخاب کند. 🌐

در عمل، این می‌تواند منجر به hairpin شدن ترافیک شود و یک round-trip اضافیِ بین قاره‌ها اضافه کند. مثال: اگر origin شما در سنگاپور باشد اما پشت یک anycast IP ارائه‌دهندهٔ کلود قرار گرفته باشد، دیتاسنتر Chicago ما ممکن است در پروب‌ها کمترین تاخیر را نشان دهد و Chicago به‌عنوان upper tier انتخاب شود. نتیجه این است که درخواست کاربر آسیایی ابتدا به دیتاسنتر محلی Cloudflare می‌خورد، سپس به‌صورت بین قاره‌ای به Chicago رفته و از آنجا دوباره به origin در سنگاپور fetch می‌شود — یعنی دو مرتبه عبور از اقیانوس. این hairpin معمولاً صدها میلی‌ثانیه تاخیر اضافه می‌کند و یکی از پرتکرارترین مشکلات گزارش‌شده توسط مشتریان با originهای میزبانی‌شده روی ابر است.

برای تشخیص این back-and-forth غیرضروری، Smart Tiered Cache یاد گرفت که anycast بودن origin را با یک قید فیزیکی تشخیص دهد: سرعت نور. ما تاخیر پروب را از چند دیتاسنترِ checkpoint در سراسر جهان به آن origin اندازه‌گیری می‌کنیم. اگر مجموع تاخیرهای اندازه‌گیری‌شده از دو دیتاسنتر checkpoint سریع‌تر از آن باشد که نور در فیبر بتواند بین دو نقطهٔ فیزیکی سفر کند، یعنی origin باید از چند مکان به درخواست‌ها پاسخ دهد — یعنی anycast است. 🔬

وقتی Smart Tiered Cache متوجه هرکست بودن origin شد، محتاطانه عمل می‌کند: آن IP را به یک upper tier ثابت پین نمی‌کند، بلکه به توپولوژی‌ای با چند upper tier برمی‌گردد. tiered caching همچنان کار می‌کند، اما چون ترافیک بین چندین tier پخش می‌شود بجای یک، تعداد درخواست‌هایی که به origin می‌رسند افزایش پیدا می‌کند. برای بعضی چیدمان‌ها این معامله قابل قبول است؛ ولی اگر بخواهید یک upper tier نزدیک به origin داشته باشید (که روی public cloud و پشت anycast است)، تا امروز گزینهٔ خوب کمی وجود داشت — تا الان. 🚀

به ما منطقه را بگویید

از داشبورد Cloudflare به Caching > Tiered Cache > Origin Configuration بروید. آدرس IP origin خود را پیدا کنید، روی “Set Region Hint” کلیک کنید و منطقهٔ کلود را به ما بگویید (برای مثال aws:us-east-1 یا gcp:europe-west1). Smart Tiered Cache از آنجا ادامه می‌دهد. 📍

توجه کنید که در داشبورد، region hint فقط برای originهایی قابل تنظیم است که ما آنها را به‌عنوان anycast تشخیص داده‌ایم. در صفحهٔ Tiered Cache به جدول Origin Configuration بروید و آیکون ویرایش کنار یک IP origin را کلیک کنید تا region hint را تنظیم کنید.

می‌توانید به‌صورت تک IP یا به‌صورت bulk برای همهٔ IPها regionها را تنظیم کنید. علاوه بر داشبورد، همین تنظیمات از طریق API و Terraform هم قابل دسترسی است تا بتوانید آن را در جریان‌های infrastructure-as-code خود ادغام کنید. فعلاً با AWS، GCP، Azure و Oracle Cloud شروع کرده‌ایم و ارائه‌دهندگان بیشتری بعداً اضافه خواهند شد.

چگونه Smart Tiered Cache for Public Cloud Regions کار می‌کند

هر چند ساعت یک‌بار، ما آخرین فایل‌های IP range را از هر ارائه‌دهندهٔ cloud پشتیبانی‌شده می‌گیریم. این فایل‌ها هر region کلود را به IP prefixهای فعلی‌اش نگاشت می‌کنند، بنابراین وقتی یک provider ساب‌نتی اضافه، حذف یا reasssign کند، ما آن را می‌گیریم.

ما این ساب‌نت‌ها را با دیتابیس upper tier خودمان که از پروب‌های تاخیر پیوسته و تازه‌شونده هر 15 دقیقه ساخته شده تطبیق می‌دهیم. برای هر region کلود، هر ساب‌نتِ تطبیق‌شده یک رأی وزن‌دار می‌دهد بر اساس تخصیص فعلی آن به upper tier. آن upper tier که قوی‌ترین سیگنال را دارد به‌عنوان primary upper tier برای آن region انتخاب می‌شود. primary و fallback همیشه از نقاط حضور (PoP) متفاوت انتخاب می‌شوند تا از حذف همزمان هر دو در اثر از کار افتادن یک PoP جلوگیری شود. 🛡️

برخی regionها ممکن است دادهٔ پروب کافی نداشته باشند — مثلاً region جدید است یا هنوز هیچ originای در Cloudflare ندارند — در این صورت ما به جغرافیا تکیه می‌کنیم: نزدیک‌ترین Tier 1 PoP را انتخاب می‌کنیم. وقتی originها آنلاین می‌شوند و دادهٔ پروب جمع می‌شود، آن region آرام‌آرام از تخمین جغرافیایی به گزینه‌ای که پشت آن دادهٔ واقعی وجود دارد سوییچ می‌کند.

الان این یعنی همهٔ کارهای انتخاب regionِ بهینه برای کش — از پروب‌های مداوم تا انتخاب الگوریتمیک بهترین upper tier برای هر region، fallbackهای جغرافیایی و failover بین PoPها — در سمت ما اجرا می‌شود. کار شما فقط انتخاب region hint است. 🧩

اگر origin anycast شما روی یک public cloud قرار دارد، حالا می‌توانید این گزینه را روشن کنید. در داشبورد به Caching > Tiered Cache > Origin Configuration بروید، IP origin را پیدا کنید، Set Region Hint را بزنید و region مناسب را انتخاب کنید.

گام بعدی ما این است که به ارائه‌دهندگان بیشتری توسعه دهیم و Smart Tiered Cache را برای شناختن چیدمان‌های originِ بیشتری آموزش دهیم تا خودش بهترین مسیر را انتخاب کند. برای آشنایی بیشتر با اینکه tiered cache چطور می‌تواند برای سرویس شما مفید باشد، مستندات Tiered Cache را مطالعه کنید. 📚