Sesi 07 — Server yang Kamu Pesan, Bukan yang Kamu Dapat

1. Bayangkan jika

Bayangkan kamu menyewa 1 server 8 vCPU dan RAM 16GB di cloud provider untuk menjalankan aplikasi pembayaran.

Di hari Senin pagi, kamu menjalankan uji beban (load test) dengan 1.000 virtual user. Hasilnya sangat memuaskan: - Waktu respon rata-rata: 120ms - Response time p99: 180ms - Throughput: 1.500 TPS tanpa ada error sama sekali.

Kamu mencatat angka ini sebagai baseline performa resmi.

Lalu di hari Kamis malam, kamu menjalankan script pengujian yang sama persis, data yang sama, dan konfigurasi server yang tidak diubah satu baris pun. Namun hasilnya hancur: - Waktu respon rata-rata: 450ms - Response time p99: 3.200ms (naik 17 kali lipat!) - CPU internal servermu hanya terpakai 35%, tapi transaksi menumpuk dan mulai bermunculan error timeout.

Aplikasi tidak berubah. Script pengujian tidak berubah. Spesifikasi server di dashboard cloud tertulis sama.

Kenapa satu server yang sama bisa menghasilkan performa yang berbeda bumi dan langit?

2. Apa yang sebenarnya terjadi

Jawabannya: Server yang kamu sewa di dashboard bukanlah komputer fisik tersendiri.

Kamu sedang berbagi satu mesin server fisik raksasa dengan puluhan penyewa (tenant) lain yang tidak pernah kamu kenal.

Di dunia infrastruktur modern, ada tiga tingkatan wujud server:

+-------------------------------------------------------------------------+
|                              1. BARE METAL                              |
|  [ Aplikasi ] ➔ [ OS Host Kernel ] ➔ [ Perangkat Keras Fisik Tunggal ]  |
+-------------------------------------------------------------------------+
|                           2. VIRTUAL MACHINE                            |
|  [ App A | Guest OS ]  [ App B | Guest OS ]  [ App C | Guest OS ]       |
|  ---------------------------------------------------------------------  |
|               [ Hypervisor (KVM / VMware ESXi / Xen) ]                  |
|  ---------------------------------------------------------------------  |
|                       [ Perangkat Keras Fisik ]                         |
+-------------------------------------------------------------------------+
|                              3. CONTAINER                               |
|  [ App A (Bin/Libs) ]   [ App B (Bin/Libs) ]   [ App C (Bin/Libs) ]     |
|  ---------------------------------------------------------------------  |
|          [ Container Engine (Docker / CRI-O / Containerd) ]             |
|  ---------------------------------------------------------------------  |
|                 [ Satu Kernel OS Host (cgroups + namespace) ]           |
|  ---------------------------------------------------------------------  |
|                       [ Perangkat Keras Fisik ]                         |
+-------------------------------------------------------------------------+

A. Bare Metal: Mesin Fisik Utuh

Seluruh core CPU, RAM, bus motherboard, kartu jaringan (NIC), dan disk controller dipakai eksklusif oleh aplikasimu.
Kelebihan: Latency deterministik, konsisten, tidak ada overhead virtualisasi.
Kekurangan: Mahal, proses provisioning lambat (butuh hitungan jam atau hari), dan sulit diubah ukurannya secara dinamis.

B. Virtual Machine (VM): Isolasi Hypervisor

Hypervisor memotong satu mesin fisik besar menjadi banyak mesin virtual mandiri. Setiap VM membawa salinan kernel OS-nya sendiri (Guest OS).
Kelebihan: Isolasi keamanan kuat, bisa menjalankan berbagai OS berbeda di satu server fisik.
Kekurangan: Ada overhead virtualisasi (5–15%), waktu boot lambat (hitungan menit), dan rentan terhadap overcommit.

C. Container: Berbagi Kernel OS

Bukan mesin virtual, melainkan proses biasa di OS host yang diisolasi menggunakan fitur kernel Linux: 1. Namespaces: Memberi ilusi bahwa proses berjalan sendirian (isolasi PID, mount, network, user). 2. cgroups (Control Groups): Membatasi jatah maksimal CPU, memori, dan I/O.
Kelebihan: Sangat ringan, waktu start dalam milidetik, konsumsi memori minim.
Kekurangan: Berbagi satu kernel host yang sama. Jika kernel mengalami kernel panic, seluruh container di host tersebut ikut mati.

3. Rahasia Provider Cloud: Overcommit & Noisy Neighbor

Kenapa harga sewa cloud vCPU bisa murah?

Karena provider mengandalkan prinsip probabilitas: Overcommit Ratio.

Jika satu server fisik memiliki 64 core fisik, provider tidak hanya menjual 64 vCPU. Mereka bisa menjual 128 hingga 256 vCPU ke berbagai pelanggan (rasio overcommit 1:2 hingga 1:4), dengan asumsi tidak semua pelanggan memakai 100% CPU di detik yang sama.

