# Arsitektur Multi-Region High Availability untuk Backend Web Modern

> Diterbitkan oleh Literally Web ID pada 21 Oct 2026
> Sumber: https://literally.web.id/articles/arsitektur-multi-region-high-availability-untuk-backend-web-modern

---

## 1. Menu Kita Hari Ini & Alat yang Perlu Disiapkan

Pernahkah Anda mengalami malam Jumat kelabu ketika AWS Region us-east-1 tiba-tiba *down*, dan seluruh aplikasi Anda ikut tumbang bersama ribuan komplain pengguna yang membanjiri channel Telegram? Sebagai engineer yang pernah terjaga pukul 3 pagi karena skenario horor itu, saya belajar satu hal pahit: *Single point of failure* di level infrastruktur cloud adalah dosa yang harus segera ditebus.

Dalam 15 menit ke depan di dapur infrastruktur ini, kita tidak akan sekadar berteori. Kita akan merakit arsitektur multi-region *high availability* dari nol sampai benar-benar berjalan mulus. Kita akan menghubungkan Cloudflare Anycast DNS, menyambungkan replikasi database MySQL Group Replication berlatensi rendah lintas benua (misalnya Singapura dan Frankfurt), dan menyiapkan skrip failover otomatis agar aplikasi Go dan Nginx kita tetap bernafas meskipun salah satu region cloud lenyap dari peta.

Sediakan secangkir kopi hitam Anda, buka terminal, pastikan akses ke minimal dua cloud provider atau dua region berbeda sudah siap, dan mari kita mulai meraciknya.

> [!TIP]
> Jangan khawatir jika Anda belum memiliki dua server fisik; Anda bisa menggunakan dua VPS berbeda region dari provider seperti DigitalOcean, Linode, atau AWS (misal `ap-southeast-1` dan `eu-central-1`) untuk simulasi nyata hari ini.

## 2. Peta Jalan Singkat: Sebelum Kita Masuk ke Dapur Inti

Sebelum tangan kita kotor oleh konfigurasi, mari kita petakan dulu apa yang sebenarnya sedang kita bangun agar tidak ada langkah yang meleset. Bayangkan sistem kita sebagai sebuah restoran mewah dengan dua cabang lintas benua. Pelanggan dari Asia akan diarahkan secara cerdas ke dapur Singapura, sementara pelanggan Eropa disambut oleh dapur Frankfurt.

Namun, bagaimana jika dapur Singapura mendadak kebakaran? Di sinilah keajaiban terjadi. Cloudflare Anycast DNS akan mendeteksi gangguan tersebut dalam hitungan detik dan mengalihkan seluruh lalu lintas ke Frankfurt secara otomatis. Sementara itu, database kita pastikan selalu sinkron secara *multi-master* atau *active-passive* dengan replikasi asinkron berkecepatan tinggi.

Transisi mulus ini menuntut koordinasi presisi antara DNS Edge, Web Server Nginx, Backend Go, dan Database MySQL. Mari kita mulai dari fondasinya.

## 3. Langkah 1: Mempersiapkan Fondasi & Environment

Fondasi yang kokoh dimulai dari konfigurasi sistem operasi dan jaringan dasar yang seragam di setiap region. Asumsikan kita menggunakan Ubuntu 22.04 LTS pada node Region A (Singapura) dan Region B (Frankfurt).

Pertama, SSH ke kedua server Anda dan pastikan parameter kernel Linux di `/etc/sysctl.conf` sudah di-tuning untuk menangani *high concurrency* dan koneksi jaringan jarak jauh:

```bash
# /etc/sysctl.conf - Tuning Network Stack untuk Multi-Region
fs.file-max = 2097152
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.core.netdev_max_backlog = 16384
```

Terapkan perubahan tersebut dengan menjalankan perintah legendaris ini di terminal:

```bash
sysctl -p
```

Lihat respons di layar Anda? Pesan sukses yang keluar menandakan kernel sistem operasi kita kini sudah siap menahan hantaman ribuan request lintas benua tanpa megap-megap. Selanjutnya, kita akan meracik konfigurasi inti yang menjembatani lalu lintas global ini.

## 4. Langkah 2: Meracik Konfigurasi Inti Tanpa Basa-basi

Bagian paling krusial dari arsitektur multi-region adalah bagaimana cara kita mengarahkan pengguna dan menjaga konsistensi data. Kita akan membaginya menjadi tiga lapis: Global DNS, Web Layer (Nginx + Go), dan Database.

### A. Global Anycast DNS & Geo-routing via Cloudflare API / Dashboard
Alih-alih menggunakan DNS konvensional, kita menggunakan Cloudflare Load Balancing dengan *Geo-steering*. Buat dua Record A untuk domain utama `api.perusahaan.com`:
- IP Node A (Singapura): `103.x.x.1` (Weight: 100)
- IP Node B (Frankfurt): `198.x.x.2` (Weight: 100)

Aktifkan Health Check Cloudflare dengan interval 10 detik. Jika endpoint `/healthz` di Node A mengembalikan status HTTP 5xx selama 3 kali berturut-turut, Cloudflare secara otomatis mencabut IP Node A dari DNS response.

### B. Web Server Nginx di Setiap Region
Di kedua region, pasang Nginx sebagai reverse proxy yang meneruskan request ke backend aplikasi Go kita yang berjalan di port `8080`.

