CDN'den Platforma: Cloudflare'ın Edge'i Nasıl Genişledi

Bir Edge Ağı Nedir (ve Neden Şimdi Önemli)

Bir edge ağı, birçok şehirde dağıtılmış ve son kullanıcılara “yakın” bulunan sunucu setidir. Her isteğin şirketinizin origin sunucularına (veya bulut bölgesine) kadar gitmesi yerine, kenar bu isteği yakın bir noktadan yanıtlayabilir, inceleyebilir veya iletebilir.

Bunu, her soruyu arka ofiste ele almak yerine mekanın girişlerine faydalı personel yerleştirmeye benzetin. Bazı istekler hemen işlenebilir (örneğin önbelleğe alınmış bir dosya sunma), bazıları ise güvenle ileri yönlendirilir.

“Perimetre” ne demek—ve neden trafik orada yoğunlaşıyor

Perimetre, dış internet trafiğinin sistemlerinizle ilk karşılaştığı sınırdır: web siteniz, uygulamalarınız, API'leriniz ve bunları koruyan/route eden servisler. Tarihsel olarak birçok şirket perimetreyi ince bir kapı (DNS ve bir load balancer) gibi ele aldı. Bugün ise en yoğun ve riskli etkileşimlerin gerçekleştiği yer—girişler, API çağrıları, botlar, scraping, saldırılar ve ani sıçramalar burada oluyor.

Daha fazla iş çevrimiçi taşındıkça ve entegrasyonların çoğu API'lara dayandıkça, trafiği perimetreden geçirmek giderek daha pratik hale geliyor; böylece istekler çekirdeğe ulaşmadan önce tutarlı kurallar—performans optimizasyonları, güvenlik kontrolleri ve erişim kontrolleri—uygulanabilir.

Bu rehberde ne beklemelisiniz

Bu makale şu ilerlemeyi takip eder: önce performans (CDN), ardından uçta güvenlik (DDoS, WAF, bot kontrolleri, Zero Trust) ve son olarak geliştirici araçları (kodu çalıştırma ve veriyi kullanıcılara yakın işleme).

Bu yazı teknik olmayan karar vericiler için yazıldı—satın alma değerlendirmesi yapanlar, temel seçimleri yapan kurucular ve “neden”i ve “ne değişiyor”u bilmesi gereken PM'ler için; ağ kitapları okumalarını gerektirmeyecek şekilde.

CDN Temelleri: Başlangıç Noktası

Geleneksel bir CDN (Content Delivery Network) basit bir vaade başladı: içerikleri ziyaretçiye daha yakın bir konumdan sunarak web sitelerini daha hızlı hissettirmek. Her isteğin origin sunucunuza (çoğunlukla tek bir bölge veya veri merkezi) geri gitmesi yerine, CDN statik dosyaların—resimler, CSS, JavaScript, indirmeler—kopyalarını birçok PoP'ta saklar. Bir kullanıcı bir dosya istediğinde, CDN yerel olarak yanıt verebilir; bu da gecikmeyi azaltır ve origin üzerindeki baskıyı hafifletir.

Klasik bir CDN ne yapar

Özünde, “yalnızca CDN” kurulumu üç çıktıya odaklanır:

• Önbellekleme: Tekrar isteklerde origin'e gitmeyi azaltmak için içeriği kenarda depolamak.
• Gecikmeyi azaltma: Kullanıcı ile içerik arasındaki fiziksel mesafeyi (ve ağ atlamalarını) kısaltmak.
• Origin yükünü azaltma: Trifikın büyük bir kısmını kenarın karşılaması, origin'in daha az veri ve isteği işlemesi.

Bu model, statik siteler, medya ağırlıklı sayfalar ve aynı varlıkların sürekli istendiği öngörülebilir trafik desenleri için özellikle etkilidir.

Erken CDN başarı metrikleri

İlk dönemlerde ekipler CDN'leri birkaç pratik metrikle değerlendirirdi:

