Panduan GCP untuk Pemula: Memahami Region, Zone, Hierarchy Resource & Billing

 

Panduan Google Cloud Platform (GCP) untuk Pemula: Memahami Region, Zone, Replikasi, Hierarchy & Billing

Membangun infrastruktur di cloud platform seperti Google Cloud Platform (GCP) memang menyenangkan, tetapi bisa membingungkan jika kita belum memahami fondasi dasarnya. Sebelum meluncurkan Virtual Machine (VM) atau deploy klaster Kubernetes pertama Anda, ada empat pilar utama yang wajib dikuasai: Lokasi Fisik (Region & Zone), Replikasi & Backup Data, Struktur Organisasi (Hierarchy Resource), dan Manajemen Tagihan (Billing).

Di artikel ini, kita akan mengupas tuntas seluruh konsep dasar GCP tersebut dengan bahasa yang santai, analogi dunia nyata yang intuitif, serta contoh skenario konfigurasi di lapangan. Yuk, simak sampai selesai!

1. 🗺️ Region & Zone: Memahami Fondasi Fisik GCP

Saat Anda menyewa server di cloud, server tersebut tetap berada di gedung fisik pusat data (data center). GCP membagi lokasi pusat datanya menjadi dua tingkatan: Region dan Zone.

A. Region (Wilayah / Kota Utama)

• Apa itu Region?

  Region adalah lokasi geografis tertentu di dunia tempat Google mendirikan kelompok pusat data. Antar-Region terpisah sangat jauh (bisa ratusan hingga ribuan kilometer).

• Kenapa Penting?

  Pemilihan Region menentukan seberapa cepat pengguna dapat mengakses aplikasi Anda (Latency). Semakin dekat server dengan lokasi pengguna, semakin cepat waktu responnya.

• Contoh Nama Region GCP:

  • asia-southeast2 (Jakarta, Indonesia)

  • asia-southeast1 (Singapura)

  • us-central1 (Iowa, Amerika Serikat)

B. Zone (Gedung Pusat Data Fisik)

• Apa itu Zone?

  Zone adalah area isolasi mandiri atau gedung data center fisik di dalam suatu Region. Dalam 1 Region, GCP selalu menyediakan minimal 3 Zone (Zone A, B, dan C). Setiap Zone memiliki sumber listrik, sistem pendingin, dan jalur jaringan independen.

• Kenapa Penting?

  Zone adalah kunci dari High Availability (Toleransi Kesalahan). Jika satu gedung data center mengalami mati listrik lokal, aplikasi Anda yang berjalan di Zone lain dalam Region yang sama tidak akan terganggu.

• Contoh Nama Zone GCP:

  • asia-southeast2-a (Jakarta, Zone A)

  • asia-southeast2-b (Jakarta, Zone B)

  • asia-southeast2-c (Jakarta, Zone C)

💡 Analogi Sederhana: Kota & Cabang Supermarket

Konsep GCP	Analogi Dunia Nyata	Penjelasan Analogi
Region	Kota Jakarta	Jika mayoritas pelanggan bisnis Anda ada di Jakarta, Anda membuka cabang di Jakarta (bukan Tokyo) agar pengiriman barang cepat sampai.
Zone	Cabang Supermarket (JakBar, JakSel, JakTim)	Anda membuka 3 supermarket di Jakarta. Jika toko Jakarta Barat mati listrik atau banjir, pelanggan tetap bisa belanja di cabang Jakarta Selatan yang berada di kota yang sama.

2. 🔄 Apakah Resource di Suatu Zone Otomatis Di-backup ke Zone Lain?

Pertanyaan yang paling sering ditanyakan pemula: "Jika saya buat VM di Zone A, apakah GCP otomatis membuatkan backup/cadangannya di Zone B?"

❌ Jawaban Singkat: TIDAK Otomatis!

Secara default, jika Anda menyewa atau membuat resource yang bersifat Zonal (seperti Virtual Machine / Compute Engine standar), GCP TIDAK otomatis mencadangkan (backup) atau mereplikasi resource dan data Anda ke Zone lain di dalam Region yang sama.