```nginx
# /etc/nginx/sites-available/api.perusahaan.com
server {
    listen 80;
    server_name api.perusahaan.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        # Timeout tuning untuk lintas benua
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
    }

    # Endpoint khusus health check untuk Cloudflare
    location /healthz {
        access_log off;
        return 200 "OK, Region Healthy\n";
    }
}
```

### C. Replikasi Database Lintas Region (MySQL Group Replication / Master-Replica)
Untuk database, skenario paling realistis tanpa kompleksitas berlebih adalah *Active-Passive with Fast Promotion* menggunakan MySQL dengan *GTID (Global Transaction Identifier)*.

Di Node A (Primary - Singapura), pastikan konfigurasi `/etc/mysql/mysql.conf.d/mysqld.cnf` memiliki parameter berikut:

```ini
[mysqld]
server-id               = 1
log_bin                 = /var/log/mysql/mysql-bin.log
gtid_mode               = ON
enforce_gtid_consistency = ON
log_slave_updates       = ON
read_only               = 0
```

Di Node B (Replica - Frankfurt), konfigurasikan sebagai berikut:

```ini
[mysqld]
server-id               = 2
log_bin                 = /var/log/mysql/mysql-bin.log
gtid_mode               = ON
enforce_gtid_consistency = ON
log_slave_updates       = ON
read_only               = 1
```

Hubungkan Node B ke Node A melalui jaringan privat yang diamankan VPN (WireGuard): penyambungan replikasi dilakukan via SQL:

```sql
CHANGE MASTER TO 
  MASTER_HOST='10.0.0.1',
  MASTER_USER='replica_user',
  MASTER_PASSWORD='PasswordKuat123!',
  MASTER_AUTO_POSITION=1;
START SLAVE;
```

Periksa status replikasi dengan `SHOW SLAVE STATUS\G`. Pastikan `Slave_IO_Running` dan `Slave_SQL_Running` bernilai `Yes`. Jika ya, data Anda kini mengalir melintasi benua dalam hitungan milidetik. Namun, infrastruktur yang hebat belum lengkap tanpa benteng keamanan.

## 5. Langkah 3: Sentuhan Akhir Keamanan & Optimasi

Infrastruktur multi-region yang terbuka ke internet publik adalah undangan terbuka bagi para bot jahat dan serangan DDoS. Kita perlu mengamankannya di level Edge dan Host.

1. **WAF & SSL/TLS di Cloudflare**: Aktifkan aturan WAF (Web Application Firewall) dasar untuk memblokir SQL Injection dan XSS. Paksa penggunaan TLS 1.3 dengan *Full (Strict)* SSL Mode.
2. **Firewall Lokal (UFW)**: Di setiap VPS region, kunci akses port database agar hanya bisa diakses dari IP privat antar-region via VPN.

```bash
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow from 10.0.0.0/8 to any port 3306
sudo ufw enable
```

Konfigurasi ini memastikan hanya Nginx yang bisa melayani publik, sementara komunikasi database antar-region terkunci rapat di dalam terowongan privat WireGuard. Kini saatnya kita menguji racikan kita di atas meja laboratorium.

## 6. Tes Rasa: Memastikan Semuanya Berjalan Sempurna

Koki yang baik selalu mencicipi masakannya sebelum disajikan ke tamu. Mari kita verifikasi apakah arsitektur multi-region kita benar-benar tahan banting.

Jalankan skrip pengujian sederhana menggunakan `curl` untuk memantau endpoint `/healthz` dan header respons dari server kita:

```bash
while true; do
  curl -I https://api.perusahaan.com/healthz
  sleep 2
done
```

Sekarang, simulasikan bencana: matikan Nginx atau putuskan koneksi di Node A (Singapura) dengan perintah `sudo systemctl stop nginx`.

Perhatikan terminal Anda. Dalam waktu 10 hingga 15 detik (sesuai interval health check Cloudflare), Cloudflare akan mendeteksi kematian Node A dan otomatis mengalihkan request ke Node B (Frankfurt). Anda akan melihat request tetap terlayani tanpa *downtime* yang berarti bagi pengguna akhir. Itulah keindahan dari *automatic disaster recovery*.

## 7. Pertolongan Pertama: Jika Terjadi Kendala Kecil

Di lapangan nyata, teori tidak selalu berjalan mulus tanpa kerikil. Berikut contekan penanganan cepat saatTroubleshooting:

- **Kendala 1: Replikasi MySQL Terputus (*Slave Lag* / *Error*)**
  *Penyebab*: Latensi jaringan trans-kontinental melonjak atau terjadi *duplicate key error*.
  *Solusi*: Masuk ke konsol MySQL Frankfurt, jalankan `STOP SLAVE; SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;`. Perbaiki juga parameter jaringan kernel jika latensi melebihi 250ms.
- **Kendala 2: Cloudflare Health Check Selalu Mengembalikan 5xx**
  *Penyebab*: Firewall lokal (UFW) atau Cloudflare Proxy memblokir IP range Cloudflare.
  *Solusi*: Pastikan Anda mengizinkan IP range Cloudflare di konfigurasi Nginx atau UFW, dan pastikan SSL sertifikat di origin server valid (bukan self-signed yang kedaluwarsa).

Dengan resep ini, Anda tidak perlu lagi terbangun ketakutan di tengah malam. Infrastruktur Anda kini berdiri kokoh, siap menghadapi terjangan badai digital apa pun dari penjuru dunia.