• Cache isabet oranı: İsteklerin yüzde kaçı cache'ten servis edildi, origin'e gönderilmedi.
• Bant genişliği tasarrufu: CDN'in origin yerine kaç GB/TB teslim ettiği.
• Sayfa yükleme süresi iyileştirmeleri: Genellikle time-to-first-byte (TTFB) ve genel sayfa render süreleri olarak takip edilir.

Bu sayılar önemlidir çünkü doğrudan kullanıcı deneyimine ve altyapı maliyetine tercüme olur.

Bir CDN'in istek yolundaki yeri

Basit bir CDN bile isteklerin sitenize ulaşma şeklini etkiler. En yaygın olarak, CDN DNS aracılığıyla devreye sokulur: alan adınız CDN'e yönlendirilir ve CDN ziyaretçileri yakın bir PoP'a yönlendirir. Oradan CDN bir reverse proxy olarak hareket edebilir—kullanıcıdan gelen bağlantıyı sonlandırır ve gerektiğinde origin ile ayrı bir bağlantı açar.

Bu “ortada olma” pozisyonu önemlidir. Sağlayıcı origin'inizin önünde güvenilir şekilde durup kenarda trafiği işlediğinde, sadece dosya önbelleklemenin ötesinde şeyler yapabilir—istekleri inceleyebilir, filtreleyebilir ve şekillendirebilir.

Modern uygulamalar için “yalnızca CDN”in sınırları

Birçok modern ürün artık çoğunlukla statik sayfalar değil. Dinamik uygulamalar, API destekli kişiselleştirme, gerçek zamanlı güncellemeler, kimlik doğrulamalı akışlar ve sık yazma işlemleri var. Önbellekleme yardımcı olur ama her şeyi çözemez—özellikle yanıtlar kullanıcıya göre değişiyorsa, çerezler veya başlıklara bağlıysa ya da anlık origin mantığı gerektiriyorsa.

İşte bu boşluk—statik hızlandırma ile dinamik uygulama ihtiyaçları arasındaki fark—“CDN”den daha geniş bir edge platformuna evrimin başladığı yerdir.

Neden Trafik Perimetrede Yoğunlaşıyor

İnternetin kullanım şeklinindeki büyük bir değişim, daha fazla isteğin origin sunucularına ulaşmadan önce “kenarda” (ağ perimetresi) toplanmasına neden oldu. Artık sadece daha hızlı web siteleri meselesi değil—trafik doğal olarak nerede akıyor sorusu önem kazandı.

Trafiği dışa çeken güçler

HTTPS her yerde olması büyük bir belirleyici. Trafiğin çoğu şifreli hale gelince, kurumsal ağ içindeki ağ kutucukları bunu kolayca inceleyip optimize edemez. Bunun yerine organizasyonlar TLS'yi kullanıcıya daha yakın—bu işe uygun bir edge serviste—sonlandırmayı ve yönetmeyi tercih ediyor.

API'ler de trafiğin şeklini değiştirdi. Modern uygulamalar web frontend'leri, mobil istemciler, partner entegrasyonları ve mikroservislerden gelen sürekli küçük istek akışlarıdır. Buna botları (iyi ve kötü) eklediğinizde, bir kısmı insan olmayan büyük bir “kullanıcı” hacmi ortaya çıkar—bu da trafiğin uygulama altyapısına ulaşmadan önce filtrelenmesi ve oran kontrolleri uygulanmasını gerektirir.

Buna mobil ağların günlük gerçekleri (değişken gecikme, dolaşım, yeniden iletimler) ve SaaS'in yükselişi eklenince, çalışanlarınız ve müşterileriniz artık tek bir ağ sınırı “içinde” değil; bu nedenle güvenlik ve performans kararları kullanıcıların gerçekten bağlandığı yere taşınıyor.

Dağıtık sistemler daha az tıkanma noktası demek

