Global Infrastructure #

Ketika kita membangun dan men-deploy aplikasi di cloud, kita tidak sedang mengirimkan kode kita ke sebuah entitas abstrak di awan yang tanpa bentuk fisik. Di balik semua kemudahan API, konsol web, dan otomatisasi serverless yang kita nikmati, terdapat infrastruktur fisik berskala masif yang tersebar di berbagai belahan dunia. Infrastruktur ini terdiri dari gedung-gedung data center raksasa, jaringan kabel serat optik bawah laut antar-benua, sistem pembangkit listrik cadangan, dan jutaan rak server fisik. Keputusan kita mengenai di mana lokasi fisik infrastruktur tersebut dijalankan akan berdampak langsung pada kecepatan akses pengguna (latensi), kepatuhan terhadap hukum kedaulatan data (compliance), anggaran operasional bulanan (cost), serta daya tahan aplikasi kita saat menghadapi bencana alam. Oleh karena itu, memahami arsitektur infrastruktur global cloud provider adalah salah satu fondasi terpenting bagi setiap cloud engineer dan arsitek sistem.

Hierarki Infrastruktur Global #

Untuk mengelola skala yang begitu masif secara teratur dan meminimalkan dampak kegagalan, cloud provider besar (seperti AWS, Google Cloud, atau Microsoft Azure) mengorganisasi infrastruktur fisik mereka ke dalam beberapa lapisan hierarki terstruktur.

flowchart TD
    Geo["Geographic Area (Benua/Wilayah Besar)"] --> Region["Region (Kumpulan AZ Mandiri)"]
    Region --> AZ["Availability Zone / AZ (Isolasi Kegagalan Fisik)"]
    AZ --> DC["Data Center (Satu atau Lebih Gedung Fisik)"]
    DC --> Racks["Physical Racks & Server (Infrastruktur Komputasi)"]

Mari kita bedah setiap lapisan hierarki tersebut dari unit terbesar hingga unit terkecil:

1. Geographic Area (Wilayah Geografis): Ini adalah pembagian tingkat teratas yang biasanya mencakup benua atau kawasan regional besar dunia, seperti Asia Pasifik, Amerika Utara, Eropa, atau Timur Tengah. Tujuannya adalah untuk membantu organisasi mengelompokkan lokasi deployment secara makro.
2. Region: Wilayah geografis spesifik di dalam suatu negara yang di dalamnya terdapat beberapa Availability Zone (AZ) yang saling terhubung. Contoh region adalah Singapore (ap-southeast-1), Jakarta (ap-southeast-3), dan Northern Virginia (us-east-1). Setiap region beroperasi secara independen dan terisolasi sepenuhnya dari region lainnya.
3. Availability Zone (AZ): Unit isolasi kegagalan di dalam satu region. Satu AZ terdiri dari satu atau beberapa data center fisik yang berdiri sendiri, memiliki pasokan listrik, pendingin, dan koneksi internet yang mandiri, namun terhubung dengan AZ lain dalam region yang sama melalui jaringan serat optik privat berlatensi sangat rendah.
4. Data Center: Gedung fisik yang menyimpan ribuan server komputer. Di sinilah perangkat keras komputasi dijalankan secara fisik di bawah pengamanan super ketat.
5. Physical Rack & Server: Rak-rak besi yang menampung server fisik, perangkat penyimpanan (storage arrays), switch jaringan, dan kabel-kabel konektivitas. Di level inilah virtualisasi hypervisor membagi resource hardware fisik menjadi Virtual Machine (VM) yang kita sewa di cloud.

Region: Kumpulan Data Center Mandiri #

Region adalah titik pusat tempat kita mendeploy aplikasi dan menyimpan data di cloud. Karakteristik utama dari sebuah region adalah independensi penuh. Artinya, kegagalan bencana alam (seperti badai, gempa bumi besar, atau mati lampu total satu negara) yang melumpuhkan sebuah region tidak akan berdampak pada operasional region lainnya. Data kita pun tidak akan pernah berpindah atau direplikasi ke region lain secara otomatis kecuali kita secara eksplisit mengonfigurasinya.

