Global Infrastructure #

Ketika kamu men-deploy aplikasi ke cloud, kamu tidak hanya memilih “cloud” sebagai lokasi abstrak — kamu memilih di mana secara fisik infrastrukturnya berjalan. Keputusan ini mempengaruhi latensi pengguna, biaya, regulasi data, dan kemampuan recovery saat terjadi kegagalan. Memahami bagaimana cloud provider membangun infrastruktur globalnya adalah fondasi untuk membuat keputusan arsitektur yang tepat.

Hierarki Infrastruktur Global #

Cloud provider besar membangun infrastruktur global dalam beberapa lapisan hierarki. Meski terminologinya sedikit berbeda antar provider, konsepnya konsisten.

Hierarki Infrastruktur (dari terbesar ke terkecil):

  Geographic Area / Continent
      └── Region (misalnya: Asia Pacific, US East)
              └── Availability Zone / AZ (misalnya: AZ-1, AZ-2, AZ-3)
                      └── Data Center (satu atau beberapa per AZ)
                              └── Physical Rack, Server, Storage

Setiap lapisan dirancang dengan tujuan spesifik dalam hal redundansi dan isolasi kegagalan.

Region — Unit Geografis Utama #

Region adalah kumpulan data center yang ditempatkan di area geografis tertentu — biasanya satu kota atau kawasan metropolitan. Setiap region beroperasi secara independen dari region lain.

Karakteristik Region:
  ✓ Lokasi geografis yang spesifik
      → "ap-southeast-1" = Singapore
      → "us-east-1" = Northern Virginia, USA
      → "ap-southeast-3" = Jakarta, Indonesia

  ✓ Independensi penuh antar region
      → Kegagalan di satu region tidak mempengaruhi region lain
      → Data tidak otomatis replikasi antar region

  ✓ Kepatuhan regulasi data
      → Data yang disimpan di region Singapore tetap di Singapore
      → Penting untuk regulasi data sovereignty

Pertimbangan Memilih Region:
  □ Kedekatan dengan pengguna → latensi lebih rendah
  □ Regulasi dan data sovereignty → sesuaikan dengan hukum setempat
  □ Ketersediaan layanan → tidak semua layanan tersedia di semua region
  □ Biaya → harga berbeda antar region (region baru sering lebih mahal)

Availability Zone — Isolasi Kegagalan #

Availability Zone (AZ) adalah satu atau beberapa data center dalam satu region yang terhubung melalui jaringan berkecepatan tinggi dengan latensi sangat rendah. AZ dirancang untuk terisolasi dari kegagalan AZ lainnya dalam region yang sama.

Isolasi Antar AZ dalam Satu Region:
  
  Region ap-southeast-1 (Singapore):
  ┌─────────────────────────────────────────────────────┐
  │  AZ-1a          AZ-1b          AZ-1c                │
  │  ┌────────┐    ┌────────┐    ┌────────┐             │
  │  │Data    │    │Data    │    │Data    │             │
  │  │Center  │    │Center  │    │Center  │             │
  │  └────────┘    └────────┘    └────────┘             │
  │      │              │              │                │
  │      └──────────────┴──────────────┘                │
  │         Jaringan privat cepat antar AZ              │
  └─────────────────────────────────────────────────────┘

  Isolasi dirancang agar:
  ✓ Kebakaran, banjir, atau pemadaman listrik di AZ-1a
    tidak mempengaruhi AZ-1b dan AZ-1c
  ✓ Setiap AZ memiliki power, cooling, dan koneksi internet
    yang terpisah
  ✗ AZ berbeda dalam region yang sama TIDAK berada di
    gedung yang sama (berbeda lokasi fisik)

Jarak antar AZ dalam satu region cukup jauh untuk isolasi fisik, tapi cukup dekat untuk latensi jaringan yang rendah (biasanya < 2ms). Ini yang membuat Multi-AZ deployment efektif.

Multi-AZ — Fondasi High Availability #

Men-deploy aplikasi di beberapa AZ adalah cara paling umum untuk mencapai high availability di cloud. Ini adalah pola dasar yang hampir selalu direkomendasikan untuk workload produksi.

Single-AZ Deployment (tidak disarankan untuk produksi):
  
  AZ-1a: [App Server] ← semua trafik masuk
  
  Jika AZ-1a mengalami masalah:
  → Seluruh aplikasi tidak tersedia

