Proxy untuk pengujian beban di k6 dan JMeter

Ketika pengujian beban terhambat oleh rate-limit, WAF, atau penyeimbangan geografis, pemikiran pertama adalah "saya akan menjalankan lalu lintas dari berbagai IP". Terdengar logis, tetapi dalam praktiknya, proxy di k6 dan JMeter hanya menyelesaikan seperangkat tugas yang sempit, dan sisanya tetap harus diperbaiki melalui arsitektur pengujian. Dalam artikel ini, kita akan membahas bagaimana cara teknis menghubungkan proxy ke kedua alat ini, jenis IP apa yang cocok untuk ini, dan di mana batas tanggung jawab server proxy berakhir.

Mengapa pengujian beban memerlukan berbagai IP

Secara default, k6 dan JMeter mengirimkan semua lalu lintas dari satu alamat IP — server tempat pengujian dijalankan (atau mesin cloud dalam CI/CD). Ini normal untuk 90% skenario, tetapi dalam beberapa kasus, satu IP tidak cukup:

Rate-limiting pada tingkat IP. Banyak API dan penyeimbang (nginx limit_req, AWS WAF, Cloudflare) membatasi jumlah permintaan dari satu alamat per detik. Pengguna nyata datang dari ribuan IP yang berbeda, sedangkan pengujian Anda hanya dari satu — dan terhambat oleh batas sebelum mencapai bottleneck nyata aplikasi.
Pengujian logika yang bergantung pada geo. CDN, konten yang ditargetkan, harga regional, geo-blocking — semua ini perlu diuji dengan IP dari negara tertentu, bukan dari pusat data tempat pengujian Anda berada secara fisik.
Pemeriksaan penyeimbang dan jaringan anycast. Jika infrastruktur mendistribusikan lalu lintas berdasarkan IP klien, pengujian dari satu alamat hanya akan memeriksa satu rute, bukan seluruh jaringan.
Simulasi distribusi lalu lintas yang nyata. Lalu lintas produksi memiliki IP yang tersebar di antara penyedia, subnet, dan terkadang operator seluler — ini mempengaruhi perilaku CDN, cache, dan logika edge.

Penting untuk segera membedakan: jika Anda menguji kinerja backend (berapa banyak RPS yang dapat ditangani API Anda), proxy hampir tidak pernah diperlukan — di sana yang penting adalah beban bersih, bukan keragaman sumber. Proxy diperlukan ketika skenario pengujian bergantung pada alamat IP klien.

Jenis proxy yang cocok: datacenter, residential, mobile

Pemilihan jenis proxy secara langsung mempengaruhi apa yang Anda uji — kapasitas infrastruktur atau perilaku sistem di bawah IP "hidup".

Jenis Proxy	Keterlambatan dan Kecepatan	Kapan digunakan dalam pengujian beban
Proxy Data Center	Keterlambatan rendah, kapasitas tinggi	Pemeriksaan rate-limit, menghindari batas "N permintaan dari IP", menghasilkan volume RPS besar dari subnet yang berbeda
Proxy Residensial	Keterlambatan lebih tinggi, kecepatan dibatasi oleh saluran pengguna nyata	Pengujian logika geo, pemeriksaan CDN dan sistem anti-bot yang lebih mempercayai rentang residensial dibandingkan data center
Proxy Seluler	Keterlambatan tertinggi, kecepatan tidak stabil	Skenario niche: pengujian API seluler, perilaku saat sering mengganti IP (operator mengubah alamat klien secara dinamis)

Untuk pemeriksaan RPS dan rate-limit yang bersih, hampir selalu cukup dengan proxy data center — mereka memberikan keterlambatan rendah yang stabil dan tidak mendistorsi hasil pengujian dengan ketidakstabilan jaringan eksternal. IP residensial dan seluler menambah realisme dalam pengujian geo, tetapi juga menambah keterlambatan sendiri yang harus diperhitungkan saat menganalisis metrik — jika tidak, mudah untuk membingungkan "jaringan proxy yang lambat" dengan "server Anda yang lambat".

Pengaturan proxy di k6

k6 adalah alat berbasis JavaScript (mesin ditulis dalam Go, skrip ditulis dalam JS), dan secara default tidak ada dukungan bawaan untuk HTTP proxy melalui opsi skrip: proxy di k6 ditentukan melalui variabel lingkungan atau pengaturan sistem, karena di balik layar k6 menggunakan klien HTTP Go.

Cara paling sederhana adalah menggunakan variabel lingkungan:

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

k6 run script.js

