Bulutta çalışan bir uygulamanın performansı yalnızca güçlü sunuculara bağlı değildir. Asıl belirleyici olan, talep artışına ne kadar hızlı yanıt verdiği, tekrar eden istekleri ne kadar düşük maliyetle servis ettiği ve içeriği kullanıcıya ne kadar yakın bir noktadan ulaştırabildiğidir. Özellikle kampanya saatleri, bilet satışları, sınav sonuç ekranları ya da B2B sipariş portalları gibi anlık yüklenen senaryolarda birkaç dakikalık gecikme bile gelir, kullanıcı memnuniyeti ve operasyon üzerinde doğrudan etkili olur.

Bulut performans optimizasyonu pratiğinde en sık birlikte değerlendirilen üç araç autoscaling, cache ve CDN’dir. Her biri aynı soruna farklı bir katmanda çözüm getirir. Autoscaling işlem kapasitesini artırır. Cache, uygulamanın tekrar eden hesaplama ve veri erişim yükünü azaltır. CDN ise statik ve kısmen dinamik içeriği son kullanıcıya daha yakın noktalardan sunar. Tek başına her biri fayda sağlar; birlikte kurgulandığında ise sonuç çok daha tutarlı hale gelir.

Bu yazıda, yoğun trafik altında bu üç yaklaşımın nasıl çalıştığını, hangi metriklere göre karar verilmesi gerektiğini ve uygulama mimarisine nasıl yerleştirilebileceğini teknik ama sade bir çerçevede ele alıyoruz.

Bulut performans optimizasyonu neden trafik zirvelerinde kritik hale gelir?

Normal çalışan bir sistem, yük 5 kat arttığında aynı davranışı göstermez. Örneğin ortalama 200 milisaniye süren bir API çağrısı, veritabanı bağlantı havuzu dolduğunda 2 saniyeyi aşabilir. CPU kullanımı yüzde 65’ten yüzde 90’a çıktığında sorun hemen başlamayabilir; ancak kuyruklar birikmeye başladığında yanıt süreleri doğrusal değil, çok daha sert yükselir.

Pratikte ekipler sık sık şu tabloyla karşılaşır: Uygulama sunucuları ayakta kalır ama oturum açma, ürün listeleme veya ödeme öncesi doğrulama gibi işlemler yavaşlar. Bunun nedeni çoğu zaman tek bir sunucu eksikliği değildir. Sık tekrarlanan sorguların her istekte yeniden çalışması, görsellerin origin sunucudan servis edilmesi ya da ani trafik artışında yeni instance’ların geç devreye girmesi zincirleme bir etki yaratır.

Burada izlenmesi gereken metrikler nettir: p95 ve p99 yanıt süresi, hata oranı, CPU ve bellek kullanımı, veritabanı sorgu süresi, cache hit ratio, CDN hit ratio. Yalnızca ortalama yanıt süresine bakmak yeterli olmaz. Örneğin ortalama 300 ms iyi görünebilir; ancak p95 değeri 2.4 saniye ise kullanıcıların anlamlı bir bölümü yavaşlık hissediyordur.

Autoscaling: Talebe göre kapasiteyi otomatik ayarlamak

Autoscaling, uygulamanın yük arttığında yeni kaynak eklemesini, trafik sakinleştiğinde ise gereksiz kapasiteyi azaltmasını sağlar. Bu yaklaşım sanal makinelerde de çalışır, container orkestrasyonunda da. Ancak başarılı olması için yalnızca “CPU yüzde 70 olunca sunucu ekle” kuralı yeterli değildir.

Hangi metrikle ölçeklenmeli?

CPU iyi bir başlangıçtır; fakat her uygulama için tek başına yeterli olmayabilir. API yoğun sistemlerde istek sayısı, kuyruk derinliği veya hedef yanıt süresi daha anlamlı sinyaller verebilir. Örneğin saniyede 1.000 istek alan bir servis için şu mantık tercih edilebilir: p95 yanıt süresi 800 ms üstüne çıkarsa 2 yeni pod aç, 10 dakika stabil kalırsa kademeli azalt. Böylece yalnızca kaynak tüketimine değil, doğrudan kullanıcı deneyimine göre karar verilmiş olur.

Stateless tasarım burada kritik önem taşır. Oturum bilgisini uygulama belleğinde tutan bir mimari, yeni instance eklense bile yükü rahat biçimde dağıtamaz. Session verisini Redis gibi paylaşımlı bir katmana taşımak ya da token tabanlı kimlik doğrulama kullanmak, autoscaling’in gerçekten etkili çalışmasını sağlar.

Scale-out gecikmesini hesaba katın

Yeni bir instance birkaç saniyede de açılabilir, 2-3 dakikayı da bulabilir. Bunu imaj boyutu, uygulamanın başlangıç süresi, migration adımları ve health check ayarları etkiler. Eğer kampanya trafiği 60 saniye içinde pik yapıyorsa, 3 dakikada hazır olan kapasite geç kalmış sayılır. Böyle durumlarda planlı ön ölçekleme uygulanır. Örneğin her cuma 20:00’de beklenen bir trafik artışı varsa, kaynakları 10-15 dakika önce artırmak daha güvenli olur.