Kriteria Utama dalam Memilih Region #

Memilih region tempat aplikasi berjalan bukanlah keputusan yang acak atau hanya berdasarkan nama region yang terdengar populer. Ada empat kriteria krusial yang wajib kita evaluasi secara mendalam sebelum memilih region:

1. Latensi (Kedekatan Geografis dengan Pengguna) #

Hukum fisika tentang kecepatan cahaya dalam kabel serat optik membatasi seberapa cepat data dapat berpindah dari server ke perangkat pengguna akhir. Setiap 1.000 kilometer jarak fisik akan menyumbang sekitar 10-15 milidetik (ms) latensi tambahan (round-trip time).

• Jika target pengguna aplikasi kita 95% berada di Indonesia, maka mendeploy aplikasi di Region Jakarta (ap-southeast-3) akan memberikan latensi yang sangat rendah (< 10 ms).
• Sebaliknya, jika kita mendeploy aplikasi tersebut di Region Northern Virginia (us-east-1), pengguna di Indonesia akan merasakan jeda (ping) sekitar 200-250 ms untuk setiap request, yang akan menurunkan kenyamanan pengalaman pengguna secara signifikan.

2. Kedaulatan Data dan Kepatuhan Hukum (Data Sovereignty & Compliance) #

Banyak negara memiliki regulasi ketat mengenai di mana data sensitif warganya boleh disimpan.

• Di Indonesia, Peraturan Pemerintah (PP) No. 71 Tahun 2019 mengatur bahwa penyelenggara sistem elektronik untuk lingkup publik wajib melakukan pengelolaan, pemrosesan, dan penyimpanan data di dalam wilayah Indonesia.
• Di Uni Eropa, regulasi GDPR (General Data Protection Regulation) melarang transfer data pribadi warga Uni Eropa ke luar wilayah tanpa perlindungan hukum yang setara.
• Kegagalan mematuhi regulasi kedaulatan data ini dapat berujung pada denda hukum bernilai fantastis atau pencabutan izin operasional bisnis kita.

3. Biaya Layanan (Cost Variations) #

Menyewa Virtual Machine atau database dengan tipe yang sama persis dapat memiliki harga yang berbeda secara signifikan antar region. Perbedaan harga ini disebabkan oleh variasi biaya operasional lokal cloud provider, seperti harga sewa tanah gedung, tarif listrik industri lokal, sistem perpajakan negara setempat, dan tingkat kelangkaan hardware di region tersebut.

• Umumnya, region-region utama yang sudah lama berdiri dan berskala sangat besar seperti us-east-1 (Virginia) memiliki tarif termurah di dunia.
• Region baru atau region di negara berkembang (seperti Jakarta atau Sao Paulo) sering kali memiliki tarif sewa yang lebih mahal 15% hingga 35% untuk tipe layanan yang sama.

4. Ketersediaan Layanan (Service Availability) #

Cloud provider tidak merilis layanan baru mereka secara serentak di seluruh dunia. Fitur-fitur mutakhir (seperti jenis GPU terbaru untuk AI, database serverless model baru, atau integrasi machine learning) biasanya diluncurkan pertama kali di region-region utama (flagship regions). Jika arsitektur aplikasi kita sangat bergantung pada fitur spesifik tersebut, kita terpaksa harus memilih region di mana layanan tersebut sudah berstatus Generally Available (GA).

Availability Zone (AZ): Kunci Isolasi Kegagalan #

Jika region dirancang untuk isolasi kegagalan skala geografis besar, maka Availability Zone (AZ) dirancang untuk mengisolasi kegagalan infrastruktur harian di dalam wilayah lokal tanpa mengorbankan performa aplikasi.