Jika Zone A tempat VM Anda berada mengalami gangguan total (seperti pemadaman listrik lokal atau masalah perangkat keras), VM Anda di Zone A tidak akan otomatis menyala di Zone B kecuali Anda telah mengonfigurasikan arsitektur High Availability (HA) atau replikasi secara mandiri.

🔍 Cakupan (Scope) Resource di GCP

GCP membagi resource berdasarkan tingkat isolasi tempat resource tersebut berjalan:

1. 🏢 Zonal Resources (Hanya Ada di 1 Zone Spesifik)

• Contoh: VM Instance (Compute Engine), Zonal Persistent Disk (Diska standar), IP Internal VM.

• Karakteristik: Resource ini sepenuhnya hidup di dalam satu gedung pusat data fisik (Zone). Jika gedung tersebut bermasalah, resource di dalamnya ikut terpengaruh.

2. 🗺️ Regional Resources (Otomatis Tersedia di Seluruh Zone dalam 1 Region)

• Contoh: Regional Persistent Disk, Static External IP Address, Regional Load Balancer, Cloud SQL dengan opsi High Availability (HA).

• Karakteristik: GCP secara otomatis mengelola ketersediaan resource ini di beberapa Zone dalam satu Region.

3. 🌐 Multi-Regional / Global Resources (Tersedia di Banyak Region/Global)

• Contoh: Cloud Storage Bucket (Multi-region), Cloud Spanner, Cloud IAM, Global Load Balancer.

• Karakteristik: Memiliki ketahanan (resilience) tertinggi karena data disimpan dan direplikasi secara lintas negara/wilayah.

🛠️ Strategi Menjaga Data & Server dari Kegagalan Zone (Zone Outage)

Untuk memastikan sistem Anda tahan terhadap kegagalan tingkat Zone, Anda dapat menerapkan strategi berikut di GCP:

1. Gunakan Snapshots untuk Backup Disk (Disimpan di Level Region/Multi-Region):

   Walaupun Persistent Disk Anda berada di Zone A, ketika Anda membuat Snapshot dari disk tersebut, GCP secara default akan menyimpan file snapshot di tingkat Region (atau Multi-Region). Jika Zone A rusak total, Anda tetap bisa memulihkan (restore) disk dari snapshot tersebut untuk membuat VM baru di Zone B.

2. Gunakan Regional Persistent Disk (Replikasi Real-Time 2 Zone):

   Mengubah tipe disk VM dari Zonal Persistent Disk menjadi Regional Persistent Disk. GCP akan melakukan replikasi data secara synchronous (real-time) ke 2 Zone sekaligus di Region yang sama. Jika VM di Zone A mati, Anda bisa langsung memasang (attach) disk tersebut ke VM cadangan di Zone B tanpa kehilangan data.

3. Terapkan Multi-Zone Managed Instance Group (MIG):

   Menjalankan beberapa salinan (replica) VM aplikasi Anda di bawah Load Balancer yang terbagi ke beberapa Zone (zone-a, zone-b, zone-c). Jika zone-a mati, Load Balancer akan otomatis mengarahkan trafik pengguna ke VM di zone-b atau zone-c tanpa ada downtime.

4. Aktifkan Opsi High Availability (HA) pada Layanan Managed:

   Saat membuat database Cloud SQL, aktifkan fitur High Availability. GCP akan membuat satu instance Primary di Zone A dan satu instance Standby di Zone B. Data direplikasi secara otomatis. Jika Zone A tumbang, sistem akan melakukan failover otomatis ke Zone B.

3. 🏗️ Hierarchy Resource: Cara GCP Mengorganisir Aset Anda

Setiap layanan yang Anda buat di GCP tidak boleh "terbang bebas" tanpa pemilik. GCP menggunakan struktur hierarki berbentuk pohon untuk mengatur keamanan, akses (IAM), dan biaya.

