Pembangun melihat aplikasi yang baru dilancarkan tersangkut sebaik sahaja beberapa ribu pengguna menekan "go", dan kelembapan tersebut jarang sekali disebabkan oleh pepijat dalam kod – sebaliknya ia adalah CPU dan RAM pelayan yang berebut ruang. Kesesakan ini muncul dalam bentuk masa pemuatan halaman yang lebih lama, tamat masa (time-outs), atau kegagalan sistem sepenuhnya, dan ia menjejaskan pengalaman pengguna, hasil pendapatan, serta kepercayaan jenama.

Mengapa pelayan yang berjalan lancar di makmal boleh terhenti sepenuhnya dalam persekitaran produksi

Semasa pembangunan, seorang pembangun hanya menghantar segelintir permintaan, jadi sumber pelayan akan berada dalam keadaan tidak aktif (idle) pada kebanyakan masa. Apabila aplikasi dilancarkan secara langsung, setiap pelawat menjana permintaan yang memerlukan dua komponen utama:

  • CPU (unit pemprosesan pusat) – pemproses yang menjalankan setiap gelung (loop), fungsi, dan pengiraan. Bayangkan ia seperti seorang tukang masak yang hanya boleh menyediakan jumlah hidangan yang terhad pada satu-satu masa. Satu pesanan disajikan serta-merta; seratus pesanan bermakna tukang masak tersebut masih bekerja pada kelajuan yang sama, tetapi pelanggan terpaksa menunggu lebih lama.
  • RAM (memori capaian rawak) – storan sementara untuk data yang diperlukan oleh CPU semasa mengendalikan permintaan. Ia seperti meja di mana tukang masak menyimpan bahan-bahan untuk setiap hidangan. Jika meja sudah penuh, tukang masak mesti berhenti menerima pesanan baharu sehingga ruang dikosongkan.

Apabila beribu-ribu pengguna log masuk secara serentak, setiap permintaan menuntut bahagian masa CPU dan bahagian RAM yang tersendiri. Kumpulan sumber pelayan yang terhad akan dibahagikan antara permintaan-permintaan tersebut, dan barisan menunggu akan semakin panjang. Pelayan itu sendiri tidak menjadi lebih perlahan; sebaliknya masa menunggu untuk setiap permintaan telah meningkat.

Godaan untuk “beli sahaja kotak yang lebih besar”

Reaksi pertama yang biasa adalah dengan menaik taraf mesin – satu amalan yang dipanggil penskalaan menegak (vertical scaling). Menambah lebih banyak teras CPU atau lebih banyak RAM memang akan meningkatkan kapasiti: beralih daripada 4 teras kepada 16, atau daripada 8 GB kepada 64 GB, dapat menampung lonjakan trafik yang lebih besar tanpa mengubah sebarang kod.

Walau bagaimanapun, penskalaan menegak mempunyai had siling yang nyata:

  • Had fizikal – setiap papan induk hanya boleh menampung jumlah teras tertentu dan jumlah memori yang terhad.
  • Pulangan yang semakin berkurangan – setiap tambahan teras atau gigabait menelan kos yang lebih tinggi daripada sebelumnya, manakala peningkatan prestasi semakin mengecil.
  • Titik kegagalan tunggal (single point of failure) – jika pelayan yang bersaiz besar itu tergendala, seluruh perkhidmatan akan hilang.

Disebabkan kekangan ini, pemain utama industri – platform penstriman, enjin carian, laman e-dagang – telah beralih daripada penggunaan satu mesin gergasi tunggal.

Alternatifnya: menyebarkan beban ke banyak kotak yang lebih kecil

Daripada membina menara yang lebih tinggi, pengendali menambah lebih banyak pelayan bersaiz sederhana dan membiarkan mereka berkongsi trafik. Pendekatan penskalaan mendatar (horizontal scaling) ini memastikan setiap mesin kekal dalam lingkungan prestasi yang selesa dan mengelakkan lengkung kos eksponen daripada naik taraf menegak.

Menyelaraskan banyak mesin memerlukan pengimbang beban (load balancer) – satu perisian atau perkakasan yang menerima setiap permintaan masuk dan menghantarnya ke pelayan yang mempunyai kapasiti paling banyak. Pengimbang tersebut menyembunyikan kerumitan daripada pelanggan; dari perspektif pengguna, laman web tersebut masih kelihatan seperti satu titik akhir (endpoint) tunggal.

Penskalaan mendatar juga membawa daya tahan. Jika satu nod tergendala, pengimbang beban hanya akan menghalakan trafik ke nod lain yang masih berfungsi, sekaligus memastikan perkhidmatan terus berjalan.

Perkara yang perlu diperhatikan apabila anda mula menambah mesin

  • Reka bentuk tanpa keadaan (stateless design) – permintaan tidak seharusnya bergantung pada data yang hanya disimpan dalam memori pelayan tertentu; jika tidak, pengguna mungkin dihantar ke nod yang tidak mempunyai konteks yang diperlukan. Penggunaan cache atau pangkalan data kongsi dapat menyelesaikan masalah ini.
  • Semakan kesihatan (health checks) – pengimbang beban mesti mampu mengesan pelayan yang gagal dengan cepat dan berhenti menghantar trafik kepadanya.
  • Polisi penskalaan automatik (auto-scaling policies) – banyak platform awan membolehkan anda menetapkan ambang (penggunaan CPU, kependaman permintaan) yang secara automatik akan menjalankan atau menutup instans, bagi memastikan kos selaras dengan permintaan.

Sudut pandangan berbeza: penskalaan menegak belum mati

Bagi pasukan kecil atau aplikasi dengan trafik rendah, satu pelayan yang dipertingkatkan boleh menjadi penyelesaian yang paling mudah dan murah. Jika lonjakan trafik boleh diramal (contohnya, pelancaran produk yang dijadualkan), naik taraf menegak sementara mungkin lebih praktikal daripada menyediakan seluruh armada instans baharu.

Kuncinya adalah untuk mengenali bila teknik “kotak yang lebih besar” tidak lagi memberikan nilai yang setimpal dan mula merancang untuk pengagihan beban.

Rumusan

Perlambatan pelayan selepas pelancaran biasanya merupakan isu persaingan sumber, bukannya kecacatan kod. Kitaran CPU dan slot RAM adalah terhad, dan apabila banyak permintaan tiba secara serentak, ia akan beratur, sekali gus memanjangkan masa tindak balas. Penskalaan menegak memberikan anda sedikit lebih ruang tambahan, tetapi tidak lama kemudian ia akan menghadapi had fizikal dan ekonomi. Penskalaan mendatar—menambah lebih banyak pelayan yang lebih sederhana di belakang pengimbang beban (load balancer)—menawarkan laluan yang lebih murah dan lebih berdaya tahan apabila trafik meningkat. Sebaik sahaja anda menyedari barisan semakin panjang, tiba masanya untuk menilai sama ada penambahan beberapa teras lagi sudah mencukupi atau sama ada anda perlu mula mengagihkan beban tersebut ke banyak mesin.

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