Kubernetes kullanan yapılarda Horizontal Pod Autoscaler yaygın bir çözümdür. Sanal makine tabanlı ortamlarda ise instance group ya da autoscaling group mantığı devreye girer. Araç değişebilir; ama prensip aynıdır: ölçekleme sinyali doğru seçilmeli, soğuma süresi iyi ayarlanmalı ve state bağımlılığı azaltılmalıdır.

Cache kullanımı: Aynı işi tekrar tekrar yapmamak

Cache, yoğun trafikte en yüksek getiriyi sağlayan katmanlardan biridir; çünkü pahalı işlemlerin tekrarını önler. Ürün listesi, fiyat kuralları, kurumsal içerik sayfaları, kullanıcı yetkileri, sık okunan referans tabloları çoğu zaman cache için uygundur. Aynı veriyi 100 kez veritabanından çekmek yerine belirli bir süre bellekte tutmak, yanıt süresini ciddi ölçüde kısaltabilir.

Hangi cache türü ne zaman kullanılır?

En yaygın üç seviye vardır: uygulama içi bellek cache, dağıtık cache ve HTTP cache. Tek sunuculu küçük yapılarda uygulama içi cache iş görebilir; fakat çoklu instance ortamında tutarlılık problemi doğurur. Dağıtık cache için Redis sık tercih edilir. HTTP katmanında ise ters vekil cache ya da CDN edge cache devreye girebilir.

Örneğin ürün katalog API’sinde 30 saniyelik TTL bile ciddi fark yaratabilir. Her verinin saatlerce sabit kalması gerekmez. Kısa TTL değerleriyle bile veritabanı yükü azalır. Buradaki kritik nokta, neyin cache’lendiğini ve ne kadar süre saklandığını bilinçli biçimde belirlemektir.

Cache invalidation en zor kısımdır

Eski veriyi çok uzun süre tutarsanız kullanıcı yanlış bilgi görür. Çok kısa tutarsanız da elde edilen kazanım düşer. Bu yüzden veri sınıfına göre politika tanımlamak gerekir. Stok adedi gibi hızla değişen alanlarla kurumsal blog sayfası aynı mantıkla ele alınmamalıdır. Sık değişen veriler için event tabanlı invalidation tercih edilebilir. Örneğin yönetim panelinde fiyat güncellendiğinde ilgili anahtarların temizlenmesi gibi.

Basit bir HTTP başlık örneği bu mantığı gösterir:

Cache-Control: public, max-age=300, stale-while-revalidate=30

Bu yapı, içeriğin 300 saniye boyunca cache’te kalmasına izin verir. Süre dolduğunda istemci tamamen beklemek yerine kısa bir pencere boyunca eski yanıtı alabilir, arka planda ise yenileme yapılır. Özellikle yoğun okunan ama her saniye değişmeyen sayfalarda yararlıdır.

Takip edilmesi gereken somut metriklerden biri cache hit ratio’dur. Yüzde 20 hit oranı ile yüzde 80 hit oranı arasında ciddi fark vardır; ancak tek başına oran da yeterli değildir. Büyük objeler mi cache’ten geliyor, en yoğun endpoint’ler mi fayda sağlıyor, buna da bakılmalıdır.

CDN: İçeriği kullanıcıya daha yakın noktadan sunmak

CDN, görsel, CSS, JavaScript, font, doküman ve bazı durumlarda API yanıtlarını kullanıcının coğrafi olarak yakınındaki edge noktalarından servis eder. Türkiye’den erişilen bir dosyanın her istekte ana sunucuya gitmesiyle bölgesel edge üzerinden gelmesi arasında hissedilir bir fark olabilir. Özellikle çok sayıda statik dosya yükleyen web uygulamalarında bu etki daha belirgin hale gelir.

CDN sadece hız için değil, origin koruması için de kullanılır

10.000 kullanıcının aynı görsel setini aynı anda istediği bir senaryoda, tüm yükün origin sunucu tarafından karşılanması gerekmez. CDN hit oranı yükseldikçe ana altyapının ağ çıkışı ve istek yükü azalır. Bu yalnızca sayfa açılışını hızlandırmaz; aynı zamanda autoscaling ve uygulama katmanındaki baskıyı da hafifletir.

Örnek bir e-ticaret kampanyasını düşünelim. Ana sayfa 2 MB toplam statik içerik yüklüyor ve 50.000 oturum aynı saat aralığında geliyor. Tüm dosyalar origin üzerinden akarsa ağ maliyeti ve bağlantı yükü büyür. Aynı varlıklar edge’den servis edildiğinde uygulama sunucuları dinamik isteklere daha fazla odaklanabilir.