Cara ini akan mengarahkan semua lalu lintas pengujian melalui satu proxy — cocok jika Anda hanya perlu keluar dari IP "putih" server. Tetapi jika tujuannya adalah mendistribusikan pengguna virtual (VU) ke berbagai IP, Anda memerlukan daftar proxy dan logika pemilihan di tingkat skrip. Secara langsung, k6 tidak mendukung proxy per-VU "secara default", jadi cara umum untuk mengatasinya adalah menjalankan beberapa proses k6 secara paralel, masing-masing dengan variabel lingkungan dan proxy sendiri dari kumpulan:

// 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

Pendekatan ini sangat skalabel dalam kombinasi dengan k6 Cloud atau orkestrasi melalui Kubernetes/Docker Compose — setiap kontainer diangkat dengan variabel proxy-nya sendiri. Jika rotasi IP diperlukan dalam satu kali menjalankan skrip, lebih logis untuk mengambil proxy dengan rotasi dari penyedia proxy itu sendiri (sticky session dengan TTL), daripada membuat rotasi di dalam kode JS.

Pengaturan proxy di JMeter

Di JMeter, proxy diatur secara native, tanpa variabel lingkungan, melalui elemen HTTP Request Defaults atau langsung di pengaturan HTTP Request Sampler:

Tambahkan elemen konfigurasi HTTP Request Defaults ke dalam Thread Group.
Di kolom Proxy Server, masukkan host dan port proxy.
Jika proxy memerlukan otorisasi — tambahkan elemen HTTP Authorization Manager dengan login dan kata sandi untuk host ini.
Semua HTTP Request Samplers di dalam Thread Group secara otomatis akan mewarisi pengaturan proxy.

Untuk mendistribusikan beban ke beberapa proxy di JMeter, mudah untuk menggunakan CSV Data Set Config — file dengan daftar proxy dimasukkan ke dalam variabel host dan port untuk setiap thread:

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

Hubungkan CSV Data Set Config ke Thread Group, masukkan variabel ${proxy_host} dan ${proxy_port} di kolom Proxy Server/Proxy Port dari sampler — setiap thread JMeter akan mengambil barisnya sendiri dari file dan berjalan melalui IP-nya sendiri. Untuk menjalankan melalui command line (mode headless, yang disarankan untuk pengujian beban nyata) proxy juga dapat disampaikan melalui flag:

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

Cara ini menetapkan satu proxy umum untuk seluruh pengujian — untuk skenario multi-proxy, Anda tetap harus menggunakan CSV Data Set Config atau Distributed Testing (beberapa slave JMeter, masing-masing dengan proxy-nya sendiri dalam konfigurasi).

Rotasi IP dan distribusi beban

Ada dua pendekatan yang berbeda secara prinsip untuk distribusi IP dalam pengujian beban:

Pemantapan statis IP untuk thread/VU. Setiap pengguna virtual mendapatkan satu IP yang sama untuk seluruh sesi — meniru pengguna nyata dengan satu alamat. Diatur melalui proxy sticky-session atau hanya daftar tetap dalam CSV/variabel lingkungan.
Rotasi IP untuk setiap permintaan. Proxy mengubah alamat keluar untuk setiap permintaan HTTP — berguna untuk memeriksa perlindungan terhadap rate-limit, tetapi kurang mencerminkan perilaku nyata pengguna, yang IP-nya tidak berubah setiap detik.

Untuk pengujian beban yang realistis, dalam 90% kasus, lebih tepat untuk mengikat IP ke VU/thread untuk seluruh sesi — sehingga pengujian dengan jujur mencerminkan perilaku banyak pengguna independen, bukan menciptakan kebisingan buatan. Rotasi untuk setiap permintaan masuk akal hanya dalam skenario sempit — misalnya, saat memeriksa secara spesifik pemicu aturan rate-limit.

Apa yang tidak dapat digantikan oleh proxy

Di sini adalah poin kunci dari artikel ini: proxy menyelesaikan masalah "dari IP mana permintaan datang", tetapi tidak menyelesaikan masalah yang sebenarnya diuji oleh pengujian beban.

Kapasitas pengujian runner Anda. Jika generator beban (mesin dengan k6/JMeter itu sendiri) terhambat oleh CPU, memori, atau kartu jaringan — proxy tidak akan memperbaikinya. Proxy menambah hop jaringan tambahan dan keterlambatan mereka sendiri, bukan mengurangi beban dari runner.
Kapasitas nyata dari server yang diuji. Server baik dapat menangani beban atau tidak — alamat IP klien tidak mempengaruhi ini, kecuali dalam kasus jelas rate-limit berdasarkan IP.
Keandalan metrik waktu respons. Proxy menambah keterlambatan mereka sendiri (terutama residensial dan seluler), yang akan masuk ke laporan Anda sebagai bagian dari waktu respons. Jika tidak mengurangi keterlambatan proxy secara terpisah, laporan latency akhir akan terdistorsi dan tidak dapat dibandingkan dengan metrik produksi.
Skalabilitas infrastruktur untuk lalu lintas nyata. Pengujian beban dengan proxy menunjukkan perilaku di bawah pola permintaan tertentu, tetapi tidak menggantikan perencanaan kapasitas, auto-scaling, dan profil beban yang dibangun berdasarkan log produksi nyata.
Pemeriksaan keakuratan logika bisnis di bawah beban. Kondisi balapan, penguncian di DB, penurunan antrean — ini berada di bawah pengujian kompetisi dan profiling, bukan dengan mengganti IP keluar.

