Belajar k6 - Distributed Load Testing & Cloud Execution

#Pendahuluan

Episode 16 mengubah k6 menjadi penjaga pipeline — setiap merge request dan release kini diuji performanya secara otomatis. Tapi ada batas yang belum kalian sentuh: berapa banyak beban yang bisa dibangkitkan satu mesin? Untuk smoke test dan load test kecil, jawabannya cukup. Untuk mensimulasikan traffic nasional di hari promo, satu binary k6 di sebuah runner tidak akan pernah cukup.

Episode 17 membuka pintu ke skala yang lebih besar: distributed load testing dan cloud execution. Kita akan mengenal k6 Cloud, cara kerja load zones, bagaimana ribuan instance diorkestrasi untuk membangkitkan ratusan ribu virtual users, serta alternatif self-managed memakai xk6 dan Kubernetes operator.

#Batas Local Execution

Sebelum bicara cloud, mari jujur soal kapasitas lokal. Satu proses k6 di satu mesin adalah mesin yang efisien — untuk skrip sederhana, puluhan ribu VU masih masuk akal di hardware yang layak. Tetapi ada empat pembatas yang tidak bisa ditembus hanya dengan menambah VU:

• CPU dan RAM mesin — setiap VU menjalankan JavaScript; skrip yang berat (parsing, kriptografi, banyak logika) memakan resource per VU.
• Bandwidth jaringan — beban request dibatasi kecepatan uplink dan downlink mesin.
• File descriptor dan port — ribuan koneksi bersamaan bertabrakan dengan batas sistem operasi.
• Perspektif geografis — semua request berasal dari satu lokasi, tidak mewakili pengguna di berbagai region.

Distribusi memecahkan semua pembatas ini sekaligus dengan membagi VU ke banyak mesin.

#Mengenal k6 Cloud

k6 Cloud adalah layanan managed dari Grafana Cloud yang menjalankan k6 secara terdistribusi. Yang menyenangkan: kalian tidak perlu menulis ulang skrip. Skrip yang sama yang kalian jalankan dengan k6 run script.js tinggal dialihkan ke cloud — semua konsep VU, scenarios, checks, dan thresholds tetap berlaku.

#k6 login cloud dan k6 cloud

Dua perintah mengalihkan kalian ke mode cloud:

k6 login cloud --token <token-k6-cloud>
 
k6 cloud script.js

k6 login cloud --token menyimpan credential di mesin kalian (token juga bisa diberikan lewat environment variable K6_CLOUD_TOKEN, cocok untuk CI). Selanjutnya, k6 cloud script.js mengunggah skrip beserta dependency-nya ke k6 Cloud, memulai test, dan mencetak URL halaman results yang menampilkan metrik secara real-time. Seluruh orchestration — membagi VU ke instance, menjalankan, menggabungkan metrik — ditangani cloud.

#Load Zones

Load zone adalah lokasi geografis tempat worker k6 berjalan. Dengan mengarahkan bagian traffic dari beberapa region, kalian mensimulasikan pengguna sebenarnya: 50% dari Jakarta tidak sama dengan 50% dari Frankfurt dalam hal latensi dan routing. Konfigurasi dilakukan lewat options.cloud di dalam skrip:

export const options = {
  scenarios: {
    flash_sale: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '5m', target: 5000 },
        { duration: '10m', target: 5000 },
        { duration: '5m', target: 0 },
      ],
    },
  },
  cloud: {
    name: 'Flash Sale - 10K VU',
    projectID: 123456,
    loadZones: [
      { name: 'ap-southeast-1', percent: 60 },
      { name: 'us-east-1', percent: 40 },
    ],
  },
};

Dengan loadZones, 60% VU dibangkitkan dari ap-southeast-1 dan 40% dari us-east-1. Perhatikan bahwa skenario tetap didefinisikan seperti biasa — cloud hanya menentukan dari mana VU itu datang.

#Skala: Dari Puluhan hingga Ratusan Ribu VU

Bagaimana k6 Cloud membangkitkan ratusan ribu VU? Jawabannya adalah orkestrasi: sebuah control plane membagi total VU menjadi banyak potongan, menugaskan tiap potongan ke sebuah worker instance cloud, menjalankan semua worker secara paralel, lalu menggabungkan hasilnya. Dari sisi kalian, peristiwa ini tampak seperti satu test; di belakang layar ia adalah sekumpulan instance yang disinkronkan.

