Belajar Cloud Engineer - Performance & Load Testing

#Pendahuluan

Sejak episode 3 kalian membangun infrastruktur, dan di episode 21 membuatnya bisa auto-scaling. Tapi ada satu hal yang belum pernah kita buktikan: berapa besar beban yang bisa ditahan infrastruktur kalian, dan di titik mana ia mulai melambat? Tanpa angka ini, setiap keputusan scaling hanyalah tebakan — dan "aplikasi lambat" di produksi selalu mahal untuk diperbaiki.

Episode 25 membahas performance & load testing di cloud: mendesain skenario beban yang realistis, membaca bottleneck dari hasil test, performance tuning, dan observability lanjutan untuk melacak latency end-to-end. Kalian akan melakukan benchmark workload — dari k6, JMeter, hingga beban nyata — dan menafsirkan hasilnya seperti engineer produksi.

#Mengapa Load Testing Itu Disiplin, Bukan Selingan

Load testing menjawab tiga pertanyaan yang tidak bisa ditebak:

1. Kapasitas — berapa request per detik (RPS) yang bisa dilayani sebelum degradasi?
2. Titik patah — di beban berapa error rate melonjak dan latency meledak?
3. Perilaku scaling — apakah auto-scaling (episode 21) menambah kapasitas sebelum titik patah, atau sesudahnya?

Tanpa jawaban ini, "kita perkirakan cukup kuat" adalah pernyataan tanpa bukti. Dengan jawabannya, kalian bisa menyetel ASG, memilih ukuran instance (episode 16), dan memutuskan strategi caching dengan percaya diri.

#Konsep Dasar: RPS, Latency, dan Percentile

Tiga metrik inti yang wajib kalian fasih:

• Throughput (RPS) — berapa banyak request per detik.
• Latency — berapa lama satu request diproses.
• Percentile — p50 (median), p95, p99 — cara membaca distribusi latency.

P99 adalah metrik yang paling jujur: p99 2 detik berarti 1 dari 100 request terasa sangat lambat — dan itu user nyata yang mengeluh. Rata-rata (average) menyesatkan: 99 request 100 ms + 1 request 10 detik = rata-rata 200 ms yang tampak sehat padahal 1% user mengalaminya sebagai bencana.

#Load Testing dengan k6

k6 adalah tool open-source modern untuk load testing, dengan skenario yang ditulis dalam JavaScript. Instal dan tulis test:

curl -s https://deb.k6.io/key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/k6-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://deb.k6.io/ stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update && sudo apt-get install k6

import http from "k6/http";
import { check, sleep } from "k6";
 
export const options = {
  stages: [
    { duration: "2m", target: 50 },   // ramping naik ke 50 VU
    { duration: "5m", target: 100 },  // beban normal 100 VU
    { duration: "3m", target: 300 },  // uji lonjakan
    { duration: "2m", target: 0 },    // turunkan beban
  ],
};
 
export default function () {
  const res = http.get("https://lab.example.com/api/products");
  check(res, {
    "status 200": (r) => r.status === 200,
    "p95 latency ok": (r) => r.timings.duration < 500,
  });
  sleep(1);
}

k6 run loadtest.js

Outputnya memberi ringkasan lengkap: RPS yang tercapai, distribusi latency, dan berapa banyak check yang lolos. Ini data pertama kalian.

#Membaca Hasil: Menemukan Bottleneck

Test selesai, RPS tercatat — sekarang bagian paling penting: di mana bottleneck-nya? Proses debug yang sistematis:

1. Lihat metrik aplikasi (episode 9): error rate, latency, dan throughput per service.
2. Cek CPU/memory instance dan database: siapa yang jenuh lebih dulu?
3. Periksa antrian (episode 13): queue depth naik? Pesan menumpuk berarti konsumen lambat.
4. Periksa jaringan: ss, koneksi tak terpakai, atau bandwidth jenuh.

Bottleneck umum di cloud dan arah perbaikannya:

Kunci membaca hasil: selalu gabungkan metrik. Satu metrik saja tidak pernah cukup — CPU 100% di instance bisa berarti aplikasi lambat atau auto-scaling terlambat menambah instance. Cerita lengkap hanya muncul dari gabungan metrik aplikasi, instance, dan database.

#Performance Tuning Dasar

Setelah bottleneck ditemukan, tuning yang umum (dari yang termurah):

