Edge Caching Nedir

"Edge" kelimesi son yıllarda o kadar çok pazarlama metninde geçti ki anlamı bulanıklaştı. Oysa arkasındaki fikir son derece somut: kullanıcının isteğini mümkün olan en erken noktada, senin sunucuna hiç ulaşmadan cevaplamak. Edge caching, yani uç önbellekleme, tam olarak bunu yapar. İstek dünyanın öbür ucundaki veri merkezine gitmez; kullanıcıya en yakın veri merkezindeki bir kopyayla karşılanır ve origin sunucun o isteği hiç görmez.

Bu rehberde edge'in ne olduğunu ve origin önbelleğinden farkını, bir isteğin geçtiği önbellek katmanlarının sırasını, uçta neyi önbelleğe alabileceğini, dinamik görünen içeriği uçta tutmanın yollarını (mikro-önbellek, cache tag, stale sunumu), edge compute'un ne işe yaradığını ve bu mimarinin sınırlarını anlatacağım. Sonunda kendi sitendeki hangi isteklerin uçtan karşılanabileceğini net biçimde ayırt edebileceksin.

Edge Nedir, Origin'den Farkı Ne#

Origin, uygulamanın çalıştığı asıl sunucudur: PHP'nin yürüdüğü, veritabanına sorgu atılan, HTML'in üretildiği yer. Tek bir fiziksel konumdadır ve tüm mantık orada yaşar.

Edge, kullanıcıya coğrafi olarak yakın, hafif ve çok sayıda bulunan sunuculardır. Uygulamanı çalıştırmazlar; hazır cevapları saklarlar ve sunarlar. Bir CDN'in PoP'ları edge'dir; bazı sağlayıcılarda edge aynı zamanda küçük kod parçaları da çalıştırabilir.

İkisi arasındaki farkı en iyi bir isteğin ne kadar iş yaptığı üzerinden anlarsın:

Buradaki asıl kazanç sadece mesafe değil, yapılmayan iştir. Edge'den dönen bir yanıtta veritabanı hiç açılmaz, şablon motoru hiç çalışmaz. Bu yüzden uç önbellekleme, aynı donanımla taşıyabileceğin ziyaretçi sayısını katlar. CDN'in genel mimarisini henüz gözden geçirmediysen CDN nedir, nasıl çalışır yazısı bu tabloyu tamamlar.

Önbellek Katmanları ve Sıraları#

Bir isteğin önünde birden fazla önbellek durur ve hangisinin devreye girdiğini bilmek, sorun ararken en çok işine yarayan bilgidir. Sıra şudur:

1. Tarayıcı önbelleği. İstek ağa hiç çıkmaz; kullanıcının diskindeki kopya kullanılır. En hızlısıdır ama sen temizleyemezsin.
2. Edge / CDN önbelleği. İstek ağa çıkar ama en yakın PoP'ta biter. Sen istediğin an temizleyebilirsin.
3. Origin shield. PoP'ların ortak üst katmanı; origin'e giden istek sayısını azaltır.
4. Origin ters vekil önbelleği. Nginx proxy_cache ya da fastcgi_cache gibi, sunucudaki hazır HTML.
5. Uygulama önbelleği. Redis veya Memcached'deki nesne ve sorgu sonuçları.
6. Veritabanı. En pahalı katman; buraya kadar gelen istek en yavaş olanıdır.

Tasarım ilkesi basittir: isteği mümkün olan en üst katmanda durdur. Her aşağı inişte maliyet katlanarak artar. Uygulama katmanındaki önbelleği Memcached nedir yazısında, origin katmanındakini Nginx FastCGI cache rehberinde ele aldım; bu yazının konusu ikinci katman.

Katmanların hangi başlıkla konuştuğunu ayırt etmek de önemlidir. max-age tarayıcıyı, s-maxage paylaşımlı önbellekleri yani edge'i ilgilendirir. İkisini ayrı ayarlamak, "uçta uzun yaşasın, tarayıcıda kısa dursun" stratejisinin temelidir:

# Tarayicida 1 dakika, uc sunucuda 12 saat
add_header Cache-Control "public, max-age=60, s-maxage=43200";

Edge'de Neyi Önbelleğe Alabilirsin#

Bir yanıtın uçta saklanabilmesi için tek bir şart vardır: aynı yanıt birden fazla kullanıcıya doğru cevap olmalıdır. Bu şartı sorduğun anda çoğu belirsizlik dağılır.

