Aplikasi sudah dideploy, fitur sudah lengkap, tapi tiba-tiba user kita melonjak dari ratusan menjadi puluhan ribu. Apa yang harus dilakukan? Sebagai DevOps, kita tidak boleh panik. Kita harus punya strategi untuk memperbesar kapasitas tanpa membuat user mengalami loading lama atau bahkan error.

1. Identifikasi Scaling: Up atau Out?

Banyak orang bingung kapan harus menambah kekuatan server yang ada (Scaling Up) dan kapan harus menambah jumlah server (Scaling Out). Inilah cara identifikasinya:

• Scaling Up (Vertical): Menambah CPU atau RAM pada server yang sudah ada. Lakukan ini jika satu kontainer kita membutuhkan resource besar untuk satu proses berat (misal: pengolahan video atau kalkulasi rumit).

• Scaling Out (Horizontal): Menambah jumlah replika kontainer atau menambah server Worker baru. Lakukan ini untuk menangani jumlah user yang banyak secara bersamaan (concurrent).

• Kapan Tambah Replika? Jika penggunaan CPU server masih di bawah 60%, tapi aplikasi mulai terasa lambat merespon request, tambahkan replika: docker service scale godocapi_backend=5.

• Kapan Tambah Worker? Jika total penggunaan CPU/RAM di seluruh server sudah menyentuh 70-80%, itulah saatnya Anda membeli server baru dan melakukan docker swarm join.

2. Zero Downtime Deployment: Update Tanpa Drama

Sebagai profesional, kita tidak boleh mematikan layanan hanya untuk update versi aplikasi. Kita akan menggunakan strategi Rolling Update dengan konfigurasi start-first.

Artinya: Swarm akan menyalakan kontainer versi baru terlebih dahulu sampai sehat, baru mematikan kontainer versi lama. User tidak akan pernah merasakan koneksi terputus.

Tambahkan ini di file docker-stack.yml :

services:
  backend:
    image: cehamot/godocapi:latest
    deploy:
      update_config:
        order: start-first
        parallelism: 1
        delay: 10s
      rollback_config:
        parallelism: 1
        order: stop-first

Pro Tip: Jika update versi baru ternyata buggy, Anda cukup jalankan docker service rollback godocapi_backend untuk kembali ke versi stabil sebelumnya secara otomatis.

3. Placement Constraint: Menjaga Docker Manager Tetap Dingin

Sesuai arsitektur yang Anda bangun, Manager (Server A) harus tetap fokus mengelola kluster dan tidak boleh terbebani oleh aplikasi berat. Kita akan "mengusir" backend agar hanya berjalan di Worker (Server B atau C).

Tambahkan ini di file docker-stack.yml

services:
  backend:
    deploy:
      placement:
        constraints:
          - node.role == worker

pastikan kembali backend berjalan di node worker

docker service ps godocapi_backend

terlihat untuk backend sudah pindah ke node docker worker dengan ini, Manager Anda akan selalu sehat untuk mengawasi jalannya kluster meskipun trafik sedang tinggi.

4. Integrasi HAProxy: The Front Gate

Di depan kluster Swarm, kita butuh HAProxy sebagai Reverse Proxy sekaligus penyeimbang beban (Load Balancer). HAProxy akan menerima trafik dari internet dan membaginya ke IP Server A, B, atau C.

Gunakan referensi artikel berikut ini untuk membuat server HAProxy.

Contoh Konfigurasi haproxy.cfg :

frontend http_front
   bind *:80
   default_backend swarm_cluster

backend swarm_cluster
   balance roundrobin
   option httpchk GET /health
   server manager_a 192.168.20.101:3000 check
   server worker_b 192.168.20.102:3000 check

Berkat teknologi Ingress Mesh, HAProxy tidak perlu pusing mencari di mana kontainer berada. Cukup tembak ke IP server mana pun di dalam kluster, Swarm yang akan mengurus sisanya.

5. Kesimpulan

• Ketika pengguna meledak, jangan panik — identifikasi dulu apakah masalahnya butuh scaling up (vertical) atau scaling out (horizontal).

• Gunakan scaling up untuk kebutuhan proses tunggal yang berat (CPU/RAM per kontainer), dan scaling out untuk menangani banyak koneksi sekaligus (menambah replika atau worker).

• Praktik sederhana: jika CPU per server masih <~60% tapi respon melambat, tambah replika (mis. docker service scale godocapi_backend=5); jika total penggunaan cluster sudah ~70–80%, tambahkan node worker dan docker swarm join.

• Pastikan monitoring dan alerting (CPU, RAM, latency, error rate) aktif supaya keputusan scaling didasarkan data, bukan tebak-tebakan.

• Siapkan proses deployment tanpa downtime (rolling updates, health checks, cukup replika saat update) agar skala naik/turun dan pembaruan versi tidak mengganggu user.

• Automasi (script/CI/CD, autoscaler, infrastruktur as code) dan perencanaan kapasitas membantu menghindari krisis saat lonjakan traffic berikutnya.

Intinya: ukur dulu, pilih strategi yang sesuai (up vs out), otomatisasi tindakan yang rutin, dan jaga pengalaman pengguna tetap mulus selama scaling atau update.