Infrastructure Recommendation

Arsitektur Infrastruktur Kreen yang Lebih Aman, Stabil, dan Siap Bertumbuh

Dokumen ini menjelaskan rancangan infrastruktur untuk platform B2C voting dan transaksi. Fokusnya bukan sekadar mencegah server crash, tetapi memastikan ketika satu komponen bermasalah, sistem tetap berjalan atau dapat dipulihkan dengan cepat tanpa kehilangan data penting.

Tujuan 1 App crash tidak ikut menjatuhkan database.

Tujuan 2 Database memiliki failover dan backup yang benar-benar bisa dipulihkan.

Tujuan 3 Lonjakan voting tidak boleh mematikan checkout, payment, dan webhook.

Kesimpulan Utama

Bukan sekadar membeli 2 server

Memisahkan App Server dan Database Server memang lebih baik dibanding satu VM untuk semua. Namun jika database masih hanya berada di satu VM, database tetap menjadi single point of failure.

Untuk sistem B2C transaksi tinggi, arsitektur final sebaiknya memisahkan fungsi utama dan memakai layanan yang memiliki redundansi bawaan.

Pilihan yang direkomendasikan

2+ App Instance + Load Balancer + Cloud SQL HA + Redis + Cloud Storage + Backup & PITR

Ini adalah titik tengah yang kuat: cukup aman untuk sistem transaksi serius, tetapi belum terlalu kompleks seperti Kubernetes atau multi-cloud.

Pahami Ini Dulu

Jadi sebenarnya kita butuh berapa VM?

Rekomendasi awal: 2 VM untuk aplikasi

Kita bukan membeli 1 server besar lalu membagi-baginya sendiri. Di GCP kita membuat 2 VM yang benar-benar terpisah. Masing-masing VM memiliki CPU, RAM, disk, dan OS Ubuntu sendiri.

Google Cloud Platform (GCP)

↓

VM TERPISAH #1 — APP A
1 VM = 1 OS Ubuntu sendiri
Laravel / PHP / Nginx

VM TERPISAH #2 — APP B
1 VM = 1 OS Ubuntu sendiri
Laravel / PHP / Nginx

↓

CLOUD SQL HA — DATABASE
Bukan VM database yang kita kelola sendiri.
Database managed oleh Google, dengan primary + standby.

VM #1

App A

Menjalankan website/app. Punya OS sendiri. Kalau VM ini rusak, VM #2 tetap bisa melayani user.

VM #2

App B

Salinan App A yang aktif juga. Bukan backup mati. Load Balancer bisa membagi traffic ke keduanya.

Database

Cloud SQL HA

Bukan “VM #3” biasa. Google yang mengelola mesin database, OS, failover primary/standby, dan integrasinya.

Yang tidak disarankan: upgrade satu VM menjadi sangat besar lalu tetap menaruh App + Database + file di dalam VM yang sama. Server memang lebih kuat, tetapi kalau VM tersebut rusak, semuanya tetap ikut mati.

Arsitektur Final

Bagaimana sistem akan bekerja

User tetap melihat satu website. Di belakangnya ada 2 VM aplikasi yang terpisah. Masing-masing VM memiliki OS sendiri. Di luar kedua VM tersebut, database menggunakan Cloud SQL HA, sehingga database tidak lagi ditempatkan di dalam VM aplikasi.

Internet / User

↓

Cloud Armor
Proteksi bot, abuse, rate limit

↓

HTTPS Load Balancer
Membagi traffic ke server sehat

↓

VM TERPISAH #1 — APP A
OS Ubuntu sendiri
Laravel / PHP / Nginx

VM TERPISAH #2 — APP B
OS Ubuntu sendiri
Laravel / PHP / Nginx

↓

Cloud SQL HA — DATABASE
Bukan VM biasa yang kita urus sendiri
Primary + Standby dikelola Google

Redis / Memorystore
Session, cache, rate limit

Cloud Storage
Upload & file user

↓

Automated Backup

Point-in-Time Recovery

Independent Backup Copy

Bahasa Sederhana

Apa fungsi setiap komponen?

Load Balancer

Pengatur jalur traffic

Jika App Server A bermasalah, traffic otomatis diarahkan ke App Server B. User tidak perlu tahu ada server yang sedang gagal.

App Instance

Tempat aplikasi berjalan

Laravel/PHP berjalan di lebih dari satu instance. Server aplikasi dianggap bisa dibuang dan dibuat ulang, sehingga tidak boleh menyimpan data penting secara lokal.

Cloud SQL HA

Database dengan cadangan aktif

Database memiliki primary dan standby. Jika primary gagal, failover dapat dilakukan tanpa proses restore manual panjang.

Redis

Penampung data sementara

Session login, cache, rate-limit counter, dan sebagian queue dapat dipindahkan ke Redis supaya App Server tidak saling bergantung.

Cloud Storage

Penyimpanan file terpisah

File user, poster, QR, attachment, dan upload penting tidak lagi disimpan di disk App Server.

Backup & PITR

Proteksi saat data rusak atau terhapus

Backup melindungi dari kerusakan besar. Point-in-Time Recovery membantu mengembalikan database ke waktu sebelum kesalahan terjadi.

Kenapa 2 VM Saja Belum Cukup?

App Server + Database Server masih punya celah

Yang sudah menjadi lebih baik

App crash tidak langsung merusak database.
Resource CPU dan RAM app tidak lagi berebut langsung dengan database.
Maintenance lebih mudah dipisahkan.

Yang masih berbahaya

Jika DB Server rusak, sistem tetap berhenti total.
Tidak ada failover cepat.
Recovery bergantung pada kualitas backup.
Jika backup tidak pernah dites, waktu recovery tidak diketahui.