1. Cache — response yang sama tidak perlu dihitung ulang: CDN untuk statis (episode 18, 24), cache aplikasi untuk yang dinamis.
2. Query database — index yang tepat, hindari SELECT *, baca dari read replica.
3. Connection pooling — koneksi DB dibuka sekali dan dipakai ulang, bukan per request.
4. Ukuran instance yang tepat — episode 16: right-sizing, bukan sekadar "perbesar".
5. Asynchronous processing — pekerjaan lambat dipindah ke queue (episode 13), API merespons cepat.

Aturannya: tuning tanpa pengukuran ulang adalah tebakan — setiap perubahan diuji load-test-nya lagi dan dibandingkan.

#Observability Lanjutan: Melacak Latency End-to-End

Untuk sistem yang terdiri dari banyak service (episode 12, 13), kita butuh distributed tracing — melacak satu request melewati banyak service. Di episode 9 kita menyebut trace sebagai pilar observability; sekarang saatnya memakai.

• OpenTelemetry — standar terbuka: SDK di aplikasi mengirim trace, collector merutekannya.
• Backend: Grafana Tempo, Jaeger, atau layanan managed provider (X-Ray, Cloud Trace, App Insights).
• Penggunaan: lihat request yang lambat, lihat di mana waktunya hilang — service mana yang paling lama.

GET /checkout      total: 1200ms
  └── gateway        :   30ms
  └── cart-svc       :   80ms
  └── inventory-svc  :  900ms   ← bottleneck!
  └── payment-svc    :  190ms

Dengan trace, kalian tidak lagi menebak — kalian tahu service mana yang menjadi biang keladi. Ini membedakan junior (melihat rata-rata) dari senior (melacak p99 end-to-end).

#Praktik: Benchmark Workload

Mari benchmark aplikasi lab-ecommerce secara menyeluruh:

1. Tulis skenario k6 dengan tahapan ramping seperti di atas.
2. Jalankan di staging, pantau metrik CloudWatch/Cloud Monitoring selama test (episode 9).
3. Catat hasil: RPS maksimal, p50/p95/p99, error rate, dan metrik instance/DB.
4. Temukan bottleneck — gabungkan semua metrik, tentukan titik jenuh pertama.
5. Terapkan satu tuning (cache/query/instance), jalankan test ulang, bandingkan angka.
6. Dokumentasikan: kapasitas aman, titik patah, dan rekomendasi sizing untuk produksi.

# Contoh catatan hasil benchmark
# 100 VU  : 420 RPS, p95 240ms, error 0.0%
# 300 VU  : 760 RPS, p95 980ms, error 0.4%  ← knee mulai di sini
# 500 VU  : 810 RPS, p95 3400ms, error 8.1% ← titik patah

Laporan benchmark yang baik berisi angka, bukan cerita: kapasitas aman, titik knee, titik patah, dan rekomendasi. Ini dokumen yang sama yang akan kalian tunjukkan saat diskusi kapasitas dengan tim — dan saat rapat auto-scaling berikutnya (episode 21).

#Kesalahan Umum (Common Pitfalls)

1. Menguji di produksi — mematikan layanan untuk pelanggan nyata; selalu staging/region terpisah.
2. Cuma satu skenario — beban nyata campur baur; kombinasi read-heavy dan write-heavy.
3. Hanya melihat rata-rata — p99 adalah metrik yang jujur; jangan puas dengan average.
4. Testing tanpa monitoring — hasil test tanpa metrik resource tidak bisa menunjuk bottleneck.
5. Tuning tanpa re-test — satu perubahan merusak hal lain; bandingkan selalu dengan baseline.
6. Melupakan trace — sistem multi-service tanpa distributed tracing = buta untuk menemukan penyebab.

#Penutup

Inti yang harus dibawa pulang:

• Load testing menjawab kapasitas, titik patah, dan perilaku scaling — bukan perkiraan.
• Metrik jujur: RPS, latency, percentile (p95/p99) — bukan average.
• k6 memberi skenario berbasis kode; hasilnya dibaca bersama metrik resource untuk menemukan bottleneck.
• Tuning = cache → query → pooling → sizing → async, selalu diukur ulang.
• Distributed tracing (OpenTelemetry) melacak latency end-to-end di sistem multi-service.

Di episode 26 selanjutnya kita akan berhenti sejenak dan melihat peta besar: ekosistem & tren modern 2026 — bagaimana cloud-native, IaC, FinOps, dan AI workloads membentuk lanskap industri, serta apa yang berubah bagi posisi cloud engineer. Sampai jumpa di episode 26!