flowchart TD
    subgraph Region["Region (misalnya: ap-southeast-3 Jakarta)"]
        direction LR
        subgraph AZ_A["Availability Zone A (AZ-a)"]
            DC1["Data Center 1"]
            DC2["Data Center 2"]
        end
        subgraph AZ_B["Availability Zone B (AZ-b)"]
            DC3["Data Center 3"]
        end
        subgraph AZ_C["Availability Zone C (AZ-c)"]
            DC4["Data Center 4"]
        end
        AZ_A <-->|"Jaringan Fiber Optik Berkecepatan Tinggi<br>(Latensi < 2ms)"| AZ_B
        AZ_B <-->|"Jaringan Fiber Optik Berkecepatan Tinggi<br>(Latensi < 2ms)"| AZ_C
        AZ_C <-->|"Jaringan Fiber Optik Berkecepatan Tinggi<br>(Latensi < 2ms)"| AZ_A
    end

Setiap AZ di dalam satu region dihubungkan oleh jaringan serat optik privat yang sangat cepat. Latensi jaringan antar AZ biasanya ditekan hingga di bawah 2 milidetik. Latensi yang sangat rendah ini sangat penting karena memungkinkan kita melakukan replikasi data secara sinkron (menunggu konfirmasi penulisan dari server di AZ lain selesai sebelum merespon sukses kepada pengguna) tanpa membuat aplikasi terasa lambat.

Karakteristik Isolasi Fisik AZ: #

• Jarak Fisik yang Aman: AZ-AZ dalam satu region dipisahkan secara geografis dengan jarak yang cukup jauh (biasanya terpisah beberapa kilometer hingga puluhan kilometer). Tujuannya adalah agar jika terjadi bencana lokal (seperti banjir bandang di satu kecamatan, kebakaran gardu listrik utama, atau kecelakaan konstruksi jalan yang memutuskan kabel internet publik), insiden tersebut hanya berdampak pada satu AZ dan tidak mengenai AZ lainnya.
• Infrastruktur Mandiri: Setiap AZ memiliki gardu listrik cadangan mandiri dengan tumpukan baterai UPS industri dan cadangan bahan bakar solar untuk generator generator listriknya yang mampu menyuplai daya selama berhari-hari tanpa listrik PLN. Sistem pendinginan air (chiller) dan koneksi internet dari ISP (backbone carrier) juga masuk ke gedung lewat jalur fisik yang berbeda di setiap AZ.

Multi-AZ Deployment: Standar Minimum Produksi #

Menjalankan seluruh aplikasi dan database di dalam satu Availability Zone saja (Single-AZ) adalah sebuah kecerobohan arsitektur yang sangat fatal untuk lingkungan produksi. Jika AZ tersebut mengalami kegagalan hardware, aplikasi kita akan langsung offline secara total.

Oleh karena itu, arsitektur modern selalu mengadopsi pola Multi-AZ Deployment. Dalam skenario ini, kita mendistribusikan instans aplikasi kita secara merata ke minimal dua atau tiga AZ, dan meletakkan Load Balancer di bagian depan sistem untuk membagi trafik secara adil.

Penanganan Kegagalan (Failover) Otomatis di Multi-AZ #

Jika salah satu AZ mengalami mati total, load balancer yang secara konstan memantau kesehatan server (health check) akan mendeteksi hilangnya respon dari server di AZ yang bermasalah. Load balancer akan segera memutus aliran trafik ke AZ tersebut dan mengalihkan seluruh beban request ke server-server yang sehat di AZ lainnya.

Proses pengalihan ini terjadi dalam hitungan detik secara otomatis tanpa memerlukan intervensi manual dari tim Operations (SRE/Sysadmin). Pengguna akhir aplikasi kita tidak akan menyadari adanya bencana fisik yang sedang terjadi di data center.

