Sunucu ölçekleme: yüksek trafikte site nasıl ayakta kalır?

Kampanya sabahı ekranınızda üç şey aynı anda olur: satışlar, ziyaretçi sayısı ve — altyapınız hazır değilse — hata sayfaları. Yüksek trafikte ayakta kalmak şansa değil, önceden kurgulanmış bir mimariye bağlıdır. Bu yazıda CDN, önbellekleme ve yatay ölçeklemenin kampanya günlerinde sitenizi nasıl kesintisiz tuttuğunu, pratik adımlarıyla ele alıyoruz.

Siteler kampanya gününde neden çöker?

Bir e-ticaret sitesinin trafik altında çökmesi tek bir nedenden değil, genelde üst üste binen üç sorundan kaynaklanır: tek sunucunun kaldıramayacağı eşzamanlı istek sayısı, her istekte tekrar tekrar çalışan ağır veritabanı sorguları ve statik dosyaların (görsel, script, stil) her seferinde sunucudan yeniden üretilmesi. Normal günlerde bu sorunlar fark edilmez, çünkü sunucu boşta kalan kapasitesiyle idare eder. Kampanya günü trafik 10-20 kat arttığında ise aynı kapasite artık yeterli gelmez ve sistem sıraya girmiş isteklerle boğulur.

Çözüm tek bir "büyük sunucu" almak değildir. Asıl çözüm, yükü doğru katmanlara dağıtmak ve her katmanın kendi işini en verimli şekilde yapmasını sağlamaktır. Aşağıdaki dört katman, bu dağılımın omurgasını oluşturur.

CDN: trafiği kaynağa değil kenara taşıyın

Bir içerik dağıtım ağı (CDN), görselleriniz, script'leriniz ve stil dosyalarınız gibi statik varlıkları, kullanıcıya coğrafi olarak en yakın sunucudan sunar. Bu sayede ana sunucunuz her istekte aynı dosyayı tekrar tekrar göndermek zorunda kalmaz; sadece dinamik ve gerçekten değişen içerikle ilgilenir.

• Statik varlıkların büyük çoğunluğu (görsel, CSS, JS) CDN üzerinden, kullanıcıya en yakın noktadan sunulmalı,
• Ürün görselleri farklı ekran boyutlarına göre optimize edilip önceden üretilmeli,
• CDN önbellek süreleri, içerik değişme sıklığına göre ayarlanmalı; nadiren değişen dosyalar için uzun, sık değişenler için kısa tutulmalı.

CDN'in getirisi sadece hız değildir; ana sunucunuzun yükünü ciddi oranda azaltarak, o kapasiteyi asıl önemli işe — sipariş oluşturma, stok kontrolü, ödeme — ayırmanızı sağlar. Kampanya gününde bu ayrım, sitenin ayakta kalıp kalmayacağını belirleyen en belirleyici faktörlerden biridir. CDN'in hız üzerindeki etkisini Core Web Vitals metrikleri bağlamında ayrı bir yazımızda ele aldık.

Önbellekleme katmanları: sayfa, sorgu ve nesne

CDN statik dosyaları çözer, ama dinamik sayfaların (ürün listesi, kategori sayfası, arama sonucu) her ziyarette veritabanına gitmesi gerekmez. Önbellekleme, bir sonucu bir kez hesaplayıp belirli bir süre yeniden kullanmak demektir; kampanya gününde aynı ürün sayfasını binlerce kişi görüntülerken veritabanına binlerce kez gitmek yerine tek bir hesaplanmış sonucu paylaşmak, sunucunuzu kurtarır.

• Sayfa önbelleği: Sık değişmeyen sayfalar (kategori, kampanya, statik içerik) tam sayfa olarak birkaç dakikalığına önbelleğe alınabilir,
• Sorgu önbelleği: Stok, fiyat gibi sık okunan ama az sıklıkla yazılan veriler bellek içi bir önbellek katmanında (örneğin Redis) tutulur,
• Nesne önbelleği: Menü, kategori ağacı gibi hesaplaması pahalı ama nadiren değişen yapılar önbelleğe alınıp değişiklik olduğunda temizlenir.

Önbelleğin en zor kısmı ne zaman güncelleneceğine karar vermektir. Stok bilgisi gibi anlık doğruluk gerektiren veriler için önbellek süresi çok kısa tutulmalı veya stok değiştiğinde önbellek anında geçersiz kılınmalıdır; aksi halde tükenen bir ürün, önbellekte hâlâ "stokta" görünmeye devam edebilir.

Yatay ölçekleme: sunucu sayısını talebe göre artırmak

Dikey ölçekleme, tek bir sunucuyu daha güçlü donanımla büyütmektir; belirli bir noktadan sonra hem maliyeti hem fiziksel sınırları nedeniyle sürdürülemez hale gelir. Yatay ölçekleme ise aynı işi yapan birden fazla sunucuyu devreye alıp gelen trafiği bir yük dengeleyici (load balancer) üzerinden bu sunuculara dağıtmaktır.

