Edge computing nedir? Klasik hosting’den farkları net açıklama

Edge computing, web uygulamalarının çalışmasını "yakınlık" mantığıyla yeniden kurar. Klasik hosting’de kaynak (compute) genellikle tek veya birkaç merkezde toplanır; bu da kullanıcı ile sunucu arasındaki gecikmenin (latency) kaderinizi belirlemesine yol açar. Edge computing’de ise hesaplama ve/veya içerik dağıtımı, kullanıcıya daha yakın noktalar üzerinden yürütülür. Bu yazıda, edge computing’in ne olduğunu, klasik hosting’den farkını ve pratik seçim/ölçüm kriterlerini net şekilde göreceksiniz.

Edge computing nedir?

Edge computing, uygulamanın belirli iş yüklerini ağın "kenarına" (edge) taşıyarak daha hızlı tepki vermesini sağlayan dağıtık bir mimaridir. Buradaki "edge" genellikle kullanıcıya yakın veri merkezi noktaları, internet servis sağlayıcı (ISP) yakın konumlar veya CDN/edge platformlarının uç PoP (Point of Presence) noktalarıdır.

Edge computing’in iki yaygın yaklaşımı vardır: - Edge’de içerik teslimi (delivery): HTML/JS/CSS gibi statik içerikler ve bazı dinamik parçalar CDN üzerinden daha yakın konumdan sunulur. - Edge’de hesaplama (compute): Basit iş mantığı (ör. yönlendirme, basit doğrulama, varyasyonlu yanıt üretimi) kullanıcıya yakın noktada çalışır.

Not: Edge computing’i tek bir ürünle sınırlamak doğru olmaz. CDN, reverse proxy, API gateway, WAF ve serverless edge fonksiyonları gibi bileşenler edge mimarisinin parçaları olabilir.

Edge ve CDN aynı şey mi?

CDN çoğu senaryoda edge’in önemli bir parçasıdır. Ancak CDN, ağırlıkla içerik önbellekleme ve teslim odaklıdır. Edge computing ise içeriğin yanında kısmî hesaplama/işlemeyi de edge’e getirebilir. Yani CDN = edge’in bir alt bileşeni gibi düşünülebilir.

Klasik hosting’de iş nasıl akar?

Klasik hosting’de (VDS/VPS veya geleneksel web hosting) kullanıcı isteği çoğunlukla şu rotayı izler: 1. Kullanıcı isteği internete çıkar. 2. İstek, ana sunucuya (veya birkaç bölgesel merkeze) gider. 3. Uygulama kodu çalışır, veritabanı/servisler merkezi kaynaklarda cevap üretir. 4. Yanıt geri kullanıcıya döner.

Bu rota, her istekte aynı merkez(ler) ile çalıştığı için kullanıcıya uzak bölgelerde gecikme büyür. Ayrıca çok sayıda farklı kullanıcı kitlesi olan sitelerde önbellek ve varyasyon yönetimi karmaşık hale gelebilir.

Klasik hosting ile edge computing’in temel farkları

Edge computing’i net ayıran farklar aşağıdadır:

1) Latency (gecikme) davranışı

• Klasik hosting: Hesaplama çoğunlukla merkezi kaynakta yapılır. Kullanıcı ile merkez arasındaki RTT (round-trip time) gecikmeye doğrudan yansır.
• Edge computing: İstek, kullanıcıya daha yakın PoP’lara uğrar. Hesaplama veya en azından yanıt üretiminin parçası daha kısa yoldan döner.

Bu fark özellikle "her istek hızlı dönmeli" durumlarında görünür: gezinti, arama/filtre, kişiselleştirme, küçük dinamik yanıtlar, A/B test varyasyonları.

2) Mimari katman dağılımı

• Klasik hosting: Uygulama katmanı (app) ve veritabanı genellikle aynı bölgede veya sınırlı sayıda bölgede toplanır.
• Edge computing: Trafik yönlendirme, ön işleme (pre-processing), varyasyon seçimi ve bazı kurallar edge’de uygulanır. Gerçek uygulama ise ancak gerektiğinde merkezi katağa devreder.