Multi-AZ Deployment:
  
  [Load Balancer] — tersebar atau managed service
      ├── AZ-1a: [App Server A]
      ├── AZ-1b: [App Server B]
      └── AZ-1c: [App Server C]
  
  Jika AZ-1a mengalami masalah:
  → Load balancer otomatis hentikan trafik ke AZ-1a
  → AZ-1b dan AZ-1c tetap melayani trafik
  → Tidak ada downtime yang dirasakan pengguna

Sebagian besar managed services dari cloud provider sudah menyediakan opsi Multi-AZ sebagai fitur bawaan — database dengan Multi-AZ failover, load balancer yang secara otomatis tersebar ke beberapa AZ, dan lain sebagainya.

Edge Locations dan CDN #

Di atas Region dan AZ, cloud provider besar juga memiliki jaringan edge location — titik kehadiran (Points of Presence / PoP) yang lebih kecil dan tersebar di lebih banyak kota. Edge location tidak digunakan untuk menjalankan workload komputasi biasa, tapi untuk layanan yang membutuhkan kedekatan dengan pengguna akhir.

Perbedaan Region vs Edge Location:

  Region:
    → Menjalankan seluruh infrastruktur cloud (compute, storage, database)
    → Jumlah terbatas (puluhan di seluruh dunia)
    → Kamu deploy aplikasi ke region

  Edge Location:
    → Untuk caching dan distribusi konten (CDN)
    → Untuk DNS resolution yang cepat
    → Untuk DDoS mitigation
    → Jumlah sangat banyak (ratusan di seluruh dunia)
    → Otomatis digunakan oleh layanan CDN

Contoh Alur CDN:
  Pengguna di Jakarta
      → Request ke edge location Jakarta (< 5ms)
      → Cache hit: content langsung dikirim dari Jakarta
      → Cache miss: edge location ambil dari origin region,
        cache, lalu kirim ke pengguna

Multi-Region — Ketika Satu Region Tidak Cukup #

Multi-AZ menangani kegagalan pada level AZ. Untuk perlindungan terhadap kegagalan seluruh region — atau untuk kebutuhan latensi global — kamu perlu Multi-Region deployment.

Kapan Multi-Region Dibutuhkan:
  ✓ Aplikasi dengan pengguna di berbagai benua (latensi global)
  ✓ SLA sangat tinggi (99.99%+) yang tidak bisa dijamin oleh
    satu region saja
  ✓ Disaster recovery dengan RPO dan RTO yang sangat ketat
  ✓ Regulasi yang mengharuskan data berada di region tertentu
    sekaligus tersedia di region lain

Kapan Multi-Region Berlebihan:
  ✗ Pengguna mayoritas di satu lokasi geografis
  ✗ Downtime beberapa jam masih bisa diterima
  ✗ Anggaran tidak mencukupi — Multi-Region mahal dan kompleks

Kompleksitas Multi-Region:
  → Data consistency — bagaimana sinkronisasi data antar region?
  → Latency — write ke region primer, baca dari mana?
  → Failover — bagaimana trafik dialihkan saat satu region gagal?
  → Biaya data transfer antar region

Multi-Region bukan solusi yang harus dikejar semua orang. Untuk sebagian besar aplikasi, Multi-AZ dalam satu region sudah memberikan availability yang sangat tinggi dengan kompleksitas yang jauh lebih rendah. Evaluasi kebutuhan nyata sebelum menambah kompleksitas Multi-Region.

Ringkasan #

Region adalah unit geografis independen — data tidak otomatis replikasi antar region, dan pilihan region mempengaruhi latensi, regulasi, dan ketersediaan layanan.
AZ adalah unit isolasi kegagalan — setiap AZ memiliki power, cooling, dan jaringan yang terpisah untuk mencegah satu kegagalan mempengaruhi AZ lain.
Multi-AZ adalah standar minimum untuk produksi — single-AZ deployment rentan terhadap AZ failure yang tidak jarang terjadi.
Edge location bukan untuk compute — ia untuk CDN, DNS, dan DDoS mitigation. Kamu tidak deploy aplikasi ke edge location.
Multi-Region untuk kebutuhan extreme — high availability global, latensi rendah di berbagai benua, atau regulasi data sovereignty yang kompleks.
Pilih region berdasarkan pengguna, regulasi, dan layanan yang tersedia — bukan hanya berdasarkan harga atau nama yang familiar.

← Sebelumnya: Elasticity vs Scalability Berikutnya: HA & Fault Tolerance →