Önceki yazıda Spaces üzerinden bir bucket oluşturup dosya yükleme sürecini adım adım anlatmıştım. Orada CDN’i etkinleştirmekten kısaca bahsetmiştim, bu yazıda ise CDN’in arka planda gerçekte nasıl çalıştığını, önbellekleme mantığını, özel alt alan adı kullanımını ve içerik güncellendiğinde nelere dikkat edilmesi gerektiğini daha derinlemesine ele alıyorum.
CDN Devreye Girdiğinde Ne Değişiyor
Bir Spaces bucket’ı oluşturulduğunda dosyalar, o bucket’ın bulunduğu bölgedeki tek bir veri merkezinde saklanıyor. Bu dosyalara doğrudan erişildiğinde her istek o veri merkezine kadar gidip geliyor. Kullanıcı Frankfurt’taki bir bucket’a New York’tan erişiyorsa, bu mesafe gecikmeye dönüşüyor.
CDN etkinleştirildiğinde, dosyalar dünya genelinde dağıtılmış edge sunucularına (uç noktalara, İngilizcesiyle point of presence ya da PoP) kopyalanıyor. Bir kullanıcı bir dosyayı istediğinde, bu istek en yakın edge sunucusuna yönleniyor. Dosya o sunucuda zaten önbelleklenmişse doğrudan oradan servis ediliyor, önbellekte yoksa edge sunucusu dosyayı origin bucket’tan çekip hem kullanıcıya iletiyor hem de kendi önbelleğine kaydediyor.
Bu mekanizmanın pratik sonucu şu oluyor: bir dosya ilk kez istendiğinde biraz daha yavaş geliyor, çünkü origin’den çekiliyor, fakat sonraki istekler önbellekten karşılandığı için önemli ölçüde hızlanıyor. Ayrıca origin bucket geçici olarak erişilemez hale gelse bile, önbellekteki içerik edge sunucular üzerinden kullanıcıya sunulmaya devam edebiliyor.
Edge Cache TTL Kavramı
CDN önbelleğinin ne kadar süre geçerli kalacağını belirleyen ayara Edge Cache TTL (Time to Live) deniyor. Varsayılan değer bir saat, fakat bu süre 60 saniyeden 30 güne kadar farklı değerlere ayarlanabiliyor. TTL, hem tüm bucket için genel bir değer olarak hem de tek tek dosyalar için özel olarak tanımlanabiliyor.
TTL süresi dolmadan önce dosyada bir değişiklik yapılırsa, CDN bu değişikliği süre dolana kadar yansıtmıyor, eski sürüm kullanıcıya sunulmaya devam ediyor. Bu davranış, sık değişmeyen statik dosyalar (bir logo, bir font dosyası) için performans açısından avantaj sağlarken, sık güncellenen içerikler için beklenmedik bir gecikmeye yol açabiliyor. Bu yüzden içeriğin ne sıklıkla değiştiğine göre TTL süresinin belirlenmesi gerekiyor: nadiren değişen dosyalar için uzun bir TTL, sık güncellenen dosyalar için daha kısa bir TTL tercih edilmeli.
İçerik Güncellendiğinde Ne Yapılmalı
Bir dosya güncellendiğinde ve bu değişikliğin hemen yansıması isteniyorsa iki yol var. Birincisi, CDN önbelleğini manuel olarak temizlemek (purge). Bu işlem panel üzerinden ya da API üzerinden yapılabiliyor, tek bir dosya için, bir klasör için ya da tüm bucket için uygulanabiliyor. Purge işlemi tetiklendiğinde tüm edge sunucular ilgili içeriği anında siliyor ve bir sonraki istekte origin’den güncel sürümü çekiyor.
İkinci ve daha sürdürülebilir yaklaşım ise dosya isimlerini versiyonlamak. Örneğin style.css yerine style.abc123.css gibi içerik değiştikçe değişen bir isimlendirme kullanmak, her güncellemede yeni bir dosya adı oluşturduğu için önbellekleme sorununu baştan ortadan kaldırıyor. Sık güncellenen projelerde manuel purge işlemiyle uğraşmak yerine bu yöntem tercih edilmeli, çünkü purge işlemleri sınırlı bir hızda çalışıyor ve klasör bazlı ya da etiket bazlı toplu geçersiz kılma desteklemiyor.
Özel Alt Alan Adı Kullanımı
Varsayılan olarak CDN üzerinden erişim, bucket-adi.bolge.cdn.digitaloceanspaces.com gibi bir adres üzerinden yapılıyor. Bu adres teknik olarak çalışsa da marka bütünlüğü açısından pek tercih edilen bir görünüm sunmuyor. Bunun yerine static.siteadi.com gibi kendi alan adına ait bir alt alan adı tanımlanabiliyor.
Bunun için önce alan adı sağlayıcısının DNS panelinden bir CNAME kaydı oluşturulup CDN uç noktasına yönlendirilmesi gerekiyor. Ardından DigitalOcean panelinden bu özel alt alan adı CDN uç noktasına tanımlanıyor ve bir SSL sertifikası ekleniyor. DigitalOcean bu sertifikayı otomatik olarak yönetebiliyor, isteniyorsa kendi sertifikası da (bring your own certificate) kullanılabiliyor. Bu adım tamamlandığında dosyalara artık kendi alan adı üzerinden, HTTPS ile erişilebiliyor.
CORS ve Tarayıcı Kaynaklı Erişim
Bir web uygulaması, frontend tarafından doğrudan Spaces üzerindeki dosyalara erişmek istediğinde (örneğin bir görsel, font ya da API yanıtı), tarayıcının güvenlik politikaları devreye giriyor. Farklı bir alan adından gelen bu tür istekler, bucket ayarlarında CORS (Cross-Origin Resource Sharing) kuralı tanımlanmadığı sürece tarayıcı tarafından engelleniyor. Bu kural, bucket’ın Settings sekmesinden hangi alan adlarının erişime izinli olduğu belirtilerek tanımlanabiliyor.
Ne Zaman CDN Kullanmalı, Ne Zaman Kullanmamalı
Statik varlıklar, görseller, videolar, indirilebilir dosyalar, bir web sitesinin CSS ve JavaScript dosyaları gibi sık erişilen ve nadiren değişen içerikler için CDN neredeyse her zaman anlamlı bir tercih. Kullanıcı deneyimini doğrudan iyileştiriyor ve origin bucket üzerindeki yükü azaltıyor.
Buna karşın sürekli değişen, kullanıcıya özel ya da anlık üretilen içerikler için CDN önbelleklemesi karmaşıklık ekleyebiliyor. Bu tür durumlarda ya çok kısa bir TTL tanımlanmalı ya da içerik doğrudan origin üzerinden, CDN’i devre dışı bırakarak sunulmalı.
Sonraki Adımlar
CDN, doğru yapılandırıldığında Spaces’in sunduğu depolama hizmetini önemli ölçüde güçlendiriyor, kullanıcıya daha hızlı erişim sağlarken origin üzerindeki yükü de azaltıyor. Bir projeye CDN eklerken TTL stratejisini baştan netleştirmek, ileride önbellek kaynaklı sürpriz sorunlarla karşılaşmayı büyük ölçüde önlüyor.
Kendi bucket’ını CDN ile denemek istersen, referans linkim üzerinden kayıt olarak bana destek olabilirsin.
Tüm projelerim ve üzerinde çalıştığım konuları incelemek istersen https://hub.barisgunduz.com/ adresini ziyaret edebilirsin.