3) Önbellek ve veri tutarlılığı

Edge’de önbellek yaygındır. Bu, performansı artırır ama doğru strateji kurulmazsa tutarsız içerik riski oluşur. - Klasik hosting’de caching genelde daha sınırlı alanlarda uygulanır (ör. uygulama cache’i, Nginx cache). - Edge’de caching daha ölçekli olur; ancak cache key tasarımı, TTL, varyasyon başlıkları (ör. Accept-Encoding, User-Agent, dil/ülke) gibi ayarlar kritik hale gelir.

4) Güvenlik ve trafik yönetimi

• Klasik hosting’de WAF/limit/deny kuralları genelde sunucuya ulaşmış trafikte çalışır.
• Edge’de bu kurallar daha en başta uygulanabilir. Böylece saldırı trafiği daha az merkezi kaynağa ulaşır.

5) Ölçeklenebilirlik modeli

• Klasik hosting: Ölçek, daha çok sunucu kaynaklarını artırma (CPU/RAM) veya yatay ölçekleme ile yapılır.
• Edge computing: Trafiği dağıtma, önbellekleme ve edge’de iş parçacıkları üretme sayesinde merkezi kaynaklara düşen yük azalır. Bu da ölçek ihtiyacını farklı bir noktaya taşır.

Ne zaman edge computing mantıklıdır? Net kullanım senaryoları

Aşağıdaki senaryolarda edge computing genellikle somut fayda verir: - Çok coğrafyalı kullanıcı tabanı: Türkiye, Avrupa ve ABD’den aynı anda yoğun trafik alan uygulamalar. - Dinamik ama sınırlı kurallı yanıtlar: Dil seçimi, cihaz tipine göre varyasyon, basit yönlendirme, ödeme sayfası ön hazırlık gibi. - Anlık kişiselleştirme: Kullanıcıya göre küçük farklar (örn. coğrafi para birimi, dil) gerekiyorsa. - API ön yüzü (API facade): Bazı istekleri doğrulamak, throttling yapmak, basit response üretmek. - Live olmayan ama sık değişen içerik: Tam her istekte origin’e gitmek yerine edge önbelleği ile TTL mantığı kurmak.

Tersine, aşağıdaki durumlarda edge’in etkisi sınırlı kalabilir: - İsteklerin tamamı ağır veritabanı işlemine bağlıysa ve hesaplamanın tamamı origin’e gidiyorsa. - Edge’de uygulanması mümkün olmayan karmaşık iş mantığı tamamen backend’de çalışmak zorundaysa.

Edge mimarisinde klasik hosting yerine ne kullanılır?

Edge computing, VDS/VPS’i tamamen ortadan kaldırmaz. Çoğu sistemde edge, ön yüz (front) rolünü üstlenirken, origin tarafında uygulama ve veri katmanı çalışmaya devam eder.

Tipik katmanlar: - Edge katmanı: CDN/edge proxy, edge fonksiyonları (varsa), WAF, DDoS koruması, trafik yönlendirme. - Origin katmanı: VDS/VPS/dedicated sunucu veya managed uygulama altyapısı. - Veri katmanı: Uygulama veritabanı, nesne depolama, arama motoru gibi.

Hangi yük edge’e taşınmalı?

Edge’e taşınacak iş, genellikle şu kriterleri karşılar: - Kısa ve deterministik işlem: yönlendirme, basit hesaplar, küçük doğrulamalar. - Cache edilebilir yanıt üretebilme. - Origin’i her istek için çağırmaya gerek bırakmama.

Örneğin bir e-ticaret sitesi düşünün: - Dil/para birimi varyasyonunu edge’de seçip şablonu varyasyona göre döndürmek faydalıdır. - Sepet içeriği gibi durum bilgisi (state) gerekiyorsa, edge sadece başlangıç aşamalarında rol almalı; gerçek hesaplama/ürün doğrulama origin’e kalmalıdır.

Performansı nasıl ölçersiniz? Edge’in işe yaradığını doğrulama rehberi

