Yoğun Trafikli Kampanyalar Neden Ayrı Bir Hosting Stratejisi Gerektirir?
Black Friday indirimleri, prime-time bir TV reklamı ya da yeni ürün lansmanı… Pazarlama tarafında masaya gelen bu fikirlerin her biri, altyapı tarafında ayrı bir oyun planı gerektirir. Normal günlerde saniyede 20-30 isteği rahatça karşılayan bir sunucu, kampanya döneminde çok daha yüksek bir istek hızıyla karşılaşabilir. Trafik artışı TV reklamında dakikalarla sınırlı kalabilirken, bir lansmanda günlere yayılabilir. İşin kritik noktası şu: Kısa bir yoğunluk döneminde bile yaşayacağınız kesinti, yılın geri kalanında yaptığınız optimizasyonların faydasını gölgeleyebilir.
Kampanya öncesi teknik planlamada pazarlama ekibinin hedefleri, yazılım ekibinin uygulama mimarisi ve altyapı ekibinin ağ, sunucu ve depolama kapasitesi değerlendirmeleri birlikte ele alınmalıdır. Buradaki amaç, “ne kadar güçlü sunucu alalım?” sorusundan çok, “bu kampanyayı en az riskle, kontrollü ve ölçülebilir şekilde nasıl ölçeklendiririz?” sorusuna yanıt bulmak. Bu rehberde; Black Friday, TV reklamı ve lansman gibi yoğun trafikli kampanyalar için hosting altyapınızı nasıl planlayacağınızı, hangi metrikleri izlemeniz gerektiğini ve hangi ölçeklendirme seçeneklerini değerlendirebileceğinizi anlatacağız. Mimari örnekler varsayımsaldır; DCHost dahil seçtiğiniz sağlayıcının kaynak, otomasyon ve destek kapsamını ayrıca doğrulamanız gerekir.
Kampanya Öncesi Kapasite Analizi: Nereden Başlamalı?
Doğru ölçeklendirme, mevcut durumunuzu dürüstçe görmekle başlar. Elinizdeki sunucu ne kadar güçlü olursa olsun, gözü kapalı “iki kat CPU, üç kat RAM” eklemek gerçek bir kapasite planlama sayılmaz. Önce bugün nerede olduğunuzu netleştirmeniz gerekir.
İzlemeniz Gereken Temel Metrikler
Kampanya planından en az birkaç hafta önce şu metrikleri düzenli olarak takip edin:
- Aktif kullanıcı ve eşzamanlı istek sayısı: Analitik araçlarındaki aktif kullanıcı tahminini, sunucunun aynı anda işlediği istek sayısıyla karıştırmayın; sunucu yükünü uygulama ve erişim metrikleriyle birlikte değerlendirin.
- İstek hızı, yanıt süresi ve hata oranı: Saniyedeki istek sayısını, p95/p99 yanıt sürelerini ve başarısız istek oranını, özellikle sepet ve ödeme akışlarında izleyin.
- CPU kullanımı: Ortalama ve pik değerler, özellikle %70 üzeri süre uzunluğu.
- RAM kullanımı: Swap kullanımına düşüyor musunuz, bellek sızıntısı var mı?
- Disk I/O ve IOPS: Özellikle yoğun veritabanı sorgularında gecikme oluyor mu?
- Veritabanı bağlantı sayısı: Maksimum bağlantı limitlerine ne kadar yaklaşıyorsunuz?
- Ağ trafiği ve bant genişliği: Ortalama Mbps ve pik değerler.
- Önbellek isabet oranı (cache hit ratio): Redis/Memcached ya da CDN istatistikleri.
Eğer WooCommerce, Laravel ya da benzeri bir uygulama kullanıyorsanız, özellikle veritabanı ve disk I/O metriklerini yakından izlemeniz gerekir. Detaylı kapasite hesabına girmek isterseniz, WooCommerce kapasite planlama rehberimizde vCPU, RAM ve IOPS hesabını adım adım anlattık.
Trafik Çarpanını Belirlemek
İkinci adım, kampanya sırasında beklediğiniz trafik artış oranını belirlemek. Tahmini geçmiş kampanya verileri, reklam erişimi ve pazarlama hedefleriyle oluşturun. Aşağıdaki çarpanlar genel geçer beklentiler değil, yük testinde değerlendirilebilecek varsayımsal senaryolardır:
- Black Friday için: Normal günün 5–10 katı trafik
- TV reklamı için: Reklamın döndüğü 10–15 dakikada ani pik (örneğin 20 kat kısa süreli yük)
- Ürün lansmanı için: İlk 24 saatte 3–5 kat sürekli yüksek yük
Örneğin normalde aynı anda maksimum 150 kullanıcıyı ağırlayan bir e-ticaret siteniz varsa ve Black Friday’de eşzamanlı kullanıcı sayısında 8 kat artış bekliyorsanız, hedef kapasitenizi en az 1200 eşzamanlı kullanıcı olarak planlamalısınız. Ancak burada sadece kullanıcı sayısını değil, sayfa başına sorgu sayısını, sepet/ödeme akışının karmaşıklığını ve görsel içerik yoğunluğunu da dikkate almalısınız.
Maliyet/Fayda Dengesini Unutmamak
Sadece birkaç gün sürecek bir kampanya için tüm yılı taşıyacak devasa bir altyapı kurmak çoğu zaman mantıklı değildir. Burada önemli olan, “pik” için akıllı bir tampon alan yaratmak ve geri kalan zamanda daha optimize, küçük bir altyapıyı kullanmaktır. Bu dengeyi kurarken, hosting maliyetlerini düşürme rehberimizde anlattığımız doğru VPS boyutlandırma ve trafik planlaması prensiplerinden yararlanabilirsiniz.
Ölçeklendirme Stratejileri: Dikey mi, Yatay mı, Hibrit mi?
Kampanya dönemlerinde en çok tartışılan soru: “Bu işi tek bir güçlü sunucuyla mı çözelim, yoksa birden fazla sunucuyu yük dengeleyici arkasında mı çalıştıralım?” Cevap, bütçeniz, teknik ekibinizin deneyimi ve uygulamanızın mimarisine göre değişir.
Dikey Ölçeklendirme (Vertical Scaling)
Dikey ölçeklendirme, mevcut sunucunuzun kaynaklarını büyütmek anlamına gelir: Daha fazla vCPU, daha çok RAM veya depolama performansını artırmak gibi. Bir VPS için kaynak artırımı ya da uygulamayı daha güçlü bir dedicated sunucuya taşıma değerlendirilebilir. Kullanılabilir kaynakları, plan değişikliği koşullarını ve işlemin yeniden başlatma veya taşıma gerektirip gerektirmediğini sağlayıcınızla önceden netleştirin.
Avantajları:
- Kurulumu ve yönetimi basittir, mimari değişiklik azdır.
- Uygulama konfigürasyonunu genelde çok az değiştirirsiniz.
- Küçük ve orta ölçekli projeler için maliyet/karmaşıklık dengesi iyidir.
Dezavantajları:
- Bir noktadan sonra tek sunucunun fiziksel sınırlarına takılırsınız.
- Sunucu arızasında tüm trafik etkilenir; yüksek erişilebilirlik sınırlıdır.
- TV reklamı gibi çok sert, kısa süreli piklerde tek makine yetmeyebilir.
Yatay Ölçeklendirme (Horizontal Scaling)
Yatay ölçeklendirme, yükü birden fazla sunucuya bölmek demektir. Örnek bir mimari şu bileşenlerden oluşabilir:
- Önde bir yük dengeleyici (load balancer)
- Arkada birden fazla web/PHP uygulama sunucusu
- Ayrı bir veritabanı sunucusu (ve gerekirse okuma replikaları)
- Redis/Memcached gibi bir önbellek sunucusu
Örnek bir kurulumda bu yapı, NVMe diskli birden fazla VPS ve gerekiyorsa dedicated veritabanı sunucusu ile oluşturulabilir. Öne HAProxy veya benzeri bir L4/L7 yük dengeleyici eklenerek trafik uygulama sunucularına dağıtılabilir. Bu konuyu merak ediyorsanız, HAProxy ile yük dengeleme rehberimiz mimariyi daha derin anlatıyor.
Avantajları:
- Gerektiğinde yeni web sunucuları ekleyebilirsiniz; ölçeklenebilirlik veritabanı, paylaşılan servisler ve ağ kapasitesiyle sınırlıdır.
- Bir web sunucusu arızalandığında, sağlık kontrolleriyle trafik dışına alınırsa ve kalan sunucuların kapasitesi yeterliyse hizmet sürebilir. Yük dengeleyici, veritabanı ve diğer ortak servisler için de yedeklilik gerekir.
- Kampanya sonrası gereksiz sunucuları devreden çıkararak maliyeti azaltmak, sözleşme ve faturalama koşulları uygunsa mümkündür; yalnızca kapatmak ücretlendirmeyi durdurmayabilir. Bir sunucuyu kaldırmadan önce yeni istek ve iş almasını durdurun, devam eden istek ve işlerin tamamlanmasını bekleyin; oturum ve dosya bağımlılıklarının kalan sistemlerde korunacağını doğrulayın.
Dezavantajları:
- Kurulum ve yönetim daha karmaşıktır.
- Oturum yönetimi, dosya yüklemeleri, paylaşılan depolama gibi konular ekstra tasarım ister.
- Uygulamanızın stateless (durumsuz) çalışmaya daha yakın olması gerekir.
Hibrit Yaklaşım: Kademeli Ölçeklendirme
Bir seçenek, önce dikey olarak makul seviyeye kadar büyütmek, ardından kritik bileşenleri ayrıştırarak yatay ölçeklendirmeye geçmektir. Ölçülen darboğazlara göre uyarlanabilecek örnek bir geçiş sırası:
- İlk adım: Mevcut paylaşımlı hosting’ten, ölçülen kaynak ihtiyacına uygun bir VPS’e geçiş.
- İkinci adım: Veritabanını ayrı bir VPS’e almak.
- Üçüncü adım: Web katmanını 2–3 VPS’e bölmek ve yük dengeleyici eklemek.
Bu sayede hem tek seferde çok büyük bir mimari değişiklik yapmamış olursunuz, hem de her adımda ölçüm yaparak gerçekten ihtiyaç duyduğunuz kapasiteyi daha net görürsünüz.
Uygulama Katmanını Kampanyaya Hazırlamak
Sunucuyu büyütmek tek başına çözüm değildir. Uygulamanız verimsiz çalışıyorsa, en güçlü donanımı bile hızlıca tüketebilirsiniz. Özellikle WordPress, WooCommerce ve Laravel gibi popüler yığınlarda birkaç temel optimizasyon, kampanya başarısı için kritik fark yaratır.
Tam Sayfa Önbellekleme ve Mikro Önbellek
En etkili tekniklerden biri, kullanıcılar arasında güvenle paylaşılabilen HTML çıktısını cache’lemektir. Sepet, ödeme, hesap ve diğer kişiselleştirilmiş yanıtları ortak tam sayfa önbelleğinin dışında tutun; oturum ve çerezlere göre önbelleği atlama kurallarını doğrulayın. WordPress tarafında bunu Nginx FastCGI Cache, Varnish veya LiteSpeed Cache ile yapabilirsiniz. Bu konuda detaylı bir rehbere ihtiyacınız varsa, WordPress’te tam sayfa önbellekleme yazımızda WooCommerce’e zarar vermeden cache kurmanın püf noktalarını anlattık.
TV reklamı gibi çok sert pike maruz kalacaksanız, ortak önbelleğe uygun yanıtlarda 1–5 saniyelik Nginx mikro önbellekleme ile PHP katmanına binen yükü azaltabilirsiniz. Listeleme ve ürün detay sayfalarında kazanç, aynı önbellek girdisine gelen isteklerin sıklığına ve isabet oranına bağlıdır; PHP-FPM’in düşük yükte kalması garanti değildir. Kısa süreli önbellekte de kişiselleştirilmiş yanıtları dışlayın ve fiyat/stok bilgilerindeki olası gecikmenin kabul edilebilir olduğunu doğrulayın.
Nesne Önbelleği ve Oturum Yönetimi
WordPress/WooCommerce tarafında Redis tabanlı nesne önbelleği, önbellek isabet oranına bağlı olarak veritabanı yükünü azaltabilir. Dosya tabanlı oturum kullanan uygulamalarda oturumları Redis gibi paylaşılan bir altyapıya taşımak, istekler farklı web sunucularına yönlendirildiğinde oturum sürekliliğine yardımcı olur; ancak tek başına oturum kaybını önleme garantisi değildir. Nesne önbelleği kurulumu, uygulamanın oturum depolamasını otomatik olarak değiştirmez. Bu yaklaşım, birden fazla web sunucusuna geçtiğinizde kritik önem taşır.
Veritabanı Optimizasyonu
Yoğun trafikte dar boğaz PHP katmanında veya veritabanında oluşabilir; hangi katmanın sınırlayıcı olduğunu metriklerle belirleyin. Kampanya öncesi mutlaka:
- Sık kullanılan sorgular için indeksleme yapın.
- Slow query log’u açıp en yavaş sorguları analiz edin.
- InnoDB buffer pool, connection limit ve cache ayarlarını gözden geçirin.
Özellikle WooCommerce çalıştırıyorsanız, WooCommerce için MySQL/InnoDB tuning kontrol listemiz kampanya öncesi yapılacak ayarları oldukça pratik bir dille özetliyor.
PHP-FPM, OPcache ve Sürüm Güncellemeleri
Güvenlik desteği süren, uygulamanızla uyumlu bir PHP 8.x sürümüne geçiş performans kazancı sağlayabilir; etkisini temsilî iş yükünüzle ölçün. Ancak sadece sürümü yükseltmek yetmez; PHP-FPM havuz ayarları, OPcache konfigürasyonu ve gerekirse Laravel tarafında Octane gibi çözümlerle uygulamanızı üretim ortamına uygun hale getirmelisiniz. Bu konuda PHP 8.x yükseltme kontrol listemizi ve Laravel prod ortam optimizasyonu rehberimizi incelemenizi öneririz.
Altyapı Bileşenleri: DNS, SSL, CDN, DDoS ve İzleme
Sunucu boyutunu artırmak önemli, ancak tek başına yeterli değil. Kampanya dönemlerinde DNS, SSL, CDN, DDoS koruması ve izleme/alerting tarafı da eksiksiz çalışmalı. Aksi halde sorun yaşadığınızda problemi hızlı teşhis edemezsiniz.
DNS ve TTL Stratejisi
Kampanya öncesi son dakika altyapı değişiklikleri yapmanız gerekebilir: Yeni bir yük dengeleyici eklemek, IP değiştirmek, farklı bir data center’a taşımak gibi. Bu tür değişikliklerde DNS önbelleklerinden kaynaklanan gecikmeleri azaltmak için TTL (Time To Live) değerlerini önceden planlamak gerekir.
Örneğin A ve AAAA kayıtlarınızın TTL değerlerini, planlanan altyapı değişikliğinden en az mevcut TTL süresi kadar önce 300 saniyeye düşürebilirsiniz; mevcut TTL daha uzunsa 48 saat yeterli olmayabilir. Önceden önbelleğe alınmış kayıtlar eski TTL dolana kadar kullanılabilir. Geçişi doğrulayıp trafik kararlı hale geldikten sonra TTL’yi yeniden yükseltebilirsiniz. Bu yaklaşımı detaylı bir oyun planına dökmek için Zero-downtime taşıma için TTL stratejileri yazımıza mutlaka göz atın.
SSL/TLS Performansı ve Güvenliği
Yoğun trafikte TLS el sıkışmaları da sunucu üzerinde ciddi bir yük oluşturabilir. TLS 1.3 ve istemci uyumluluğuna uygun sertifika seçimi (gerektiğinde ECDSA/RSA kombinasyonu), güvenlik ve performans hedeflerini destekleyebilir. OCSP stapling ise sertifika otoritesinin ve sertifikanın desteğine bağlıdır; genel bir öneri değildir. Let’s Encrypt, OCSP hizmetini 6 Ağustos 2025’te sonlandırdı ve iptal bilgilerini artık yalnızca CRL üzerinden yayımlıyor; güncel Let’s Encrypt sertifikalarında OCSP stapling kullanılamaz. Eğer kampanya döneminde ödeme alıyorsanız, SSL tarafında hiçbir uyarı görmek istemezsiniz. Bu noktada e-ticaret ve kurumsal siteler için SSL sertifikası yol haritamız hangi sertifika türünün ne zaman doğru olduğunu netleştirmenize yardımcı olacaktır.
CDN ve Statik İçerik Dağıtımı
Kampanya döneminde görsel, CSS, JS gibi statik dosyalar için CDN kullanımını değerlendirin. Önbellek isabetleri ana sunucunuzdaki bant genişliği yükünü azaltabilir; ziyaretçiye yakın edge noktalarından içerik sunmak da gecikmeyi düşürebilir. Kazanç, ziyaretçilerin konumuna, CDN kapsamasına ve önbellek kurallarına bağlıdır; temsilî bölgelerden ölçüm yapın. Bu tarafı doğru kurgulamak için CDN önbellekleme, Cache-Control ve edge kuralları rehberimiz pratik bir kontrol listesi sunuyor.
DDoS Koruması ve Güvenlik
Kampanya planında meşru trafik artışının yanında DDoS saldırıları, brute-force denemeleri ve istenmeyen bot trafiği risklerini de değerlendirin; kampanya günlerinde bunların mutlaka artacağını varsaymayın. Uygulama seviyesinde WAF (Web Application Firewall), oran sınırlama (rate limiting) ve IP engelleme gibi önlemleri iş yükünüze göre yapılandırın; kuralların meşru ziyaretçileri ve ödeme akışlarını engellemediğini doğrulayın. Ancak bu önlemler bağlantı kapasitesini tüketen hacimsel saldırılara tek başına yeterli değildir; ağ seviyesindeki DDoS korumasının kapsamını da sağlayıcınızla netleştirin. Temel kavramlar ve korunma yöntemleri için DDoS saldırıları ve korunma yöntemleri yazımıza göz atabilirsiniz.
İzleme, Uyarı ve Loglama
Büyük bir kampanyaya dashboard’suz ve alarmsız girmek, karanlıkta yüksek hızla araç kullanmak gibidir. CPU, RAM, disk I/O, ağ trafiği, HTTP hata oranları (5xx), veritabanı bağlantıları ve queue uzunlukları için temel metrikleri izleyen bir sistem kurun. Ayrıca loglarınızı merkezi bir yerde toplayıp, kritik hata desenleri için uyarılar oluşturun. Başlangıç seviyesinde bile olsa, VPS izleme ve alarm kurulumu rehberimizde anlattığımız yaklaşım size sağlam bir temel sağlayacaktır.
Black Friday, TV Reklamı ve Lansman İçin Örnek Mimari Senaryoları
Teoriyi pratiğe dökmek için üç varsayımsal senaryoyu ele alalım. Trafik değerleri, kaynak boyutları ve sunucu adetleri örnektir; günlük tekil ziyaretçi sayısı tek başına kapasiteyi belirlemez. Boyutlandırmayı pik istek hızı, eşzamanlılık, önbellek isabet oranı ve temsilî yük testi sonuçlarıyla doğrulayın. Her proje kendine özgüdür, ancak aşağıdaki örnekler size nereden başlayabileceğiniz konusunda net bir çerçeve verir.
Senaryo 1: Orta Ölçekli E-Ticaret Sitesi ve Black Friday
Durum:
- Günlük 3–5 bin tekil ziyaretçi
- Normalde paylaşımlı hosting kullanılıyor; varsayımsal yük testinde kampanya hedefi için kaynak limitleri yetersiz kalıyor
- Black Friday’de 10 kat trafik artışı test senaryosu olarak ele alınıyor
Önerilen mimari:
- Güçlü bir NVMe VPS (örneğin 6–8 vCPU, 16–32 GB RAM) üzerine uygulamanın taşınması
- Ayrı bir veritabanı VPS’i (IOPS odaklı NVMe disk, yüksek RAM)
- WordPress/WooCommerce için tam sayfa önbellekleme + Redis nesne cache; tam sayfa önbelleğinde sepet, ödeme, hesap ve kullanıcıya özel yanıtların hariç tutulması
- CDN üzerinden tüm statik içeriklerin servis edilmesi
Bu senaryoda web katmanını yatay ölçeklendirmeden, dikey ölçeklendirme ve bileşenleri ayırma yoluyla kapasiteyi artırabilirsiniz; kazanımı yük testiyle doğrulayın. Kampanya sonrasında daha küçük kaynaklarla çalışmak ve maliyeti azaltmak, planın küçültmeye izin vermesine ve sözleşme/faturalama koşullarına bağlıdır. CPU ve RAM azaltılabilse bile disk boyutu yerinde küçültülemeyebilir; daha küçük bir sunucuya veri taşıma ve planlı kesinti gerekebilir. Küçültme öncesinde veri boyutunu, yedekleri, geri dönüş yolunu ve yeni kapasitenin yeterliliğini doğrulayın. Yalnızca sunucuyu kapatmak ücretlendirmeyi durdurmayabilir.
Senaryo 2: TV Reklamı ile 10 Dakikalık Sert Pik
Durum:
- Normalde günlük 10 bin tekil ziyaretçi
- Prime-time TV reklamı; reklam süresince 20–30 kat trafik bekleniyor
- Reklam sonrası trafik nispeten normale dönüyor
Önerilen mimari:
- Önde bir yük dengeleyici VPS
- Arkada, pik başlamadan hazırlanmış örneğin 3–5 adet web/PHP VPS’i
- Ayrı, güçlü bir veritabanı VPS’i, gerekirse okuma replikası
- Uygulamanın oturum depolaması için ayrıca yapılandırılmış Redis ve nesne önbelleği
- CDN ve yalnızca ortak önbelleğe uygun yanıtlar için Nginx mikro önbellekleme
On dakikalık bir pikte yeni sunucuların trafik başladıktan sonra yetişeceğine güvenmeyin. Sunucuları önceden sağlayıp uygulamayı dağıtın; yük dengeleyici sağlık kontrollerini, oturum sürekliliğini ve önbelleklerin doğru içerikle ısındığını doğrulayın. Otomatik ölçeklendirme için ayrıca sunucu sağlama API’si veya eşdeğer bir mekanizma, orkestrasyon, metriklere dayalı tetikleyiciler ve sağlıklı düğümleri trafiğe alma süreci gerekir. Bunların kullanılabilirliği sağlayıcıya ve kurduğunuz sisteme bağlıdır; VPS sayısını artırabilmek tek başına zamanında devreye giren otomatik ölçeklendirme sağlamaz. Hazır olma süresini önceden ölçün ve pik için gerekli temel kapasiteyi yayından önce çalışır durumda tutun.
Burada kritik nokta, reklamın yayına girdiği dakikalarda cache isabet oranını maksimumda tutmak. Bu örnekte ziyaretçilerin çoğunun ürün listeleme ve detay sayfalarında dolaştığını varsayalım. Bu sayfalar da dinamik veya kullanıcıya özel olabilir; yalnızca herkese aynı sunulabilen yanıtları, fiyat ve stok güncelliğine uygun süre ve geçersizleştirme kurallarıyla önbelleğe alın. Ödeme, sepet ve kullanıcıya özel yanıtları paylaşılan sayfa önbelleğinin dışında tutun. Bu akışlarda yüksek erişilebilirlik hedefleniyorsa, yukarıdaki tek yük dengeleyici ve tek veritabanı sunucusunun arıza noktaları olduğunu dikkate alın; yedeklilik ve test edilmiş devralma planı gerekir. Okuma replikası eklemek tek başına otomatik devralma sağlamaz.
Senaryo 3: SaaS Ürün Lansmanı
Durum:
- Yeni bir SaaS ürün, henüz trafik verisi sınırlı
- Lansman için yoğun bir dijital pazarlama ve PR planı var
- İlk 24–72 saatte hem kayıt olma hem ürün içi kullanım yoğun olacak
Önerilen mimari:
- Uygulama için yük dengeleyici arkasında örneğin 2 adet web/API VPS’i
- Ayrı bir veritabanı VPS’i, ileride replikaya uygun konfigürasyon
- Queue/işleyici (worker) süreçleri için ayrı bir VPS veya dedicated sunucu
- Redis veya benzeri bir mesajlaşma/önbellek katmanı
- Detaylı izleme, loglama ve alarm mekanizmaları
SaaS ürünlerde yoğun trafik sadece web arayüzünden değil, arka planda çalışan cron job’lar, queue’lar ve entegrasyonlardan da gelir. Bu nedenle API, background job ve web trafiğini mümkün olduğunca ayrı katmanlarda ele almak daha sağlıklı olur. Bu varsayımsal mimaride uygulama, veritabanı ve worker süreçlerini farklı VPS’lerde konumlandırıp, büyüme oldukça her katmanı ihtiyaca göre ayrı ayrı ölçeklendirebilirsiniz.
Operasyonel Hazırlık: Test, Runbook ve Geri Dönüş Planı
En güçlü altyapı bile plansız bırakıldığında sorun çıkarabilir. Kampanya günü geldiğinde herkesin ne yapacağını bildiği, test edilmiş bir operasyonel planınız olmalı.
Yük ve Stres Testleri
Kampanya öncesi mutlaka yük testi ve mümkünse stres testi yapın. Amaç, hedeflediğiniz eşzamanlı kullanıcı ve istek sayısına çıktığınızda:
- CPU, RAM ve disk I/O değerlerinin nereye kadar yükseldiğini görmek,
- Hangi noktada 5xx hata oranının artmaya başladığını tespit etmek,
- Veritabanındaki dar boğazları ve lock/satır kilitlenmelerini fark etmek.
Testi yalnızca yetkili olduğunuz sistemlerde, tercihen üretimi temsil eden ayrı bir ortamda yürütün. Listeleme yanında sepet, oturum ve ödeme gibi kritik akışları gerçekçi oranlarla modelleyin; ödeme ve diğer dış servislerde test ortamlarını kullanın, üçüncü taraflara izinsiz yük göndermeyin. Hedef istek hızında p95/p99 yanıt süresi ve hata oranı için kabul sınırları belirleyin; sıcak ve soğuk önbellek davranışını değerlendirin. Üretimde test gerekiyorsa sağlayıcıyla sınırları ve zamanlamayı koordine edin, durdurma eşikleri tanımlayın. Elde ettiğiniz sonuçlar, kaynak artırma kararlarınızı ve önbellekleme stratejinizi somut verilerle besleyecektir.
Runbook ve Olay Yönetimi
Kampanya sırasında bir sorun çıktığında “kime soracağız?” diye düşünmeye başlıyorsanız, çoktan vakit kaybetmişsiniz demektir. Önceden hazırlanmış bir runbook ile şu sorulara net cevaplarınız olsun:
- Yoğunluk artınca ilk bakılacak dashboard’lar hangileri?
- CPU/RAM %90’ı görürse ne yapıyoruz, hangi kaynağı önce büyütüyoruz?
- Veritabanı kuyrukları dolarsa hangi sorgular geçici olarak sınırlandırılacak?
- Hangi log desenleri kritik incident olarak kabul edilecek, kim bilgilendirilecek?
Altyapı değişiklikleri kadar operasyonel akışı da netleştirin. Belirsiz sorumluluklar ve iletişim zinciri, soruna müdahaleyi geciktirerek kesintinin uzamasına yol açabilir.
Geri Dönüş (Rollback) ve Acil Durum Planı
Kampanya öncesi yaptığınız her büyük değişiklik için bir geri dönüş planınız olsun. Örneğin:
- Yeni bir sürüm dağıttıysanız, eski sürüme nasıl döneceksiniz; eski uygulama sürümü yeni veritabanı şemasıyla uyumlu mu?
- Yeni bir okuma replikası eklediyseniz, sorun çıkarsa okuma trafiğini eski yapıya nasıl yönlendireceksiniz; eski yapı bu yükü karşılayabilecek mi?
- Yeni bir CDN kuralı tanımladıysanız, hatalı davranırsa nasıl devre dışı bırakacak ve gerekirse önbellekteki yanıtları nasıl temizleyeceksiniz?
Uygulama sürümünü geri almak, veritabanı değişikliklerini veya kampanya sırasında oluşan siparişleri otomatik olarak geri almaz. Değişiklik öncesi yedekleri ve geri yükleme yolunu doğrulayın; eski bir yedeğe dönmenin yeni verileri kaybettirebileceğini hesaba katın. Geri dönüş süresini ve veri koruma adımlarını önceden planlayın.
Bu noktada sıfır kesinti CI/CD, canary dağıtımı, blue/green mimarileri gibi kavramlar işinize yarar. Blogumuzda bu konularda da detaylı rehberler bulabilirsiniz; özellikle VPS’e sıfır kesinti CI/CD kurulumu yazısı pratik bir başlangıç noktası sunuyor.
DCHost ile Kampanya Dönemine Hazırlanmak
Ekibiniz küçükse veya ilk kez büyük bir kampanyaya hazırlanıyorsanız, altyapı seçimi kadar görev paylaşımını da netleştirin. DCHost ile görüşürken ihtiyaç duyduğunuz kaynakları, hedef trafik profilini ve operasyonel beklentilerinizi paylaşın. Kendi donanımınızı barındırmayı değerlendiriyorsanız colocation çözümlerine ilişkin rehberimiz de seçenekleri karşılaştırmanıza yardımcı olabilir. Bu yazı, belirli bir pakette kampanyaya özel danışmanlık, uygulama optimizasyonu veya yönetilen geçiş hizmetinin dahil olduğunu doğrulamaz; hizmet kapsamını ve sorumlulukları güncel teklif ve sözleşmeyle netleştirin.
Kampanya öncesinde kendi ekibinizle planlayıp, sağlayıcı desteği gerektiren maddeleri DCHost ile ayrıca netleştirebileceğiniz kontrol listesi:
- Kapasite: Mevcut mimari ve metrikleri kim analiz edecek; hedef kapasite ve kabul ölçütleri neler olacak?
- Kaynak sağlama: İstenen CPU, RAM, disk ve ağ kapasitesi hangi koşullarla, ne kadar sürede sağlanabilir; büyütme ve küçültme nasıl ücretlendirilir?
- Geçiş: Veri ve uygulama taşıma, doğrulama ve geri dönüş adımlarında hangi işler ekibinize, hangileri varsa satın alınan hizmete aittir?
- Güvenlik ve dağıtım: DNS, SSL, CDN ve DDoS ayarlarından kim sorumludur; korumanın kapsamı ve sınırları nelerdir?
- Operasyon: İzleme, alarm müdahalesi, yedekleme ve geri yükleme sorumluları kimlerdir; destek saatleri, yanıt hedefleri ve ek ücretler nelerdir?
Eğer WordPress, WooCommerce veya popüler bir PHP/Laravel yığını üzerinde çalışıyorsanız, blogumuzdaki WordPress için sunucu tarafı optimizasyon rehberi ve diğer performans odaklı içeriklerimiz, teknik ekibiniz için somut kontrol listeleri sağlar.
Özet ve Sonraki Adımlar
Yoğun trafikli kampanyalar, altyapınızı en çıplak haliyle ortaya çıkarır. Black Friday’de, bir TV reklamında ya da büyük bir lansmanda fark yaratan şey; sadece daha büyük bir sunucuya geçmek değil, ölçeklendirmeyi bir süreç ve mimari kararlar bütünü olarak ele almaktır. Mevcut kapasitenizi doğru ölçmek, dikey ve yatay ölçeklendirme kombinasyonunu bilinçli seçmek, uygulama ve veritabanı katmanını optimize etmek ve DNS/SSL/CDN/DDoS/izleme bileşenlerini sağlam bir zemine oturtmak, kampanya sırasındaki performans ve kesinti risklerini azaltmaya yardımcı olur.
Şimdi bir sonraki büyük kampanya tarihini takvimde işaretleyip bu tarihten geriye doğru bir teknik yol haritası çıkarın. Kapasite artırımı, testler ve geri dönüş hazırlıkları için son tarihleri ve sorumluları belirtin. DCHost’tan kaynak veya destek talep edecekseniz, ihtiyaç listenizle birlikte başvurup kullanılabilirliği, sağlama sürelerini, kapsamı ve ücretleri önceden netleştirin. Sağlık taraması, kapasite danışmanlığı veya geçiş projesinin sunucu hizmetine kendiliğinden dahil olduğunu varsaymayın.
