02 May 2025·4 dk
CDN'den Platforma: Cloudflare'ın Edge'i Nasıl Genişledi
Cloudflare'ın edge'inin CDN önbelleklemeden güvenlik ve geliştirici hizmetlerine nasıl genişlediğini öğrenin; daha fazla trafik ağ perimetresine kaydıkça neler değişiyor görün.
Cloudflare'ın edge'inin CDN önbelleklemeden güvenlik ve geliştirici hizmetlerine nasıl genişlediğini öğrenin; daha fazla trafik ağ perimetresine kaydıkça neler değişiyor görün.
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, 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 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.
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.
Özünde, “yalnızca CDN” kurulumu üç çıktıya odaklanır:
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.
İlk dönemlerde ekipler CDN'leri birkaç pratik metrikle değerlendirirdi:
Bu sayılar önemlidir çünkü doğrudan kullanıcı deneyimine ve altyapı maliyetine tercüme olur.
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.
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.
İ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ı.
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.
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.
Ç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.
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.
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, 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, şifreli bağlantı önce kenarda kurulmuş olur. Bu üç pratik yetenek yaratır:
İşte zihinsel model:
user → edge (reverse proxy) → origin
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:
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.
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.
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.
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:
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.
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:
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.
Kenar tabanlı DDoS korumasını değerlendiriyorsanız, doğrulayın:
Bir edge ağı, isteklerin kullanıcılara daha yakın işlenebildiği birçok şehirde yer alan dağıtık sunucu (PoP) setidir. İstek türüne göre kenar şunları yapabilir:
Pratik sonuç: daha düşük gecikme ve origin altyapınızda daha az yük ve maruziyet.
Perimetre, internet trafiğinin sistemlerinize ilk ulaştığı sınırdır—web siteniz, uygulamalarınız ve API'leriniz genellikle DNS ve bir kenar reverse proxy aracılığıyla erişilir. Önemli olmasının nedenleri:
Kontrolleri perimetrede merkezileştirmek, trafik çekirdeğinize ulaşmadan önce tutarlı performans ve güvenlik kuralları uygulamanızı sağlar.
Klasik bir CDN, kenar lokasyonlarda statik içeriği önbelleğe alma üzerine odaklanır (resimler, CSS, JS, indirmeler). Bu, mesafeyi azaltarak ve origin üzerindeki yükü hafifleterek hızı artırır.
Modern bir edge platformu ise çoğu trafiğe tam bir reverse proxy gibi davranarak yönlendirme, güvenlik incelemesi, erişim kontrolleri ve bazen compute yetenekleri sağlar—içerik önbelleğe alınabilir olmasa bile.
DNS genellikle bir CDN/edge sağlayıcısını sitenizin önünde konumlandırmanın en basit yoludur: alan adınız sağlayıcıya işaret eder ve sağlayıcı ziyaretçileri yakın bir PoP'a yönlendirir.
Birçok kurulumda kenar ayrıca reverse proxy olarak davranır; kullanıcı önce kenara bağlanır ve kenar gerektiğinde origin ile iletişime geçer. Bu “ortada olma” konumu, büyük ölçekli önbellekleme, yönlendirme ve güvenlik uygulamalarını mümkün kılar.
Kenar TLS'yi sonlandırdığında, HTTPS bağlantısı kenarda kurulur. Bu üç pratik yetenek kazandırır:
Daha fazla kontrol sağlar—ancak kenar konfigürasyonunun kritik hale gelmesi demektir.
Bir CDN'i kullanıcı deneyimi ve altyapı maliyetiyle ilişkilendiren metriklerle değerlendirmelisiniz, örneğin:
Bunları origin tarafı metrikleriyle (CPU, istek oranı, egress) eşleştirerek CDN'in gerçekten önemli yerde baskıyı azaltıp azaltmadığını doğrulayın.
Edge mitigasyonu, birçok DDoS saldırısının volümetrik olması nedeniyle etkilidir—saldırılar bant genişliğini veya ağ cihazlarını doyurmaya çalışır.
Dağıtık bir kenar şunları yapabilir:
Sadece origin'de savunmak genellikle faturalandırma, doygun bağlantılar veya aşırı yük gibi maliyeti size ödetir.
Hız sınırlama (rate limiting), bir istemcinin veya bir tokenin belirli bir zaman aralığında yapabileceği istek sayısını sınırlayarak tek bir kaynağın orantısız kaynak tüketmesini engeller.
Yaygın kenar kullanım örnekleri:
Her DDoS'u durdurmaz, ama kötü niyetli veya hatalı ani sıçramalar için güçlü ve anlaşılır bir kontrol sağlar.
WAF, HTTP isteklerini inceler ve yaygın uygulama saldırı desenlerini engellemek için kurallar uygular (örneğin SQLi ve XSS). Bot yönetimi ise otomatik trafiği—hem iyi botları (arama motorları) hem de zararlı botları (scraping, sahte kayıtlar, credential stuffing)—tanımlayıp ele almaya odaklanır.
Pratik bir yaygınlaştırma adımları:
Zero Trust, erişim kararlarının kimlik ve bağlama dayalı olduğu anlamına gelir; ağa ‘‘içeriden’’ gelindiği için otomatik güven verilmez. Kenarda tipik uygulamalar şunlardır:
Yaygın hata: bunu sadece VPN yerine koymak. VPN'i kaldırmak kullanılabilirliği artırsa da kimlik uygulamalarını güçlendirmemek, geniş izinleri kaldırmamak veya oturum sürelerini kısaltmamak riski sürdürür.