E-ticaret altyapısı ve kampanya günü hazırlığı

E-ticarette kesintinin maliyeti doğrudan hesaplanabilir: dakika başına kaybedilen sipariş. Ve kesinti en çok, trafiğin en yüksek olduğu gün gelir. Kampanya gününe hazırlık, o gün değil en az üç hafta önce başlar.

E-ticaret yükü neden farklıdır?

Tanıtım sitesinde ziyaretçilerin çoğu aynı sayfaları görür ve içerik önbelleklenebilir. E-ticarette ise ziyaretçilerin önemli bölümü oturum açmıştır: sepet, öneriler, stok durumu ve fiyat kişiye özeldir. Bu sayfalar önbellekten verilemez, her istek uygulamaya ve veritabanına ulaşır. Aynı ziyaretçi sayısında e-ticaret sitesi, tanıtım sitesinin birkaç katı kaynak tüketir.

Önbelleği katman katman kurun

• Tam sayfa önbelleği: Ana sayfa, kategori ve ürün sayfaları için anonim ziyaretçiye. Trafiğin büyük bölümü buradadır.
• Parça önbelleği: Menü, kategori ağacı, "çok satanlar" gibi bloklar ayrı önbelleklenir; kişisel alanlar dinamik kalır.
• Nesne önbelleği: Redis ile sorgu sonuçları bellekte tutulur; oturum açmış kullanıcıların sayfalarını hızlandıran asıl katman budur.
• Kesinlikle önbelleklenmeyecekler: sepet, ödeme, hesabım, sipariş takibi. Bu kural yazılmadığında bir müşterinin sepeti başkasına görünür.

Stok bilgisini önbelleklerken dikkatli olun. Beş dakikalık eski stok verisi, tükenmiş ürünün satılmasına yol açar; kampanya günü bu, iptal ve iade demektir.

Kuralı yapılandırmaya yazın

"Sepet önbelleklenmesin" cümlesi bir niyet beyanıdır; sunucuda karşılığı olması gerekir. Ters vekil önbelleğinde bu, hassas yolların açıkça dışarıda bırakılmasıyla yapılır:

map $request_uri $onbellek_atla { default 0; ~^/(sepet|odeme|hesabim|siparis-takip) 1; }

Ardından bu değişken hem proxy_cache_bypass hem proxy_no_cache yönergesine verilir. Oturum çerezi taşıyan isteklerin de aynı şekilde dışarıda bırakılması gerekir; yalnız yola bakan bir kural, giriş yapmış kullanıcının kişiselleştirilmiş ana sayfasını anonim ziyaretçiye servis edebilir.

Kurulumu yayına almadan önce tek satırla sınayın: curl -sI https://ornek.com/sepet | grep -i "x-cache\|cache-control". Sepet ve ödeme yollarında beklenen sonuç, önbellek isabeti olmaması ve Cache-Control başlığında private ifadesinin görünmesidir.

Yük testini gerçek akışla yapın

Yalnız ana sayfaya istek atan bir test yanıltıcıdır; ana sayfa önbellekten döner ve her şey harika görünür. Gerçekçi bir senaryo şu adımları içermeli: ana sayfa → kategori → ürün → sepete ekle → sepeti görüntüle → ödeme adımı. Ölçülecekler:

• Her adımın p95 yanıt süresi.
• Hata oranının yükseldiği eşzamanlı kullanıcı sayısı.
• Veritabanı bağlantı havuzunun dolduğu nokta.
• CPU ve belleğin hangi adımda tükendiği.

Testi üretim benzeri bir kopyada yapın; canlı sistemde yük testi yapmak, önlemeye çalıştığınız kesintiyi kendi elinizle yaratmaktır.

Senaryoyu betikle tarifleyebilen bir araç kullanın; k6, vegeta ve Locust bu iş için yaygın ve ücretsiz seçeneklerdir. Kullanıcı sayısını tek adımda tepeye çıkarmak yerine kademe kademe artırın:

k6 run --stage 2m:50 --stage 5m:200 --stage 3m:400 senaryo.js

Böylece sistemin hangi eşzamanlılık seviyesinde kırıldığını görürsünüz; bir anda 400 kullanıcı bindiren test yalnız "çöktü" der, nerede çöktüğünü söylemez. Test sırasında sunucuda top, iostat -x 2 ve veritabanının SHOW PROCESSLIST çıktısını açık tutun; darboğazın CPU'da mı, diskte mi, kilit bekleyen sorgularda mı olduğu ancak bu üçüne aynı anda bakarak anlaşılır.