Uygulamalar, kullanıcılar ve servisler bölgelere ve bulutlara dağıldıkça, kuralların uygulanacağı güvenilir yerler azalır. Geleneksel kontrol noktaları—tek bir veri merkezi güvenlik duvarı gibi—varsayılan yol olmayı bırakır. Kenar, çoğu isteğin yönlendirilebileceği tutarlı kontrol noktalarından biri haline gelir.

Kenar, politika ve koruma kontrol noktası olarak

Çok fazla trafik perimetreden geçtiği için, burası paylaşılan politikaların uygulanacağı doğal bir yerdir: DDoS filtreleme, bot tespiti, WAF kuralları, TLS ayarları ve erişim kontrolleri. Bu, her origin'de ayrı ayrı karar verme ihtiyacını azaltır ve korumaları uygulamalar arasında tutarlı kılar.

Operasyonel takaslar

Trafiği kenarda merkezileştirmek origin IP'leri gizleyebilir ve doğrudan maruziyeti azaltabilir; bu anlamlı bir güvenlik kazanımıdır. Fakat takas bağımlılıktır: kenarın kullanılabilirliği ve doğru konfigürasyonu kritik hale gelir. Birçok ekip kenarı basit bir önbellekten ziyade çekirdek altyapının bir parçası—kontrol düzleminin bir parçası—olarak ele alır.

Pratik bir kontrol listesi için /blog/how-to-evaluate-an-edge-platform'a bakın.

Önbellekten Tam Proxy'ye: Ana Mimari Değişim

Geleneksel bir CDN “akıllı önbellekleme” olarak başladı: statik dosyaların kullanıcıya yakın kopyalarını sakladı ve gerektiğinde origin'den getirdi. Bu performansa yardımcı olur, ama bağlantının “sahibini” kökten değiştirmez.

Büyük değişim, kenar sadece bir cache olmaktan çıktığında ve tam bir reverse proxy haline geldiğinde olur.

Reverse proxy, basitçe

Reverse proxy, web sitenizin veya uygulamanızın önünde oturur. Kullanıcılar proxy'ye bağlanır; proxy origin'inize bağlanır. Kullanıcıya proxy siteymiş gibi görünür; origin'e proxy, kullanıcıymış gibi görünür.

Bu konumlandırma, her isteğin altyapınıza ulaşmadan önce işlenebildiği, değiştirilebildiği veya engellenebildiği servisleri mümkün kılar—ki bunlar “yalnızca cache” davranışıyla mümkün değildir.

Kenar TLS'yi sonlandırdığında neler değişir

Kenar TLS'yi sonlandırdığında, şifreli bağlantı önce kenarda kurulmuş olur. Bu üç pratik yetenek yaratır:

1. Görünürlük: kenar artık HTTP isteklerini ve yanıtlarını (başlıklar, yollar, metodlar) gerçekten okuyabilir, sadece şifreli baytları iletmez.
2. Yönlendirme kontrolü: kenar isteğe göre kararlar alabilir—trafiği farklı origin'lere gönderme, kesintilerde yönlendirme veya coğrafya/cihaz/URL bazlı kurallar uygulama.
3. İnceleme ve uygulama: kenar isteği yorumlayabildiği için güvenlik kontrolleri (şüpheli yükleri filtreleme, bot doğrulama) ve performans mantığı (sıkıştırma, resim dönüşümleri, istek şekillendirme) çalıştırabilir.

İşte zihinsel model:

user → edge (reverse proxy) → origin

Takaslar: daha fazla kontrol, daha fazla bağımlılık

Kenarın ortada olması kontrolü merkezileştirir; bu genellikle hedeflenen şeydir: tutarlı güvenlik politikaları, daha basit dağıtımlar ve her origin'de daha az “özel durum”.

Ancak bu aynı zamanda karmaşıklık ve bağımlılık da getirir:

