CDN Kurulumu Nasıl Planlanır?

Sesli Dinle — Makale

CDN kurulumu yalnızca alan adını yeni bir hedefe yönlendirmekten ibaret değildir. Bir siteyi CDN arkasına alma işlemi, ziyaretçi ile kaynak sunucu arasına reverse proxy (ters proxy) ve ortak önbellek katmanı eklediği için DNS, TLS, yönlendirme, oturum ve içerik güncelliğini birlikte ele almayı gerektirir.

Kesinti riskini azaltmak için kaynak sunucuyu çalışır durumda tutun, CDN üzerinden erişimi önceden test edin ve geri dönüş yolunu DNS değişikliğinden önce hazırlayın. Önbellek kurallarını başlangıçta temkinli tutun; doğrulama tamamlandıktan sonra kaynak sunucuya doğrudan erişimi kademeli olarak sınırlandırın.

CDN Geçişinden Önce Mevcut Yapının Kaydedilmesi

Kurulum öncesinde mevcut durumu kaydetmek hem karşılaştırma hem de geri dönüş için referans oluşturur. Yalnızca ana sayfayı değil, www ve kök alan adını, API ve dosya sunucularının host adlarını, yönetim panelini, giriş sayfasını, ödeme ve sepet işlemlerini, dosya yükleme uç noktalarını ve yönlendirme zincirlerini kapsayan bir liste hazırlayın.

Her host adı için A ve AAAA kayıtlarını ve varsa başka bir ada yönelten CNAME kaydını not edin. A kaydı IPv4 adresini, AAAA ise IPv6 adresini bildirir. DNS yanıtının önbellekte kalma süresini sınırlayan TTL değerlerini; kaynak IP adresini; TLS sertifikasının kapsadığı adları; web isteklerini ve yanıtlarını taşıyan HTTP durum kodlarını; Cache-Control (önbellek denetimi), Vary (yanıtı değiştiren istek başlıklarını bildirme), ETag (varlık etiketi) ve Last-Modified (son değiştirilme zamanı) gibi yanıt başlıklarını kaydedin. Test isteğinin kaynak sunucuya doğrudan mı, yoksa bir proxy veya yük dengeleyici üzerinden mi ulaştığını kaydedin. IPv4 ve IPv6 bağlantılarında görünen çıkış adresleri farklı olabilir; günlükleri testte gerçekten kullanılan bağlantı üzerinden karşılaştırın.

• Kimlik doğrulaması veya çerez kullanan sayfaları ayrı işaretleyin.
• POST, PUT ve DELETE gibi durum değiştiren istekleri ve dosya yüklemelerini belirleyin.
• Çift yönlü WebSocket bağlantıları, SSE (Server-Sent Events) veya uzun süren API istekleri varsa CDN hizmetinin destek ve süre sınırlarını önceden kontrol edin.
• Mevcut izleme ölçümlerini, tipik istemci hatası (4xx) ve sunucu hatası (5xx) oranlarını, kaynak yükünü ve yanıt sürelerini başlangıç değeri olarak saklayın.

Kaynak Sunucu ile CDN Arasındaki Bağlantı

CDN'nin kaynak sunucuya göndereceği isteğin hedefini açıkça tanımlayın. Kaynak host adı, bağlantı portu, HTTP iletişimini TLS ile koruyan HTTPS kullanımı, Host istek başlığı, bağlantı ve okuma zaman aşımı, izin verilen en büyük istek gövdesi ve sağlık kontrolü yolu planın parçasıdır. Aynı IP adresinde birden fazla site barındırılıyorsa Host başlığı ile SNI (Server Name Indication) uzantısında gönderilen sunucu adının doğru sanal sunucuyu seçmesi özellikle önemlidir.

Mümkün olduğunda kaynak için yalnız CDN'nin kullandığı ayrı bir host adı oluşturun ve bunu herkese açık site bağlantılarında kullanmayın. CDN'nin sertifika doğrulamasında kullandığı ad, kaynak sertifikasıyla eşleşmelidir; bağlantı adresi, SNI ve Host değeri hizmetin ayarlarına göre farklı olabilir. Kaynak için seçilen hedef yeniden aynı CDN'ye yönelerek döngü oluşturmamalı; uygulama da ziyaretçileri kaynak adına yönlendirerek CDN dışına çıkarmamalıdır.