Edge computing’in değerini, varsayımla değil ölçümle doğrulayın. Aşağıdaki yöntemler özellikle karşılaştırma için nettir.

1) Ölçüm hedeflerini tanımlayın

Şunları netleştirin: - İlk bayta kadar süre (TTFB) - Tam yüklenme süresi (TTI/inceleme hedefiniz) - API için istek başına p50/p95 gecikme - Origin’e giden istek oranı (cache hit oranı)

2) Aynı içerik/aynı varyasyonla karşılaştırın

Edge’i test ederken şu hataya düşmeyin: Edge ile test ettiğiniz yol farklı cache key’lerle çalışıyorsa sonuçlar yanıltır. - Dil varyasyonu - Cihaz türü varyasyonu - Önbellek bypass başlıkları - Oturumlu kullanıcılar vs oturumsuz kullanıcılar

3) Cache hit oranını ve origin çağrı sayısını takip edin

Somut hedef örnekleri: - Statik sayfalar için cache hit oranını yükseltmek - Origin’e giden istek sayısını düşürmek

4) Bölgesel test yapın

Türkiye’den test etmek tek başına yeterli değil. En azından: - Uygulamanın gerçek kullanıcı dağılımı: ör. TR-AB-UK/US - Aynı endpoint’i aynı saat diliminde karşılaştırın

5) Görünür metrikleri günlükleyin

• Edge tarafında istek sayısı, hata kodları, throttling/WAF tetiklenmeleri
• Origin tarafında CPU/RAM ve veri tabanı sorgu sayısı

Böylece edge’in sadece hız değil, kaynak tüketimi üzerindeki etkisini de görürsünüz.

Edge vs klasik hosting: seçim kriterleri tablosu

Aşağıdaki tablo, hangi durumda hangi yaklaşımın daha mantıklı olduğunu hızlıca görmenize yardım eder.

Pratik uygulama: edge’i başarılı yapmak için kontrol listesi

Edge’e geçiş yaparken en sık yapılan hatalar cache tutarsızlığı, yanlış varyasyon anahtarları ve origin’e gereksiz çağrıdır. Bu kontrol listesi doğrudan işinize yarar.

1) Cache stratejisini belirleyin

• Statik içerik için uzun TTL
• Dinamik sayfalar için kısa TTL veya kural bazlı cache
• Önbellek bypass gerektiren durumları listeleyin (örn. ödeme/hesap sayfaları)

2) Cache key tasarımını netleştirin

• Dil/ülke başlıklarını standartlaştırın
• Oturum cookie’sine bağlı içerik için ayrı davranış kurgulayın

3) Origin’e giden trafiği azaltın

• Görsel/js/css’leri doğru cache header ile yönetin
• Aynı API isteklerini mümkünse cache’leyin (uygun ise)

4) Güvenlik kurallarını katmanlayın

• WAF/DDoS kural setlerini edge’de erken uygulayın
• Uygulama katmanında ek doğrulama yapmayı sürdürün

5) Rollback planı kurun

Test sonrası edge kurallarının performansı düşürdüğü senaryolar olabilir. Şunları hazırlayın: - Cache’i geçici kapatma kuralı - Yönlendirme/edge fonksiyonlarını geri çekme planı

Sonuç: Edge computing’e geçmeden önce doğru hedefi seçin

Edge computing, doğru kurgulandığında gecikmeyi düşürür, origin kaynaklarını rahatlatır ve güvenliği daha erken uygular. Aksiyon planı olarak önce hedefinizi belirleyin: "coğrafyalara göre p95 gecikme" mi istiyorsunuz, "origin’e giden istek oranı" mı, yoksa "WAF tetikleme ve saldırıların origin’e ulaşmaması" mı? Ardından aynı içerik/varyasyonla ölçüm yapın; cache hit oranı ve origin çağrılarını takip ederek karar verin. Eğer trafiğiniz coğrafi olarak dağınıksa, içerik tekrar oranı yüksekse ve bazı dinamik kararlar kural bazlı yapılabiliyorsa edge mimarisi net biçimde değer üretir.