CDN ve Teslimat
Edge Cache Nedir?
Bir sayfa yüklendiğinde içerik her seferinde origin sunucudan gelmek zorunda değildir. Eğer aynı içerik daha önce başka bir kullanıcıya sunulmuşsa ve geçerliliğini yitirmemişse, edge cache devreye girer ve origin'e hiç ulaşmadan yanıtı iletir. Bu mekanizma hem gecikmeyi azaltır hem de sunucu üzerindeki baskıyı hafifletir.
CDN'in site hızına katkısı büyük ölçüde coğrafi yakınlıktan gelir; ama bu yakınlığın değer üretebilmesi için edge düğümünün içeriği elinde tutması gerekir. Edge cache olmadan CDN yalnızca bir ağ yolu kısaltıcısına dönüşür; her istek için origin'e döner, gecikme ve yük azalmaz. Kısacası edge cache, CDN altyapısının işlevini yerine getiren temel mekanizmadır.
Bu mekanizmanın nasıl çalıştığını, Cache-Control başlıklarıyla ilişkisini ve konfigürasyonun neden bu kadar belirleyici olduğunu anlamak, edge cache'ten gerçek kazanım elde etmenin önkoşuludur.
Origin cache ile temel ayrım
Origin sunucu kendi önbelleğini de tutabilir: uygulama katmanı cache'i, veritabanı sorgu cache'i ya da sunucu taraflı bir cache katmanı bu kapsamda sayılır. Bu önbellek origin'de çalışır ve origin'den yanıt üretir. Edge cache ise origin'in dışında, kullanıcıya çok daha yakın bir noktada çalışır ve origin'in yanıt üretmesine hiç gerek kalmadan isteği yanıtlayabilir.
İki katman çoğu zaman birbirini tamamlayıcı biçimde kullanılır. Origin cache tekrarlayan veritabanı sorgularını azaltırken, edge cache origin'e ulaşan istek sayısını doğrudan kısar. Ama ikisini aynı şey olarak düşünmek, gecikme üzerindeki etkilerini yanlış yorumlamaya yol açar. Origin cache TTFB'yi iyileştirir; edge cache ise kullanıcı ile içerik arasındaki fiziksel mesafeyi kısaltır. Bu ayrım, performans sorununu doğru katmanda aramak için önemlidir.
Edge node'un içeriği tutma süreci
Bir kullanıcı edge node'a ilk kez istek gönderdiğinde, node bu içeriği önbellekte bulamaz; buna cache miss denir. Node origin'e yönelir, yanıtı alır ve iki şey yapar: yanıtı kullanıcıya iletir ve bir kopyasını kendi önbelleğine yazar. Sonraki istekte aynı içerik istenirse ve geçerliliği devam ediyorsa doğrudan önbellekten yanıtlanır; buna cache hit denir.
Bu süreçte iki değişken belirleyicidir: içeriğin önbellekte ne kadar kalacağı (TTL — time to live) ve önbelleğe alınıp alınmayacağına kimin karar verdiği. TTL origin sunucusunun gönderdiği Cache-Control başlığıyla belirlenir; CDN konfigürasyonuyla da geçersiz kılınabilir. Kimin kararının öncelikli olduğu sağlayıcıya ve ayara göre değişir. Bu belirsizlik, düşük cache hit oranlarının en yaygın nedenlerinden biridir.
Cache-Control başlıklarının edge davranışına etkisi
Cache-Control başlıkları tarayıcı katmanında nasıl çalışıyorsa, aynı başlıklar edge düğümünde de yorumlanır; ancak bazı direktifler farklı davranır. Cache-Control: no-store edge'e de sakla deme; no-cache ise her istek için yeniden doğrulama talep eder. s-maxage direktifi özellikle paylaşılan önbellekler — yani edge gibi aracı katmanlar — için geçerlidir ve max-age değerini geçersiz kılar.
Pratikte origin sunucu s-maxage=3600 gönderirse bu içerik edge'de bir saat tutulur. Tarayıcı için farklı bir değer istenirse max-age ayrıca belirtilebilir. Bu iki direktifi birbirinden bağımsız kullanmak, edge ve tarayıcı davranışları üzerinde daha ince kontrol sağlar. Origin başlıklarını hiç ayarlamadan yalnızca CDN kontrol paneline güvenmek ise cache davranışını tahmin edilemez hale getirir; hangi kaynağın ne zaman dolacağını bilmek imkânsızlaşır.
Statik varlıklar için edge avantajı
CSS, JavaScript, font dosyaları ve görseller edge cache'in en rahat çalıştığı alandır. Bu dosyalar içeriğe göre değişmez; bir kez alınır ve uzun süre geçerliliğini korur. Doğru ayarlandığında TTL günler, hatta haftalar olabilir. Bu süre boyunca aynı dosyayı isteyen kullanıcılar origin'e hiç ulaşmadan en yakın edge düğümünden yanıt alır.
Burada kritik bir gerçeklik vardır: içerik değiştiğinde eski sürüm edge'de beklemeye devam edebilir. Bu sorunu çözmenin en yaygın yolu içerik parmak izi kullanmaktır. Dosya adına ya da URL'ye hash eklenir; içerik değiştiğinde URL de değişir, yeni URL için cache miss oluşur, eski URL kendi TTL'ini tüketene kadar erişilmez olur. Bu yaklaşım hem uzun TTL hem de anlık güncelleme avantajlarını birleştirir ve statik varlık önbelleğinin temel stratejisi haline gelmiştir.
Dinamik içerikte sınır nereden başlar
Edge cache her içerik türü için eşit ölçüde çalışmaz. Kişiselleştirilmiş sayfalar, oturum bilgisine göre üretilen yanıtlar ve gerçek zamanlı veri içeren içerikler edge'de önbelleğe alınamaz ya da alınmamalıdır. Kullanıcıya özel bir hesap sayfasını edge'de önbelleğe almak, sonraki farklı bir kullanıcıya yanlış içerik teslim etme riskini doğurur. Bu tür bir hata güvenlik açığı olarak da değerlendirilebilir.
Bu sınırı belirlemek hem teknik hem de içerik kararıdır. Ürün listeleme sayfası önbelleğe alınabilir; sipariş geçmişi sayfası alınamaz. Ana sayfa HTML'i önbelleğe alınabilir ama içinde oturum durumuna göre değişen bir alan varsa dikkat gerekir. Bu yüzden bazı CDN yapılandırmalarında HTML belgeleri hiç önbelleğe alınmazken varlık dosyaları agresif biçimde önbelleğe alınır. Bu yaklaşım çoğu site için makul ve güvenli bir başlangıç noktasıdır.
Coğrafi dağılım ve istek yönlendirme
Edge cache, dünya genelinde birden fazla veri merkezine dağıtılmış düğümlere dayanır. Kullanıcı bir istekte bulunduğunda CDN, DNS çözümlemesi veya anycast yönlendirmesiyle isteği coğrafi olarak en yakın edge düğümüne gönderir. O düğümde cache hit oluşursa yanıt birkaç milisaniye içinde gelir; yoksa origin'e gidilir.
Bu dağılımın önemli bir sonucu vardır: her düğüm kendi önbelleğini bağımsız tutar. Tokyo'daki düğümde cache miss oluşması, Londra'daki düğümün aynı içeriği önbellekte tutmasını etkilemez. Bu bağımsızlık aynı zamanda bir ısınma sorununa yol açar: yeni içerik yayınlandığında ya da mevcut içerik güncellendiğinde tüm coğrafi düğümler ilk istekte origin'e dönmek zorunda kalır. Büyük lansman veya beklenmedik trafik artışı öncesinde bu gerçekliği hesaba katmak, ani yük sorunlarını önceden önler.
Purge ve geçersiz kılma mekanizması
TTL dolmadan önce edge'deki içeriği geçersiz kılmak gerektiğinde purge mekanizması devreye girer. Bir URL'yi, bir tag'i ya da tüm önbelleği temizlemek CDN API'si veya kontrol paneli üzerinden yapılabilir. Bazı CDN sağlayıcıları anlık purge sunarken bazılarında gecikme birkaç saniye ile birkaç dakika arasında değişebilir; bu fark acil içerik düzeltmelerinde kritik hale gelir.
Purge ihtiyacının en sık ortaya çıktığı durumlar şunlardır: acil içerik düzeltmeleri, ürün fiyatı güncellemeleri, haber başlığı değişiklikleri. Bu tür güncellemelerin hızla yansıtılması gerekiyorsa uzun TTL değerleri ve hızlı purge mekanizması birlikte planlanmalıdır. Yalnızca uzun TTL'e güvenmek güncelleme gecikmesine; yalnızca kısa TTL kullanmak yüksek origin yüküne yol açar. İki uç arasındaki dengeyi bulmak, edge cache konfigürasyonunun en çok düşünülmesi gereken boyutudur.
Cache hit oranı ve ısınma süreci
Edge cache'in etkinliğini ölçmek için kullanılan temel metrik cache hit oranıdır: toplam isteklerin kaçı edge'den yanıtlandı? Bu oran düşükse ya TTL yanlış ayarlanmıştır, ya içerik sık sık değişiyordur, ya da önbelleğe alınamayan içerik oranı yüksektir. Üç durum da farklı müdahale gerektirir; hepsini "CDN performansı düşük" başlığı altında toplamak kökeni çözmeyi zorlaştırır.
Yeni bir site ya da yeni bir edge lokasyonu için önbellek başlangıçta boştur. Trafik arttıkça önbellek dolar ve hit oranı yükselir. Bazı sağlayıcılar popüler URL'leri proaktif olarak önbelleğe alabilir; ama bu özellik standart değildir. Çoğu durumda ilk trafik dalgası origin'i doğrudan vurur. Yüksek trafik dönemlerinden önce bu beklentinin karşılanıp karşılanamayacağını değerlendirmek, kapasiteyi doğru planlama açısından önemlidir.
Oturum ve kimlik doğrulama gerektiren sayfalar
Kimlik doğrulama gerektiren sayfalar edge cache için özel bir dikkat alanıdır. Authorization başlığı içeren istekler ya da Set-Cookie döndüren yanıtlar, çoğu CDN konfigürasyonunda varsayılan olarak önbelleğe alınmaz. Bu davranış kasıtlıdır ve güvenlik açısından yerindedir.
Ancak oturumlu kullanıcılara hizmet eden sitelerde bile önbelleğe alınabilecek unsurlar vardır. Giriş sayfasının HTML'i, herkese açık ürün açıklamaları, paylaşımlı medya dosyaları bunlar arasındadır. Oturum durumunu taşıyan içerikle taşımayan içeriği ayırt eden bir strateji kurabilmek, edge cache'in kişiselleştirme ağırlıklı sitelerde de değer üretmesini sağlar. Bu ayrımı net çizmeden konfigürasyona başlamak, ilerleyen aşamada hem güvenlik hem de performans sorunlarına zemin hazırlar.
Edge cache ile origin yük ilişkisi
Cache hit oranı yüksek olduğunda edge cache, origin üzerindeki yükü dramatik biçimde azaltır. Günde bir milyon istek gelen bir sitede yüzde doksanlık hit oranı, origin'e yalnızca yüz bin istek ulaşması demektir. Bu fark sunucu kapasitesi planlamasını, ani trafik artışlarına karşı direnci ve altyapı maliyetini doğrudan etkiler.
Ama bu ilişki her yönde simetrik değildir. Edge miss durumunda kullanıcı hem edge'e gidip gelme süresini hem de origin'in yanıt üretme süresini bekler. Cache hit oranı düşükse toplam gecikme, edge kullanmayan bir senaryodan daha yüksek olabilir. Bu asimetri, edge cache'in her koşulda gecikme azaltıcı olduğu varsayımını kırar ve hit oranını düzenli olarak izlemeyi zorunlu kılar.
Ne zaman anlamlı fark yaratır
Edge cache en çok statik veya statik ağırlıklı sitelerde, coğrafi olarak dağınık kullanıcı kitlesine hizmet eden platformlarda ve ani trafik artışlarına hazırlanmak isteyen servislerde anlamlı fark yaratır. Global bir içerik platformu, yazılım dağıtım altyapısı ya da yüksek trafikli haber sitesi bu kategorinin belirgin örnekleridir.
Kullanıcı kitlesinin büyük çoğunluğu origin'e coğrafi olarak yakınsa ve trafik düzenli ve tahmin edilebilirse edge cache katkısı hâlâ vardır ama daha mütevazı kalır. LCP süresini iyileştirmeye çalışıyorsanız hero görsel veya ilk HTML gibi kritik kaynakların edge'den gelip gelmediğine bakmak, cache stratejisinin neye odaklanması gerektiğini hızla ortaya koyar. Büyük kaynak sayısı yerine kritik kaynakların hit oranına odaklanmak genellikle daha etkili bir yaklaşımdır.
Konfigürasyonun CDN sağlayıcısına göre farklılaşması
Edge cache davranışı CDN sağlayıcısına göre önemli farklılıklar gösterir. Bazı sağlayıcılar origin başlıklarını esas alır; bazıları kendi kurallarını origin başlıklarının önüne geçirir. Bazıları Vary başlığını destekler ve aynı URL için farklı içerik sürümleri tutabilir; bazıları Vary desteğini sınırlar ya da hiç desteklemez. Bu farklar, bir CDN'den diğerine geçerken aynı konfigürasyonun aynı sonucu vermediği anlamına gelir.
Image CDN gibi özel önbellek katmanlarında da edge davranışı konfigürasyon ağırlıklıdır; format ve boyut kombinasyonlarına göre farklı cache anahtarları oluşturulur ve her kombinasyon bağımsız biçimde ısınmak zorunda kalır. Her sağlayıcının cache anahtar mantığını, varsayılan TTL atamalarını ve purge mekanizmasının sınırlarını anlamak, edge cache'in beklenen biçimde çalışıp çalışmadığını değerlendirmenin önkoşuludur. Kontrol paneliyle konfigürasyon yapmak yerine önce bu temel davranışı belgelemek, ilerleyen sorunları çok daha kolay çözülebilir hale getirir.
Edge cache, CDN altyapısının en gözle görülür kazanımını sağlayan katmandır. Ama bu kazanımı gerçekleştirmek için konfigürasyonun bilinçli olması gerekir. TTL değerleri, Cache-Control başlıkları, purge stratejisi ve önbelleğe alınabilir içerik sınırı — bunların her biri cache hit oranını ve dolayısıyla gerçek performans kazanımını doğrudan belirler.
Öte yandan edge cache evrensel bir çözüm değildir. Kişiselleştirilmiş içerik, oturum bağımlı sayfalar ve gerçek zamanlı veri bu mekanizmanın kapsamı dışında kalır. Bu sınırı erkenden çizmek, hangi kaynakların önbellekleneceğine dair net bir strateji oluşturmayı kolaylaştırır ve yanlış beklentilerin önüne geçer.
En basit başlangıç noktası şudur: statik varlıkları uzun TTL ile agresif biçimde önbelleğe alın, HTML belgelerini içeriğin kişiselleşme durumuna göre değerlendirin ve purge mekanizmasını test etmeden yüksek TTL'e güvenmeyin. Bu üç adımın ötesi, sitenin trafik profili ve içerik güncellenme sıklığına göre şekillenir.