Analoginya seperti penerbangan untuk ratusan penumpang: tidak ada satu pesawat yang bisa memuat semua orang, jadi kalian memecahnya menjadi banyak pesawat, semuanya terbang ke tujuan yang sama, dan tiba dalam satu kesimpulan. Worker adalah pesawatnya; k6 Cloud adalah pusat kendali lalu lintasnya.

#Observability Multi-Instance

Begitu beban tersebar, metrik juga tersebar. Praktik yang perlu kalian biasakan:

• Threshold tetap di dalam skrip. http_req_duration: ['p(95)<500'] dievaluasi terhadap metrik yang diagregasi dari seluruh worker — satu sumber kebenaran yang membuat test di cloud juga gagal atau berhasil secara otomatis.
• Pahami agregasi. Metrik Rate dan Trend dihitung ulang dari gabungan seluruh instance; definisikan custom metrics dengan jenis yang tepat agar agregasinya bermakna.
• Lihat breakdown per load zone. Halaman results k6 Cloud menampilkan metrik terpisah per region, sehingga kalian bisa melihat apakah keterlambatan berasal dari satu zona saja — informasi yang mustahil didapat dari test single-instance.
• Alirkan hasil ke sistem observability. Hasil cloud bisa dihubungkan dengan dashboard Grafana yang sudah kalian bangun di episode 14.

#Kapan Cloud dan Kapan Lokal

Distributed load testing bukan pengganti lokal — keduanya melayani kebutuhan berbeda:

Aturan praktis: mulailah lokal, naikkan ke cloud hanya ketika beban, geografi, atau kebutuhan berbagi hasil melebihi kapasitas mesin kalian. Test yang seharusnya 50 VU tidak perlu membayar worker cloud.

#Alternatif Self-Managed: xk6 dan Kubernetes Operator

k6 Cloud nyaman, tetapi sebagian tim membutuhkan kendali penuh — misalnya karena data harus tetap di infrastruktur sendiri. Untuk itu ada dua jalur self-managed:

• k6-operator. Proyek open-source dari Grafana yang memperkenalkan Custom Resource TestRun ke Kubernetes. Kalian mendeskripsikan test dan jumlah worker (parallelism), lalu operator membuat beberapa job k6 dan menyinkronkannya:

apiVersion: k6.io/v1alpha1
kind: TestRun
metadata:
  name: my-load-test
spec:
  parallelism: 4
  script:
    configMap:
      name: k6-scripts
      file: script.js

• Eksekusi segment manual. k6 mendukung pembagian VU secara eksplisit lewat flag --execution-segment dan --execution-segment-sequence. Kalian menjalankan beberapa instance secara paralel — misalnya lewat beberapa job CI atau pod — masing-masing memegang potongan VU yang berbeda, lalu menggabungkan metriknya ke backend yang sama (InfluxDB atau Prometheus). Fleksibel, tetapi kalian bertanggung jawab penuh atas sinkronisasi dan agregasi.

Pilihan antara managed dan self-managed adalah keputusan trade-off: k6 Cloud menghemat pekerjaan orkestrasi dan menyertakan observability, sementara k6-operator memberi kepemilikan penuh atas infrastruktur dengan tanggung jawab operasional di pihak kalian.

#Penutup

Episode 17 membawa k6 melewati batas mesin tunggal: dari batas local execution, mengenal k6 Cloud dengan k6 login cloud dan k6 cloud, memahami load zones dan orkestrasi ratusan ribu VU, praktik observability multi-instance, hingga dua jalur self-managed (k6-operator dan execution segment). Kalian kini tahu cara membangkitkan beban sebesar apa pun — dari 10 VU di laptop hingga ratusan ribu VU dari berbagai benua.

Semua perjalanan punya ujung. Di episode 18 — episode terakhir series ini — kita memantapkan production readiness: tooling stabil seperti k6 archive dan xk6, fitur-fitur yang siap dipakai di produksi, tren industri seperti performance budget dan shift-left testing, serta refleksi utuh perjalanan 19 episode Belajar k6. Sampai jumpa!