Proxy adalah alat untuk tugas spesifik "mensimulasikan lalu lintas dari berbagai IP", bukan penguat universal untuk pengujian beban. Jika tujuannya adalah untuk memahami berapa banyak RPS yang dapat ditangani backend, proxy dalam banyak kasus tidak diperlukan sama sekali: cukup dengan beberapa runner pengujian tanpa proxy, dengan pengaturan keep-alive yang benar dan kumpulan koneksi.

Kesalahan umum saat pengujian melalui proxy

Dalam praktiknya, sebagian besar masalah dengan proxy dalam pengujian beban berkisar pada beberapa kesalahan yang berulang.

Mencampurkan keterlambatan proxy dengan keterlambatan layanan yang diuji. Tanpa pengukuran baseline (permintaan langsung tanpa proxy) tidak mungkin untuk memahami berapa milidetik yang ditambahkan oleh server proxy itu sendiri.
Penggunaan proxy seluler atau residensial di tempat yang memerlukan kapasitas bersih. Proxy semacam itu dibatasi oleh saluran nyata dari perangkat akhir dan secara fisik tidak dapat menangani puluhan ribu RPS — untuk beban bersih, diperlukan proxy data center.
Jumlah IP yang tidak mencukupi untuk banyak VU. Jika 5000 pengguna virtual hanya memiliki 10 alamat proxy, pengujian tetap akan terhambat oleh rate-limit yang sama, hanya dengan keterlambatan — layanan akan cepat melihat pola "10 IP, ribuan permintaan".
Mengabaikan timeout di sisi proxy. Dengan beban kompetitif yang tinggi, server proxy dapat mulai menolak koneksi — penting untuk mengonfirmasi batas sesi bersamaan sebelumnya dengan penyedia proxy.
Menjalankan pengujian tanpa memeriksa whitelisting/otorisasi. Jika proxy memerlukan otorisasi berdasarkan IP, dan pengujian dijalankan dari CI/CD dengan alamat runner yang dinamis — permintaan akan gagal dengan 407 Proxy Authentication Required, dan hasil pengujian akan menjadi tidak berarti.

Daftar periksa sebelum menjalankan tes

Menentukan apakah tugas benar-benar memerlukan berbagai IP, atau cukup dengan pengujian dari satu alamat.
Memilih jenis proxy sesuai dengan tugas: data center untuk RPS dan rate-limit, residensial/mobile untuk logika geo.
Melakukan pengukuran baseline tanpa proxy, untuk memisahkan keterlambatan jaringan dari keterlambatan proxy.
Memeriksa batas koneksi bersamaan dengan penyedia proxy untuk tingkat VU yang diperlukan.
Mengatur otorisasi proxy (login/kata sandi atau whitelisting IP runner).
Menentukan apakah sticky session diperlukan pada VU atau rotasi untuk setiap permintaan.
Menjalankan tes dalam interval pendek (1-2 menit) sebelum menjalankan penuh, untuk memeriksa konfigurasi.

Kesimpulan

Proxy di k6 dan JMeter adalah cara yang efektif untuk mensimulasikan lalu lintas dari berbagai alamat IP, memeriksa perilaku rate-limit dan logika yang bergantung pada geo. Namun, ini bukan pengganti perencanaan pengujian beban yang cerdas: kapasitas server, stabilitas backend di bawah beban kompetitif, dan perencanaan kapasitas nyata tidak diuji dan tidak ditingkatkan oleh proxy. Gunakan mereka secara selektif — di mana pengujian benar-benar bergantung pada alamat IP klien, bukan sebagai alat universal "untuk kejujuran".

Jika tugasnya adalah untuk memeriksa batas berdasarkan IP dan mensimulasikan lalu lintas massal dengan kapasitas tinggi, masuk akal untuk memulai dengan proxy data center — mereka memberikan keterlambatan minimal dan dapat menangani banyak sesi bersamaan. Untuk pengujian yang terkait dengan logika geo dan kepercayaan sistem anti-bot terhadap asal lalu lintas, proxy residensial lebih cocok, dan untuk skenario niche dengan lalu lintas seluler — IP seluler.