Kaynak Sunucuya Doğrudan Erişimin Kademeli Sınırlandırılması

Kaynak sunucuya erişimi CDN sağlayıcısının çıkış IP adresi aralıklarıyla sınırlandırmak doğrudan bağlantıları azaltabilir. Ancak ortak adres aralıkları veya bütün müşterilerin kullandığı bir istemci sertifikası, isteğin sizin hesabınızdan geldiğini kanıtlamaz. Bu ayrım gerektiğinde size özel istemci sertifikasıyla mTLS (mutual TLS) veya eşdeğer bir hesap doğrulaması kullanın. IP adresi aralıklarıyla kısıtlama uygulanacaksa listenin değişimini izleyen bir güncelleme süreci de kurulmalıdır. CDN'nin eklediği gizli bir HTTP başlığını doğrulamak ek koruma sağlayabilir, ancak başlık sızabileceği veya taklit edilebileceği için tek başına yeterli değildir.

CDN geçişinden önce diğer bütün kaynak bağlantıları kapatılırsa mevcut ziyaretçiler kaynak sunucuya erişemeyebilir. Önce CDN erişimini ekleyin, testleri tamamlayın, DNS geçişini izleyin ve eski DNS önbelleklerinin etkisi azaldıktan sonra gerekli yönetim ve sağlık denetimi erişimlerini koruyarak diğer doğrudan erişim yollarını kapatın. Eski DNS kayıtları, pasif DNS verileri veya başka hizmetler kaynak IP adresini daha önce açığa çıkarmış olabileceği için yalnız adresi gizlemeye güvenmeyin.

Gerçek İstemci IP Adresinin Güvenilir Biçimde İşlenmesi

Kaynak sunucu, TCP bağlantısının kaynak adresi olarak çoğu zaman CDN düğümünün IP adresini görür. Uygulama günlükleri, oran sınırlama ve erişim kuralları için CDN sağlayıcısının eklediği gerçek istemci IP adresi başlığı kullanılacaksa uygulama bu başlığı yalnız güvenilir CDN bağlantılarından kabul etmelidir. İnternetten doğrudan gelen bir isteğin aynı başlığı kendisinin eklemesine izin vermek, günlük ve erişim kararlarını yanıltabilir.

CDN başlığına güvenmek, içindeki her adresin güvenilir olduğu anlamına gelmez. X-Forwarded-For gibi adres listelerinde istemci tarafından eklenmiş değerler bulunabilir. Güvenilir proxy listesini sunucuda tanımlayın ve adresi CDN sağlayıcısının belgelediği yöntemle seçin; listenin en solundaki adresi koşulsuz kullanmayın. Görülen adres bir VPN veya başka bir proxy çıkışı da olabilir; kişinin veya cihazın kimliğini tek başına kanıtlamaz.

CDN Kurulumunda DNS, TLS, Önbellek ve Kaynak Erişimi Sırası

Aynı anda çok sayıda değişiklik yapmak hata kaynağını belirsizleştirir. Önce CDN yapılandırmasını üretim DNS'ine dokunmadan hazırlayın ve test edin; ardından DNS'i değiştirin, trafiği izleyin ve kaynak erişimini sıkılaştırın. Geçici bir test adı ilk denemeler için yararlıdır fakat gerçek alan adının çerez, yönlendirme ve sertifika davranışını tek başına doğrulamaz.

Gerçek alan adını ve sertifikasını CDN üzerinde önceden tanımlayın. CDN hizmeti destekliyorsa test cihazına özel DNS eşlemesi veya curl aracının --resolve seçeneğiyle, genel DNS kaydını değiştirmeden gerçek alan adı üzerinden CDN hedefine bağlanın. Sertifika doğrulamasını kapatmayın; uygulama işlemlerini de aynı adla sınayın. Bu deneme genel DNS geçişinin doğrulaması değildir.

Aşağıdaki aşamalarda geri dönüş için eski yapılandırma korunur. Recursive resolver (özyinelemeli DNS çözümleyicisi), DNS yanıtını TTL süresi boyunca önbellekte tutabileceği için geçiş sırasında eski ve yeni hedefler bir süre birlikte görülebilir.

CDN Geçişinde DNS Yönlendirmesinin Planlanması

