Kampanya günü site çöktü: yük testi ve kapasite planlaması nasıl yapılır?

Kampanya günü çöken sitelerin çoğu, sunucusu küçük olduğu için çökmez. Sistemdeki tek bir kaynak doyar, arkasında kuyruk birikir ve gecikme birkaç dakika içinde zaman aşımına dönüşür. Yük testi, gerçek trafiğin şeklini taklit ederek bu doyma noktasının nerede olduğunu kampanya gününden önce bulma işidir. Kapasite planlaması ise o noktayı beklenen zirvenin belirgin biçimde üstünde tutmaktır. İki sayıyı bilmeden başlanmaz: saniyede kaç istek bekliyorsunuz, sistem saniyede kaç istekte bozuluyor. Aradaki payı bilmiyorsanız kampanya gününü şansa bırakıyorsunuz.

Önce beklenen zirveyi sayıya çevirin

"Çok trafik bekliyoruz" bir hedef değil. Analitik verinizden son on iki ayın en yoğun saatini çıkarın, o saatteki oturum sayısını ve ortalama oturum süresini alın. k6 dokümantasyonunun önerdiği basit formül işi görür: eşzamanlı kullanıcı = saatlik oturum sayısı × ortalama oturum süresi (saniye) / 3600. Sonra bir oturumun kaç istek ürettiğine bakın. Bir ürün sayfası tek bir istek değildir; HTML, birkaç API çağrısı, arama önerileri, sepet durumu ve ölçüm çağrıları hepsi ayrı ayrı sayılır.

Kampanya trafiği ortalama trafik gibi davranmaz. E-posta saat 10:00'da gönderiliyorsa trafiğin yarısı ilk on dakikada gelir. Geçen yılın aynı kampanyasında zirve dakikası neydi, ona bakın ve büyüme oranıyla çarpın. Ortalamayı hedef alırsanız zirvede iki kat açık verirsiniz.

"Kaç eşzamanlı kullanıcı" çoğu zaman yanlış birim

Klasik yük testi araçları sabit sayıda sanal kullanıcı çalıştırır: her kullanıcı bir isteği bitirir, biraz bekler, bir sonrakini yollar. Buna kapalı model deniyor ve içinde sinsi bir hata var. Sistem yavaşladığında sanal kullanıcılar da bekler, yani test aracının ürettiği yük kendiliğinden düşer. Gerçek kullanıcılar öyle davranmaz; siteniz yavaşlarken yenileri gelmeye devam eder, hatta sayfayı yenileyip yükü artırırlar. Gil Tene'nin "coordinated omission" adını verdiği bu sapma, en kötü anların ölçüme hiç girmemesine yol açar ve p99 değerini olduğundan iyi gösterir.

Açık model bunu düzeltir. Sanal kullanıcı sayısını değil, varış hızını sabitlersiniz: saniyede 200 istek, yanıtlar gecikse de gecikmese de. k6'da constant-arrival-rate ve ramping-arrival-rate yürütücüleri bu işe bakar, Locust ve Artillery tarafında da karşılıkları var. API ve kampanya trafiği için doğru varsayılan budur.

Altı test türü, altı ayrı soru

k6 dokümantasyonundaki sınıflandırma pratikte iyi çalışıyor. Duman testi (smoke) az kullanıcı ve kısa süreyle senaryonun doğru çalıştığını doğrular; her değişiklikten sonra çalıştırılacak olan budur. Ortalama yük testi beklenen normal trafiği 5 ila 60 dakika uygular. Stres testi beklenenin üstünü dener. Ani yük testi (spike) çok yüksek yükü birkaç dakikalığına bindirir, kampanya senaryosunun tam karşılığıdır. Dayanıklılık testi (soak) ortalama yükü saatlerce sürdürür ve bellek sızıntısı, kapanmayan bağlantı, dolan disk gibi ancak zamanla ortaya çıkan sorunları yakalar. Kırılma noktası testi (breakpoint) yükü sistem bozulana kadar kademeli artırır.

Sıralama önemli. Önce duman testi, sonra ortalama yük, sonra kırılma noktası. İlk iki adımı atlayıp doğrudan sistemi kırmaya çalışırsanız, elinizde yalnızca "bir yerde bozuldu" bilgisi kalır.

Senaryo gerçekçi değilse sonuç da değil

