Kampanya veya viral yayın öncesinde sunucuyu, cache katmanlarını ve izleme alarmlarını hazırlamanın adım adım senaryosu: yük testi, cache ısıtma, zamanlanmış ölçekleme ve devre kesici desenleri.
Yüksek Trafik Dönemlerinde Site Performansı Nasıl Korunur?
Kampanya başlangıç saati yaklaştığında ekipler genellikle içerik ve tasarımla uğraşır; sunucu tarafı ise son dakikaya kalır. Trafik bir anda geldiğinde, özellikle sosyal medyada kısa sürede yayılan bir içerik ya da büyük bir indirim duyurusu söz konusuysa, hazırlıksız bir altyapı dakikalar içinde boyun eğebilir. Cache'siz gelen her istek doğrudan veritabanına düşer, bağlantı havuzu dolar, TTFB yükselir ve kullanıcılar boş ekranla ya da hata sayfasıyla karşılaşır.
Sorun çoğunlukla sunucunun yetersizliği değil, hazırlığın eksikliğidir. Kapasite yeterli olsa bile soğuk cache, yanlış zamanlanmış ölçekleme ya da tek bir yanıtsız dış API, zirve trafik altında sistemi çökertmeye yeter. Yük testi, cache ısıtma, ölçekleme kuralları ve izleme alarmları bir araya geldiğinde bu risklerin büyük bölümü kontrol altına alınabilir.
Büyük bir kampanya veya viral yayın öncesi hazırlık, yük testi, ölçekleme, cache ısıtma ve alarm kalibrasyonunu aynı haftaya sıkıştırır. Katmanları paralel yürütmek zaman kazandırır; aralarındaki bağımlılık da ancak o zaman görünür.
Yük testini kampanyadan önce çalıştırmak
Kapasite planlaması tahminle değil, ölçümle yapılır. Yük testi olmadan beklenen trafiğin sistemi nasıl etkileyeceğini bilmenin yolu yoktur. k6, Locust veya Gatling gibi araçlar gerçek kullanıcı yolculuklarını betiklerle simüle edebilir: ana sayfa, ürün sayfası, sepet ve ödeme adımlarını birlikte çalıştırmak, yalnızca ana sayfa trafiğini tekrar etmekten çok daha gerçekçi bir sonuç verir.
Yük testinde hedef, beklenen zirve değeri doğrulamak değil, sistemi kırmaktır. Kapasite sınırını bulmak için yükü kademeli olarak artırın; TTFB'nin belirgin biçimde yükseldiği, hata oranının artmaya başladığı ya da bellek veya CPU'nun doyuma ulaştığı nokta gerçek sınırı gösterir. Çoğu senaryoda beklenen zirvenin en az iki katı yük altında sistemin nasıl davrandığını görmek, hazırlık için somut bir zemin sunar.
Dar boğazlar veritabanı bağlantısında, önbelleksiz çağrılarda ya da senkron çalışan bir dış API'de olabilir. Yük testi bu noktaları görünür kılar; her dar boğaz için ayrı bir eylem planı hazırlamak gerekir: bağlantı havuzunu artırmak, bir çağrıyı asenkron hale getirmek ya da yavaş bir dış API için timeout değerini düşürmek gibi.
Testi üretim ortamında çalıştırmak her zaman mümkün olmaz. Staging ortamı üretimle birebir aynıysa sonuçlar geçerlidir; farklıysa yalnızca yönlendirici olmakla kalır. Üretim trafiğini yansıtmanın pratik bir yolu, mevcut kullanıcı davranışından türetilen istek dağılımını - yani en çok ziyaret edilen URL listesini - teste dahil etmektir.
Sunucu ölçekleme: önceden yapmak ile otomasyona bırakmak
Otomatik ölçekleme kulağa çekici gelir, ama bir sınırı vardır. Yeni bir instance başlatmak zaman alır; cloud ortamlarında bu süre genellikle birkaç dakikadır. Trafik ani artış gösterdiğinde bu birkaç dakika, ilk dalgayı karşılayan mevcut sunucuların çökmesi için yeterlidir. Büyük bir etkinlik öncesinde zamanlanmış ölçekleme (scheduled scaling) kurmak, bu gecikmeyi ortadan kaldırır: beklenen trafik artışından birkaç saat önce instance sayısını artırmak ve etkinlik sona erdikten sonra azaltmak, hem maliyet hem de güvenilirlik açısından dengeli bir yaklaşım sunar.
Yatay ölçekleme, dikey ölçeklemeye kıyasla daha esnektir. Daha büyük bir sunucuya geçmek (dikey) hızlı bir çözüm gibi görünse de tek nokta başarısızlığı riski taşır ve ölçeği geri almak yeniden bir bakım penceresi gerektirir. Yatay ölçeklemede aynı anda birden fazla instance çalışır; bir tanesi hata verirse diğerleri trafiği karşılamaya devam eder. Bunun için uygulama stateless olmalıdır: oturum verisi sunucunun belleğinde değil, Redis gibi merkezi bir depolama alanında tutulmalıdır.
Yük dengeleyici yapılandırması da sıklıkla göz ardı edilir. Sağlık kontrolü (health check) aralıkları ve başarısız istek eşikleri doğru ayarlanmazsa yük dengeleyici, yanıt vermeye devam eden bir instance'ı devre dışı bırakabilir ya da gerçekten çökmüş bir instance'ı havuzda tutabilir. Kampanya öncesinde bu ayarların gözden geçirilmesi, kriz anında yanlış yönlendirmeden kaynaklanan kayıpları önler.
Ölçekleme politikası yazılırken minimum instance sayısını sıfır yapmak cazip görünür; maliyet tasarrufu sağlar. Ama sıfırdan ölçeklenen bir sistem, ilk gelen istek kümesine yavaş yanıt verir. Minimum değeri sıfırın üzerinde, makul bir sayıda tutmak, soğuk başlangıcın önüne geçer.
Cache ısıtma: soğuk başlangıcın getirdiği tehlike
Soğuk cache tehlikelidir. Sunucu yeniden başlatıldığında, yeni bir deploy yapıldığında veya CDN cache'i temizlendiğinde gelen ilk istekler cache'e değil doğrudan origin'e düşer. Normal trafikte bu kabul edilebilir bir gecikmeye yol açar; ama kampanya başladığı anda yüzlerce eşzamanlı istek aynı anda origin'e ulaşırsa sonuç ciddi olabilir. Thundering herd olarak bilinen bu durum, özellikle veritabanına yapılan ağır sorguların önbelleklenmediği sayfalarda belirginleşir.
Cache'i ısıtmak için kritik URL'lerin kampanya başlamadan önce istenip cache'e alınması gerekir. En basit yöntem, sitemap ya da yüksek trafik beklenen URL listesinden türetilen bir betik çalıştırmaktır. Betik, her URL'ye bir HTTP isteği göndererek sayfanın hem uygulama düzeyinde (Redis, Memcached) hem de CDN'de önbelleğe alınmasını sağlar.
Isıtma her cache katmanı için ayrı planlanmalıdır. CDN cache ve uygulama cache farklı kurallarla dolup boşalır; CDN'de bir sayfa cache'lenmişken uygulama tarafında aynı sayfa hâlâ soğuk olabilir ve origin çağrısı geldiğinde cache miss alınır. Her iki katmanın da ısındığını doğrulamak için cache header'larını kontrol edin: CDN için genellikle X-Cache: HIT ya da benzer bir header döner; uygulama cache için izleme aracındaki hit oranı takip edilebilir.
Isıtma ne zaman gereksizdir? Dinamik, kişiselleştirilmiş sayfalar cache'lenemez; giriş yapmış kullanıcıya özel içerik için bu adım atlanabilir. Bu durumda veritabanı sorgu optimizasyonuna ve bağlantı havuzu kapasitesine odaklanmak çok daha verimlidir.
CDN yapılandırması ve origin'i aşırı yükten korumak
CDN, yüksek trafik dönemlerinde en güçlü tampon katmanıdır. Yanlış yapılandırılmış bir CDN ise beklenen korumayı sağlamak yerine origin'i deşifre eder. Cache-Control header'ları eksikse ya da çok kısa TTL değerleriyle ayarlandıysa CDN her istekte origin'e sorar; böyle bir kurulumda CDN bir proxy gibi çalışır, cache gibi değil.
Statik varlıklar için uzun TTL değerleri, HTML sayfaları için daha kısa ama makul değerler tercih edilebilir. stale-while-revalidate direktifi, TTL süresi dolmuş bir yanıtı arka planda yenilerken son kullanıcıya eski yanıtı sunmaya devam eder; bu sayede origin üzerindeki anlık yük azalır. stale-if-error ise origin bir hata döndürdüğünde son geçerli yanıtı kullanıcıya iletir ve kısa süreli arızaları kullanıcıdan gizler.
Origin sunucuyu yalnızca CDN'den gelen trafiğe açmak, katmanlar arasındaki güvenliği artırır. CDN sağlayıcısının IP aralıklarını bir allowlist olarak tanımlamak, doğrudan origin'e gelen bot trafiğini ya da beklenmedik tarayıcıları filtreler; bu hem güvenlik hem de yük yönetimi açısından değer taşır.
Rate limiting doğru kurulduğunda saldırı değil hız kontrolü işlevi görür. Belirli bir IP'den saniyede gelen istek sayısını sınırlamak, bot trafiğini azaltır ve meşru kullanıcıların kaynaklara erişimini korur. CDN katmanında uygulanan rate limiting, isteği hiç origin'e ulaştırmadan engeller ve bu, uygulama seviyesinde uygulanandan çok daha verimlidir.
İzleme alarmları: hangi metrikte, hangi eşikte uyarı kurulmalı
Alarm yoksa sorun fark edildiğinde çoğunlukla çok geç olmuştur. Kullanıcılar şikayet eder, sosyal medyada yorum yapar ya da sessizce ayrılır. Alarm eşikleri müdahale için zaman bırakacak kadar erken tetiklenmelidir; ama o kadar geniş tutulmamalıdır ki her ufak dalgalanmada ekibi uyandırsın.
İzlenmesi gereken birincil metrikler şunlardır: TTFB, hata oranı (HTTP 5xx yüzdesi), sunucu CPU ve bellek kullanımı, veritabanı bağlantı havuzu doluluk oranı ve CDN hit/miss oranı. TTFB için normal baseline değerinin iki katına ulaştığında alarm tetiklenmesi makul bir başlangıç noktasıdır; hata oranı içinse çoğu durumda yüzde birden beşe kadar kademeli eşikler tanımlanabilir.
Gerçek kullanıcı verisi (RUM - Real User Monitoring) sunucu taraflı metriklerden farklı bir tablo çizebilir. Sunucu sağlıklı görünse bile CDN edge noktasından son kullanıcıya uzanan son kilometre yavaş olabilir, ya da büyük bir JavaScript bundle kullanıcı tarafında uzun görev (long task) oluşturabilir. Her iki kaynaktan gelen verileri bir arada değerlendirmek, sorunun hangi katmanda olduğunu hızla anlamayı sağlar.
Kampanya süresi boyunca izleme panosunu açık tutmak ve nöbet tutacak kişiyi önceden belirlemek gerekir. Alarm geldiğinde kimin ne yapacağını bilmek - kimin ölçekleme kararı vereceğini, kimin CDN ayarlarına erişeceğini - müdahale süresini önemli ölçüde kısaltır. Panik anında bu bilgileri aramak zaman kaybettirir.
Veritabanı darboğazları ve bağlantı havuzu yönetimi
Bağlantı havuzu dolarsa sistem çöker. Bu basit bir mekanizmadır: her web isteği veritabanından bir bağlantı alır, işini yapar ve bırakır. Havuz kapasitesini aşan eşzamanlı istek geldiğinde yeni istekler bağlantı bekler; bekleme uzadıkça TTFB yükselir, timeout hataları başlar ve kullanıcı hata sayfasıyla karşılaşır.
PgBouncer (PostgreSQL için) veya benzeri bağlantı havuzlayıcılar, gerçek veritabanı bağlantısını uygulama bağlantısından ayırır. Uygulama binlerce eşzamanlı bağlantı açık tutuyormuş gibi davranabilirken, veritabanına gerçekte yüzlerce bağlantı gider. Yüksek trafik dönemlerinde bu katman olmadan ölçekleme yapmak genellikle yetersiz kalır.
Yavaş sorgular yük altında daha da yavaşlar. Kampanya öncesinde en sık çalışan sorguları analiz etmek ve index eksikliği olanları bulmak - EXPLAIN ANALYZE çıktıları bu konuda yol gösterir - ani yük altında performans düşüşünü engeller. Query cache'i etkin olmayan, tam tablo taraması yapan bir sorgu normal trafikte kabul edilebilir görünse bile, eşzamanlılık arttığında çarpan etkisiyle sistemi yorar.
Salt okunur sorgular için read replica kullanmak, yazma bağlantısı üzerindeki yükü azaltır. Ürün listesi, kategori sayfası ve içerik sorguları gibi okuma ağırlıklı işlemler replica'ya yönlendirilebilir; sepet ve ödeme gibi yazma gerektiren işlemler birincil sunucuda kalır. Bu ayrımı yapmak uygulamada küçük bir değişiklik gerektirir, ama kriz anında sağladığı esneklik büyüktür.
Devre kesici ve geri dönüş stratejileri
Her şey planlandığı gibi gitmez. Zirve trafik altında bir dış API yanıt vermeyebilir, bir servis beklenmedik biçimde yavaşlayabilir ya da ani bir traffic spike ölçekleme süresi dolmadan gelir. Bu senaryolara karşı hazırlıklı olmak, kriz anında soğukkanlı kararlar almayı sağlar.
Devre kesici (circuit breaker) deseni, başarısız olan bir bağımlılığa istek göndermeyi belirli bir hata eşiğinden sonra otomatik olarak durdurur. Bu sayede sürekli başarısız olan çağrılar sistemin geri kalanını yavaşlatmaz; devre kesilinceye kadar biriken timeout'lar kaynak tüketimini artırır. Hystrix, Resilience4j gibi kütüphaneler bu deseni uygular; bazı servis mesh çözümleri bunu altyapı katmanında doğrudan sunar.
Geri dönüş (fallback) içeriği, bir servis ya da bileşen başarısız olduğunda ne gösterileceğini önceden tanımlar. Öneri motoru yanıt vermiyorsa statik bir ürün listesi göster; yorum servisi çöktüyse o bölümü gizle, sayfanın geri kalanını bozmadan sun. Her kritik bileşen için bu kararı kampanya öncesinde vermek, kriz anında sıfırdan karar almaktan çok daha hızlıdır.
Kuyruğa alma (queuing) ve asenkron işleme de yüksek trafik dönemlerinde değer kazanır. Stok güncelleme, bildirim gönderme veya raporlama gibi işlemleri senkron akıştan çıkarmak, kullanıcıya yanıt vermeyi geciktiren iş miktarını azaltır. RabbitMQ veya Redis Streams gibi bir kuyruk sistemi bu işlemleri gerçek zamanlı değil, işlenebilir bir hızda tüketir.
Hazırlık, kampanya başlamadan önce tamamlanması gereken bir süreçtir; başladıktan sonra yapılacak değişikliklerin etkisi sınırlı kalır ve risk taşır. Yük testi sonuçları, cache ısıtma betiği, ölçekleme politikası ve alarm eşikleri üçer-dörder gün öncesinden yerinde olmalıdır.
Hazırlık sürecindeki en büyük tuzak, her şeyin yolunda gittiğini varsaymaktır. Sistemin zirve trafik altında nasıl davrandığını görmek için tek güvenilir yol onu test etmektir. Yük testi sırasında ortaya çıkan her dar boğaz, canlı ortamda kullanıcıların görmeyeceği bir sorun anlamına gelir.
Kampanya sona erdikten sonra da iş bitmez. Alarm logları, TTFB grafikleri, hata oranları ve CDN hit oranı bir araya getirilerek sonraki etkinlik için referans noktası oluşturulabilir. Neyin işe yaradığını ve neyin beklenenden farklı geliştiğini kayıt altına almak, ekibin bir sonraki seferinde daha az belirsizlikle hazırlanmasını sağlar.