Gak Butuh Kubernetes: Scaling Sistem Bertahap

Lo punya sistem. Traffic naik. Terus seseorang bilang: “Lo harus pake Kubernetes.”

Stop. Duduk dulu. Napas.

Kubernetes itu alat yang luar biasa - di tangan yang tepat, buat masalah yang tepat. Tapi kalo lo pindah ke K8s cuma karena katanya “standard industry” atau “semua perusahaan besar pake”, lo bakal dapet kompleksitas tanpa value.

Artikel ini bukan buat ngelesinin K8s. Miu mau kasih framework praktis buat nentuin: di tahap mana sistem lo butuh apa - dari ratusan user sampe lonjakan traffic gara-gara event atau boost iklan.

Kenapa Banyak Yang Kejar K8s Padahal Belum Butuh?

Gini, K8s itu populer karena:

• Dipakai oleh Google, Netflix, Spotify - jadi keliatan kayak “wajib”
• Banyak job description yang minta - developer jadi pengalaman biar kompetitif
• Infrastructure-as-code yang rapi - declarative, reproducible, scalable

Semua itu bener. Tapi ada biaya yang jarang disebut:

Intinya: K8s nambahin 2 lapis abstraksi (container orchestration + service mesh) yang mungkin gak lo butuhin kalo traffic lo masih ratusan atau bahkan ribuan user per hari.

Sekarang kita bahas tahapannya.

Tahap 1: Ratusan User per Hari - Satu Server Udah Cukup

Di tahap ini, sistem lo dipake oleh tim internal, early adopter, atau client terbatas. Traffic masih rendah, error gak terlalu kritis, dan lo masih bisa nge-fix manual.

Arsitektur yang cukup:

Satu VPS (2-4 CPU, 4-8GB RAM)
├── Nginx (reverse proxy + static files)
├── Docker Compose
│   ├── App (Django / Laravel / dll)
│   ├── Database (PostgreSQL / MySQL)
│   └── Redis (cache + session)
└── Backup cron ke S3-compatible storage

Semua jalan di satu mesin. Nginx handle routing, Docker Compose bikin service terisolasi tapi tetep gampang di-debug.

Checklist:

• ✅ Backup otomatis - database di-dump tiap hari, file di-sync
• ✅ Health check endpoint - /health atau /ping yang return 200 kalo semua jalan
• ✅ Deployment simpel - git pull && docker compose up -d --build - itu doang
• ✅ Monitoring minimal - uptimerobot.com gratisan atau cron + curl notif ke Telegram
• ✅ SSL - Caddy atau Nginx + Let’s Encrypt (auto-renew)

Kapan naik ke tahap berikutnya?

• CPU/memory rutin di atas 70%
• Downtime karena maintenance mulai ganggu user
• Lo mulai mikir “gimana kalo server ini mati tengah malam?”

Titik keputusan: Satu server itu fragile. Kalo lo udah khawatir sama single point of failure, artinya lo siap naik level.

Tahap 2: Ribuan User per Hari - High Availability Minimal

Di tahap ini, lo butuh redundancy. Bukan karena traffic gede banget, tapi karena user udah mulai bergantung sama sistem lo. Downtime 30 menit bukan cuma masalah teknis - udah mulai kerasa ke pengguna.

Arsitektur yang cukup:

Load Balancer (Nginx / HAProxy / Cloud LB)
├── App Instance 1 (VPS 1)
├── App Instance 2 (VPS 2)
└── VPS 3 (standby - bisa dipake buat staging)

Database:
├── Primary (VPS dedicated atau managed DB)
└── Read Replica (buat report & read-heavy query)

Shared Services:
├── Redis Cluster (cache + session - external dari app)
├── Object Storage (S3-compatible - user uploads)
└── CI/CD pipeline (GitHub Actions / GitLab CI)

Yang berubah dari Tahap 1:

1. Stateless app - session gak boleh nyimpen di filesystem local. Pindah ke Redis external.
2. Upload files - gak boleh pake media/ folder lokal. Pindah ke S3/MinIO.
3. Database terpisah - gak satu server dengan sistem. Kalo managed DB (RDS, Cloud SQL), lo dapet auto-backup + failover.
4. Deployment pakai pipeline - bukan ssh manual. GitHub Actions build image, push ke registry, deploy ke server.
5. Rollback strategy - simpan 3-5 image versi terakhir. Kalo error, tinggal deploy ulang tag sebelumnya.

Kapan naik ke tahap berikutnya?

• Waktu deploy mulai makan waktu lama karena app makin gede
• Lo perlu handle traffic spike yang predictable (event besok, campaign minggu depan)
• Satu developer mulai kewalahan maintain infrastruktur