sequenceDiagram
    participant Client as Pengguna
    participant LB as Load Balancer (Multi-AZ)
    participant AZ_A as Instans AZ-A (Mati)
    participant AZ_B as Instans AZ-B (Aktif)
    
    Client->>LB: Kirim HTTP Request
    LB-->>AZ_A: Kirim request (Mengalami Kegagalan Fisik)
    LB->>LB: Deteksi Health Check Gagal di AZ-A
    LB->>LB: Tandai AZ-A sebagai Tidak Sehat (Unhealthy)
    LB-->>AZ_B: Reroute request ke AZ-B
    AZ_B-->>LB: Respon sukses (HTTP 200)
    LB-->>Client: Respon sukses ke Pengguna

Pada tingkat database, Multi-AZ bekerja dengan menaruh database utama (Primary) di AZ-1 dan database cadangan (Standby) di AZ-2. Replikasi data berjalan secara sinkron dari Primary ke Standby. Jika AZ-1 hancur, cloud provider secara otomatis mempromosikan database Standby di AZ-2 menjadi Primary yang baru, serta mengarahkan ulang koneksi aplikasi (endpoint string) ke database yang baru tersebut dalam waktu kurang dari satu menit.

Edge Location dan CDN: Menjangkau Pengguna Akhir #

Di luar Region dan Availability Zone, terdapat komponen infrastruktur global lain yang sangat penting untuk mempercepat performa konten aplikasi kita, yaitu Edge Location (atau dikenal sebagai Points of Presence / PoP).

Perbedaan Region vs Edge Location #

Sangat penting untuk tidak menyamakan Edge Location dengan Region atau AZ. Keduanya memiliki fungsi dan arsitektur yang sangat bertolak belakang:

Bagaimana CDN Memanfaatkan Edge Location? #

Ketika kita menggunakan layanan CDN (Content Delivery Network), Edge Location bertindak sebagai garda terdepan yang paling dekat dengan lokasi fisik pengguna.

Jika origin server aplikasi kita berada di Region Singapore, dan seorang pengguna di Jakarta mengakses gambar aset aplikasi, alur caching di Edge Location akan berjalan seperti berikut:

flowchart TD
    User["Pengguna di Jakarta"] -->|"Minta file gambar.jpg"| Edge["Edge Location Jakarta"]
    Edge -->|"Check Cache"| CacheCheck{"Ada di Cache?"}
    CacheCheck -- "Ya (Cache Hit)" --> DeliverHit["Kirim Gambar ke Pengguna (< 5ms)"]
    CacheCheck -- "Tidak (Cache Miss)" --> FetchOrigin["Ambil Gambar dari Origin Server (Region Singapore, ~30ms)"]
    FetchOrigin --> SaveCache["Simpan Gambar di Cache Edge"]
    SaveCache --> DeliverMiss["Kirim Gambar ke Pengguna"]

Di samping CDN, Edge Location juga melayani fitur keamanan kritis seperti:

• DDoS Mitigation (Mitigasi DDoS): Menyerap trafik serangan banjir request palsu di level terdekat dari sumber penyerang, sebelum trafik tersebut sempat mencapai dan melumpuhkan server origin kita di region utama.
• Anycast DNS: Menyediakan resolusi nama domain yang super cepat karena server DNS terdekat yang menjawab query pengguna.
• Edge Computing: Menjalankan fungsi komputasi ringan (seperti manipulasi header HTTP atau pengalihan rute/redirect) langsung di Edge Location sebelum request dikirim ke server utama.

Multi-Region Deployment: Ketahanan Tingkat Ekstrim #

Meskipun Multi-AZ memberikan perlindungan yang sangat baik untuk sebagian besar kegagalan infrastruktur harian, ia masih memiliki keterbatasan. Jika terjadi bencana katastrofe berskala benua (seperti perang, pemutusan kabel fiber optik bawah laut nasional, atau kegagalan konfigurasi software global di level cloud provider yang melumpuhkan seluruh region), maka arsitektur Multi-AZ dalam satu region tersebut akan ikut runtuh.

Untuk sistem dengan tingkat kritikalitas sangat tinggi (seperti sistem perbankan nasional, aplikasi ride-hailing global, atau portal e-commerce raksasa), kita memerlukan arsitektur Multi-Region Deployment.