Bu modelin gücü esnekliğinde yatar: normal günlerde iki-üç sunucu yeterliyken, kampanya öncesinde bu sayı otomatik veya elle on'a çıkarılabilir, kampanya bitince tekrar düşürülebilir. Yatay ölçeklemenin çalışabilmesi için uygulamanın "durumsuz" (stateless) tasarlanması gerekir; yani kullanıcı oturumu veya sepet bilgisi tek bir sunucunun belleğinde değil, tüm sunucuların erişebildiği ortak bir katmanda (veritabanı veya Redis) tutulmalıdır. Aksi halde bir kullanıcının isteği farklı sunuculara düştüğünde sepeti "kaybolmuş" görünebilir.

İki yaklaşımın ne zaman tercih edileceğini netleştirmek için temel farkları yan yana koymak faydalıdır:

"Kampanya günü altyapınızı test ettiğiniz gün değil, altyapınızın sizi test ettiği gündür. Hazırlık, gün gelmeden haftalar önce başlar."

Veritabanı darboğazı: en sık gözden kaçan nokta

Sunucu sayısını artırmak kolaydır; asıl darboğaz genelde tek bir veritabanında toplanır. Tüm sunucular aynı veritabanına yazıp okuduğu için, sunucu sayısı arttıkça veritabanı üzerindeki yük de artar ve bir noktada veritabanı tüm mimarinin en zayıf halkası olur.

Bu noktada üç önlem işe yarar: sık okunan ama az değişen verileri veritabanından değil önbellekten okumak, okuma yoğun sorguları ana veritabanından ayrı bir "okuma kopyası" (read replica) üzerinden karşılamak ve stok düşümü gibi kritik-eşzamanlı işlemleri kuyruk üzerinden sıraya dizerek veritabanına aynı anda binlerce yazma isteği göndermemek. Kuyruklama, özellikle "sepete ekle" ve "sipariş oluştur" gibi anlarda ani yük patlamalarını yumuşatan en etkili yöntemlerden biridir.

Kampanya öncesi yük testi

Mimari ne kadar iyi kurgulanmış olursa olsun, gerçek trafikle test edilmeden kampanya gününe girmek risklidir. Yük testi, beklenen ziyaretçi sayısının birkaç katını simüle eden araçlarla sitenizin kırılma noktasını önceden bulmanızı sağlar.

1. Geçmiş kampanya verilerinize bakarak beklenen zirve trafiğin 2-3 katını hedefleyen bir senaryo kurun,
2. Sadece ana sayfayı değil, ürün sayfası, sepet ve ödeme akışını da test kapsamına alın — asıl darboğaz genelde ödeme adımında ortaya çıkar,
3. Testi kampanyadan en az bir hafta önce yapın; bulunan sorunları düzeltip yeniden test edecek zamanınız olsun.

Beklenen trafiği tahmin ederken stok tarafında da benzer bir planlama disiplini gerekir; sezon öncesi talep tahminini talep tahmini rehberimizde ayrıntılı işledik.

Gerçek zamanlı izleme ve otomatik alarm

Kampanya günü en tehlikeli senaryo, bir sorunun fark edilmeden büyümesidir. Sunucu tepki süresi, hata oranı ve kuyruk uzunluğu gibi göstergeleri gerçek zamanlı izleyen bir panel kurun; belirlenen eşikler aşıldığında ekibe otomatik bildirim gitsin. Ayrıca yatay ölçeklemeyi trafiğe göre otomatik tetikleyen bir kural tanımlamak, ekibin manuel müdahale etmesini beklemeden kapasiteyi büyütür.

İzlemenin bir diğer faydası, kampanya sonrası değerlendirmedir: hangi saatte zirve yaşandığı, hangi sayfanın en çok yük bindirdiği ve mevcut kapasitenin ne kadarının kullanıldığı verisi, bir sonraki kampanyanın planlamasını çok daha isabetli hale getirir.

Sonuç

Yüksek trafikte ayakta kalmak, tek bir güçlü sunucu satın almakla değil, yükü doğru katmanlara (CDN, önbellek, uygulama sunucuları, veritabanı) dağıtan ve talebe göre büyüyüp küçülebilen bir mimariyle mümkündür. Bu mimariyi kampanya gününden önce test etmek, sorunları müşteri fark etmeden çözmenizi sağlar. Kampanya takviminizi ve bu altyapı hazırlığını birlikte planlamak için Kara Cuma hazırlık rehberimize göz atabilirsiniz.

Bu altyapıyı sıfırdan kurmak, doğru ekip ve zaman gerektiren bir mühendislik işidir. Şimşek Software'in e-ticaret platformu, CDN entegrasyonu, çok katmanlı önbellekleme ve talebe göre büyüyen sunucu mimarisini kutudan çıkarır; kampanya gününde altyapı endişesi yaşamadan satışa odaklanabilirsiniz.