Belajar Infrastructure Engineer - Performance & Capacity

#Pendahuluan

Setelah di episode 21 kita membuat sistem tahan gagal, kini kita memastikan sistem tidak lemah batuk saat dibebani: performance & capacity. Infrastruktur yang aman tapi lambat tetap gagal memenuhi harapan — dan infrastruktur tanpa kapasitas yang direncanakan adalah bom waktu yang meledak tepat saat traffic naik.

Mengapa topik ini penting? Karena performa dan kapasitas bukan tebakan — keduanya bisa diukur, dibandingkan, dan direncanakan. Episode ini membekali kalian metrik yang benar, benchmarking yang tidak menipu, proses tuning yang sistematis, dan capacity plan yang berbasis data.

#Metrik Performa yang Benar

#Metrik Komponen vs Metrik Pengalaman

Metrik server memberi tahu kondisi komponen; metrik pengalaman memberi tahu yang dirasakan user. Keduanya dibutuhkan:

Pilar metrik performa (dari USE dan RED method):

Utilization : seberapa penuh resource? (target < 70-80%)
Saturation  : berapa banyak yang mengantre? (target: mendekati nol)
Errors      : berapa banyak yang gagal? (target: nol)

Rate       : request per detik
Errors     : error per detik
Duration   : latency (p50, p95, p99)

#Jangan Pakai Average — Pakai Percentile

Rata-rata latency yang "enak" bisa menyembunyikan bencana: 99% request cepat, 1% sangat lambat. Percentile jauh lebih jujur:

p50 = 80 ms   → setengah user di bawah 80ms
p95 = 200 ms  → 5% user lebih lambat dari 200ms
p99 = 900 ms  → 1% user menunggu hampir 1 detik!

Jika kalian hanya melihat rata-rata, outlier p99 yang menyakitkan tidak terlihat. Selalu pantau p95/p99.

#Benchmarking yang Tidak Menipu

Benchmark berguna — jika dilakukan dengan benar. Kesalahan umum membuat hasil tak berarti:

1. Benchmark di mesin yang salah: hasil laptop tidak mewakili produksi.
2. Beban sintetis yang tidak mirip nyata: profil request buatan yang tidak realistis.
3. Lupa baseline: tidak mengukur "sebelum" jadi tidak tahu perubahan "sesudah".
4. Satu angka saja: latency tanpa throughput, throughput tanpa error rate.

#Alat Benchmark Dasar

sysbench cpu run
sysbench memory run
fio --name=test --ioengine=libaio --rw=randwrite --size=1G
iperf3 -c 10.0.1.10

Dan untuk HTTP/API:

docker run --rm -i grafana/k6 run - <<'EOF'
import http from 'k6/http'
 
export const options = {
  stages: [
    { duration: '1m', target: 50 },
    { duration: '2m', target: 200 },
    { duration: '1m', target: 0 },
  ],
}
 
export default function () {
  http.get('http://api.lab.local/healthz')
}
EOF

Perhatikan pola ramp-up bertahap (50 → 200 → turun): beban nyata tidak meledak seketika, dan ramp-up menemukan titik patah dengan lebih aman.

#Tuning yang Sistematis

Tuning bukan "coba-coba parameter". Proses yang benar:

1. Ukur baseline
2. Identifikasi bottleneck (lapisan mana yang pertama penuh)
3. Hipotesis perbaikan
4. Ubah satu variabel
5. Ukur ulang
6. Bandingkan → simpan jika membaik, rollback jika tidak
7. Dokumentasikan

#Contoh: Tuning Nginx

Bottleneck umum: worker terlalu sedikit → request mengantre; atau buffer terlalu kecil → respons patah.

worker_processes auto;
worker_connections 1024;
keepalive_timeout 30;
client_max_body_size 20m;

Uji: naikkan worker_connections, bandingkan p99, rollback jika tidak membantu.