$$\text{Organization} \longrightarrow \text{Folder} \longrightarrow \text{Project} \longrightarrow \text{Resources}$$

[ Organization (majubersama.com) ]
       │
       ├── [ Folder: Divisi E-Commerce ]
       │        │
       │        └── [ Project: web-tokoonline-prod ]
       │                 │
       │                 └── [ Resources: Compute Engine / Cloud SQL ]

A. 🏢 Organization (Tingkat Teratas / Perusahaan)

• Fungsi: Akar (root) dari seluruh ekosistem GCP milik perusahaan Anda. Tempat Admin IT menerapkan kebijakan keamanan global dan hak akses utama.

• Analogi: Gedung Kantor Pusat Perusahaan (misal: PT Maju Bersama).

B. 📁 Folder (Tingkat Menengah / Departemen & Divisi)

• Fungsi: Kontainer opsional untuk mengelompokkan beberapa Project. Folder dapat dibuat bersarang (nested) untuk memisahkan departemen (Finance, Engineering) atau lingkungan (Dev, Staging, Prod).

• Analogi: Divisi atau Lantai Kerja di kantor pusat.

C. 📌 Project (Unit Fondasi Wajib)

• Fungsi: Unit organisasi utama di GCP. Semua layanan wajib dibuat di dalam sebuah Project. Project menjadi batas isolasi keamanan, batas tagihan (billing), dan batas IAM.

• Analogi: Ruangan Kerja Proyek Khusus (misal: Ruang Proyek Website Toko Online).

D. ⚙️ Resources (Komponen Layanan GCP)

• Fungsi: Layanan nyata yang Anda gunakan, seperti VM (Compute Engine), Database (Cloud SQL), atau Penyimpanan (Cloud Storage).

• Analogi: Peralatan Kerja (Laptop, Printer, Server) di dalam ruangan proyek.

❓ FAQ Hirarki GCP (Pertanyaan Populer)

1. Apakah bisa membuat Project tanpa Folder terlebih dahulu?

Bisa. Folder bersifat opsional. Hirarki minimal GCP adalah:

$$\text{Organization} \longrightarrow \text{Project} \longrightarrow \text{Resource}$$

Jika tidak menggunakan Folder, Project akan langsung berada di Root Level di bawah Organization.

2. Apakah akun Google individu (@gmail.com) harus memiliki Organization?

Tidak. Akun Gmail pribadi tidak memiliki node Organization. Strukturnya sangat sederhana:

$$\text{Project} \longrightarrow \text{Resource}$$

Node Organization hanya muncul jika Anda mendaftar menggunakan domain email perusahaan via Google Workspace atau Cloud Identity.

4. 💳 Billing: Mengelola Pembayaran dan Tagihan GCP

Cloud Billing adalah sistem yang mengelola pembayaran atas seluruh layanan yang digunakan oleh Project-Project Anda.

🔑 Konsep Utama Billing:

1. Cloud Billing Account: Akun pembayaran pusat yang terhubung ke metode pembayaran nyata (Kartu Kredit, Invoicing, Transfer Bank). Satu Billing Account dapat membiayai banyak Project sekaligus, tetapi satu Project hanya terhubung ke satu Billing Account pada satu waktu.

2. Budgets & Alerts: Fitur penting untuk menetapkan batas anggaran bulanan. Anda dapat mengaktifkan notifikasi email otomatis jika penggunaan biaya mencapai persentase tertentu (misal: 50%, 80%, 100%) agar terhindar dari billing shock.

5. 🏢 Skenario Lanjutan: Cross-Organization Billing (Billing Lintas Organisasi)

Di dunia industri / enterprise, tim Finance sering kali mengelola akun pembayaran yang terpisah dari akun Engineering. GCP mendukung mekanisme Cross-Organization Billing.

❓ Pertanyaan Seputar Billing Akun Bisnis:

1. Apakah Cloud Billing harus dibuat oleh pembuat organisasi?

   Tidak. Siapa pun di organisasi bisa membuat Billing Account asalkan memiliki peran Billing Account Creator (roles/billing.creator). Tugas ini biasa didelegasikan ke tim Finance.