Titik keputusan: Kalo lo udah punya 2+ server, pipeline CI/CD, dan managed DB - lo udah punya fondasi yang lebih solid dari 90% startup yang migrasi ke K8s grasa-grusu.

Tahap 3: Lonjakan Traffic - Event, Promo, Boost Iklan

Nah, ini yang paling seru. Bayangin:

• Sistem lo tiba-tiba muncul di berita
• Iklan Facebook/Google mulai jalan jam 8 pagi
• Promo flash sale 12.00-13.00 WIB dengan diskon 70%
• Traffic naik 5-10x dalam beberapa menit

Di sinilah beda antara “sistem yang jalan” sama “sistem yang resilient”.

Yang harus disiapkan SEBELUM lonjakan:

1. Auto-scaling (Tanpa K8s)

Banyak provider cloud punya auto-scaling group native:

• AWS: EC2 Auto Scaling + Target Tracking
• GCP: Managed Instance Group + Autoscaler
• DigitalOcean/Vultr: API-based - lo bisa pake script atau integrator kayak Docker Cloud

Cara kerjanya: lo define AMI/image yang udah siap, dan cloud provider bakal spin up instance baru kalo CPU/request count naik di atas threshold.

# Contoh AWS Auto Scaling config (simplified)
auto_scaling_group:
  min_size: 2
  max_size: 8
  scaling_policy:
    - metric: CPUUtilization
      target: 70%
      cooldown: 120
  launch_template:
    image: web-app-v3.2
    instance_type: t3.medium

2. Queue System

Waktu traffic naik, jangan biarin sistem nge-handle semua request sinkron. Pake queue:

# Contoh: kirim email via queue, bukan langsung di request
from celery import Celery