CDN için DNS ayarı, CDN sağlayıcısının çalışma modeline ve host adının kök alan adı mı yoksa alt alan adı mı olduğuna göre değişir. Alt alan adı çoğunlukla CNAME ile CDN hedefine yöneltilebilir. Zone apex’te (bölgenin tepe adında) klasik CNAME kaydı, aynı adda bulunması gereken SOA (Start of Authority) ve NS kayıtlarıyla birlikte kullanılamaz. CDN veya DNS sağlayıcısı; A ve AAAA kayıtları, kendine özgü ALIAS veya ANAME kayıtları, CNAME flattening (CNAME düzleştirme) ya da destekleniyorsa HTTPS kaydının AliasMode işlevi gibi bir yöntem sunabilir. HTTPS kaydını tanımayan istemciler için kök addaki A ve AAAA kayıtlarının gerekebileceği unutulmamalıdır. Bu seçenekler birbirinin evrensel karşılığı değildir; yalnız seçilen CDN ve DNS hizmetinin belgelediği yöntem uygulanmalıdır.

Yalnız web kaydı değiştirilecekse MX, TXT, CAA (Certification Authority Authorization) ve diğer hizmet kayıtlarını koruyun. Ancak MX hedefi değişen web adıysa, posta da bu adın A/AAAA kayıtlarına bağlıdır; MX bulunmadığında bazı teslimatlar doğrudan alan adının adres kayıtlarını kullanır. SPF (Sender Policy Framework) içindeki a ve mx kuralları da bu adres değişikliğinden etkilenebilir. Posta hizmetinin hedeflerini CDN'nin yalnız web trafiği taşıyan adreslerine yöneltmeyin. Yetkili DNS sağlayıcısı da değişiyorsa tüm bölgeyi eksiksiz kopyalayın; e-posta doğrulama kayıtlarını, alt alan adlarını ve DNSSEC kullanılıyorsa delegasyon zincirini ayrı kontrol edin. Eksik bir kayıt, CDN'den bağımsız görünen e-posta veya hizmet kesintilerine yol açabilir.

Geçişten önce ilgili kaydın TTL değerini düşürmek, daha sonra alınan kopyaların saklanma süresini kısaltır; önceden saklanmış kopyaların süresini geriye dönük değiştirmez. Düşük TTL tüm yetkili sunucularda doğrulandıktan sonra en az eski TTL kadar bekleme payı bırakın. Kök alan adı, www, API ve statik içerik host adlarının A, AAAA, CNAME ve varsa HTTPS kayıtlarını yetkili sunuculardan ve farklı recursive resolver hizmetlerinden sorgulayın. Sonuçları seçilen CDN yöntemine göre değerlendirin; HTTPS AliasMode kullanılıyorsa A/AAAA kayıtları uyumsuz istemciler için ayrı bir hedefi koruyabilir. Geçiş kararlı duruma geldikten sonra gereksiz derecede düşük TTL değerlerini normal işletim düzeyine çıkarın.

Ziyaretçi ile CDN, CDN ile Kaynak Sunucu Arasındaki TLS Bağlantıları

TLS bağlantılarını kendi üzerinde sonlandıran CDN yapısında iki ayrı TLS oturumu bulunur: ziyaretçi ile CDN, ardından CDN ile kaynak sunucu. İlk oturumun geçerli olması ikinci oturumun güvenli veya doğrulanmış olduğu anlamına gelmez. Kaynak bağlantısında HTTPS kullanın ve CDN'nin kaynak sertifikasının adını, süresini ve zincirini doğrulamasını sağlayın.

• CDN uç sertifikasının kök alan adı, www ve kullanılan diğer host adlarını kapsadığını doğrulayın.
• Kaynak sertifikasının CDN'nin doğrulama için kullandığı adla eşleşmesini ve ara sertifikaların eksiksiz sunulmasını sağlayın.
• Sertifika yenilemesinin kaynak erişim kısıtlamalarından sonra da çalışacağını test edin.
• HTTP'den HTTPS'ye ve www ile kök alan adı arasındaki yönlendirmeleri tek sorumlu katmanda tutarak döngüleri önleyin.
• CDN geçişiyle aynı anda tarayıcıya bu alan adına yalnız HTTPS ile bağlanmasını bildiren, geri dönüşü zor yeni bir HSTS (HTTP Strict Transport Security) politikası başlatmayın; önce bağlantının kararlı olduğunu doğrulayın.

