Edge computing nedir? Klasik hostingden farkı ve kullanım alanı

Edge computing; uygulamanın ve içeriğin, kullanıcıya en yakın ağ kenarında (edge) çalıştırılmasını hedefler. Klasik hosting modelinde istekler çoğunlukla tek bir merkez sunucuya gider ve yanıt buradan döner. Edge computing; gecikmeyi (latency) düşürür, trafik dalgalanmalarında daha stabil çalışmayı hedefler ve bazı iş yüklerinde maliyeti daha öngörülebilir hale getirir. Bu yazıda edge computing’in ne olduğunu, klasik hosting ile farklarını ve hangi senaryolarda işe yarayıp yaramadığını teknik olarak ayıracağız.

Edge computing nedir? “Sunucu” fikrini nasıl değiştirir?

Edge computing, istemci isteğini merkezi bir veri merkezine göndermek yerine, bu isteği ağın kenarında işleyen bir dağıtık mimaridir. Buradaki “kenar” kavramı; internet servis sağlayıcısının (ISP) veya içerik dağıtım ağlarının (CDN/CDN benzeri) sahip olduğu erişim noktaları, bölgesel PoP’ler (point of presence) ve bazen bulut sağlayıcısının edge lokasyonları anlamına gelir.

Edge’de genellikle şu bileşenler çalıştırılır: - Statik içerik önbellekleme: görsel, JS/CSS, indirme dosyaları - Dinamik içerik için kenar uygulaması: hafif işleme, varyant üretimi (ör. ülkeye göre içerik) - Akıllı yönlendirme: kullanıcıya en yakın kaynağı seçme - Koruma ve optimizasyon: WAF kuralları, rate limit, bot/akış filtreleme - Protokol katmanı iyileştirmeleri: HTTP/3 (QUIC) benzeri düşük gecikme yaklaşımları

Bu yaklaşımın temel etkisi şudur: içerik ya da kararlar, kullanıcının fiziksel konumuna daha yakın bir yerde oluşur. Böylece özellikle ilk byte süresi (TTFB) ve toplam gecikme azalır.

Edge computing nerede “çalışır”?

Pratikte iki katman görürsünüz: 1. CDN + Edge güvenlik/transform: Çoğu kullanıcı senaryosunda en hızlı görülen kısım budur. 2. Edge compute (serverless/mini runtime): Daha fazla mantık gerekiyorsa, kenarda çalışan küçük uygulama mantığı devreye girer.

Klasik hostingde “sunucu” tek bir fiziksel/virtual makinedir. Edge’de ise sunucu mantığı dağıtılır: bazı kararlar ve bazı hesaplamalar birçok edge lokasyonda gerçekleşir.

Klasik hosting ile edge arasındaki farklar (somut karşılaştırma)

Klasik hosting (paylaşımlı hosting, VDS/VPS, dedicated, hatta tek bölge bulut sunucusu) istekleri genellikle tek bir bölgedeki uygulama sunucusuna ulaştırır. Edge tarafında ise istekler dağıtılır ya da uygulamanın bazı adımları kenarda tamamlanır.

Aşağıdaki tablo, karar vermeyi kolaylaştıracak şekilde farkları netleştirir:

Aynı web uygulamasında fark nerede hissedilir?

Özellikle şu durumlarda edge’in etkisi daha belirgindir: - Kullanıcılar ülke/bölge olarak dağınıksa (ör. Avrupa + Türkiye + Orta Doğu) - İçeriğin önemli kısmı statik veya az değişkense - İlk yükleme süresi (page load) ve TTFB kritikse - Bot saldırıları veya istek filtresi erken yapılmalıysa

Buna karşılık, CPU yoğun ve veri bağımlılığı yüksek işler (ör. her istekte ağır veritabanı işlemi) edge’de sınırlı fayda gösterebilir. Kenarda doğru yerleştirme yapılmadıkça, istek yine merkeze döner.

Edge compute: Ne zaman “hesaplama” yapar?

Edge computing tek başına yalnızca CDN gibi çalışmaz. Edge compute ile bazı iş adımları kenarda yürütülür. Buradaki kritik nokta “her şeyi kenarda çalıştırma” hedefi değil; doğru iş yükünü doğru katmanda çözmektir.

Kenarda işlem mantığı şu şekilde kurulabilir: - İstek kenarda karşılanır - Cache hit ise doğrudan yanıt döner - Cache miss ise kenarda hafif dönüşüm/filtreleme yapılır - Gerekirse nihai yanıt merkez uygulamadan alınır

Edge compute için doğru örnekler: - Ülkeye/cihaza göre küçük varyant üretme (dil, para birimi gibi) - Basit yönlendirme ve URL rewrite - Kenarda imza/doğrulama (ör. belirli header tabanlı kararlar) - Bot/ülke bazlı hız sınırlama

Doğru olmayan örnekler: - Her istekte çok ağır veri modelleme ve uzun süren hesaplar - Büyük miktarda bellek/disk gerektiren kalıcı iş akışları

Edge ile klasik hosting mimarisini birlikte düşünün

Edge computing çoğu zaman “klasik hostingin yerine geçmek”ten ziyade “klasik hostingin performans katmanını güçlendirmek” olarak kullanılır. Yani tipik mimari şöyle işler: - Domain → DNS → edge yönlendirme - Edge → önbellek + güvenlik kuralları - Edge → gerekirse origin (klasik hosting uygulama sunucusu) - Origin → dinamik yanıt

Cache stratejisi: Farkı yaratan asıl teknik detay

Edge’in değeri cache başarısına bağlıdır. Yanlış cache ayarları, performans kazancını yok edebilir ya da dinamik içerikte tutarsızlığa yol açabilir.