Pola Arsitektur Multi-Region #

Ada dua pola utama dalam merancang sistem Multi-Region:

1. Active-Passive (Disaster Recovery): Satu region utama (Active) menangani 100% trafik operasional harian. Data direplikasi secara asinkron ke region cadangan (Passive). Jika region Active mengalami mati total, sistem DNS global akan dialihkan ke region Passive. Bergantung pada arsitekturnya, terdapat beberapa varian:
   • Backup & Restore: Murah, tapi RTO (Recovery Time Objective) lambat karena kita harus memulihkan database dari backup.
   • Pilot Light: Database cadangan selalu hidup dan sinkron, namun server aplikasi dalam kondisi mati atau minimal. Butuh waktu beberapa menit untuk men-scale up saat terjadi bencana.
   • Warm Standby: Server aplikasi di region Passive sudah menyala dengan kapasitas minimum, siap menerima pengalihan trafik dengan RTO sangat cepat.
2. Active-Active: Kedua region secara aktif melayani trafik pengguna secara bersamaan. Pengguna di Asia akan diarahkan ke Region Singapore, sedangkan pengguna di Amerika akan diarahkan ke Region Virginia oleh sistem latency-based routing. Data disinkronkan secara dua arah (bi-directional replication).

Kompleksitas Teknis Multi-Region #

Meskipun menawarkan tingkat ketersediaan (availability) tertinggi, arsitektur Multi-Region membawa kompleksitas teknis yang sangat besar dan biaya yang luar biasa mahal:

• Replikasi Asinkron & Konsistensi Data (Eventual Consistency): Jarak ribuan kilometer antar region membuat replikasi data sinkron tidak mungkin dilakukan karena latensi jaringan yang terlalu besar (misal, menulis data di Jakarta dan harus menunggu konfirmasi tertulis dari Virginia sebelum membalas user akan menambah latensi ratusan milidetik). Kita terpaksa menggunakan replikasi asinkron, yang berarti ada risiko kehilangan data terakhir (data loss) jika region utama mendadak hancur sebelum replikasi selesai.
• Biaya Transfer Data (Data Egress Costs): Cloud provider mengenakan tarif yang cukup mahal untuk lalu lintas data yang keluar dari suatu region menuju region lain. Biaya sinkronisasi database lintas region yang sibuk dapat melampaui biaya sewa VM itu sendiri.
• Split-Brain Syndrome: Jika jaringan komunikasi penghubung antar-region terputus (namun kedua region secara fisik masih hidup), kedua region tersebut mungkin akan berasumsi bahwa region pasangannya telah mati. Keduanya akan mencoba menulis data baru secara mandiri tanpa sinkronisasi, mengakibatkan konflik data yang sangat sulit diperbaiki (data corruption).

Ringkasan #

• Region adalah area geografis independen yang terisolasi penuh dari region lainnya untuk mencegah kegagalan berantai skala besar. Pilihan region menentukan latensi pengguna, biaya operasional, kepatuhan regulasi data, dan ketersediaan fitur.
• Availability Zone (AZ) adalah unit isolasi kegagalan fisik di dalam satu region. Terdiri dari data center mandiri dengan jalur kelistrikan, pendingin, dan konektivitas internet terpisah untuk menangani insiden lokal tanpa downtime.
• Multi-AZ deployment adalah standar minimum aplikasi produksi untuk menjamin ketersediaan tinggi (high availability) lewat fitur otomatisasi failover dan penyeimbangan beban trafik.
• Edge Location bukan tempat menjalankan komputasi umum, melainkan titik kehadiran terdistribusi yang bertindak sebagai CDN untuk meng-cache konten statis, mempercepat DNS, dan menyerap serangan DDoS di perimeter terdekat dari pengguna.
• Multi-Region deployment ditujukan untuk disaster recovery tingkat tinggi dan latensi global rendah, namun membutuhkan penanganan konsistensi data yang sangat kompleks (eventual consistency) serta biaya data transfer yang mahal.

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