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.
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.
Ini adalah titik tengah yang kuat: cukup aman untuk sistem transaksi serius, tetapi belum terlalu kompleks seperti Kubernetes atau multi-cloud.
Jadi sebenarnya kita butuh berapa VM?
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.
1 VM = 1 OS Ubuntu sendiri
Laravel / PHP / Nginx
1 VM = 1 OS Ubuntu sendiri
Laravel / PHP / Nginx
Bukan VM database yang kita kelola sendiri.
Database managed oleh Google, dengan primary + standby.
App A
Menjalankan website/app. Punya OS sendiri. Kalau VM ini rusak, VM #2 tetap bisa melayani user.
App B
Salinan App A yang aktif juga. Bukan backup mati. Load Balancer bisa membagi traffic ke keduanya.
Cloud SQL HA
Bukan “VM #3” biasa. Google yang mengelola mesin database, OS, failover primary/standby, dan integrasinya.
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.
Proteksi bot, abuse, rate limit
Membagi traffic ke server sehat
OS Ubuntu sendiri
Laravel / PHP / Nginx
OS Ubuntu sendiri
Laravel / PHP / Nginx
Bukan VM biasa yang kita urus sendiri
Primary + Standby dikelola Google
Session, cache, rate limit
Upload & file user
Apa fungsi setiap komponen?
Pengatur jalur traffic
Jika App Server A bermasalah, traffic otomatis diarahkan ke App Server B. User tidak perlu tahu ada server yang sedang gagal.
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.
Database dengan cadangan aktif
Database memiliki primary dan standby. Jika primary gagal, failover dapat dilakukan tanpa proses restore manual panjang.
Penampung data sementara
Session login, cache, rate-limit counter, dan sebagian queue dapat dipindahkan ke Redis supaya App Server tidak saling bergantung.
Penyimpanan file terpisah
File user, poster, QR, attachment, dan upload penting tidak lagi disimpan di disk App Server.
Proteksi saat data rusak atau terhapus
Backup melindungi dari kerusakan besar. Point-in-Time Recovery membantu mengembalikan database ke waktu sebelum kesalahan terjadi.
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.
Backup harus berlapis, bukan hanya satu snapshot
Automated Backup
Backup database otomatis setiap hari dengan retention yang cukup.
Point-in-Time Recovery
Mengembalikan database ke titik waktu tertentu sebelum data terhapus atau rusak.
Independent Backup
Salinan backup terpisah dari lingkungan production untuk melindungi dari human error atau kegagalan besar.
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.
boleh scale agresif
checkout & payment
email, WA, PDF, analytics
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.
Load Balancer, proteksi bot, WAF, dan apa saja yang sebenarnya dibutuhkan?
Sebelum traffic masuk ke dua VM aplikasi, sebaiknya ada lapisan depan yang mengatur traffic dan menyaring request berbahaya. Untuk Kreen, saya tidak menyarankan membeli semua fitur paling mahal sejak awal. Kita pakai yang memang relevan.
1 domain tetap sama • membagi traffic ke VM sehat
WAF • rate limit • block IP/negara/pattern berbahaya
Vote • Login • Register • Checkout • endpoint rawan bot
OS Ubuntu sendiri
OS Ubuntu sendiri
1. HTTPS Load Balancer
Domain seperti kreenconnect.com diarahkan ke Load Balancer.
Load Balancer mengecek VM mana yang sehat dan membagi traffic ke VM App #1 dan VM App #2.
Contoh: kalau VM #1 mati, request baru otomatis diarahkan ke VM #2.
2. Cloud Armor Standard
Ini lapisan firewall aplikasi / WAF di depan VM. Bisa dipakai untuk memblokir request abnormal, rate limiting, IP/range tertentu, dan memakai preconfigured WAF rules untuk serangan umum seperti SQL injection, XSS, file inclusion, dan remote code execution.
3. Rate Limiting
Dipakai supaya satu bot, user, IP, token, atau pola traffic tidak bisa membanjiri endpoint. Google Cloud Armor mendukung mode throttle dan temporary rate-based ban.
Batasnya tidak boleh dibuat asal. Endpoint /vote, login, API, checkout, dan webhook
harus punya aturan berbeda.
4. reCAPTCHA / Bot Check
Tidak perlu ditampilkan ke semua user di semua halaman. Gunakan terutama ketika sistem mendeteksi risiko, atau untuk endpoint yang memang rawan otomatisasi seperti voting dan login.
Cloud Armor dapat memakai hasil penilaian reCAPTCHA untuk allow, deny, rate-limit, atau memberikan challenge.
5. Cloud CDN
Berguna untuk poster, gambar, CSS, JavaScript, dan file static agar tidak semuanya diambil dari VM. Ini dapat mengurangi beban server dan mempercepat akses user, tetapi biaya tergantung bandwidth.
6. Cloud Armor Enterprise
Memberikan proteksi dan model enterprise yang lebih tinggi, tetapi untuk kondisi sekarang saya belum melihat alasan untuk langsung membayar tier ini. Mulai dari Standard, ukur traffic dan serangan, lalu upgrade jika memang diperlukan.
HTTPS Load Balancer + Cloud Armor Standard + WAF rules + Rate Limiting + reCAPTCHA selektif.
Cloud CDN ditambahkan jika traffic gambar/static memang cukup besar. Cloud Armor Enterprise belum perlu.
Berapa biaya Load Balancer, WAF, dan bot protection?
Harga berikut menggunakan harga publik Google Cloud yang aktif saat dokumen diperbarui dan kurs ilustrasi US$1 ≈ Rp17.630. Nilai rupiah dapat berubah mengikuti kurs dan tagihan GCP sebenarnya. Angka di bawah belum termasuk VM App, Cloud SQL, Redis, storage, dan internet egress utama.
| Komponen | Harga Resmi / Formula | Contoh Rupiah | Keputusan |
|---|---|---|---|
| HTTPS Load Balancer |
Forwarding rule pertama: US$0,025/jam. Data processing regional: US$0,008/GiB inbound dan outbound. |
Biaya dasar sekitar US$18,25/bulan ≈ Rp322 ribu. Jika total data yang diproses 500 GiB/bulan: sekitar US$22,25 ≈ Rp392 ribu, sebelum internet egress. |
WAJIB |
| Cloud Armor Standard |
Security policy sekitar US$0,006849/jam (~US$5/bulan). Rule sekitar US$0,00137/jam (~US$1/rule/bulan). Global requests: US$0,75 per 1 juta request. |
Contoh 1 policy + 10 rules + 10 juta request: sekitar US$22,50 ≈ Rp397 ribu/bulan. |
WAJIB |
| Rate Limiting | Dibuat sebagai rule di Cloud Armor. Tidak perlu membeli produk rate-limit terpisah; biaya mengikuti policy/rule/request Cloud Armor. | Sudah masuk dalam contoh biaya Cloud Armor di atas, tergantung jumlah rules dan requests. | WAJIB |
| reCAPTCHA Essentials | Gratis sampai 10.000 assessments/bulan per organization. | Rp0 jika masih dalam free allowance. | SELEKTIF |
| reCAPTCHA Premium |
1–10.000 assessments: gratis. 10.001–100.000: US$8 flat/bulan. Di atas 100.000: pricing usage berlaku US$1 per 1.000 assessments. |
Sampai 100.000 assessment berada di kisaran US$8 ≈ Rp141 ribu/bulan. | PAKAI JIKA PERLU |
| Cloud Armor Enterprise Paygo | Sekitar US$200/bulan untuk hingga 2 protected resources, kemudian ada data processing charge. | Biaya dasar sekitar Rp3,53 juta/bulan sebelum biaya pemrosesan data. | BELUM PERLU |
| Cloud CDN | Untuk Jakarta, cache data transfer out pada tier awal tercantum sekitar US$0,12/GiB untuk penggunaan di bawah 10 TiB, ditambah request/cache-related charges. | Contoh 500 GiB cache delivery: sekitar US$60 ≈ Rp1,06 juta hanya untuk komponen transfer CDN tersebut. | OPSIONAL |
Dengan traffic ilustratif 10 juta request/bulan, 10 Cloud Armor rules, dan sekitar 500 GiB data diproses Load Balancer:
Load Balancer ± Rp392 ribu
+ Cloud Armor Standard ± Rp397 ribu
+ reCAPTCHA Rp0–Rp141 ribu pada volume assessment rendah/menengah
Jadi orde biaya lapisan Load Balancer + WAF + rate-limit + bot check bisa sekitar Rp800 ribu–Rp930 ribu/bulan pada contoh ini, sebelum VM, database, internet egress, logging, dan layanan lainnya.
Dokumentasi resmi Google Cloud
Cloud Load Balancing Pricing — cloud.google.com/load-balancing/pricing
Cloud Armor Pricing — cloud.google.com/armor/pricing
reCAPTCHA Pricing — cloud.google.com/security/products/recaptcha
Cloud CDN Pricing — cloud.google.com/cdn/pricing
Harga diperiksa pada September 2026. Tagihan final mengikuti SKU, region, traffic, kurs billing, serta konfigurasi aktual di project Google Cloud.
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.
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. |
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 |
Urutan yang paling aman
Scheduled snapshot + logical database backup + tes restore pertama.
CPU, RAM, disk, DB connection, 5xx, queue, backup failure.
Cek request spike, query berat, worker runaway, cron, bot, dan endpoint voting.
Private IP, backup otomatis, PITR, retention policy.
Gunakan continuous replication agar downtime cutover bisa ditekan.
Upload ke Cloud Storage, session/cache ke Redis.
Pasang Load Balancer, health check, autoscaling, Cloud Armor.
Voting, transaksi, payment webhook, dan worker tidak boleh berebut resource tanpa batas.
Matikan App A, test failover DB, test restore backup, test load voting.
Setelah sistem baru lolos smoke test, load test, dan restore test.
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.
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.