Uygulamada kontrol etmeniz gereken başlıklar: - Cache süresi (TTL): Statik içerik uzun TTL ile daha verimli olur. - Cache key: Dil/ülke/oturum gibi varyantlar doğru anahtarda ayrılmalı. - Purging (temizleme): İçerik güncellenince edge cache nasıl temizleniyor? - Stale-while-revalidate: Güncelleme sırasında kullanıcıya eski içerik döndürmek ne zaman mantıklı?

Edge cache’i doğru kurulduğunda, klasik hosting sunucunuzun “orijin trafik” yükü ciddi biçimde düşer.

Edge computing maliyetini nasıl okursunuz? (sadece sunucu fiyatı değil)

Klasik hostingte maliyet çoğunlukla sabittir: aylık ücret + bant genişliği. Edge computingde ise maliyet, edge sağlayıcının hesaplama/bant genişliği/istek metrikleriyle şekillenir.

Bu nedenle maliyeti şu şekilde okumanız gerekir: - Origin trafiği azalıyor mu? (edge cache hit arttıkça) - İstek sayısı artıyor mu? (kenarda uygulama/kurallar kullanımı) - Edge compute çağrıları ne kadar sık? (kullanım bazlı ücretler)

NetKıyas’ta karar verirken bakılacak teknik sinyaller

Tek bir fiyat satırına takılmak yerine, aşağıdaki sorulara teknik cevap arayın: - İçeriğin kaçta kaçı statik ve ne kadar süre değişiyor? - Dinamik sayfalarda hangi endpoint’ler kenarda kararlaştırılabilir? - Uygulamanın en çok yük getiren akışları (login, arama, ödeme) hangi katmanda çalışmalı? - Hangi güvenlik kontrolleri kenarda uygulanabilir? (ör. WAF kuralları)

Bu çerçeve, “edge mi klasik mi” tartışmasını somutlaştırır.

Edge computing için doğru kullanım senaryoları

Edge computing’in güçlü olduğu alanları net örneklerle ayıralım:

1) Çok bölgeli kullanıcı trafiği olan siteler

Türkiye’den Avrupa’ya veya farklı kıtalara yayılmış kullanıcıların olduğu durumlarda gecikme farkı ilk yüklemede hissedilir. Edge; kullanıcıya yakın noktadan yanıt vererek sayfa hızını artırır.

2) Statik ağırlıklı içerik (dosya, görsel, medya)

Dosyalar CDN’de önbelleklenir. Origin sunucu daha az meşgul olur. Büyük indirme trafiğinde merkezde bant genişliği ihtiyacı düşer.

3) Bot saldırısı ve hızlı WAF kararları

Kenarda rate limit ve WAF kontrolleri çalıştığında, kötü niyetli istekler origin’e ulaşmadan filtrelenir. Bu; hem performansı hem de origin kaynak tüketimini etkiler.

4) Dinamik içerikte sınırlı ama kritik varyantlar

Tam “her şey edge’de” yapılmaz; ancak dil/ülke varyantı gibi küçük dönüşümler kenarda üretilebilir.

Edge computing ne zaman beklediğiniz kadar kazandırmaz?

Edge’de her problem çözülmez. Aşağıdaki durumlar kazancı düşürür:

1) Her istek ağır veritabanı işlemi gerektiriyorsa

Kenarda cache hit olsa bile; kritik akışlar sürekli origin’e gidiyorsa edge’in temel avantajı sınırlanır.

2) Cache stratejisi kurulamazsa

TTL yanlışsa veya cache key varyantları doğru ayrılmıyorsa tutarsız içerik üretir. Bu durumda edge’i devre dışı bırakmak veya daha kısa TTL kullanmak gerekir; kazanç düşer.

3) Uygulama kenar koşullarına uyumlu değilse

Kenarda çalışan mantığın kısıtları vardır: süre/işlem limitleri, depolama kısıtları, dış servis erişim modeli gibi. Uygulama tasarımı buna göre uyarlanmazsa fayda azalır.

Uygulama planı: Klasik hostingten edge’e adım adım geçiş

Edge’i bir anda “tam geçiş” yerine, aşamalı optimizasyon olarak düşünün. Aşağıdaki plan tipik bir yol haritasıdır:

1) İçerik envanteri çıkarın

• Statik dosyalar (JS/CSS/görsel/indirilebilir dosya)
• Dinamik sayfalar ve endpoint’ler
• En sık erişilen URL’ler

2) Cache hedeflerini belirleyin

• Statikler için uzun TTL
• Dinamikler için doğru varyantlama
• Güncelleme senaryoları için purge mekanizması

3) Güvenlik kurallarını kenara taşıyın

• Rate limit
• Temel WAF kuralları
• Bot filtreleme

4) Edge compute ile küçük iş adımları ekleyin

• URL rewrite
• Dil/ülke varyantı
• Hafif doğrulamalar

5) Ölçümleyin ve geri bildirimle ilerleyin

• TTFB değişimi
• Origin’e giden istek oranı
• Cache hit oranı
• Hata oranı ve gecikme dağılımı

Son olarak, edge computing; doğru içerik ve doğru mimari ile gecikmeyi düşürür, origin maliyetini ve kaynak tüketimini azaltır. Aksiyon olarak şu sırayla ilerleyin: önce içerik türlerini ayırın, ardından cache stratejisini tasarlayın, en sonra güvenlik ve küçük kenar iş adımlarını devreye alın. Bu planı takip ettiğinizde edge’in sağladığı performans kazanımı ölçülebilir hale gelir ve klasik hosting maliyetinizle birlikte daha net bir optimizasyon yaparsınız.