Kesinlikle uçta olmalı: görseller, fontlar, CSS ve JavaScript dosyaları, indirilebilir belgeler, video parçaları, robots.txt ve site haritası. Bunlar herkes için aynıdır ve genellikle nadiren değişir.

Genellikle uçta olabilir: anonim ziyaretçiye gösterilen blog yazıları, kategori sayfaları, ürün detay sayfaları, ana sayfa, iletişim sayfası. Bunlar dinamik olarak üretilir ama sonuç herkes için aynıdır.

Uçta olmamalı: sepet, ödeme adımları, üyelik paneli, sipariş geçmişi, kişiye özel öneriler, yönetim arayüzü, kimlik doğrulama gerektiren API uç noktaları.

Kararsız kaldığın bir sayfa için şu testi uygula: sayfayı gizli pencerede aç, sonra farklı bir tarayıcıda tekrar aç. İki çıktı birebir aynıysa uçta önbelleğe alınabilir. Farklıysa, farkın nereden geldiğini bul; genellikle bir kullanıcı adı, sepet sayısı ya da kişiselleştirilmiş bir blok çıkar.

Bu son durumda çözüm, sayfanın tamamını önbellek dışı bırakmak değil, o küçük parçayı sayfadan ayırmaktır. Sepet sayacını JavaScript ile ayrı bir istekten çekersen HTML'in tamamı önbelleklenebilir hâle gelir. Buna "delik açma" (hole punching) denir ve dinamik sitelerde uç önbelleklemeyi mümkün kılan tek pratik yöntemdir.

Bir ayrıntı daha var: istek yöntemi ve durum kodu da belirleyicidir. Uç önbellekler yalnızca GET ve HEAD isteklerini saklar; POST, PUT ve DELETE tanım gereği durum değiştiren işlemlerdir ve hiçbir koşulda önbelleğe alınmazlar. Aynı şekilde her durum kodu saklanmaz: 200, 301 ve 404 gibi kodlar önbelleklenebilirken 500 ailesindeki hatalar genellikle saklanmaz, ki bu iyi bir varsayılandır. Bir kaynağın neden uçtan gelmediğini araştırırken ilk bakman gereken yerlerden biri, isteğin yöntemi ve dönen durum kodudur; başlıkları incelemeye geçmeden önce bu ikisini eleyip zaman kazanabilirsin.

Dinamik İçeriği Uçta Tutmak#

Dinamik üretilen ama herkese aynı görünen içeriği uçta tutmanın üç ana tekniği var.

Mikro-önbellek. Sayfayı çok kısa bir süre, örneğin bir ila on saniye önbellekte tut. Kulağa anlamsız gelir ama saniyede yüz istek alan bir sayfada bu, origin'e giden istek sayısını yüzden bire düşürür. İçeriğin en fazla birkaç saniye eski olması ise neredeyse hiçbir senaryoda sorun değildir. Trafik yoğunluğu arttıkça kazancı büyür; tam da yükün bindiği anda devreye girer.

# Mikro-onbellek: 5 saniye, ama esneme payi genis
add_header Cache-Control "public, max-age=0, s-maxage=5, stale-while-revalidate=60, stale-if-error=3600";

Bayat sunum (stale serving). stale-while-revalidate, süresi dolmuş bir kopyanın kullanıcıya anında verilmesini ve yenilemenin arka planda yapılmasını sağlar. Böylece TTL'in dolduğu anda gelen istekler beklemek zorunda kalmaz. stale-if-error ise origin çöktüğünde eski kopyanın sunulmasını sağlar; kesinti sırasında sitenin ayakta görünmesini sağlayan tek mekanizma çoğu zaman budur. Bu direktiflerin tamamını Cache-Control başlıkları rehberinde tek tek açıkladım.

Etiketli temizleme (cache tag). Uzun TTL vermenin en büyük korkusu, içerik değiştiğinde eski kopyanın dolaşımda kalmasıdır. Çözüm, TTL'i kısaltmak değil, değişiklik anında hedefli temizlik yapmaktır. Yanıta içerik kimliklerini içeren bir etiket başlığı eklersin; içerik güncellendiğinde o etikete sahip tüm kopyaları tek çağrıyla silersin.