Doğru cache başlığı olmadan CDN verimli çalışmaz

CDN kurmak tek başına çözüm değildir. Statik dosyalar için sürümlü dosya adı kullanmak gerekir; örneğin app.v184.js gibi. Böylece 30 gün veya daha uzun cache süresi tanımlanabilir. Dosya değiştiğinde adı da değişir ve eski içerik doğal biçimde devreden çıkar. HTML belgeleri ise genelde daha kısa TTL ile yönetilir; çünkü içeriğin güncellenme sıklığı daha yüksektir.

Dinamik API yanıtlarında CDN kullanımı daha dikkatli planlanmalıdır. Her kullanıcıya özel veri edge cache’e bırakılmaz. Ancak herkese aynı dönen lokasyon listeleri, kampanya banner yapılandırmaları ya da anonim içerik endpoint’leri için kısa süreli edge cache oldukça etkili olabilir.

Autoscaling, cache ve CDN birlikte nasıl çalışır?

Bu üç yaklaşım birbirinin alternatifi değil, tamamlayıcısıdır. CDN dış katmandaki statik yükü emer. Cache, uygulama ve veri erişim katmanındaki tekrarları azaltır. Autoscaling ise geriye kalan dinamik yükü karşılamak için kapasiteyi ayarlar. Mimariyi katmanlı düşünmek gerekir.

Gerçekçi bir senaryo üzerinden ilerleyelim: Bir B2B sipariş portalı normalde dakikada 1.500 istek alırken, bayi kampanyası açıldığında bu sayı 10 dakika içinde 7.000’e çıkıyor. Ürün görselleri CDN üzerinden servis ediliyor. Katalog ve fiyat listeleri Redis üzerinde 60 saniye tutuluyor. Sipariş oluşturma ve stok doğrulama gibi kritik işlemler cache dışı kalıyor. API pod’ları p95 yanıt süresi 700 ms üstüne çıktığında 6 adetten 14 adede yükseliyor. Bu yapıda ölçeklenen şey tüm trafik değil; gerçekten dinamik ve iş kuralı içeren istekler oluyor. Böylece kaynak daha verimli kullanılıyor.

En sık yapılan hata ise bunun tersidir: Önce agresif autoscaling açılır, cache ihmal edilir, CDN ise kısmen kullanılır. Sonuçta sistem ayakta kalır ama maliyet şişer. Oysa her isteği yeni sunucularla karşılamak yerine gereksiz origin çağrılarını ve tekrar eden hesaplamaları azaltmak çoğu zaman daha sağlıklı bir yaklaşımdır.

Uygulama performansını artırırken dikkat edilmesi gereken teknik ayrıntılar

Performans iyileştirmesi yalnızca bu üç başlıktan ibaret değildir. Veritabanı indeksleri, bağlantı havuzu ayarları, asenkron işleme, sıkıştırma, HTTP/2 veya HTTP/3 desteği gibi konular da önemlidir. Yine de autoscaling, cache ve CDN doğru kurulmadan diğer optimizasyonların etkisi sınırlı kalabilir.

Ölçmeden değişiklik yapmamak gerekir. En az 1 haftalık gözlemle trafik desenleri çıkarılmalı, yük testi ile kontrollü senaryolar denenmelidir. Örneğin 500 eşzamanlı kullanıcı, ardından 2.000 eşzamanlı kullanıcı testi uygulanabilir. Buradaki amaç yalnızca “çöküyor mu” sorusuna yanıt bulmak değil; hangi katmanın önce dar boğaz oluşturduğunu anlamaktır.

Log, metrik ve trace verisini birlikte izlemek burada büyük fark yaratır. Bir endpoint yavaşsa yalnızca uygulama loguna bakmak yeterli olmayabilir. Trace üzerinde veritabanı çağrısı mı uzuyor, dış API entegrasyonu mu gecikiyor, cache miss mi artmış; bunlar çok daha net görülebilir.

Sonuç: Yoğun trafik yönetiminde katmanlı yaklaşım daha sürdürülebilir

Bulutta yüksek performans, tek bir güçlü sunucu satın alarak elde edilmez. İsteklerin bir kısmını edge’de karşılamak, tekrar eden işlemleri cache ile hafifletmek ve kalan dinamik yükü otomatik ölçekleme ile yönetmek daha dengeli bir model sunar. Özellikle büyüyen dijital ürünlerde bu yaklaşım hem kullanıcı deneyimini korur hem de altyapı kararlarını daha öngörülebilir hale getirir.

Kuruma özel mimari tasarım yapılırken trafik tipi, veri güncellenme sıklığı, oturum yönetimi ve entegrasyon bağımlılıkları birlikte değerlendirilmelidir. İyi kurgulanmış bir bulut performans optimizasyonu stratejisi, yalnızca pik anları kurtarmak için değil; günlük operasyonu daha stabil, izlenebilir ve maliyet açısından daha kontrollü hale getirmek için de gereklidir.