Developers menyaksikan aplikasi yang baru saja diluncurkan melambat saat beberapa ribu pengguna mulai menggunakannya, dan perlambatan tersebut jarang sekali disebabkan oleh bug pada kode – melainkan karena CPU dan RAM server yang berebut ruang. Bottleneck ini muncul dalam bentuk pemuatan halaman yang lebih lama, timeout, atau bahkan crash total, yang pada akhirnya merusak pengalaman pengguna, pendapatan, dan kepercayaan terhadap merek.

Mengapa server yang berjalan lancar di lab bisa berhenti mendadak saat produksi

Selama pengembangan, seorang pengembang tunggal hanya mengirimkan beberapa permintaan, sehingga sumber daya server sebagian besar berada dalam kondisi idle. Saat aplikasi mulai live, setiap pengunjung menghasilkan permintaan yang membutuhkan dua komponen inti:

  • CPU (central processing unit) – prosesor yang menjalankan setiap loop, fungsi, dan kalkulasi. Bayangkan seperti seorang koki yang hanya bisa menyiapkan sejumlah hidangan dalam satu waktu. Satu pesanan dapat disajikan seketika; seratus pesanan berarti koki tetap bekerja dengan kecepatan yang sama, tetapi pelanggan harus menunggu lebih lama.
  • RAM (random-access memory) – penyimpanan sementara untuk data yang dibutuhkan CPU saat menangani permintaan. Ini seperti meja kerja tempat koki menyimpan bahan-bahan untuk setiap hidangan. Jika meja penuh, koki harus berhenti menerima pesanan baru sampai ada ruang yang dikosongkan.

Ketika ribuan pengguna masuk secara bersamaan, setiap permintaan mengambil jatah waktu CPU dan kapasitas RAM-nya sendiri. Kumpulan sumber daya server yang terbatas terbagi di antara permintaan-permintaan tersebut, sehingga antrean pun memanjang. Server itu sendiri tidak menjadi lebih lambat; waktu tunggu untuk setiap permintaanlah yang meningkat.

Godaan untuk “sekadar membeli kotak yang lebih besar”

Reaksi pertama yang umum adalah meningkatkan spesifikasi mesin – sebuah praktik yang disebut vertical scaling. Menambah lebih banyak core CPU atau lebih banyak RAM memang meningkatkan kapasitas: berpindah dari 4 core ke 16, atau dari 8 GB ke 64 GB, dapat menyerap lonjakan trafik yang lebih besar tanpa mengubah kode apa pun.

Namun, vertical scaling memiliki batasan yang kaku:

  • Batasan fisik – setiap motherboard hanya dapat menampung jumlah core tertentu dan jumlah memori yang terbatas.
  • Diminishing returns – setiap tambahan core atau gigabyte membutuhkan biaya yang lebih mahal dari sebelumnya, sementara peningkatan performanya semakin mengecil.
  • Single point of failure – jika server yang berukuran besar tersebut mati, maka seluruh layanan akan hilang.

Karena batasan-batasan ini, para pemain besar di industri – platform streaming, mesin pencari, situs e-commerce – telah beralih dari penggunaan satu mesin raksasa tunggal.

Alternatifnya: menyebarkan beban ke banyak kotak yang lebih kecil

Alih-alih membangun menara yang lebih tinggi, operator menambahkan lebih banyak server berukuran sedang dan membiarkan mereka berbagi trafik. Pendekatan horizontal scaling ini menjaga agar setiap mesin tetap berada dalam batas performa yang nyaman dan menghindari kurva biaya eksponensial dari upgrade vertikal.

Mengoordinasikan banyak mesin memerlukan load balancer – perangkat lunak atau perangkat keras yang menerima setiap permintaan masuk dan meneruskannya ke server dengan kapasitas yang paling tersedia. Load balancer menyembunyikan kompleksitas tersebut dari klien; dari perspektif pengguna, situs tersebut tetap terlihat seperti satu endpoint tunggal.

Horizontal scaling juga memberikan resiliensi. Jika satu node crash, load balancer cukup mengarahkan trafik ke node lain yang masih sehat, sehingga layanan tetap berjalan.

Hal yang perlu diperhatikan saat Anda mulai menambah mesin

  • Stateless design – permintaan tidak boleh bergantung pada data yang hanya disimpan di memori server tertentu; jika tidak, pengguna bisa saja diarahkan ke node yang tidak memiliki konteks yang dibutuhkan. Menggunakan shared cache atau database dapat menyelesaikan masalah ini.
  • Health checks – load balancer harus mampu mendeteksi server yang bermasalah dengan cepat dan berhenti mengirimkan trafik ke sana.
  • Auto-scaling policies – banyak platform cloud memungkinkan Anda menentukan ambang batas (penggunaan CPU, latensi permintaan) yang secara otomatis menjalankan atau mematikan instance, sehingga biaya tetap selaras dengan permintaan.

Sisi lainnya: vertical scaling tidaklah mati

Untuk tim kecil atau aplikasi dengan trafik rendah, satu server yang diperkuat bisa menjadi solusi termudah dan termurah. Jika lonjakan trafik dapat diprediksi (misalnya, peluncuran produk yang dijadwalkan), upgrade vertikal sementara mungkin lebih praktis daripada menyediakan seluruh armada instance baru.

Kuncinya adalah mengenali kapan trik “kotak yang lebih besar” tidak lagi memberikan nilai yang proporsional dan mulai merencanakan distribusi.

Kesimpulan

Perlambatan server setelah peluncuran biasanya merupakan masalah perebutan sumber daya (resource contention), bukan cacat kode. Siklus CPU dan slot RAM bersifat terbatas, dan ketika banyak permintaan datang secara bersamaan, permintaan tersebut akan mengantre, sehingga memperlama waktu respons. Scaling vertikal memberi Anda sedikit lebih banyak kapasitas cadangan, tetapi akan segera menemui batas fisik dan ekonomi. Scaling horizontal—menambahkan lebih banyak server dengan spesifikasi lebih rendah di belakang load balancer—menawarkan jalur yang lebih murah dan lebih tangguh seiring bertambahnya trafik. Saat Anda menyadari antrean mulai memanjang, itulah saatnya untuk mengevaluasi apakah penambahan beberapa core saja sudah cukup atau apakah Anda harus mulai menyebarkan beban ke banyak mesin.

Sumber: artikel dev.to “Why Servers Slow Down – CPU, RAM and the hidden cost of every request.”