Belajar Cloud Computing - Relational Managed Databases (RDBMS)

#Pendahuluan

Di episode 6 kalian belajar menjalankan dan membayar VM, di episode 7 menyimpan data, dan di episode 8 membuat aplikasi selalu tersedia dan bisa men-scalable. Namun semua itu berpulang pada satu komponen yang paling sensitif: database. Aplikasi boleh saja crash dan di-restart, tetapi kehilangan data adalah bencana yang tidak bisa di-undo.

Episode 9 ini membahas relational managed database: kenapa memilih managed daripada self-managed, bagaimana high availability multi-AZ bekerja (synchronous replication dan automatic failover), apa itu SQL terdistribusi cloud-native, serta peta komparasi layanan di AWS, GCP, dan Azure.

#Managed vs Self-Managed Database

Ada dua cara menjalankan database relasional di cloud. Cara pertama: install sendiri PostgreSQL atau MySQL di VM (self-managed). Cara kedua: pakai layanan terkelola seperti RDS atau Cloud SQL (managed).

Yang sering tidak dihitung orang saat membandingkan biaya adalah biaya operasional self-managed: waktu untuk patch, on-call saat database turun di tengah malam, dan risiko kehilangan backup. Managed database menambahkan sedikit premium harga, tetapi menghapus hampir seluruh biaya tersembunyi itu.

#Multi-AZ High Availability: Replikasi Sinkron dan Failover Otomatis

Keunggulan utama managed database adalah high availability yang "tinggal nyalakan". Konsepnya: satu database utama (primary) di satu AZ, satu replika standby di AZ lain, terhubung dengan replikasi sinkron.

            Client aplikasi
                 |  (terhubung ke satu endpoint saja)
                 v
         [ Endpoint / DNS ]
                 |
    +------------+------------+
    |                         |
    v                         v
PRIMARY (AZ-a)             STANDBY (AZ-b)
PostgreSQL                 PostgreSQL
    +------ synchronous replication ------+

Replikasi sinkron berarti setiap transaksi harus ditulis ke primary dan standby sebelum dianggap sukses. Jika primary mengalami kegagalan — crash, atau seluruh AZ-a padam — endpoint yang sama otomatis diarahkan ke standby dalam hitungan menit. Aplikasi tidak perlu tahu ada pergantian; ia hanya perlu reconnect ke endpoint yang sama.

Inilah alasan mengapa database managed bisa mencapai uptime tinggi: failover otomatis, backup otomatis, dan perbaikan replika otomatis disediakan oleh provider, sehingga kalian tidak lagi bangun tengah malam untuk mempromosikan replika manual.

#Cloud-Native Distributed SQL

Selain database relasional klasik, muncul kelas baru: SQL terdistribusi cloud-native yang dirancang sejak awal untuk skala cloud. Perwakilannya adalah Amazon Aurora (kompatibel MySQL dan PostgreSQL), Google Cloud Spanner (SQL global dengan konsistensi kuat), dan Azure SQL Database (termasuk tier Hyperscale).

Ciri khasnya:

• Storage dipecah ke banyak node secara otomatis, sementara aplikasi tetap berinteraksi lewat SQL standar dan menjanjikan ACID.
• Kapasitas bisa bertambah tanpa downtime dan tanpa mengganti instance besar.
• Replikasi lintas region bisa dilakukan dengan konsistensi yang terjamin — Spanner bahkan bisa menjangkau beberapa benua sekaligus.

#Komparasi Layanan Database Relasional Managed

Peta layanan di tiga provider besar:

Kabar baiknya, RDS, Cloud SQL, dan Azure Database for PostgreSQL mendukung engine open-source yang kalian kenal. Artinya, kalian bisa pindah antar-provider tanpa mengganti ORM atau menulis ulang query — migrasi cukup ekspor data dan impor ke layanan baru.

#Membuat Database dengan AWS CLI

Praktik langsung: aws rds create-db-instance membuat database PostgreSQL terkelola:

aws rds create-db-instance \
  --db-instance-identifier prod-postgres \
  --db-instance-class db.t3.medium \
  --engine postgres \
  --engine-version 16.1 \
  --allocated-storage 100 \
  --multi-az \
  --master-username admin \
  --master-user-password 'S3cure!Pass' \
  --db-subnet-group-name prod-db-subnets \
  --vpc-security-group-ids sg-0abc123

Penjelasan singkat flag penting:

• --multi-az menyalakan high availability sekaligus — primary dan standby otomatis tersebar di dua AZ.
• --db-subnet-group-name menunjuk grup subnet yang membentang di beberapa AZ; inilah tempat replika standby akan hidup.
• --vpc-security-group-ids membatasi siapa yang boleh terhubung — idealnya hanya security group aplikasi, bukan internet.

#Penutup

Pada episode 9 ini, kalian sudah memahami kenapa managed database lebih masuk akal untuk produksi daripada self-managed, bagaimana high availability multi-AZ bekerja lewat synchronous replication dan automatic failover, serta apa itu SQL terdistribusi cloud-native dan kapan layak dipakai. Kalian juga melihat peta layanan RDS, Aurora, Cloud SQL, Spanner, Azure SQL, dan Azure Database for PostgreSQL beserta contoh perintah aws rds create-db-instance.

Kunci yang harus dibawa pulang:

• Managed database menghemat biaya operasional tersembunyi — patch, backup, failover, dan monitoring ditangani provider.
• Multi-AZ berarti replika sinkron yang otomatis diaktifkan — standby bukan untuk membaca, melainkan untuk menggantikan saat primary gagal.
• Distributed SQL (Aurora, Spanner) untuk skala dan uptime ekstrem — bukan kebutuhan default.

Data relasional hanyalah satu bentuk data. Di episode 10, kita akan membahas NoSQL & In-Memory Databases — DynamoDB, Redis, dan kawan-kawan — untuk kebutuhan yang tidak cocok dengan tabel kaku: skema fleksibel, latency milidetik, dan cache yang mempercepat aplikasi ribuan kali.