Belajar Cloud Architect - Multi-Region & Data Residency
Ketika aplikasi melayani user global atau wajib mematuhi hukum regional, satu region tidak cukup. Episode ini membandingkan active-active vs active-passive, membedah data residency & sovereignty, dan merancang arsitektur multi-region yang menyeimbangkan latensi, kepatuhan, dan biaya
#Pendahuluan
Di episode 8 kita mengenal multi-region sebagai tingkat tertinggi ketahanan, dan di episode 14 membahas cluster per-region. Episode ini membahas pertanyaan yang lebih dalam: kapan dan bagaimana beroperasi di banyak region sekaligus.
Multi-region menambah biaya, kompleksitas, dan kewajiban kepatuhan — tapi kadang tidak bisa dihindari. Ada dua alasan utama: user tersebar global (latensi), dan hukum yang mengikat data di wilayah tertentu (data residency). Episode ini membangun kerangka keputusan untuk keduanya.
#Kapan Multi-Region Diperlukan
| Pemicu | Jenis Solusi |
|---|---|
| User global, SLO latency ketat | Region di dekat user (multi-region aktif) |
| Disaster recovery dari bencana regional | Region kedua sebagai standby (episode 8) |
| Hukum: data wajib di negara X | Region di negara X (data residency) |
| Ketersediaan layanan negara | Region independen per negara |
Penting untuk membedakan: multi-region untuk latency dan multi-region untuk kepatuhan adalah masalah yang berbeda, meskipun solusinya mirip.
#Active-Active vs Active-Passive
#Active-Passive (Standby)
Satu region aktif melayani traffic; region kedua standby — menjalankan layanan tapi tidak menerima traffic nyata (kecuali untuk DR test). Data direplikasi dari aktif ke standby.
| Kelebihan | Kekurangan |
|---|---|
| Simpler: satu region yang "benar" | Failover ada jeda (RTO menit) |
| Tanpa konflik data tulis | Region standby "menganggur" |
| Lebih murah | Tidak membantu latency global |
#Active-Active
Semua region aktif melayani traffic. User diarahkan ke region terdekat; data ditulis di region lokal dan direplikasi.
| Kelebihan | Kekurangan |
|---|---|
| Latency rendah untuk semua user | Konflik tulis lintas region harus ditangani |
| RTO/RPO mendekati nol | Replikasi data jauh lebih kompleks |
| Utilisasi resource penuh | Biaya dan kompleksitas tinggi |
#Aturan Praktis
- Butuh DR sederhana? → active-passive.
- Butuh latency global + user tersebar? → active-active — tapi hanya untuk workload yang data-nya bisa ditangani eventual consistency (episode 3), atau dengan strategi tulis khusus.
Kepatuhan/DR → active-passive (sederhana, cukup)
Latency global → active-active (bila konsistensi mengizinkan)
Sangat kritis → active-active + conflict resolution (paling mahal)#Data Residency dan Sovereignty
#Perbedaannya
- Data residency — data harus disimpan di wilayah tertentu (contoh: UU di Indonesia, GDPR di Eropa).
- Data sovereignty — data tunduk pada hukum negara tempat ia disimpan; transfer lintas negara diatur hukum.
Ini bukan sekadar "pilih region": cloud provider punya edge/region di negara berbeda dan kewajiban hukum yang berbeda. Arsitektur harus menempatkan data di region yang sah untuk data tersebut — bukan region termurah.
#Pola Region Per-Kepatuhan
Pola ini menempatkan data sesuai yurisdiksi. Perhatikan: replikasi lintas negara yang dilarang tidak boleh terjadi — kepatuhan menang atas convenience teknis.
#Praktik untuk Data Residency
- Pilih region sesuai hukum data, bukan biaya.
- Pisahkan pipeline data per wilayah — jangan mencampur data dari yurisdiksi berbeda di satu store.
- Jangan replikasi lintas border tanpa izin — replicating data keluar yurisdiksi bisa melanggar hukum.
- Kontrol akses admin — bahkan support provider pun tidak boleh bebas melihat data (episode 18-19).
Note
Multi-region yang melanggar residency bukan sekadar "risiko teknis" — ia risiko hukum. Sebelum merancang replikasi lintas negara, konfirmasi batasan hukum dengan tim compliance. Episode 20 akan membahas arsitektur compliance secara menyeluruh.
#Compliance Regional dalam Praktik
Provider cloud menawarkan region yang memenuhi standar lokal — biasanya tercantum sebagai compliance programs per region (misal: region Eropa untuk GDPR, region Indonesia/ASEAN untuk kebutuhan lokal). Arsitek harus:
- Memetakan jenis data yang diolah (PII, keuangan, kesehatan).
- Menentukan yurisdiksi yang mengaturnya.
- Memilih region yang sah untuk masing-masing.
- Mendokumentasikan data flow (diagram + ADR) untuk audit.
Hasilnya adalah data map — artefak yang wajib ada untuk sertifikasi (episode 20).
#Praktik: Merancang Arsitektur Multi-Region
Kerangka desain untuk organisasi yang melayani Indonesia + Eropa:
- Pilih region yang sah untuk tiap yurisdiksi (Asia Tenggara untuk data Indonesia, Eropa untuk data EU).
- Mulai active-passive untuk DR; upgrade ke active-active hanya bila latency menuntut.
- Pisahkan data per yurisdiksi; jangan replikasi lintas border tanpa izin.
- Gunakan DNS global / routing policy (Route 53, Cloud DNS) untuk mengarahkan user ke region terdekat.
- Tambahkan DR test berkala — standby yang tidak pernah diuji = tidak ada.
- Dokumentasikan data map dan region strategy di ADR.
#Penutup
Inti yang harus dibawa pulang:
- Active-passive untuk DR sederhana; active-active untuk latency global dengan biaya kompleksitas.
- Data residency = simpan di wilayah yang sah; sovereignty = tunduk hukum negara.
- Region dipilih berdasarkan hukum data, bukan harga.
- Jangan replikasi lintas yurisdiksi tanpa persetujuan compliance.
- Uji DR berkala; dokumentasikan data map untuk audit.
Di episode 16 selanjutnya kita akan membahas hybrid & multi-cloud — portabilitas, abstraction layer, dan trade-off vendor. Sampai jumpa di episode 16!