Kesimpulan: pemisahan App dan DB boleh dipakai sebagai langkah sementara, tetapi sebaiknya bukan desain akhir untuk platform transaksi.

Backup Strategy

Backup harus berlapis, bukan hanya satu snapshot

Layer 1

Automated Backup

Backup database otomatis setiap hari dengan retention yang cukup.

Layer 2

Point-in-Time Recovery

Mengembalikan database ke titik waktu tertentu sebelum data terhapus atau rusak.

Layer 3

Independent Backup

Salinan backup terpisah dari lingkungan production untuk melindungi dari human error atau kegagalan besar.

Prinsip penting: backup yang belum pernah diuji restore belum bisa dianggap backup yang siap dipakai.

Traffic Tinggi

Voting tidak boleh menjatuhkan payment

Salah satu risiko terbesar adalah endpoint voting menjadi viral atau diserang bot. Jika semua proses berada di jalur resource yang sama, lonjakan voting bisa ikut mematikan checkout dan payment callback.

Traffic Masuk

↓

Rate Limit / Cloud Armor

↓

Voting Pool
boleh scale agresif

Transaction Pool
checkout & payment

Worker Pool
email, WA, PDF, analytics

Jika voting tiba-tiba penuh, target kita adalah vote mungkin melambat, tetapi payment callback dan transaksi tetap hidup.

Resource Protection

Auto-scaling saja tidak cukup

App harus diberi batas supaya satu endpoint tidak bisa menghabiskan seluruh CPU, worker, atau koneksi database.

PHP / App

Batas worker PHP-FPM.
Request timeout.
Memory limit.
Queue worker limit.
Rate limit per endpoint.

Database

Batas koneksi database.
Slow query monitoring.
Index & query review.
Connection pool / concurrency planning.
Alarm ketika koneksi mulai penuh.

Monitoring

Masalah harus diketahui sebelum user komplain

Yang Dipantau	Warning	Critical
App CPU	> 65%	> 80%
RAM	> 75%	> 90%
Disk	> 70%	> 85%
HTTP 5xx	Naik tidak normal	Spike tinggi
DB CPU	> 65%	> 80%
DB Connection	> 70%	> 85%
Queue backlog	Tumbuh abnormal	Tidak bergerak / terlalu besar
Backup	-	Gagal = alert langsung

Notifikasi penting sebaiknya tidak hanya masuk email. Untuk P1/P0, gunakan channel yang benar-benar dilihat tim operasional.

Target Reliability

Apa yang seharusnya terjadi ketika ada masalah?

Kejadian	Target Respons Sistem
Satu App Instance mati	Traffic pindah otomatis ke instance lain.
CPU voting melonjak	Scale up + rate limit, payment tetap terlindungi.
Database primary gagal	Failover ke standby.
Developer salah hapus data	Recovery dengan PITR.
OS App Server rusak	Instance diganti, data bisnis tidak hilang.
Backup gagal	Alert langsung ke tim.

Pilihan Arsitektur

Perbandingan singkat

Opsi	Keamanan	Operasional	Rekomendasi
1 VM App + DB	Rendah	Sederhana	Jangan digunakan lagi
1 VM App + 1 VM DB	Sedang	Cukup sederhana	Bagus untuk sementara
2 VM Active/Standby self-managed	Sedang–Tinggi	Lebih rumit, banyak manual failover	Bukan pilihan utama
Regional App + Cloud SQL HA	Tinggi	Relatif terkelola	Pilihan utama
GKE / Kubernetes	Tinggi	Kompleks	Belum perlu
Multi-cloud	Tinggi secara teori	Sangat kompleks	Belum perlu

Rencana Implementasi

Urutan yang paling aman

Aktifkan backup darurat sekarang.
Scheduled snapshot + logical database backup + tes restore pertama.

Aktifkan monitoring dan alert.
CPU, RAM, disk, DB connection, 5xx, queue, backup failure.

Cari root cause CPU 100%.
Cek request spike, query berat, worker runaway, cron, bot, dan endpoint voting.

Siapkan Cloud SQL HA.
Private IP, backup otomatis, PITR, retention policy.

Replikasi database lama ke Cloud SQL.
Gunakan continuous replication agar downtime cutover bisa ditekan.

Jadikan App stateless.
Upload ke Cloud Storage, session/cache ke Redis.

Buat minimal 2 App Instance.
Pasang Load Balancer, health check, autoscaling, Cloud Armor.

Pisahkan workload berat.
Voting, transaksi, payment webhook, dan worker tidak boleh berebut resource tanpa batas.

Uji kegagalan.
Matikan App A, test failover DB, test restore backup, test load voting.

Baru pensiunkan arsitektur lama.
Setelah sistem baru lolos smoke test, load test, dan restore test.

Catatan Penting

HA, Backup, dan Disaster Recovery itu berbeda

High Availability

Server atau database rusak, sistem tetap dapat melayani user.

Backup

Data rusak atau terhapus, masih ada salinan yang bisa dikembalikan.

Disaster Recovery

Jika ada kegagalan besar, tim punya prosedur jelas untuk membangun dan memulihkan sistem.

Rekomendasi final

Gunakan 2 VM App terpisah (masing-masing punya OS sendiri) + Cloud SQL HA + HTTPS Load Balancer + Cloud Armor + Redis + Cloud Storage + Automated Backup + PITR.

Arsitektur ini cukup kuat untuk platform voting dan transaksi B2C dengan traffic tinggi, tanpa masuk ke kompleksitas Kubernetes atau multi-cloud yang belum diperlukan saat ini.