• Operasyonel bağlılık: kenar konfigürasyonu bozulursa, her şey hızla bozulur.
• Sağlayıcı bağımlılığı: özellikler taşınamaz, özel kurallar, loglar veya API'lere dayalı olabilir.
• Hata ayıklama yükü: artık çok adımlı bir yolu (kullanıcı ↔ kenar ↔ origin) değil, bu çok adımlı yolu çözümlemeniz gerekir.

Bu mimari değişim, bir CDN'i bir platforma dönüştürür: kenar proxy olduğunda, önbelleklemenin çok ötesinde işler yapabilir.

Güvenlik Adım 1: Kenarda DDoS Koruması

DDoS (Dağıtık Hizmet Reddi) saldırısı basitçe bir siteyi veya uygulamayı gerçek kullanıcıların erişemeyeceği kadar çok trafikle aşırı yüklemeye çalışmaktır. "İçeri hacklemek" yerine saldırgan arabayı tıkamaya çalışır.

Neden volümetrik saldırılar kenarda hafifletmeye elverişli

Birçok DDoS saldırısı volümetriktir: hedef IP adresinize yüksek miktarda veri göndererek bant genişliğini veya ağ cihazlarını tüketmeyi hedefler. Origin'de (veri merkezi veya bulut bölgesi) savunmayı beklerseniz, zaten bedelini ödemiş olursunuz—üst akış bağlantılarınız doygun hale gelebilir ve firewall veya load balancer tıkanma noktası olur.

Bir edge ağı yardımcı olur çünkü trafiğin internete giriş yaptığı yerlere daha yakın koruma kapasitesi koyar; sadece sunucularınızın olduğu yere değil. Savunma ne kadar dağıtık olursa, saldırganların tek bir tıkanma noktasında “yığılmaları” o kadar zorlaşır.

Kenarda “absorbe etme ve filtreleme” ne demek

Sağlayıcılar DDoS korumasını “absorbe ve filtre etme” şeklinde tanımladığında, birçok PoP arasında gerçekleşen iki şeyi kastederler:

• Absorb: gelen bağlantı taşkınlarını çökmeksizin kabul edip sonlandırmak, yükü küresel kapasiteye yaymak.
• Filter: meşru istekleri çöplerden (örn. bozuk paketler, şüpheli desenler veya amplifikasyon trafiği) ayırmak ve sadece temiz trafiği origin'e iletmek.

Ana fayda, saldırının en kötü kısmının altyapınıza ulaşmadan yukarı akışta ele alınmasıdır; böylece kendi ağınızın veya bulut faturanızın kurban olma ihtimali azalır.

Hız sınırlama: teknisyen olmayanların anlayabileceği kontrol

Rate limiting, tek bir kaynak veya davranışın çok fazla kaynağı çok hızlı tüketmesini önlemenin pratik bir yoludur. Örneğin sınırlayabilirsiniz:

• Bir giriş uç noktasına dakika başına istek sayısını
• Token başına API çağrılarını
• IP başına pahalı sayfaları

Kendi başına her türlü DDoS'u durdurmaz, ama kötüye yönelik ani baskıları azaltan ve kritik yolları kullanılabilir tutan etkili bir basınç tahliye valfidir.

Buna güvenmeden önce doğrulamanız gerekenler

Kenar tabanlı DDoS korumasını değerlendiriyorsanız, doğrulayın:

• Kapsam: hangi trafik türleri korunuyor (HTTP/S, TCP/UDP, DNS) ve tüm alan adlarınız/uygulamalarınız için otomatik olarak geçerli mi?
• SLA ve taahhütler: sağlayıcının ne garanti ettiği (çalışırlık, mitigasyon beklentileri, destek yanıtı) ve herhangi bir limit veya hariç tutma var mı?
• Raporlama: saldırı boyutu, süresi, uygulanan mitigasyonlar ve origin'e ne ulaştığını gösteren net panolar ve loglar—böylece olayları şirket içinde açıklayabilir ve kontrolleri zamanla ayarlayabilirsiniz.