DNS geçişinden sonra tarayıcının sertifika ayrıntılarından ziyaretçiye sunulan sertifikayı, zinciri ve alan adı kapsamını kontrol edin. Kaynak sertifikasını da CDN dışına kalıcı erişim açmadan, yönetim ağı veya kontrollü test yöntemi üzerinden ayrıca doğrulayın.

İçerik Türüne Göre CDN Önbellek Ayarları

Önbellek politikasını tüm siteye uygulanacak tek bir süreye indirgemeyin. HTTP önbellekleme kuralları tazelik, yeniden doğrulama, ortak önbellek davranışı ve içerik varyantlarını ayrı mekanizmalarla yönetir. Başlangıçta yalnız davranışı kesin olarak bilinen içerikleri önbelleğe alın; dinamik alanları daha sonra kontrollü olarak genişletin.

Statik dosyalar ile HTML için farklı süreler: Dosya adına sürüm veya içerik özeti eklenen CSS, JavaScript, yazı tipi ve görseller uzun tazelik süresiyle saklanabilir; dosya değiştiğinde yeni ad üretildiği için eski kopyayla çakışma azalır. HTML sayfaları daha sık değişebildiğinden kısa tazelik süresi veya ETag ve Last-Modified ile yeniden doğrulama çoğu sitede daha kontrollü bir başlangıçtır.

Kişiye özel yanıtlar ve durum değiştiren istekler: Yönetim paneli, giriş, hesap, sepet, ödeme, kişiselleştirilmiş içerik ve yetkilendirme gerektiren API yanıtlarını varsayılan olarak ortak önbelleğe almayın. Cache-Control içindeki no-store depolamayı engeller; private ise yanıtın ortak önbellek tarafından saklanmaması gerektiğini belirtir. CDN-Cache-Control gibi hedefli başlıklar genel Cache-Control yerine uygulanabildiğinden CDN kurallarını da ayrıca denetleyin. Çerezler tek başına saklama yasağı değildir; Authorization (kimlik doğrulama bilgisini taşıyan başlık) bulunan isteklere verilen yanıtların ortak önbellekte kullanımı ise açık izin gerektirir. Paylaşıma uygunluğu doğrulanmamış yanıtları saklamayın ve durum değiştiren yöntemleri genel bir önbellek kuralıyla kapsam içine almayın.

Yanıtı Değiştiren Bilgilerin Önbellek Anahtarına Eklenmesi

Cache key (önbellek anahtarı), isteği saklanan yanıtla eşleştirir; HTTP yöntemini ve hedef adresi dikkate alır. CDN yapılandırmasında host adı, yol ve sonucu gerçekten değiştiren sorgu parametreleri birbirinden ayrılmalıdır. Dil, cihaz türü, ülke, para birimi veya belirli bir başlık yanıtı değiştiriyorsa bu bilgi önbellek anahtarına eklenmeli ya da CDN hizmetinin desteklediği Vary davranışıyla ayrılmalıdır. Aksi halde bir kullanıcı için üretilen yanıt başka kullanıcıya verilebilir. Yetki ayrımı için anahtar kullanmak, her istekte gereken erişim kontrolünün yerini tutmaz.

Her çerezi, tüm User-Agent değerini veya gereksiz sorgu parametrelerini anahtara eklemek ise aynı içerik için çok sayıda ayrı önbellek kaydı oluşturur ve isteğin eldeki kopyayla karşılanması anlamındaki cache hit oranını düşürür. Analitik etiketler gibi içeriği değiştirmeyen parametreler ancak uygulama davranışı doğrulandıktan sonra dışarıda bırakılmalıdır.

CDN’de Hata Yanıtlarını Önbelleğe Alma

404 gibi kalıcı olabilecek yanıtlarla 500, 502, 503 ve 504 gibi geçici kaynak hatalarına aynı süreyi vermeyin. Eski içeriğin hata sırasında sunulması kabul edilecekse bunun hangi içeriklerde, ne kadar süreyle ve hangi durum kodlarında geçerli olacağını belirleyin; ödeme, stok veya kullanıcı hesabı gibi güncelliğin kritik olduğu alanlarda aynı yaklaşım uygun olmayabilir.

CDN İçeriği Güncellendiğinde Önbelleğin Temizlenmesi