Tek bir URL'ye saniyede on bin istek atmak sizi değil, CDN'inizi test eder. Gerçekçi bir senaryo trafik karışımını yansıtır: ziyaretçilerin çoğu gezinir, bir kısmı arama yapar, küçük bir yüzdesi sepete ekler, daha küçüğü ödemeye gider. Yazma işlemleri özellikle önemli, çünkü stok düşme, sipariş numarası üretme ve ödeme kaydı gibi adımlar kilit çekişmesi yaratır ve okuma testinde hiç görünmez.

İkinci tuzak önbellek. Bütün sanal kullanıcılar aynı ürünü isterse her şey önbellekten döner, sayılar harika çıkar, kampanya günü ise yüzlerce farklı ürün istenir ve trafiğin çoğu veritabanına iner. Senaryoda ürün, kullanıcı ve arama terimlerini veri dosyasından çeşitlendirin. Düşünme süresi de ekleyin: gerçek kullanıcı sayfayı okuduğu için istekler arasında saniyeler geçer. Önbellek katmanlarının testte nasıl davrandığını önbellek stratejisi yazımızda ayrıntılı anlattık.

Hangi sayılara bakacaksınız

Ortalama yanıt süresi tek başına neredeyse hiçbir şey anlatmaz. p95 ve p99 gecikmeye, hata oranına ve doygunluk göstergelerine (CPU, bellek, bağlantı havuzu kullanımı, kuyruk derinliği) birlikte bakın. Bir uyarı: yüzdelikler toplanamaz ve ortalanamaz. İki sunucunun p95 değerlerinin ortalaması, sistemin p95'i değildir.

Başarısızlık tanımını teste başlamadan yazın. Örneğin "p95 bir saniyeyi aşarsa veya hata oranı %1'i geçerse kapasite sınırına gelinmiştir" gibi. Zaman aşımlarını hata sayın. Bir de yanıtların doğruluğunu kontrol edin; yük altında 200 dönen ama içi boş gelen sayfalar sık görülür ve sadece durum koduna bakan test bunu başarı olarak raporlar. Ölçüm eşiklerini SLO'larınıza bağlamak isterseniz izlenebilirlik ve hata bütçesi yazımız çerçeveyi veriyor.

Darboğaz çoğu zaman CPU değil

Yük testlerinde en sık çıkan darboğaz veritabanı bağlantı havuzudur. PostgreSQL varsayılan olarak 100 eşzamanlı bağlantı kabul eder ve bu sayı uygulama sunucusu başına değil, tüm sistem için geçerlidir. Uygulama sunucusunu ikiye katlayıp hiçbir şeyin düzelmediğini görmek buradan gelir: iki sunucu da aynı havuzun önünde sıra bekler.

Diğer olağan şüpheliler sabittir. İstek başına onlarca sorgu üreten N+1 döngüleri, aynı satıra yazan işlemler arasındaki kilit çekişmesi, istek içinde senkron çağrılan e-posta veya PDF üretimi, tek bir dış servise bağlı kalan ödeme ya da kargo adımı. Yavaş sorguların nasıl bulunacağını veritabanı performansı yazımızda anlattık. Kural şu: darboğazı bulmadan kaynak eklemeyin, yoksa faturayı büyütür, sorunu çözmezsiniz.

Hedef %100 kullanım değil

Kapasite planlamasında sezgi yanıltır. Basit bir kuyruk modelinde (M/M/1) ortalama yanıt süresi, kullanım oranı arttıkça doğrusal değil hızlanarak büyür: %70 kullanımda kuyrukta ortalama 1,6 istek beklerken, %90 kullanımda bu sayı 8,1'e çıkar. %80 kullanımda ortalama yanıt süresi, işin kendi süresinin yaklaşık beş katıdır. Gecikme eğrisinin sertçe yukarı kırıldığı bölge tipik olarak %70 ile %80 arasındadır.

Pratik sonuç: sürekli hedefinizi %60-70 kullanımda tutun ve zirve için pay bırakın. Buna bir de yedeklilik ekleyin. Üç sunucudan biri çöktüğünde kalan ikisi zirveyi karşılayabiliyor mu? Cevap hayırsa, sisteminiz üç sunucuyla değil aslında bir arıza uzaklıkta çalışıyor demektir.

Otomatik ölçekleme gecikmeyi ortadan kaldırmaz

Otomatik ölçekleme yeni sunucuyu anında getirmez. Metriğin toplanması, eşiğin aşılması, örneğin başlatılması, uygulamanın ısınması ve sağlık kontrolünden geçmesi toplamda dakikalar sürer. Kampanya zirvesi ise 60 saniyede gelir. Bu yüzden bilinen tarihli olaylarda zamanlanmış ölçekleme kullanın ve kapasiteyi zirveden önce açın.

