Kampanya Döneminde E-Ticaret Altyapısı: Yük Testi Sonuçlarını Nasıl Okursunuz?

Kampanya günü sitenin yavaşlaması ya da ödeme adımında hata vermesi, reklam bütçesinin ve kampanya emeğinin boşa gitmesi demektir. Bu yüzden birçok ekip kampanyadan önce yük testi yapar. Asıl zorluk testi çalıştırmak değil, çıkan rakamları doğru okuyup karara bağlamaktır. Bu yazıda e-ticaret altyapısı yük testi sonuçlarını hangi ölçütlerle değerlendireceğinizi ve bulguların ölçekleme, önbellek ve veritabanı gibi altyapı kararlarına nasıl dönüştüğünü adım adım anlatıyoruz.

01E-ticaret altyapısı yük testi için önce hedef yükü yazın

Test sonucunu yorumlamak için karşılaştıracağınız bir hedef olmalı. Hedefiniz 1.200 eş zamanlı oturumsa “sistem 500 kullanıcıyı kaldırdı” cümlesi iyi haber değildir. Hedefi üç girdiyle çıkarın:

• Geçmiş veri: önceki kampanyanın ya da yoğun bir günün zirve saatindeki eş zamanlı oturum sayısı ve saniyedeki sipariş sayısı. Kaynağınız analitik araçlarınız ve sunucu günlükleridir.
• Büyüme beklentisi: pazarlama ekibinin reklam, bülten ve SMS planından çıkardığı trafik çarpanı.
• Güvenlik payı: tahmin hatasına karşı eklenen tampon.

Varsayımsal bir örnek: geçen kampanyanın zirvesinde 300 eş zamanlı oturum gördünüz, bu kez trafiğin 3 katını bekliyorsunuz ve yüzde 30 pay istiyorsunuz. Hedef yük 300 × 3 × 1,3 = 1.170 oturum olur.

Senaryo karışımını da gerçeğe yaklaştırın. Zirve trafik çoğunlukla ana sayfa, kategori ve arama sayfalarında toplanır. Sepet ve ödeme adımlarını ise ayrı senaryolar olarak ölçün; bu adımlar önbelleğe alınamaz ve veritabanına yazar. Ödeme sağlayıcısının canlı sistemine yük bindirmeyin; test ortamını ve sağlayıcının kullanım koşullarını kullanın.

02Yük testi sonuçlarında bakılacak beş ölçüt

Rapordaki tek bir ortalama sayı çoğu zaman yanıltır. Aşağıdaki beş ölçütü birlikte okuyun:

Sunucu tarafındaki gecikme, kullanıcının tarayıcıda gördüğü hızın yalnızca bir parçasıdır. Kullanıcı deneyimi ölçütlerini ayrıca izlemek için web.dev üzerindeki Core Web Vitals açıklamasına bakabilirsiniz.

Geçti/kaldı eşiklerini testten önce yazılı olarak belirleyin. Örnek bir eşik: ödeme adımında p95 gecikme 2 saniyenin altında, hata oranı yüzde 1'in altında. Bu değerler yalnızca örnektir; kendi iş hedefinize ve müşteri beklentinize göre belirleyin. Eşik sonuçtan sonra belirlenirse rapor kendini doğrulamaya başlar.

03Bir test raporu adım adım nasıl okunur?

Kademeli artış testi (yükü basamak basamak yükselten test) yaptığınızı ve hedefin yukarıdaki 1.170 oturum olduğunu varsayalım. Rapor şunları gösteriyor:

• 400 oturum: p95 gecikme yaklaşık 0,8 sn, hata yok denecek kadar az.
• 800 oturum: p95 gecikme yaklaşık 1,3 sn, hata oranı yüzde 0,3.
• 1.200 oturum: p95 gecikme yaklaşık 5,1 sn, hata oranı yüzde 4, verim 800 oturum seviyesinde düzleşmiş.
• Aynı anda veritabanı CPU'su tavanda, uygulama sunucularının CPU'su ise yarının altında.

Okuma sırası şöyle olabilir:

