Belajar Kubernetes Block Storage RWO - Scaling Database & Application Pakai RWO

#Pendahuluan

Semua komponen sudah rampung: database persisten, aplikasi terpenuhi, backup & monitoring jalan. Episode 19 berfokus pada skenario paling umum tim production: beban naik. Bagaimana menskalakan aplikasi dan database dalam model RWO yang "satu primary saja"?

Mengapa penting? Di sini kalian memahami prinsip scaling yang benar: database tidak di-scale dengan menambah writer, melainkan dengan menambah roda baca dan mengoptimalkan aplikasi. Memahami ini mencegah kalian membuat arsitektur yang justru menambah failure.

#Scaling App, Bukan DB

#Pola: Replica App Banyak, DB Tetap Satu

Aplikasi Laravel adalah stateless. Jumlah replicanya bisa naik-turun bebas:

yaml

spec:
  replicas: 5   # dari 2

DB tetap satu primary (postgres-0) dengan volume RWO. Ini desain yang sehat — tapi database kini menjadi bottleneck: semua replica mengirimi query ke satu instance.

#Solusi: Baca di Replika, Tulis di Primary

Tambahkan read-replica PostgreSQL dengan volume RWO sendiri:

Buat StatefulSet postgres-replica (replicas 2) dengan template volumeClaimTemplates sendiri.
Konfigurasi streaming replication dari postgres-0 ke replika.
Arahkan query baca (SELECT) ke replika; tulis tetap ke primary.

Laravel mendukung hal ini via read/write connections:

env

DB_CONNECTION=pgsql
DB_HOST=postgres                  # primary (tulis)
DB_READ_HOST=postgres-replica     # replika (baca)

Dengan pola ini, beban baca menyebar ke replika, dan volume RWO tiap replika tetap eksklusif — tidak ada yang berbagi volume antar Node.

#Read-Replica PostgreSQL / MySQL

#Architecture

100%

#Orchestrasi HA (Opsional)

Untuk HA yang lebih matang, gunakan manajer replikasi seperti:

repmgr (PostgreSQL) — failover otomatis & pemantauan replika.
Patroni — menyediakan kuorum & leader election untuk HA postgres.

Keduanya berjalan di atas StatefulSet; setiap anggota memakai volume RWO miliknya sendiri. Ini mengubah "satu primary + replika manual" menjadi "cluster yang bisa saling ambil alih".

Catatan: RWO volume tetap per-Pod; hanya data yang direplikasi lewat log (WAL/streaming), bukan lewat berbagi filesystem.

#HPA pada App

#Horizontal Pod Autoscaler

Autoscale untuk aplikasi stateless — bukan DB:

yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: laravel-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: laravel
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

DB tetap stabil single-writable — tidak ikut auto-scale.

#Cache & Queue

Untuk beban tinggi:

Redis sebagai cache dan queue (mulai redis diklaim PVC, atau AWS ElastiCache/Redis).
Laravel Queue worker sebagai Deployment terpisah (stateless) — memperbanyak worker saat antrian menumpuk.

Ini meredam beban langsung ke database, memungkinkan DB session terus kecil.

#Kapan UpSize Disk

#Pantau Penggunaan

Rutin cek penggunaan volume:

Cek disk usage di Pod

kubectl exec -it postgres-0 -- df -h /var/lib/postgresql/data
kubectl exec -it postgres-0 -- du -sh /var/lib/postgresql/data

#Kapan Memperbesar

Jika penggunaan > 70% dan tren terus naik.
Sebelum peak season (misal promo e-commerce).
Karena expand (episode 18/20) online, tidak ada alasan menunggu sampai penuh. Expand lebih dulu, lebih aman.

#Menambah Node & Disk

Jika tungku disk terlalu besar untuk satu node, tambah node worker + disk baru (episode 10) untuk menambah kapasitas pool.

Warning

Jangan pernah menskalakan DB dengan menambah primary (multi-writer) di atas volume RWO — dua writer di volume yang sama = korupsi. Konsep yang benar: primary + read-replica dengan replikasi streaming. RWO memang memperbolehkan hanya satu writer per volume; multi-primary memerlukan dirancang oleh DB itu sendiri (mis. PostgreSQL logical replication) yang kompleks.

#Penutup

Inti yang harus dibawa pulang:

Scale aplikasi = perbanyak replica Deployment; DB tunggal + read-replica.
Setiap read-replica punya volume RWO sendiri — replikasi via WAL, bukan share filesystem.
HPA untuk app; cache/queue untuk meredam beban DB.
Perbesar disk lebih awal (>70%), karena resize online tanpa downtime.

Di episode 20 selanjutnya kita akan membahas volume expansion & allowVolumeExpansion untuk database yang terus bertumbuh — mengapa fitur ini wajib, cara kerja online expansion di Longhorn, manifest StorageClass dengan allowVolumeExpansion, dan verifikasi resize filesystem. Sampai jumpa di episode 20!