app = Celery('tasks', broker='redis://redis-cluster:***@app.task
def send_welcome_email(user_id):
    user = get_user(user_id)
    mailer.send(user.email, template='welcome')
    log_activity(user_id, 'welcome_email_sent')

Request yang berat (email, notifikasi, export data, image processing) dijalanin async via worker. Sistem tetep responsif walau lagi banjir request.

3. Caching Bertingkat

Jangan biarin setiap request nge-HIT database. Susun cache:

Browser Cache (Cache-Control headers) ← CDN (Cloudflare/CloudFront)
↓
Application Cache (Redis) - query results, rendered fragments
↓
HTTP Cache (Nginx cache) - API responses yang gak real-time
↓
Database (PostgreSQL/MySQL) - sumber kebenaran terakhir

Kalo laporan analytics yang gak perlu real-time bisa di-cache 5 menit, itu udah ngurangin beban database 90%+ di jam sibuk.

4. Rate Limiting + Circuit Breaker

Ini penting pas traffic spike. Jangan biarin satu pengguna atau satu endpoint ambruk semua server:

# Nginx rate limiting
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;

location /api/ {
    limit_req zone=api burst=20 nodelay;
    proxy_pass http://backend;
}

Kalo database mulai lambat, circuit breaker otomatis return fallback response daripada nge-queue request yang gak bakal selesai tepat waktu.

5. Database Scaling

Di tahap ini, database biasanya jadi bottleneck pertama:

• Read replicas - query SELECT diarahin ke replica, biar primary fokus write
• Connection pooling - PgBouncer (PostgreSQL) atau ProxySQL (MySQL) - jangan biarin app bikin 1000 connection langsung ke DB
• Query optimization - explain analyze, slow query log, indexing yang tepat
• Vertical scaling dulu - upgrade RAM/CPU DB sebelum mikir sharding

Contoh Skenario Lengkap

Bayangin sistem lo ada promo Flash Sale Tengah Malam - traffic naik dari 5.000 req/min ke 50.000 req/min dalam 5 menit.

Yang terjadi kalo gak siap:

05 menit: Traffic mulai naik → CPU 90%
07 menit: Database connection pool habis → 502 Bad Gateway
10 menit: Server down → semua user dapet error page

Yang terjadi kalo siap dengan arsitektur bertahap:

05 menit: Auto-scaling detect CPU > 70% → spin up 2 instance baru
07 menit: CDN serve cached pages → database aman
10 menit: Queue handle email notifikasi → app tetap responsif
12 menit: Traffic puncak → 5 instance jalan, rate limiting aktif
15 menit: Traffic mulai turun → instance kelebihan auto-terminate

Gak pake Kubernetes. Gak pake service mesh. Gak pake operator custom. Cuma pake auto-scaling group + queue + CDN + rate limiting.

Perbandingan Biaya: GCP vs AWS di Tiap Tahap

Biaya cloud sering jadi alasan orang pindah ke K8s - “biar murah” katanya. Tapi sebelum lo mikir orchestration, ada baiknya tahu dulu berapa yang sebenarnya lo bayar di setiap tahap.

Berikut estimasi bulanan untuk arsitektur yang kita bahas di atas, pakai on-demand pricing di region US (paling umum dipake sebagai benchmark). Harga bisa beda tergantung region, diskon, dan commit.

Tahap 1 - Satu Server + DB Kecil

GCP unggul di compute (e2 20% lebih murah), tapi RDS jauh lebih hemat daripada Cloud SQL untuk spec setara. AWS lebih murah ~45% di skenario ini.

Tahap 2 - Multi-Server + HA

Perbedaan paling signifikan ada di database HA. Cloud SQL Multi-AZ butuh 2 replica aktif, sementara RDS Multi-AZ lebih efisien.

Tahap 3 - Auto-Scaling + Spike

Asumsi: rata-rata 6 instance (2 idle + 10 spike), DB primary + read replica.

GCP unggul di compute - e2 30% lebih murah dari t3.large per jam. Tapi ketertinggalan di managed DB bikin total AWS tetap lebih murah ~22%.

Yang Sering Dilupain: Biaya Egress

Ini jebakan Batman-nya cloud. Transfer data keluar (egress) bisa nyusup tanpa lo sadar sampe tagihan datang:

Sumber: cloud.google.com/vpc/network-pricing, aws.amazon.com/ec2/pricing, cloudflare.com/bandwidth-alliance. Data diverifikasi 2 Juni 2026.

Bottom line: Kalo sistem lo banyak serving content ke user, egress bisa nyaris setara atau bahkan melebihi biaya compute. Ini yang bikin banyak orang kaget pas migrasi ke cloud.

Catatan Penting

• Harga di atas on-demand - belum termasuk diskon (AWS Savings Plans bisa potong 40-60%, GCP Committed Use Discounts juga)
• Biaya tambahan yang sering kelewat: NAT Gateway ($0.045/GB di AWS), Cross-AZ transfer ($0.01/GB tiap arah), VPC endpoint
• Kalo lo pake preemptible/spot instance, biaya compute bisa turun 60-90% - cocok buat workload yang gak kritis
• Selalu cek pricing calculator resmi sebelum ambil keputusan - cloud.com/pricing berubah berkala

Intinya: Pilih provider berdasarkan workload, bukan karena “temen pada pake.” GCP compute murah, AWS DB murah. Dua-duanya bisa lebih murah dari K8s kalo lo belum butuh orchestrasi.

Decision Framework: Kapan Lo Beneran Butuh K8s?

Misalnya: ini bukan kalkulator eksak atau formula ilmiah - lebih ke panduan reflektif. Tiap tim punya konteks beda, dan framework ini cuma bantu lo liat dari sisi lain sebelum ambil keputusan.

Jawab pertanyaan ini:

Total skor:

• 0-2: Sistem lo belum butuh K8s. Fokus ke scaling vertikal + Docker Compose + auto-scaling simpel.
• 3-4: Mulai explore alternatif kayak Nomad, Docker Swarm, atau managed K8s (EKS/GKE - biar setup minimal).
• 5-6: Lo siap. Tapi siapin tim dan waktu transisi minimal 3 bulan.

Alternatif yang Patut Dipertimbangkan Sebelum K8s

Persiapan Dari Sekarang - Biar Gak Ribet Nanti

Kalo sekarang lo masih di Tahap 1 atau 2, tapi tau suatu saat mungkin butuh arsitektur yang lebih kompleks, ini yang bisa lo siapin dari sekarang:

1. Containerize dari awal - Dockerfile yang rapi, docker-compose yang baku. Ini investasi paling berharga.
2. 12-factor app - environment variables, stateless processes, log sebagai event stream. Kalo udah begini, migrasi ke platform manapun gampang.
3. Stateless design - session di Redis, file di S3, cache di external. App instance bisa mati kapan aja, user gak ngerasa.
4. Health + readiness probes - endpoint /health dan /ready yang bener. Bukan cuma return 200, tapi beneran cek koneksi DB, Redis, dan dependency lain.
5. Dokumentasi infrastruktur - diagram arsitektur, runbook, SOP deployment. Ini yang paling sering dilupain.

Kesimpulan

Kubernetes itu alat buat masalah tertentu: orchestrasi banyak service di banyak node dengan team besar. Kalo masalah lo cuma “gimana handle traffic spike pas promo”, ada 10 solusi lain yang lebih simpel sebelum lo harus belajar etcd, RBAC, dan network policies.

Mulai dari yang paling simpel. Tambah kompleksitas cuma kalo ada masalah yang gak bisa diselesaiin tanpa itu.

Server lo mungkin udah cukup. Serius.

Terima kasih sudah meluangkan waktu buat baca artikel ini. Semoga ada manfaat yang bisa diambil - baik buat yang lagi nimbang-nimbang mau migrasi, atau yang cuma penasaran. 🐾