[ SERVER FISIK: 64 PHYSICAL CORES ]
├── vCPU Pelanggan A (Perusahaan Fintech - Sedang Uji Beban) ➔ 32 vCPU
├── vCPU Pelanggan B (Aplikasi Batch Processing Berat)      ➔ 32 vCPU
├── vCPU Pelanggan C (Machine Learning Training)            ➔ 32 vCPU
└── vCPU Kamu (Aplikasi Pembayaran)                         ➔ 32 vCPU
-------------------------------------------------------------------------
TOTAL vCPU DIJUAL = 128 vCPU (Overcommit 200% pada 64 Physical Core)

Fenomena Noisy Neighbor (Tetangga Berisik)

Ketika Tetangga B dan Tetangga C tiba-tiba menjalankan proses komputasi berat: 1. Hypervisor terpaksa mengantrekan jatah waktu eksekusi CPU fisik (CPU scheduling latency). 2. Paket jaringan aplikasimu tertahan di ring buffer kartu jaringan fisik karena tetangga membanjiri bandwidth. 3. Head disk storage berebut antrean IOPS.

Aplikasi kamu tidak mengalami crash dan CPU internalmu terlihat baru 35%, tetapi thread-mu terhenti menunggu giliran core CPU fisik. Di metrik Linux, fenomena ini tercatat sebagai %steal time (CPU Steal).

4. Nama resminya

Istilah	Definisi dalam Dokumen Desain & Operasional
Bare Metal	Server komputasi fisik tunggal tanpa lapisan hypervisor, disewa secara eksklusif (single-tenant).
Hypervisor (Type-1 / Type-2)	Lapisan software/firmware (seperti KVM, ESXi) yang membuat dan mengelola mesin virtual.
Guest OS vs Host OS	OS yang berjalan di dalam VM (Guest) versus OS utama yang berjalan langsung di atas hardware (Host).
Containerization	Metode virtualisasi level OS menggunakan Linux Namespaces dan cgroups tanpa menjalankan kernel ganda.
Overcommit Ratio	Perbandingan antara total vCPU/RAM virtual yang dialokasikan kepada penyewa dibanding kapasitas fisik sebenarnya.
Noisy Neighbor	Situasi di mana beban kerja satu penyewa di server bersama menyedot sumber daya bersama dan merusak performa penyewa lain.
CPU Steal (%steal)	Persentase waktu virtual CPU menunggu alokasi waktu eksekusi dari hypervisor fisik saat core fisik sedang sibuk.

5. Di dunia kita (Sistem Produksi Nyata)

Skenario Nyata: Latency Spikes Misterius di Jam Sibuk

Sebuah bank digital meluncurkan microservices transaksi di cloud publik menggunakan instance VM standar (Shared Multi-Tenant).

Gejala: Setiap jam 12:00–13:00 siang, latency p99 transaksi melonjak dari 150ms ke 4.500ms. Tim developer memeriksa log aplikasi, query database, dan garbage collection, namun semuanya bersih.
Investigasi: Monitoring APM menunjukkan metrik %steal pada VM melonjak hingga 42%. Artinya, 42% dari waktu prosesor yang seharusnya mengeksekusi thread aplikasi habis direbut oleh VM penyewa lain di host fisik yang sama.
Solusi Arsitektur: 1. Memindahkan database dan core payment engine ke Dedicated Instance / Bare Metal (zero overcommit). 2. Mengaktifkan CPU pinning di Kubernetes node agar thread tidak berpindah-pindah core fisik.

6. Lensa Performance Tester

Sebagai tester performa, memahami wujud fisik server menghindarkan kamu dari salah mendiagnosis bottleneck:

Waspadai Metrik %steal saat Uji Beban di Cloud: - Selalu monitor %steal di top, vmstat 1, atau agent APM (Datadog/Prometheus). - Jika %steal > 5%, hasil load test tidak valid karena kamu sedang mengukur kepadatan tetangga, bukan batas kemampuan aplikasimu.
Jalankan Uji Beban di Jam yang Berbeda: - Lakukan uji beban pagi, sore, dan tengah malam. Jika throughput berbeda signifikan pada environment yang sama, kemungkinan besar terjadi interferensi noisy neighbor di lapisan I/O atau jaringan.
Uji Disk IOPS dan Jaringan Secara Terisolasi: - Gunakan tool seperti fio untuk benchmark disk IOPS dan iperf3 untuk network throughput sebelum menjalankan load test aplikasi. Pastikan bandwidth yang didapat sesuai dengan SLA instance.
Tentukan Environment Uji yang Tepat: - Environment Performance Testing (Staging/Perf) harus memiliki rasio overcommit dan tipe instance yang identik dengan Production (misal: Compute-Optimized Dedicated Instance, bukan Burstable Shared T-Series).

7. Rangkuman & Jembatan ke Sesi Berikutnya

Server di era modern terbagi menjadi Bare Metal (eksklusif & konsisten), Virtual Machine (fleksibel tapi ada hypervisor & overcommit), dan Container (sangat cepat & berbagi satu kernel).
Harga murah cloud didorong oleh overcommit; resikonya adalah fenomena Noisy Neighbor dan CPU Steal.
Sekarang kita sudah memahami apa sebenarnya satu server itu. Pertanyaan berikutnya: ketika satu server tidak lagi mampu menampung beban, haruskah kita membeli server yang jauh lebih besar atau membeli sepuluh server kecil?

Lanjut ke Sesi 8 — Membesarkan atau Memperbanyak (Vertical vs Horizontal Scaling).