1. Kırılma noktasını bulun. Sistem 800 ile 1.200 arasında bozuluyor. Hedefiniz bu aralığın üst ucunda olduğu için mevcut yapı güvenli değil.
2. Eşikle karşılaştırın. 1.200 oturumda hem gecikme hem hata oranı eşiği aşıyor. Sonuç “kaldı”.
3. Darboğazın yerini belirleyin. Uygulama sunucuları boştayken veritabanı doyduğu için sınırı veritabanı belirliyor.
4. Yanlış çözümü eleyin. Uygulama sunucusu sayısını artırmak bu tabloda sorunu çözmez, hatta veritabanına gelen bağlantı sayısını artırarak durumu kötüleştirebilir.
5. Düzeltip yeniden ölçün. Bir darboğaz giderilince bir sonrakisi görünür hâle gelir. Aynı senaryoyu tekrar koşmadan kapasite kararı vermeyin.

04Bulguyu altyapı kararına çevirmek

Aşağıdaki tablo, sık görülen bulguları olası nedenleri ve karar adaylarıyla eşleştirir. Kesin teşhis için kendi sisteminizin izleme verisine ve sorgu analizine ihtiyaç vardır; tablo bir başlangıç noktasıdır.

Otomatik ölçeklemeye güvenmeden önce ölçeklemenin ne kadar hızlı tepki verdiğini testte ölçün. Yeni sunucu örneğinin hazır olması dakikalar sürebilir; kampanya saatinde trafik saniyeler içinde yükselirse otomatik ölçekleme geç kalabilir. Bu durumda kampanyadan hemen önce kapasiteyi bilinçli olarak artırmak (önceden ölçekleme) daha güvenli bir karardır. Ölçekleme için bir üst sınır koyun; hem maliyeti hem de veritabanı gibi ölçeklenmeyen bağımlılıkları korur.

Yük altındaki davranışı tasarım ilkeleri açısından gözden geçirmek için AWS Well-Architected Framework ve otomatik ölçekleme tarafında Microsoft'un Azure otomatik ölçekleme rehberi iyi birer başlangıç kaynağıdır. Hangi bulut sağlayıcıyı kullanırsanız kullanın, sağlayıcının kendi sınır ve kota belgelerini de kontrol edin.

05Sık sorulan sorular

Yük testini canlı ortamda mı yapmalıyız?

Mümkünse canlıya yakın bir hazırlık ortamında yapın; yapı, veri hacmi ve ayarlar canlıdan çok farklıysa sonuçlar yol göstermez. Canlıda test yapacaksanız düşük trafikli saati seçin, yazılı onay alın, test siparişlerini gerçek verilerden ayırın ve bulut ile üçüncü taraf sağlayıcıların test politikalarını önceden kontrol edin.

Testi ne zaman yapmalı, ne kadar önce tekrarlamalı?

İlk testi kampanyadan birkaç hafta önce yapın ki bulgulara göre düzeltme yapacak zaman kalsın. Her düzeltmeden sonra aynı senaryoyla kısa bir doğrulama koşun. Kod dondurma sonrasında da son bir test yapmak, son anda eklenen bir değişikliğin kapasiteyi bozmasını yakalamaya yardım eder.

Test başarılı geçti ama kampanyada yine yavaşlama yaşanırsa?

Test senaryosu gerçek trafikten farklı olabilir: önbelleğin soğuk ya da sıcak olması, tek bir ürüne yoğunlaşan talep, bot trafiği ve sayfaya eklenen üçüncü taraf betikleri sık görülen nedenlerdir. Bu yüzden testin yanında canlı izleme panosu ve uyarı eşikleri de hazırlayın; ilk belirtiyi kullanıcı şikâyetinden önce görmelisiniz.

06Sonuç: kampanya haftası için karar listesi

Yük testi sonucu bir not değil, karar girdisidir. Kampanyadan önce şu listeyi gözden geçirin:

1. Hedef yük, geçmiş veri ve trafik çarpanıyla yazılı olarak belirlendi mi?
2. Geçti/kaldı eşikleri testten önce tanımlandı mı?
3. Rapor ortalamaya değil p95/p99 gecikmeye, hata oranına ve verim düzleşmesine göre okundu mu?
4. Darboğaz bir bileşene (veritabanı, uygulama, önbellek, dış sağlayıcı) bağlandı mı?
5. Düzeltmeden sonra aynı senaryo yeniden koşuldu mu?
6. Kampanya günü için izleme panosu, uyarı eşikleri, ölçekleme üst sınırı ve geri dönüş planı hazır mı?

Kampanya öncesi bulut mimarisi, ölçekleme ve izleme kararlarında dış destek almak isterseniz OPEIS'in Bulut Çözümleri sayfasından hizmet kapsamını inceleyebilirsiniz.