# Yanitla birlikte etiket gonder (uygulama tarafinda)
# Cache-Tag: urun-1042, kategori-ayakkabi, anasayfa

# Urun guncellenince yalnizca o etiketi temizle
curl -sS -X POST "https://api.ornek-cdn.com/v1/zones/ZONE/purge" \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"tags":["urun-1042"]}'

Bu yaklaşımla bir ürün sayfasına günlerce TTL verip, fiyat değiştiği saniyede o sayfayı ve onu içeren listeleri temizleyebilirsin. Etiket bazlı temizleme çoğu sağlayıcıda üst planlara ait bir özelliktir; yoksa URL bazlı hedefli purge ile benzer sonucu daha fazla çağrıyla elde edersin.

Edge Compute ve Kişiselleştirme#

Bazı sağlayıcılar uç sunucularda küçük kod parçaları çalıştırmana izin verir. Bu, önbelleklemenin sınırını genişletir çünkü artık uçta karar verebilirsin.

Pratikte en çok işe yarayan kullanımlar şunlardır: isteği coğrafyaya göre farklı bir sürüme yönlendirmek, A/B testi için kullanıcıyı bir gruba atayıp cache key'e o grubu eklemek, yanıt başlıklarını düzenlemek, basit yetkilendirme kontrolü yapmak, eski adresleri yeni adreslere yönlendirmek.

Kritik fikir şu: uçta çalışan kod, cache key'i belirleyebilir. Örneğin ziyaretçinin ülkesine göre iki farklı sürüm sunuyorsan, cache key'e yalnızca ülke kodunu eklersin. Böylece iki kopya oluşur ve ikisi de uçta yaşar; oysa Vary: User-Agent gibi yüksek çeşitlilikli bir başlık kullansaydın binlerce kopya oluşur ve önbellek işlevsiz kalırdı. Cache key çeşitliliğini kontrol altında tutmanın önemini CDN cache hit oranını artırma yazısında ayrıntılı ele aldım.

Edge compute'un bedeli de vardır: her istekte çalışan kod, uç yanıtına küçük de olsa bir gecikme ekler ve genellikle çalıştırma başına ücretlendirilir. Uçta yapılabilecek en iyi iş, hiç iş yapmamaktır; kodu yalnızca gerçekten karar verilmesi gereken yerlerde kullan.

Sınırlar ve Sık Yapılan Hatalar#

Uç önbellekleme güçlüdür ama her problemi çözmez ve yanlış kurulduğunda ciddi zarar verir.

En tehlikeli hata, kişiye özel bir yanıtı uçta önbelleğe almaktır. Bir kullanıcının oturumlu sayfası uçta saklanırsa aynı sayfa başka ziyaretçilere sunulabilir. Bu, performans hatası değil veri sızıntısıdır. Geniş kapsamlı bir önbellek kuralı yazarken kişiye özel yolları her zaman önce dışarıda bırak.

İkinci hata, origin'i düzeltmeden uca güvenmektir. Uçta olmayan her istek origin'e gider ve orada ne kadar bekliyorsa o kadar bekler. Hit oranın yüzde 80 ise ziyaretçilerin beşte biri hâlâ origin hızını yaşıyor demektir. Uç önbellekleme, yavaş bir origin'i gizler ama iyileştirmez.

Üçüncü hata, kesinti senaryosunu düşünmemektir. stale-if-error tanımlı değilse origin çöktüğünde uç sunucu da hata döndürür. Tek bir başlık, kesinti sırasında sitenin okunabilir kalmasını sağlar.

Dördüncü hata, her dağıtımda tüm önbelleği temizlemektir. Uç önbellekler yeniden ısınana kadar origin ani bir yük dalgası alır; tam da dağıtım sonrası en kırılgan olduğun anda. Hedefli temizleme ya da sürümleme kullan.

Beşinci hata, doğrulamayı tarayıcıda yapmaktır. Tarayıcının kendi önbelleği araya girer ve edge'in gerçekte ne yaptığını göremezsin. Ölçümü daima komut satırından, aynı adresi arka arkaya iki kez isteyerek yap:

# Uc onbellek gercekten devrede mi
for i in 1 2; do
  curl -sSI https://firmaniz.com/blog/ornek-yazi \
    | grep -iE 'cache-status|x-cache|cf-cache-status|age'
done

Sıkça Sorulan Sorular#

Edge caching ile CDN aynı şey mi#

