Modul 09Term 3 · Reliabilitas dan skala16 item poster

Performa dan Skalabilitas

Masuk untuk menyimpan progres Anda di semua perangkat. Sampai saat itu, progres disimpan di browser ini.

Mengapa ini penting

Dua kesalahan yang saling berlawanan sama-sama membunuh produk: merilis sesuatu yang tumbang di 100 pengguna, dan membangun berlebihan untuk sejuta pengguna yang belum Anda miliki. Modul ini mengajarkan Anda untuk mengukur dulu, lalu menerapkan perbaikan termurah, dalam urutan yang jelas.

Capaian pembelajaran

  1. Menemukan bottleneck dengan load test dan profiling, bukan dengan menebak.
  2. Menerapkan tangga skalabilitas dalam urutan yang benar.
  3. Melakukan caching dengan benar, termasuk invalidation.
  4. Memahami load balancer, reverse proxy, dan API gateway.
  5. Mengetahui batas serverless dan cold start.
  6. Mengendalikan biaya cloud dan AI sebagai metrik kelas utama.

Tangga skalabilitas (naik hanya setelah diukur)

  1. Perbaiki kodenya: index, N+1, pagination, ukuran payload (03 · Fondasi Data).
  2. Cache: CDN untuk konten statis, edge cache untuk konten dinamis publik, cache aplikasi untuk komputasi mahal.
  3. Pindahkan pekerjaan ke async (08 · Async, Event, dan Real-Time).
  4. Vertical scale (47): database/server yang lebih besar. Murah dari sisi waktu engineering; bisa membawa Anda lebih jauh dari yang dikira orang.
  5. Horizontal scale tier aplikasi stateless (46) di belakang load balancer, dengan autoscaling (45).
  6. Read replica (29) untuk beban yang dominan baca (terima adanya replication lag).
  7. Partisi (31) tabel besar (misalnya per bulan untuk event/log).
  8. Shard (30) hanya ketika satu database primary benar-benar tidak sanggup. Kebanyakan perusahaan tidak pernah membutuhkannya.

Materi

9.1 Caching (2, 48, 49, 50)

  • Lapisan: browser (Cache-Control), CDN untuk aset statis (48), edge caching untuk respons dinamis (49), cache aplikasi (Redis), cache query DB.
  • Pola: cache-aside (baca lewat aplikasi), write-through, stale-while-revalidate.
  • Invalidation (50): TTL (sederhana, akhirnya segar), purge eksplisit saat write (purge berbasis tag), key berversi (user:42:v7).
  • Jangan pernah menyimpan data privat per pengguna di cache bersama dengan key bersama (kebocoran data). Sertakan user/tenant di key atau tandai Cache-Control: private.
  • Cegah stampede: request coalescing, TTL dengan jitter, refresh lebih awal.
  • Khusus LLM: gunakan prompt caching dari penyedia untuk prefix statis yang panjang; cache hasil yang deterministik (embedding, klasifikasi).

9.2 Komponen pintu depan (3, 4, 5)

  • Reverse proxy (4): terminasi TLS, kompresi, buffering untuk klien lambat, routing (Nginx, Caddy, Cloudflare, edge platform).
  • Load balancer (3): menyebarkan traffic ke beberapa instance memakai health check; L4 (TCP) atau L7 (HTTP). Sticky session adalah tanda bahaya; jaga server aplikasi tetap stateless.
  • API gateway (5): auth, kuota, rate limit, routing, API key untuk banyak service. Berguna begitu Anda punya beberapa service atau menjual akses API.

9.3 Realitas serverless (89, 90)

  • Batas: waktu eksekusi maksimal, memori, ukuran payload, eksekusi konkuren, dan tekanan koneksi DB. Ketahui angka-angka platform Anda.
  • Cold start: request pertama setelah idle terasa lambat. Mitigasi dengan bundle lebih kecil, runtime lebih ringan (edge), provisioned/min instance untuk jalur yang kritis terhadap latensi.
  • Pekerjaan agen yang berjalan lama tidak tempatnya di fungsi yang terikat request; gunakan durable job.

9.4 Optimasi biaya (88)

  • Perlakukan biaya per pengguna aktif dan biaya per tugas AI sebagai metrik produk di dashboard.
  • Kemenangan terbesar: instance dengan ukuran yang pas, mematikan resource yang menganggur, caching hasil LLM, mengarahkan tugas sederhana ke model yang lebih kecil/murah, batching, lifecycle rule untuk storage, sadar biaya egress.
  • Spend cap keras dan alert anomali di setiap penyedia. Beri tag resource per produk/venture untuk atribusi biaya.

9.5 Metode load testing

Tentukan skenario (perjalanan pengguna yang realistis, think time, volume data) → naikkan bertahap (smoke, load, stress, soak) → pantau p95/p99, error rate, saturasi (CPU, memori, koneksi DB, kedalaman queue) → temukan hal pertama yang rusak → perbaiki → ulangi.

Lab 9: Temukan tebingnya

  1. Tulis skenario k6 untuk perjalanan utama Anda; naikkan beban sampai error rate melewati 1% atau p95 melampaui anggaran. Catat "tebing"-nya.
  2. Lakukan profiling dan perbaiki bottleneck teratas. Ulangi dua kali. Buat grafik kenaikan kapasitas per perbaikan.
  3. Tambahkan CDN + edge caching untuk satu halaman dinamis publik dengan invalidation yang benar saat ada update.
  4. Bangun dashboard biaya: biaya infra + AI bulanan per pengguna aktif.

Definition of Done

Paket prompt AI

  • "Berdasarkan output k6 dan statistik DB ini, urutkan kemungkinan bottleneck dan usulkan perbaikan termurah untuk masing-masing."
  • "Tambahkan caching ke endpoint ini. Sertakan desain cache key (dengan tenant), TTL, invalidation saat write, dan perlindungan stampede."