Kırılma noktasını bulduğunuzda hedefinizle karşılaştırın: kampanya günü beklediğiniz tepe eşzamanlı kullanıcı sayısının en az iki katını sorunsuz taşıyabilmelisiniz. Aradaki pay, tahminin tutmadığı durumlar içindir ve tahmin kampanya günlerinde sıklıkla tutmaz.

Kampanya öncesi üç hafta

1. 3 hafta kala: Yük testini yapın, darboğazları listeleyin. Yavaş sorgu günlüğünü açıp en pahalı sorguları düzeltin. Gerekiyorsa kaynak artışını planlayın.
2. 2 hafta kala: Düzeltmeleri uygulayın ve testi tekrarlayın. Önbellek kurallarını gözden geçirin. Yedeklerin çalıştığını doğrulayın.
3. 1 hafta kala: Kod dondurma. Kampanya haftasında altyapıya dokunulmaz. İzleme eşiklerini sıkılaştırın, nöbet listesini belirleyin.

Kampanya günü

• İzleme ekranı açık kalsın: yanıt süresi, hata oranı, sipariş sayısı. Sipariş sayısının düşmesi, teknik metrikler iyi görünse bile bir arıza işaretidir.
• Riskli özellikleri kapatabilecek bir anahtarınız olsun: canlı öneri motoru, ısı haritası, ağır arama filtreleri. Yük kritik seviyeye gelirse bunları kapatmak siteyi ayakta tutar.
• Ödeme sağlayıcısının durumunu ayrıca izleyin. Kesintilerin bir bölümü sizde değil, dış serviste olur; müşteriye ne mesaj göstereceğinize önceden karar verin.
• E-posta kuyruğuna dikkat edin. Binlerce sipariş onayı aynı anda gönderildiğinde teslimat sorunları başlar; gönderim hızını sınırlayın ve kimlik doğrulama kayıtlarınızın doğru olduğundan emin olun.

Geri dönüş planı hazır olsun

Kampanya günü en kötü senaryo, sistemin tamamen yanıtsız kalmasıdır. İkinci en kötü senaryo, o an ne yapacağını kimsenin bilmemesidir. Şunlar önceden hazır olmalı:

• Bakım sayfası. Statik, kampanyayı ve tahmini süreyi açıklayan, 503 durum koduyla ve Retry-After başlığıyla dönen bir sayfa. Doğru durum kodu, arama motorunun sayfayı kalıcı olarak kaybolmuş saymasını engeller.
• Tek komutluk geri alma. Son çalışan sürüme dönüş bir dizin değiştirmekten ibaret olmalı; kampanya gecesi kod düzeltmeye çalışmak en kötü seçenektir.
• Yazılı karar eşiği. "Hata oranı beş dakika boyunca %5'i aşarsa öneri motorunu kapat" gibi kararlar önceden yazılırsa, o anda tartışılmaz.
• Ulaşılabilir kişi listesi. Barındırma sağlayıcısı, ödeme sağlayıcısı ve kargo entegrasyonu için kimin arayacağı belli olsun.

Bu yaklaşım ne zaman gereğinden ağır kalır

Üç haftalık hazırlık, yükü gerçekten katlanan bir mağaza içindir. Günde birkaç sipariş alan bir siteyi bekleyen tehlike kapasite değil, kampanya duyurusunun hiç duyulmamasıdır; orada emek altyapıya değil pazarlamaya gider. Satışı tamamen bir pazaryeri üzerinden yapan bir işletmede kapasite sorunu sizin değil, o platformundur. Ürün sayısı az ve fiyatı herkes için aynı olan bir katalogda ise sayfaların neredeyse tamamı önbelleklenebilir; böyle bir sitede tam sayfa önbelleği tek başına yükün büyük kısmını karşılar ve geri kalan katmanlara ihtiyaç duyulmaz.

Altyapı seçimi

Düzenli sipariş alan bir e-ticaret sitesi için paylaşımlı barındırma tepe noktalarında yetersiz kalır. Kaynağı dakikalar içinde büyütülebilen cloud sunucu, kampanya dönemlerinde geçici olarak büyütüp sonra küçültmenize izin verdiği için en esnek seçenektir. Sürekli yüksek ve öngörülebilir yükte fiziksel sunucu, izole edilmiş kaynak ve veri ayrımı gereken kurumsal senaryolarda private cloud daha uygundur.

Kampanya sonrası

Ertesi gün rakamları soğukkanlılıkla inceleyin: tepe eşzamanlı kullanıcı, en yavaş sayfa, oluşan hatalar, terk edilen sepet oranı. Bu veri, bir sonraki kampanyanın hazırlık listesidir. Geçici olarak büyüttüğünüz kaynakları küçültmeyi de unutmayın; unutulan yapılandırma, sessizce büyüyen bir gider kalemidir.