Belajar Cloud Architect - Performance Architecture

#Pendahuluan

Di episode 8 kita menetapkan SLO latency dan di episode 10 menjadikannya kontrak. Episode ini menjawab pertanyaan teknis: bagaimana memastikan arsitektur memenuhi janji performa itu? Performance bukan "semoga cepat" — ia keputusan desain yang bisa dihitung: latency budget, strategi caching, dan pengujian yang realistis.

Prinsip inti: performa diukur dari sudut pandang user, bukan dari server. Latensi yang kalian lihat di server internal adalah satu bagian dari perjalanan penuh. Episode ini membangun tiga kemampuan arsitektur: menghitung latency budget, merancang caching berlapis, dan mendesain performance testing.

#Latency Budget

#Perjalanan Satu Request

Dari klik user sampai jawaban kembali, request melewati banyak lapisan. Setiap lapisan memakan waktu:

#Menghitung Budget

Latency budget = total target (p99) dibagi per lapisan, dan harus menjumlah kembali ke target. Jika target p99 = 500ms:

User + DNS       : 100ms
Load balancer    :  50ms
Aplikasi (logic) : 100ms
Cache hit        :  30ms  (sebagian besar request)
Database hit     : 120ms  (saat cache miss)
Jaringan internal:  50ms  (buffer/headroom)
────────────────────────────────────────
Total            : 450ms (25% headroom untuk variabilitas)

Alasan buffer penting: target p99 artinya 99% request harus di bawah target. Variabilitas alami (GC, spike, cold start) memakan ruang — tanpa headroom, p99 pasti meleset.

#Keputusan dari Budget

Latency budget menjadi input keputusan arsitektur: jika budget database 120ms dan query-nya 80ms, sisa 40ms untuk jaringan — tapi jika query tiba-tiba 200ms, arsitektur harus menambahkan cache atau mengubah desain data (episode 5). Budget yang eksplisit membuat keputusan ini objektif.

#Strategi Caching

#Cache Berlapis

Caching adalah tool performa paling efektif, dan bekerja paling baik berlapis — setiap lapisan menyaring bagian request yang berbeda:

#Desain Cache yang Benar

• Cache untuk read-heavy, bukan write — data yang sering dibaca jarang berubah paling diuntungkan.
• TTL masuk akal — terlalu singkat tak berguna; terlalu panjang data basi.
• Invalidation terjadwal — saat data berubah, cache harus tahu (publish event, episode 12).
• Cache-aside vs write-through — pilih pola sesuai konsistensi yang dibutuhkan (episode 3).

#P99 dan P95: Kenapa Harus Persentil

Cache sangat memengaruhi persentil: p50 (median) turun drastis dengan cache, tapi p99 tetap tinggi jika request uncached lambat. Ukur p99 cache-hit vs cache-miss — jika miss jauh lebih lambat, user yang beruntung dapat cache cepat dan yang tidak dapat lambat; pengalaman tidak konsisten.

#Performance Testing Design

#Test yang Mencerminkan Beban Nyata

Performance testing bukan "kirim request sebanyak mungkin sampai patah". Desain yang benar meniru pola beban produksi:

#Alat dan Desain

• k6 (scriptable, modern), JMeter, atau Gatling untuk men-generate beban.
• Data produksi (anonymized) sebagai workload — data sintetik yang "bersih" menipu.
• Ukur persentil, bukan rata-rata (episode 10).
• Awasi semua lapisan: aplikasi, database, network, cache — bottleneck sering di database.

import http from 'k6/http'
 
export const options = {
  stages: [
    { duration: '1m', target: 50 },   // ramping naik
    { duration: '3m', target: 50 },   // beban stabil
    { duration: '1m', target: 0 },    // turun
  ],
}
 
export default function () {
  http.get('https://api.example.com/orders')
}

Test di atas mengukur perilaku pada beban bertahap — jauh lebih realistis daripada serangan 10.000 request instan.

#Performance Testing sebagai Kontrol CI

Jangan uji performa sekali sebelum rilis. Jadikan regression test: setiap perubahan kode berpotensi menurunkan performa. Bandingkan metrik dengan baseline — jika p99 naik melebihi ambang, pull request ditolak. Ini menyatukan performance dengan pipeline episode 11.

#Praktik: Arsitektur Performa Tinggi

Kerangka desain:

1. Tetapkan latency budget dari target p99, alokasikan per lapisan.
2. Rancang cache berlapis (CDN → in-memory → DB) untuk read-heavy.
3. Ukur cache hit rate & p99 per pola akses.
4. Desain performance testing dengan beban realistis (load/stress/soak/spike).
5. Jadikan performa regression test di pipeline CI.
6. Verifikasi dengan observability (episode 10) bahwa produksi memenuhi budget.

#Penutup

Inti yang harus dibawa pulang:

• Performance diukur dari sudut user; latency budget dihitung per lapisan.
• Sertakan headroom — target p99 butuh ruang untuk variabilitas.
• Cache berlapis paling efektif; waspadai cache stampede.
• Ukur persentil, bukan rata-rata.
• Performance testing dengan beban nyata, dan jadikan regression test di CI.

Di episode 22 selanjutnya kita akan membahas scalability patterns — scaling horizontal/vertikal, desain stateless, dan scaling database. Sampai jumpa di episode 22!