#Contoh: Tuning Kernel

Parameter kernel memengaruhi seluruh host:

sysctl: parameter yang sering dituning

net.core.somaxconn              # antrean koneksi (naikkan untuk banyak koneksi)
net.ipv4.tcp_fin_timeout        # waktu socket menunggu (kecilkan untuk short connections)
vm.swappiness                   # kecenderungan swap (kecilkan untuk server DB)
fs.file-max                     # batas file descriptor

Terapkan sysctl

sudo sysctl -w vm.swappiness=10
sudo sysctl -p /etc/sysctl.conf

Selalu ukur sebelum/sesudah dan simpan perubahan di file (/etc/sysctl.conf) — bukan sysctl -w sementara yang hilang saat reboot.

#Capacity Planning

Capacity planning menjawab: berapa kapasitas yang dibutuhkan bulan depan, tahun depan — dan kapan harus menambah.

#Formula Dasar

Kebutuhan = (beban saat ini × proyeksi pertumbuhan) + buffer
Sisa waktu = kapasitas tersedia ÷ tingkat konsumsi per bulan

Contoh: disk terpakai 600 GB dari 1 TB, tumbuh 40 GB/bulan → habis dalam 10 bulan → tambah/tiering sebelum bulan ke-7 (dengan buffer 20-30%).

#Data yang Dibutuhkan

1. Konsumsi historis (minimal 12 bulan bila bisa).
2. Proyeksi pertumbuhan bisnis (user, traffic, data).
3. Pola musiman (bulan ramai, event tahunan).
4. SLA/target (berapa headroom yang dijamin).

#Menyusun Capacity Plan

1. Ringkasan eksekutif (apa yang akan habis dan kapan)
2. Data historis & proyeksi per sumber daya
   - Compute : CPU, memory per host/pool
   - Storage : kapasitas, IOPS
   - Network : bandwidth puncak
   - Lain    : IP, connection, license
3. Titik kritis (kapan tiap sumber daya habis)
4. Rencana aksi (tambahan kapasitas, optimasi, tiering)
5. Review berkala (jadwal, misal kuartalan)

Capacity plan bukan dokumen mati — ia di-review berkala dan diperbarui dari data nyata.

#Kapasitas di Cloud: Kanan vs Kiri

• Left (over-provision): beli banyak, aman, boros biaya.
• Right (under-provision): beli pas, hemat, berisiko saat spike.
• Cloud (elastic): scale otomatis (episode 21) — namun tetap butuh rencana maksimum dan prediksi biaya.

#Common Pitfalls Performance & Capacity

• Optimasi prematur: mengotak-atik parameter sebelum tahu bottleneck sebenarnya.
• Melihat rata-rata saja: p99 yang menyakitkan tersembunyi di balik rata-rata yang mulus.
• Benchmark di lingkungan yang tidak representatif: hasil tidak berlaku di produksi.
• Capacity plan tanpa review: dokumen setahun sekali yang tidak pernah dibaca.
• Tunggu penuh baru bertindak: mulai tambah kapasitas saat 80%, bukan 99%.
• Mengubah banyak parameter sekaligus: tidak tahu perubahan mana yang berhasil.

#Penutup

Pada episode 22 ini kalian telah menguasai performa & kapasitas:

• Metrik yang benar: USE (resource) dan RED (layanan), dengan percentile bukan average.
• Benchmarking: ramp-up bertahap, satu variabel sekali, dan lingkungan yang representatif.
• Tuning sistematis: ukur → hipotesis → ubah satu → ukur ulang → bandingkan.
• Capacity planning berbasis data: proyeksi pertumbuhan, titik kritis, dan review berkala.
• Tambah kapasitas di 80%, bukan menunggu penuh.

Di episode 23 selanjutnya kita masuk topik paling panas 2026: AI infrastructure — GPU clusters, workload AI, dan inference infra. Sampai jumpa di episode 23!