Ölçeklenemeyen anlar için elinizde bir plan olsun: bekleme odası veya sanal sıra, uç noktalara hız sınırı, aşırı yükte en pahalı özellikleri kapatma. Öneri motorunu, canlı stok sayacını ya da kişiselleştirilmiş ana sayfayı özellik bayrağıyla kapatıp statik sürüme düşebiliyorsanız, çökmek yerine kısıtlı hizmet verirsiniz. Bunun adı yük atma (load shedding) ve kampanya günü en değerli düğmeniz odur.

Nerede test edilir, neyi kırar

Test ortamı üretimin küçük bir kopyasıysa çıkan sayılar doğrudan taşınmaz; oran olarak yorumlanır. En sağlıklısı üretime denk bir ortamda test etmek, o mümkün değilse üretimde düşük trafikli saatte, elde acil durdurma düğmesiyle, kademeli şekilde ilerlemek.

Önünüzde CDN veya WAF varsa iki şey olur: ya testiniz hız sınırına takılıp kesilir, ya da istekler kenarda önbellekten karşılanıp asıl sunucunuzun ne kadar yorulduğunu gizler. Test IP'lerinizi tanımlı hale getirin ve önbelleği bilinçli olarak devre dışı bırakıp açarak iki ayrı ölçüm alın.

Bulut sağlayıcısının kurallarına da bakın. AWS, kendi altyapısındaki kaynaklara yönelik yük testini ön onay olmadan yapılabilir kabul ediyor, ancak EC2 üzerinden hacimsel DDoS simülasyonunu açıkça yasaklıyor ve bunu ayrı bir politikaya bağlıyor; ayrıca trafik belirli hacimleri aştığında (bölgeye ve ağ yoluna göre 25 Gbps civarından başlayarak) trafik şekillendirmesi uygulayabileceğini belirtiyor. Kısacası yük testi bir DDoS simülasyonu değildir ve öyle davranmamalıdır; ikisinin farkı için DDoS koruması yazımıza bakabilirsiniz. Aynı nezaket üçüncü taraflar için de geçerli: ödeme sağlayıcınızın, SMS servisinizin ve kargo API'nizin üretim uçlarına yük bindirmeyin, sandbox kullanın veya sahte servis koyun. Üretim verisinin kopyasıyla test edecekseniz kişisel verileri maskeleyin.

Kampanya günü bir planla girilir

Ticketmaster'ın 15 Kasım 2022'deki Taylor Swift ön satışında sisteme 3,5 milyar istek geldiğini ve bunun önceki zirvesinin dört katı olduğunu açıkladı. Ölçek çoğumuz için uzak, ders yakın: yeterince büyük bir zirvede soru "kaç sunucu ekleyelim" değil, "hangi işlevi geçici olarak feda ederiz ve sırayı nasıl yönetiriz" sorusudur.

Kampanya öncesi şunlar yazılı olsun: o gün panoları kim izliyor, hangi eşikte kim karar veriyor, hangi özellik hangi sırayla kapatılıyor, geri dönüş adımı ne. Kampanya haftasında dağıtımları dondurun; zirve gününde çıkan sürüm, sorunun kaynağını bulmayı imkansız hale getirir. Kesintisiz yayın akışını kurmadıysanız sıfır kesintili dağıtım yazımız işe yarar.

Bir haftada yapılabilecek beş adım

1. Son on iki ayın en yoğun saatini bulun, oturumları istek/saniyeye çevirin ve hedefi bunun 2-3 katı olarak belirleyin.
2. En kritik iki akış için senaryo yazın: arama ve ürün görüntüleme, bir de sepet ve ödeme. Veriyi dosyadan çeşitlendirin, düşünme süresi ekleyin.
3. Duman testi, ortalama yük testi ve kırılma noktası testini bu sırayla çalıştırın. Kırılma anındaki istek/saniye değerini yazın.
4. Kırılmanın hangi kaynakta olduğunu bulun (bağlantı havuzu, CPU, dış servis, kilit) ve tek seferde tek bir limiti değiştirip testi tekrarlayın.
5. Kampanya günü için eşik-aksiyon tablosu hazırlayın: hangi metrik hangi değere gelince hangi düğmeye basılacak.

Elinizde bir kampanya tarihi var ve sistemin o yükü kaldırıp kaldırmayacağını bilmiyorsanız, mevcut mimariye bakıp gerçekçi bir senaryo kurabilir, kırılma noktasını ölçüp o tarihe kadar kapatılabilecek açıkları önceliklendirebiliriz.