İçerik güncellemesi için önce CDN sağlayıcısının desteklediği URL, etiket, host adı veya URL yolu öneki gibi hedefli temizleme yöntemlerini kullanın; tüm önbelleği boşaltmayı son seçenek olarak tutun. CDN önbellek temizliği ziyaretçinin tarayıcısında saklanmış dosyaları doğrudan silmez. Uzun süreli tarayıcı önbelleği kullanılan dosyalarda sürümlü dosya adları, güncellemenin eski kopyadan bağımsız dağıtılmasını sağlar.

Kurulum Sonrası DNS, TLS, HTTP ve Uygulama Doğrulaması

Yayına alma kontrolü tek bir tarayıcıda ana sayfanın açılmasıyla tamamlanmaz. Anonim istekleri ve farklı yetkilere sahip en az iki kullanıcının oturumlu isteklerini, farklı host adlarını, yönlendirmeleri, sorgu parametrelerini ve durum kodlarını birlikte test edin.

1. DNS: Her web host adının seçilen CDN yöntemine uygun hedefleri döndürdüğünü ve e-posta hedeflerinin doğru kaldığını kontrol edin.
2. TLS: Sertifika adı, geçerlilik süresi, zincir ve HTTPS yönlendirmesini her host adı için doğrulayın.
3. HTTP: Başarılı (2xx), yönlendirme (3xx), istemci hatası (4xx) ve sunucu hatası (5xx) yanıtlarının beklenen anlamı koruduğunu, yönlendirme döngüsü veya yöntem değişikliği oluşmadığını sınayın.
4. Önbellek: Tekrarlanan anonim isteklerde CDN'nin önbellek durumu göstergesini, kaynakta üretim veya son doğrulamadan beri geçen tahmini saniyeyi bildiren Age ve önbellek davranışını açıklayan Cache-Status gibi mevcut başlıkları inceleyin; dinamik ve oturumlu sayfalarda önbelleği atlama veya kaynak sunucudan alma davranışını doğrulayın.
5. İçerik: HTML, görsel ve indirilebilir dosyaların sürümünü kaynakla karşılaştırın; dil, cihaz ve sorgu parametresi varyantlarının birbirine karışmadığını kontrol edin.
6. Uygulama: Giriş, çıkış, form gönderimi, dosya yükleme, ödeme, API istekleri ve WebSocket bağlantılarını ayrı test edin.
7. Kaynak: Günlüklerde CDN bağlantısının ve gerçek istemci IP adresi bilgisinin doğru işlendiğini, 5xx oranının ve kaynak yükünün beklenmeyen biçimde artmadığını izleyin.

Performans karşılaştırmasını aynı sayfa, aynı test yöntemi ve benzer ağ koşullarıyla yapın. CDN kullanımı tek başına belirli bir hız veya güvenlik sonucu garanti etmez; önbellek isabeti, kaynak konumu, içerik yapısı, ağ yolu ve yapılandırma sonucu etkiler.

DNS Geri Dönüşü ve Olay Müdahale Planı

DNS değiştirilmeden önce hangi belirtilerde geri dönüleceğini belirleyin. Yaygın tetikleyiciler: sertifika hatası, yönlendirme döngüsü, oturumlu içeriğin yanlış kullanıcıya gösterilmesi, kritik API işlevinin bozulması, yüksek 5xx oranı ve CDN'nin kaynağa erişememesidir.

• Eski DNS değerlerini, CDN yapılandırma sürümünü ve kaynak erişim kurallarını geri yüklenebilir biçimde saklayın.
• DNS'i doğrudan kaynağa döndürecekseniz önce kaynak güvenlik duvarının bu trafiği kabul ettiğini ve sertifikanın genel host adını kapsadığını doğrulayın.
• Sorun önbellek kuralındaysa önce hatalı kuralı düzeltin veya kapatın, ardından etkilenmiş kopyaları hedefli olarak temizleyin. Özellikle kişisel içerik yanlış kullanıcıya sunuluyorsa yalnız temizleme yapmak sorunu çözmez; aynı yanıt tekrar saklanabilir.
• DNS, TLS veya kaynak bağlantı hatasını yalnız önbelleği temizleyerek çözmeye çalışmayın; önbellek temizliği bu katmanlardaki yapılandırmayı değiştirmez.
• Geri dönüşten sonra DNS önbellekleri nedeniyle bir süre iki yolun da trafik alabileceğini hesaba katın ve her iki yolu izleyin.