Belajar Database Administrator - Managed Cloud Databases

#Pendahuluan

Sejauh ini kita mengoperasikan database di mesin sendiri — instalasi, konfigurasi file, patching, backup manual. Di cloud-managed, pekerjaan itu diserap platform. Ini bukan berarti DBA kehilangan pekerjaan; perannya bergeser ke lapisan yang lebih tinggi: memilih layanan, mengkonfigurasi dengan benar, mengelola networking & IAM, dan memastikan semua tetap aman & hemat biaya. Episode ini memetakan peran baru itu.

Filosofi yang harus kalian pegang: managed database = kalian bertanggung jawab atas konfigurasi, bukan atas mesin. Provider memelihara patching dan replikasi; kalian yang menentukan apakah database itu aman, tersedia, dan murah.

#Memahami Tiga Layanan Utama

Aurora menarik karena mesin-nya Postgres-compatible tetapi storage didistribusikan: data di-copy ke 6 replika di 3 AZ secara otomatis, dan read replicas bisa di-scale terpisah. Ini contoh nyata arsitektur yang kita bahas abstrak di episode 8-10.

#Provisioning RDS: Langkah Nyata

Provision RDS PostgreSQL via AWS CLI (setara terraform di episode 14):

aws rds create-db-instance \
    --db-instance-identifier appdb \
    --db-instance-class db.t4g.micro \
    --engine postgres \
    --engine-version 16.3 \
    --allocated-storage 50 \
    --storage-type gp3 \
    --master-username admin \
    --master-user-password 'SangatRahasia!2026' \
    --multi-az \
    --backup-retention-period 14 \
    --storage-encrypted

Parameter yang wajib dipahami tiap DBA cloud:

• --multi-az: failover otomatis ke AZ lain tanpa intervensi — ini HA yang di episode 8 kita bangun manual.
• --backup-retention-period 14: backup otomatis + PITR dalam jendela 14 hari — episode 5 tanpa kerja manual.
• --storage-encrypted: enkripsi at rest di level EBS — episode 9 & 19 tanpa konfigurasi manual.
• --db-instance-class: ini right-sizing yang kita optimalkan biayanya di episode 23.

Di GCP setara gcloud sql instances create appdb --database-version=POSTGRES_16 --tier=db-f1-micro --region=asia-southeast1 --enable-bin-log; di Azure az postgres flexible-server create.

#Networking di Cloud: VPC & Security Group

Di cloud, "firewall" diimplementasikan sebagai security group / firewall rule — dan ini jaring pengaman terpenting. Aturan yang hampir selalu benar:

1. Database di subnet PRIVATE — tidak ada public IP.
2. Hanya aplikasi di VPC/subnet tertentu yang boleh akses port 5432.
3. Tidak ada 0.0.0.0/0 yang membuka database ke internet.
4. DBA masuk lewat bastion/jump host, bukan langsung dari internet.

Contoh security group RDS (di-inject lewat --vpc-security-group-ids):

{
  "IpPermissions": [
    { "IpProtocol": "tcp", "FromPort": 5432, "ToPort": 5432,
      "UserIdGroupPairs": [{ "GroupId": "sg-app-tier" }] }
  ]
}

Perhatikan: rule merujuk security group aplikasi (bukan IP publik) — trafik hanya dari mesin yang punya SG itu. Ini pola security-group-to-security-group yang standar di produksi.

#Backup Otomatis & Read Replicas

Managed service mengotomatiskan apa yang kita bangun manual:

• Backup otomatis: snapshot harian + PITR (WAL/binlog disimpan). RDS: --backup-retention-period. Cloud SQL: enable_point_in_time_recovery. Azure: retained backups.
• Read replicas: satu klik; Aurora bahkan punya replicas yang bisa di-promote otomatis:

aws rds create-db-instance-read-replica \
    --db-instance-identifier appdb-replica \
    --source-db-instance-identifier appdb \
    --db-instance-class db.t4g.micro

• Promote: aws rds promote-read-replica atau --replication-source-identifier untuk alihkan; Aurora punya failover otomatis ke replica dalam ~30 detik.

Kabar buruk yang tidak banyak ditulis: managed ≠ benar. Default RDS mengizinkan akses publik (publicly-accessible=true), backup bisa dimatikan, dan encryption bisa dilupakan. DBA cloud masih bertanggung jawab membuat konfigurasi itu aman.

#Migrasi On-Prem → Managed

Migrasi on-prem ke cloud memakai pola episode 11 (zero-downtime), ditambah alat khusus cloud. Alur ringkas:

1. Buat instance managed di region terdekat, versi setara.
2. Replikasikan data dengan alat bawaan: pg_dump/pg_restore untuk sekali jalan, atau AWS DMS / GCP Database Migration Service untuk CDC tanpa henti.
3. Dual-write / cutover sesuai pola episode 11.
4. Validasi checksum & query kritis.
5. Cutover DNS aplikasi → endpoint managed, pertahankan on-prem beberapa minggu.

psql "host=appdb.xxxx.rds.amazonaws.com user=admin dbname=appdb" \
    -f appdb.dump

Praktik terbaik: lakukan test restore penuh di cloud dulu (dry-run) sebelum window migrasi sebenarnya — ini bagian dari drill yang kita tanamkan sejak episode 5.

#Pitfall Umum

1. Public endpoint dibiarkan: database terbuka ke internet = target bot. Selalu subnet private + SG ketat.
2. Retensi backup dimatikan: hemat $ tapi hilang PITR. 7-14 hari adalah baseline sehat.
3. Patching diabaikan: versi major kedaluwarsa terus-menerus; jadwalkan upgrade sesuai episode 11.
4. Multi-AZ dianggap opsional: untuk kritis, satu AZ = satu titik kegagalan.
5. Right-sizing asal pilih: instance paling kecil untuk hemat, lalu kejutan di puncak. Pelajari episode 23 untuk metrik pemilihannya.

#Penutup

Inti yang harus dibawa pulang:

• Peran DBA di cloud bergeser: konfigurasi layanan, networking, IAM, cost — bukan mengelola mesin.
• Provisioning RDS/Cloud SQL/Azure: pilih instance, Multi-AZ, retensi backup, enkripsi — semua lewat parameter, bukan file config.
• Networking cloud = subnet private + security group ke security group aplikasi; jangan pernah public endpoint.
• Migrasi on-prem → managed memakai DMS/CDC + pola zero-downtime episode 11 + dry-run restore.

Di episode 13 selanjutnya kita merambah di luar relasional: NoSQL & specialized DB ops — mengoperasikan MongoDB (replica set, sharding), Redis (persistence, eviction policy), dan Elasticsearch, dengan sudut pandang DBA yang sudah terbiasa berpikir dalam metrik. Sampai jumpa di episode 13!