Cara Scale Aplikasi di Helipod — CPU, Memory, dan Horizontal Scaling

Aplikasimu mulai dapat traffic. Response time mulai lambat. CPU usage tinggi terus. Apa yang harus dilakukan?

Di server VPS tradisional, scaling berarti upgrade ke server yang lebih besar (dan lebih mahal) — atau setup load balancer yang kompleks. Di Helipod, scaling semudah menggeser slider dan mengubah angka replica.

Artikel ini menjelaskan semua opsi scaling di Helipod dan kapan harus menggunakannya.

Dua Jenis Scaling

Vertical Scaling (Scale Up)

Tambah CPU dan Memory pada pod yang sudah ada. Cocok untuk aplikasi yang butuh lebih banyak resource per instance.

Horizontal Scaling (Scale Out)

Tambah jumlah replica pod yang identik. Cocok untuk menangani traffic tinggi dengan distribusi beban.

Di Helipod, keduanya tersedia dan bisa dikombinasikan.

Mengakses Settings Scaling

1. Klik service di canvas dashboard
2. Buka tab Settings
3. Scroll ke bagian Scaling & Resources

Kamu akan melihat:

• Region & Replicas — pilih region dan jumlah replica
• Hardware Limits — slider CPU dan Memory per replica

Vertical Scaling: CPU dan Memory

CPU Slider

Range: 0.25 vCPU sampai 4 vCPU (per plan).

Cara baca CPU di tab Metrics: CPU ditampilkan dalam millicores (m). 1000m = 1 vCPU.

Jika CPU chart kamu sering flatline di angka mendekati limit — itu tanda pod butuh CPU lebih. Jika CPU selalu di bawah 30% dari limit, kamu mungkin over-provisioned.

Memory Slider

Range: 256MB sampai 8GB (per plan).

Cara baca Memory di Metrics: Ditampilkan dalam MB dengan persentase dari limit. Contoh: 325 MB · 31.0% of 1024MB limit.

Tanda butuh scale up memory:

• Memory mendekati atau menyentuh limit (>80%)
• Restarts counter naik (OOM kill)
• Memory naik terus secara linear tanpa turun (memory leak — solve di kode, bukan scale)

Cara Mengubah CPU dan Memory

1. Buka Settings → Scaling & Resources
2. Geser slider CPU ke nilai yang diinginkan
3. Geser slider Memory ke nilai yang diinginkan
4. Klik Save atau Apply Changes
5. Helipod akan melakukan rolling restart untuk apply perubahan

Perubahan resource akan ter-apply langsung tanpa perlu redeploy kode.

Estimasi Biaya Setelah Scale

Ingat formula harga resource Helipod:

• CPU: Rp 300 / 0.25 vCPU / hari
• RAM: Rp 400 / 256MB / hari

Contoh kalkulasi:

Horizontal Scaling: Replicas

Replicas adalah cara menjalankan beberapa instance pod yang identik secara bersamaan, dengan traffic didistribusikan secara otomatis antar instance.

Cara Mengatur Replicas

Di Settings → Scaling & Resources → Region & Replicas, ada kontrol + dan - untuk mengatur jumlah replica.

Batas replica per plan:

Kapan Pakai Replicas?

Gunakan replicas jika:

• Traffic tinggi dan satu pod tidak cukup untuk handle semua request
• Butuh high availability — jika satu pod mati, pod lain tetap melayani traffic
• Aplikasi kamu stateless (tidak menyimpan state di memory antar request)

Jangan pakai replicas jika:

• Aplikasi kamu stateful (menyimpan session di memory, tidak di database/Redis)
• Menggunakan file local yang perlu dibaca/tulis (pakai persistent volume atau object storage)
• Punya cron job atau scheduler yang tidak boleh jalan lebih dari satu instance

Stateless vs Stateful

Ini konsep penting untuk horizontal scaling.

Stateless (aman untuk replicas):

• Session disimpan di database atau Redis
• Cache disimpan di Redis
• File disimpan di object storage (S3, Spaces) atau persistent volume yang shared
• Tidak ada in-memory data yang perlu dibagi antar instance

Stateful (butuh pertimbangan extra):

• Session disimpan di memory aplikasi
• Cache in-memory yang berbeda per instance
• File yang ditulis ke disk local container

Cara bikin stateless:

Laravel:

SESSION_DRIVER=redis
CACHE_DRIVER=redis
QUEUE_CONNECTION=redis

Django:

SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
CACHES = {
    'default': {
        'BACKEND': 'django_redis.cache.RedisCache',
        'LOCATION': os.environ['REDIS_URL'],
    }
}

Next.js — sudah stateless by default (state di client atau database).

Traffic Distribution

Helipod menggunakan round-robin load balancing antar replicas melalui Traefik. Setiap request baru dikirim ke replica berikutnya secara bergantian.

Ini berarti satu user bisa dilayani oleh replica yang berbeda di setiap request — pastikan session management sudah stateless sebelum menambah replicas.

Strategi Scaling yang Direkomendasikan

Langkah 1: Mulai Kecil

Mulai dengan spec minimum yang cukup, bukan spec maksimum. Lebih mudah scale up daripada scale down karena takut tidak cukup.

Konfigurasi starting point yang direkomendasikan:

• Simple Laravel/Django/Flask: 0.5 vCPU + 512MB
• Next.js / NestJS: 0.5 vCPU + 1GB
• Background worker: 0.25 vCPU + 256MB
• PostgreSQL: 0.5 vCPU + 512MB (untuk app kecil-medium)

Langkah 2: Monitor Selama 1 Minggu

Pantau tab Metrics selama seminggu pertama:

• CPU average usage di atas 70%? → Scale up CPU
• Memory di atas 80% limit? → Scale up Memory
• Restarts > 0? → Cek App logs, kemungkinan OOM atau crash

Langkah 3: Scale Berdasarkan Data

Jangan scale berdasarkan asumsi. Scale berdasarkan metrics actual:

CPU < 30% consistently → pertimbangkan scale DOWN (hemat biaya)
CPU 30-70% → zona nyaman
CPU > 70% consistently → scale UP atau tambah replica
Memory > 80% → scale UP memory
Restarts > 0 → investigasi root cause dulu

Langkah 4: Traffic Spike — Tambah Replicas

Untuk traffic spike yang predictable (misalnya jam 9 pagi, atau saat promo):

1. Tambah replicas sebelum spike
2. Pantau metrics selama spike
3. Kurangi replicas setelah spike untuk hemat biaya

Scaling Database

Database adalah sering bottleneck pertama sebelum aplikasinya sendiri. Untuk PostgreSQL di Helipod:

Scale up PostgreSQL pod:

• Tambah RAM untuk connection pool dan buffer cache
• Tambah CPU untuk query-heavy workload

Optimasi sebelum scale:

-- Cek query yang lambat
SELECT query, mean_exec_time, calls
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 10;

-- Cek missing indexes
SELECT relname, seq_scan, idx_scan
FROM pg_stat_user_tables
WHERE seq_scan > idx_scan
ORDER BY seq_scan DESC;

Connection pooling: Untuk aplikasi dengan banyak replica, pertimbangkan PgBouncer sebagai connection pooler agar tidak terlalu banyak koneksi ke PostgreSQL:

# Deploy PgBouncer sebagai pod terpisah
# dan arahkan connection dari app ke PgBouncer, bukan langsung ke PostgreSQL
DB_HOST=pgbouncer  # bukan postgres langsung

Tips Hemat Biaya saat Scaling

1. Scale down di jam sepi Jika traffic aplikasimu jelas-jelas rendah di malam hari, kurangi replicas di malam hari dan tambah lagi di pagi hari. Helipod menghitung resource per hari, jadi mengubah spec di tengah hari tetap lebih hemat.

2. Monitor overkill Pakai tab Metrics untuk identifikasi service yang over-provisioned. CPU selalu <10%? Memory selalu <30%? Turunkan spec dan hemat biaya.

3. Pisahkan background worker Jangan jalankan background worker (queue, scheduler) di pod yang sama dengan web server. Deploy sebagai pod terpisah dengan spec yang lebih kecil.

4. Gunakan helipack.json untuk hint resource:

{
  "spec": {
    "cpu": 0.5,
    "memory": 512
  }
}

Kesimpulan

Scaling di Helipod dirancang semudah mungkin — geser slider untuk vertical scaling, ubah angka untuk horizontal scaling. Tidak perlu konfigurasi load balancer, tidak perlu setup auto-scaling rules yang kompleks.

Yang terpenting: scale berdasarkan data dari tab Metrics, bukan berdasarkan asumsi. Mulai kecil, monitor, dan scale saat memang dibutuhkan.

Ingin setup database untuk aplikasimu? Baca Deploy PostgreSQL di Helipod.

Punya pertanyaan? Hubungi kami di support@helipod.id atau bergabung ke komunitas di hangar.helipod.io.