2. Apakah Cloud Billing Account harus milik/anggota organisasi tersebut?

   Tidak wajib. Billing Account dapat berdiri sendiri (standalone) atau berada di bawah entitas lain (seperti GCP Partner / Reseller).

🎭 Contoh Skenario Praktis: Link Billing Lintas Organisasi

Kasus:

• Akun A: Admin dari Organisasi org-A dan Project pro-A.

• Akun B: Pemilik dari Cloud Billing Account billing-B.

• Tujuan: Menghubungkan Project pro-A agar seluruh biaya layanannya dibayar oleh billing-B.

🔑 Prasyarat Kunci (Izin IAM)

Untuk menghubungkan Project ke Billing Account, pengguna wajib memiliki 2 peran sekaligus:

1. Role Billing Account User (roles/billing.user) pada billing-B.

2. Role Project Billing Manager atau Owner pada pro-A.

[ Akun B (Billing-B) ] ──( Beri Role: Billing Account User )──> [ Akun A ]
                                                                   │
                                                      ( Melakukan Linking )
                                                                   ▼
                                                       [ Project: pro-A ]

🚀 Alur Pelaksanaan (Step-by-Step Flow)

1. Langkah 1: Akun B Memberi Izin ke Akun A

   • Akun B masuk ke Console GCP $\rightarrow$ Menu Billing $\rightarrow$ Pilih billing-B.

   • Buka tab Account Management / Permissions.

   • Tambahkan email Akun A dengan role: Billing Account User (roles/billing.user).

2. Langkah 2: Akun A Menghubungkan Project ke Billing Account

   • Akun A masuk ke Console GCP $\rightarrow$ Buka Project pro-A.

   • Buka menu Billing $\rightarrow$ Klik Change Billing / Link a Billing Account.

   • Pilih billing-B dari daftar, lalu klik Set Account.

⚙️ Mekanisme Keamanan & Hasil Akhir

Aspek	Yang Terjadi pada Sistem
Kepemilikan Resource	pro-A tetap 100% berada di bawah hirarki org-A. Admin org-A memegang penuh kontrol keamanan dan data.
Akses Data oleh Akun B	Akun B TIDAK bisa melihat data atau masuk ke server di pro-A. Akun B hanya bertindak sebagai pembayar tagihan.
Aliran Tagihan	Semua biaya layanan di dalam pro-A akan otomatis ditagihkan ke billing-B.
Rincian Biaya	Akun B dapat melihat laporan pengeluaran bulanan (cost breakdown) untuk pro-A di dashboard billing-B.

📌 Kesimpulan & Best Practices

Jenis Resource	Apakah Otomatis Di-backup ke Zone Lain?	Solusi / Cara Menjaga Ketersediaan Data
VM Instance Biasa	❌ Tidak	Gunakan Regional Managed Instance Group (Multi-Zone Deployment).
Zonal Persistent Disk	❌ Tidak	Buat jadwal Scheduled Snapshot atau gunakan Regional Persistent Disk.
Cloud Storage (GCS)	✅ Ya (Regional/Multi-Region)	Data otomatis direplikasi di beberapa pusat data oleh sistem GCP.
Cloud SQL (Default)	❌ Tidak	Aktifkan opsi High Availability (HA) saat membuat instance.

Prinsip DevOps Cloud: "Jangan pernah mengasumsikan cloud melakukan backup otomatis kecuali jenis resource-nya secara tegas tertulis Regional atau Multi-Regional."

Memahami konsep Region & Zone, Sifat Replikasi Zonal, Hierarchy Resource, dan Billing adalah langkah awal paling krusial sebelum membangun infrastruktur di GCP. Dengan penataan hirarki yang rapi, strategi High Availability yang tepat, dan manajemen billing yang cermat, infrastruktur cloud Anda tidak hanya aman dan berkinerja tinggi, tetapi juga efisien secara biaya!

Selamat mencoba dan sampai jumpa di artikel DevOps berikutnya!