Tam olarak aynı şey değil. CDN, içeriği dağıtan ağın tamamıdır; edge caching ise o ağın uç noktalarında önbellekleme yapılması davranışıdır. Her CDN edge caching yapar, ama edge kavramı önbelleklemeden fazlasını da kapsar: uçta kod çalıştırma, yönlendirme ve güvenlik filtreleri de edge katmanında yaşar. Kısaca CDN altyapı, edge caching o altyapının en temel işlevidir.

Dinamik sayfalarımı uçta önbelleğe alabilir miyim#

Sayfa anonim ziyaretçiler için herkese aynı görünüyorsa evet. Dinamik üretilmiş olması engel değildir; önemli olan sonucun kişiye özel olmamasıdır. Kullanıcı adı, sepet sayısı gibi küçük kişisel parçaları sayfadan ayırıp ayrı bir istekle yükletirsen, HTML'in tamamı önbelleklenebilir hâle gelir. Sepet ve hesap sayfalarını ise hiç önbelleğe alma.

Mikro-önbellek gerçekten işe yarar mı#

Yoğun trafikte çok işe yarar. Saniyede yüz istek alan bir sayfaya beş saniyelik önbellek verirsen origin bu süre içinde yüz yerine bir istek görür. İçerik en fazla birkaç saniye eskidir, ki bu neredeyse hiçbir sitede sorun değildir. Düşük trafikte kazancı sınırlıdır çünkü her istek zaten süresi dolmuş bir kopyaya denk gelir; asıl faydası yük altında ortaya çıkar.

Edge önbelleğini nasıl temizlerim#

Sağlayıcı panelinden ya da API üzerinden purge çağrısı yaparsın. Üç yöntem vardır: tek URL, önek veya etiket bazlı, ve tümünü temizleme. Tek URL en güvenli olanıdır. Tümünü temizleme origin'de ani yük yarattığı için yalnızca gerçekten gerektiğinde kullanılmalıdır. En temiz yaklaşım, statik dosyalarda dosya adına sürüm koyup temizlemeye hiç ihtiyaç duymamaktır.

Edge caching sunucumu tamamen rahatlatır mı#

Hayır, ama yükün büyük bölümünü alır. Önbelleğe alınamayan istekler, önbelleği yenileyen istekler ve kişiye özel sayfalar her zaman origin'e ulaşır. Ayrıca ilk kez istenen her adres tanım gereği origin'den çekilir. Gerçekçi hedef, origin'e ulaşan istek sayısını birkaç kat azaltmaktır; sıfıra indirmek yalnızca tamamen statik sitelerde mümkündür.

Edge compute kullanmak zorunda mıyım#

Hayır, çoğu site için gerek yoktur. Klasik önbellekleme kuralları ve doğru Cache-Control başlıkları vakaların büyük bölümünü çözer. Edge compute'a, coğrafyaya göre farklı içerik sunmak, A/B testi yönetmek ya da uçta yetkilendirme yapmak gibi karar gerektiren ihtiyaçlar doğduğunda geç. Erken başvurmak sistemi gereksiz karmaşıklaştırır ve her isteğe küçük bir maliyet ekler.

Kapanış#

Edge caching, isteği kullanıcıya en yakın noktada durdurup origin'in hiç çalışmamasını sağlama sanatıdır. Aklında tutman gereken dört alışkanlık şu: her yanıt için "bu cevap birden fazla kişiye doğru mu" sorusunu sor, kişiselleştirilmiş küçük parçaları sayfadan ayır ki gerisi önbelleklenebilsin, TTL'i kısaltmak yerine uzun tutup hedefli temizleme kullan, stale-while-revalidate ve stale-if-error ile hem gecikmeyi hem kesinti riskini azalt.

Origin katmanını da güçlendirmek istersen Nginx FastCGI cache ve LiteSpeed Cache yazılarımız sunucu tarafındaki önbelleği kurmanı sağlar. Altyapı tarafında hızlı bir zemin arıyorsan WordPress hosting ve e-ticaret hosting paketlerimize, kendi önbellek mimarini uçtan uca kurgulamak istiyorsan VDS ve bulut sunucu seçeneklerimize göz atabilirsin. Kurgu ve bakımı bize bırakmak istersen sunucu yönetimi hizmetimiz bu katmanları senin yerine ayağa kaldırır.