K6 ve JMeter için yük testleri için proxy

Yük testi rate-limit, WAF veya coğrafi dengeleme ile sınırlı kaldığında, ilk düşünce "farklı IP'lerden trafik başlatacağım" olur. Mantıklı geliyor, ancak pratikte k6 ve JMeter'daki proxy'ler dar bir görev setini çözer, geri kalanını yine test mimarisi ile düzeltmek zorunda kalırsınız. Bu yazıda, her iki araca proxy'yi teknik olarak nasıl bağlayacağımızı, hangi IP türlerinin uygun olduğunu ve proxy sunucusunun sorumluluk alanının nerede sona erdiğini inceleyeceğiz.

Yük testine neden farklı IP'ler gerekir

Varsayılan olarak k6 ve JMeter, tüm trafiği tek bir IP adresinden gönderir — testi çalıştırdığınız sunucu (veya CI/CD'deki bulut makinesi). Bu, senaryoların %90'ı için normaldir, ancak bazı durumlarda tek bir IP yeterli değildir:

IP düzeyinde rate-limiting. Birçok API ve dengeleyici (nginx limit_req, AWS WAF, Cloudflare) bir adresten saniyede gelen istek sayısını sınırlar. Gerçek kullanıcılar binlerce farklı IP'den gelirken, testiniz tek bir IP ile sınırlı kalır ve gerçek uygulama darboğazına ulaşmadan önce limitlere takılır.
Coğrafi bağımlı mantığın test edilmesi. CDN, hedeflenmiş içerik, bölgesel fiyatlar, coğrafi engellemeler — bunların hepsi belirli ülkelerden gelen IP'lerle test edilmelidir, veri merkezinden değil, test koşucunuzun fiziksel olarak bulunduğu yerden.
Dengeleyici ve anycast ağı kontrolü. Eğer altyapı trafiği IP'ye göre bölgelere dağıtıyorsa, tek bir adresten yapılan test sadece bir rotayı kontrol eder, tüm ağı değil.
Gerçek trafik dağılımının simülasyonu. Üretim trafiği IP'leri sağlayıcılara, alt ağlara ve bazen mobil operatörlere göre dağıtılmıştır — bu, CDN, önbellekler ve edge mantığının davranışını etkiler.

Hemen belirtmek önemlidir: eğer arka uç performansını test ediyorsanız (API'nizin ne kadar RPS dayanabileceği), proxy'ler neredeyse hiç gerekli değildir — burada önemli olan saf yük, kaynak çeşitliliği değil. Proxy'ler, test senaryonuzun gerçekten istemci IP adresine bağlı olduğu durumlarda gereklidir.

Hangi proxy'ler uygundur: veri merkezi, konut, mobil

Proxy türünün seçimi, neyi test ettiğinizi doğrudan etkiler — altyapının bant genişliğini mi yoksa "canlı" IP'ler altındaki sistem davranışını mı.

Proxy Türü	Gecikme ve Hız	Yük testlerinde ne zaman kullanılmalı
Veri Merkezi Proxy'leri	Düşük gecikme, yüksek bant genişliği	Rate-limit kontrolü, "IP'den N istek" limitinin aşılması, farklı alt ağlardan büyük RPS hacmi oluşturma
Konut Proxy'leri	Gecikme daha yüksek, hız gerçek kullanıcının bağlantısı ile sınırlı	Coğrafi mantık testi, CDN ve anti-bot sistemlerinin kontrolü, konut aralıklarına veri merkezi kadar güven duyulması
Mobil Proxy'ler	En yüksek gecikme, kararsız hız	Niş senaryolar: mobil API testi, IP'nin sık değişimi durumunda davranış (operatörler istemci adresini dinamik olarak değiştirir)

Saf RPS ve rate-limit kontrolü için genellikle veri merkezi proxy'leri yeterlidir — bunlar kararlı düşük gecikme sağlar ve test sonuçlarını dışsal ağ kararsızlığı ile çarpıtmaz. Konut ve mobil IP'ler, coğrafi testlerde gerçekçilik katarken, analiz metriklerinde dikkate alınması gereken kendi gecikmelerini de getirir — aksi takdirde "proxy ağı yavaşlatıyor" ile "sunucunuz yavaşlatıyor" karıştırılabilir.

k6'da proxy ayarlama

k6, JavaScript tabanlı bir araçtır (motoru Go'da yazılmıştır, betikler JS ile yazılır) ve varsayılan olarak HTTP proxy desteği yoktur: k6'da proxy, ortam değişkenleri veya sistem ayarları aracılığıyla ayarlanır, çünkü k6'nın altında Go HTTP istemcisi kullanılır.

En basit yol, ortam değişkenleridir:

export HTTP_PROXY="http://login:password@proxy-host:port"
export HTTPS_PROXY="http://login:password@proxy-host:port"

k6 run script.js

Bu yöntem, testin tüm trafiğini tek bir proxy üzerinden yönlendirecektir — "beyaz" IP sunucusundan çıkmak istiyorsanız uygundur. Ancak, sanal kullanıcıları (VU) farklı IP'ler arasında dağıtmak gerekiyorsa, bir proxy listesine ve betik düzeyinde seçim mantığına ihtiyacınız vardır. k6, doğrudan per-VU proxy'yi "kutudan çıkar çıkmaz" desteklemez, bu nedenle yaygın bir çözüm yolu, her biri kendi ortam değişkeni ve kendi proxy'si ile birkaç k6 sürecini paralel olarak çalıştırmaktır:

// run-with-proxies.sh
PROXIES=("proxy1:port" "proxy2:port" "proxy3:port")

for proxy in "${PROXIES[@]}"; do
  HTTP_PROXY="http://user:pass@$proxy" \
  HTTPS_PROXY="http://user:pass@$proxy" \
  k6 run --vus 50 --duration 5m script.js &
done
wait

Bu yaklaşım, k6 Cloud ile veya Kubernetes/Docker Compose aracılığıyla orkestrasyon ile iyi ölçeklenir — her konteyner kendi proxy değişkeni ile başlatılır. Tek bir betik çalıştırması içinde IP döngüsü gerekiyorsa, mantıklı olan, proxy sağlayıcısının kendisinde döngüye sahip proxy almak (TTL ile yapışkan oturum) ve JS kodu içinde döngü oluşturmaktan kaçınmaktır.

JMeter'da proxy ayarlama

JMeter'da proxy, ortam değişkenleri olmadan, HTTP Request Defaults öğesi veya doğrudan HTTP Request Sampler ayarları aracılığıyla yerel olarak ayarlanır:

Thread Group'a HTTP Request Defaults yapılandırma öğesini ekleyin.
Proxy Server alanında proxy'nin ana bilgisayarını ve portunu belirtin.
Proxy kimlik doğrulaması gerekiyorsa — bu ana bilgisayar için kullanıcı adı ve şifre ile HTTP Authorization Manager öğesini ekleyin.
Thread Group içindeki tüm HTTP Request Sampler'lar otomatik olarak proxy ayarlarını devralır.

JMeter'da birden fazla proxy arasında yük dağıtmak için CSV Data Set Config kullanmak oldukça uygundur — proxy listesinin bulunduğu bir dosya, her akış için ana bilgisayar ve port değişkenlerine yerleştirilir:

proxy_host,proxy_port,proxy_user,proxy_pass
proxy1.example.com,8000,user1,pass1
proxy2.example.com,8000,user2,pass2
proxy3.example.com,8000,user3,pass3

CSV Data Set Config'i Thread Group'a bağlayın, ${proxy_host} ve ${proxy_port} değişkenlerini Proxy Server/Proxy Port alanlarında belirtin — her JMeter akışı dosyadan kendi satırını alacak ve kendi IP'si üzerinden gidecektir. Komut satırından çalıştırmak için (headless mod, gerçek yük testleri için önerilir) proxy'yi ayrıca bayraklarla iletebilirsiniz:

jmeter -n -t test_plan.jmx -l results.jtl \
  -H proxy-host -P port \
  -u username -a password

Bu yöntem, tüm test için tek bir ortak proxy belirler — çoklu proxy senaryoları için yine CSV Data Set Config veya Dağıtılmış Test (her biri kendi proxy'sine sahip birkaç JMeter köleniz) kullanmanız gerekecektir.

IP döngüsü ve yük dağılımı

Yük testinde IP dağıtımına dair iki temel yaklaşım vardır:

Akışa/VU'ya statik IP atama. Her sanal kullanıcı, oturum boyunca aynı IP'yi alır — bu, tek bir adresle gerçek bir kullanıcıyı simüle eder. Yapışkan oturum proxy'si veya sadece CSV/değişkenlerde sabit bir liste ile ayarlanır.
Her istek için IP döngüsü. Proxy, her HTTP isteği için çıkış adresini değiştirir — bu, rate-limit korumasını test etmek için yararlıdır, ancak IP'si her saniye değişmeyen kullanıcıların gerçek davranışını yansıtmaz.

Gerçekçi bir yük testi için %90 durumda, IP'yi VU/akışa oturum boyunca atamak daha doğrudur — bu, testi bağımsız kullanıcıların davranışını doğru bir şekilde yansıtır, yapay gürültü yaratmaz. Her istekte döngüye almak yalnızca dar senaryolar için mantıklıdır — örneğin, rate-limit kuralının tetiklenmesini hedefleyen bir kontrol sırasında.

Proxy'nin kesinlikle değiştiremeyeceği şeyler

Burada makalenin ana noktası: proxy, "isteğin hangi IP'den geldiği" sorununu çözer, ancak yük testinin gerçekten kontrol ettiği sorunları çözmez.

Test koşucunuzun bant genişliği. Eğer yük oluşturucu (k6/JMeter ile makine) CPU, bellek veya ağ kartında sınırlı kalıyorsa — proxy bunu düzeltmez. Proxy, ek bir ağ atlaması ve kendi gecikmesini ekler, koşucudan yükü almaz.
Test edilen sunucunun gerçek bant genişliği. Sunucu ya yükü kaldırır ya da kaldırmaz — istemci IP adresi bunun üzerinde etki etmez, yalnızca açık rate-limit durumları dışında.
Yanıt süreleri için metriklerin güvenilirliği. Proxy, kendi gecikmesini (özellikle konut ve mobil) ekler, bu da raporlarınıza yanıt süresinin bir parçası olarak yansır. Proxy'nin gecikmesini ayrı olarak çıkarmazsanız, nihai gecikme raporu çarpıtılır ve üretim metrikleri ile karşılaştırmak için uygun olmaz.
Gerçek trafik altında altyapının ölçeklenmesi. Proxy ile yapılan yük testi, belirli bir istek desenine göre davranışı gösterir, ancak gerçek üretim günlüklerine dayalı kapasite planlaması, otomatik ölçekleme ve yük profilleri yerine geçmez.
Yük altında iş mantığının doğruluğunu kontrol etme. Yarış koşulları, veritabanında kilitlenmeler, kuyrukların bozulması — bunlar eşzamanlılık testleri ve profil oluşturma ile bulunur, çıkış IP'sinin değiştirilmesi ile değil.

Proxy, "farklı IP'lerden trafik emüle etmek" için özel bir araçtır, yük testini evrensel olarak güçlendiren bir araç değildir. Amaç, arka ucun ne kadar RPS dayanabileceğini anlamaksa, çoğu durumda proxy'lere ihtiyaç yoktur: doğru ayarlanmış keep-alive ve bağlantı havuzuyla birkaç test koşucusu yeterlidir.

Proxy üzerinden test yaparken yaygın hatalar

Pratikte, yük testlerinde proxy ile ilgili çoğu sorun birkaç tekrarlayan hataya indirgenir.

Proxy gecikmesini test edilen hizmetin gecikmesi ile karıştırmak. Temel ölçüm olmadan (proxy olmadan doğrudan istek) proxy sunucusunun ne kadar milisaniye eklediğini anlamak mümkün değildir.
Temiz bant genişliği gereken yerlerde mobil veya konut proxy'leri kullanmak. Bu tür proxy'ler, son cihazın gerçek bağlantısı ile sınırlıdır ve fiziksel olarak on binlerce RPS'yi kaldırmaz — saf yük için veri merkezi proxy'leri gereklidir.
Büyük sayıda VU için yetersiz IP havuzu. Eğer 5000 sanal kullanıcı için 10 proxy adresi varsa, test yine aynı rate-limit'e takılacaktır, sadece gecikme ile — hizmet hızlı bir şekilde "10 IP, binlerce istek" desenini görecektir.
Proxy tarafında zaman aşımını göz ardı etmek. Yüksek rekabetçi yük altında, proxy sunucusu bağlantıları reddetmeye başlayabilir — önceden proxy sağlayıcısının eşzamanlı oturum limitlerini kontrol etmek önemlidir.
Whitelisting/kimlik doğrulama kontrolü olmadan testi başlatmak. Eğer proxy IP üzerinden kimlik doğrulaması gerektiriyorsa ve test CI/CD'den dinamik bir koşucudan başlatılıyorsa — istekler 407 Proxy Authentication Required hatası ile düşecektir ve test sonuçları anlamsız olacaktır.

Testi başlatmadan önce kontrol listesi

Gerçekten görevin farklı IP'lere ihtiyaç duyup duymadığını veya tek bir adresle testin yeterli olup olmadığını belirlediniz.
Göreve uygun proxy türünü seçtiniz: RPS ve rate-limit için veri merkezi, coğrafi mantık için konut/mobil.
Proxy olmadan temel ölçüm yaptınız, böylece ağ gecikmesini proxy gecikmesinden ayırdınız.
Gerekli VU seviyesine göre proxy sağlayıcısındaki eşzamanlı bağlantı limitlerini kontrol ettiniz.
Proxy kimlik doğrulamasını ayarladınız (koşucunun IP'si için kullanıcı adı/şifre veya whitelisting).
VU için yapışkan oturumun gerekli olup olmadığını veya her istek için döngüye almanın gerekip gerekmediğini belirlediniz.
Yapılandırmayı kontrol etmek için tam geçişten önce kısa bir süre (1-2 dakika) test başlattınız.

Sonuç

k6 ve JMeter'da proxy, farklı IP adreslerinden trafik emüle etmek, rate-limit ve coğrafi bağımlı mantığın davranışını kontrol etmek için etkili bir yöntemdir. Ancak, bu, yük testinin akıllıca planlanmasının yerini almaz: sunucunun bant genişliği, rekabetçi yük altında arka ucun kararlılığı ve gerçek kapasite planlaması proxy ile kontrol edilmez ve iyileştirilmez. Bunları, testin gerçekten istemci IP adresine bağlı olduğu yerlerde kullanın, evrensel bir "dürüstlük" aracı olarak değil.

Eğer amaç, IP'ye göre limitleri kontrol etmek ve yüksek bant genişliği ile kitlesel trafiği simüle etmekse, veri merkezi proxy'leri ile başlamak mantıklıdır — bunlar minimum gecikme sağlar ve çok sayıda eşzamanlı oturumu kaldırır. Coğrafi mantık ve anti-bot sistemlerinin trafik kaynağına güvenini gerektiren testler için konut proxy'leri daha uygun olacaktır, mobil trafik ile niş senaryolar için ise mobil IP'ler tercih edilmelidir.