Aurora #

Dalam dunia komputasi cloud, database relasional tradisional (seperti MySQL dan PostgreSQL) sering kali menjadi hambatan (bottleneck) terbesar ketika sebuah aplikasi mulai berskala besar. Masalah skalabilitas penyimpanan, ketersediaan tinggi (high availability) yang rumit dikonfigurasi, serta waktu pemulihan dari kegagalan (failover) yang lambat merupakan tantangan klasik yang menghantui para insinyur database.

AWS Aurora hadir untuk mendesain ulang arsitektur database relasional agar kompatibel dengan karakteristik cloud modern. Aurora adalah database relasional terkelola penuh dari AWS yang kompatibel dengan MySQL dan PostgreSQL, namun dengan performa hingga 5 kali lebih cepat daripada MySQL standar dan 3 kali lebih cepat daripada PostgreSQL standar. Artikel ini akan membedah secara mendalam arsitektur internal Aurora, cara kerja Aurora Serverless (v1 & v2), kebutuhan esensial koneksi database serverless melalui RDS Proxy, serta panduan praktis penerapannya di dunia nyata.

Arsitektur Penyimpanan Terdistribusi Aurora #

Kunci utama performa luar biasa dan ketahanan data AWS Aurora terletak pada pemisahan yang bersih antara Compute Layer (mesin yang memproses query SQL) dengan Storage Layer (sistem penyimpanan data).

flowchart TD
    subgraph Compute["Compute Layer (Database Instance)"]
        Writer["Writer Node (Primary)"]
        Reader["Reader Node (Read Replica)"]
    end
    
    subgraph Storage["Storage Layer (Distributed Storage Volume)"]
        direction TB
        subgraph AZ1["Availability Zone 1"]
            C1["Copy 1"]
            C2["Copy 2"]
        end
        subgraph AZ2["Availability Zone 2"]
            C3["Copy 3"]
            C4["Copy 4"]
        end
        subgraph AZ3["Availability Zone 3"]
            C5["Copy 5"]
            C6["Copy 6"]
        end
    end

    Writer -->|Tulis Data (Log stream)| Storage
    Reader -->|Baca Data| Storage

1. Replikasi Multi-AZ Otomatis #

Storage Aurora bersifat tervirtualisasi dan terdistribusi. Ketika data ditulis ke dalam database, Aurora secara otomatis menduplikasi data tersebut ke dalam 6 salinan data (copies) yang tersebar di 3 Availability Zones (AZ) yang berbeda.

2. Model Quorum (Write & Read Quorum) #

Untuk menjamin konsistensi data di atas penyimpanan terdistribusi, Aurora menggunakan aturan Quorum:

  • Write Quorum (4/6): Operasi penulisan dianggap sukses jika 4 dari 6 salinan penyimpanan berhasil menulis data. Ini membuat proses penulisan sangat cepat karena kita tidak perlu menunggu respon lambat dari pusat data terakhir.
  • Read Quorum (3/6): Operasi pembacaan data memvalidasi minimal 3 dari 6 salinan untuk memastikan data yang dibaca adalah data paling mutakhir.

3. Skalabilitas Penyimpanan Tanpa Provisioning #

Di database tradisional, kita harus menentukan ukuran disk (misal: 100 GB). Jika disk penuh, database akan crash kecuali kita menambah ukuran disk secara manual. Storage Aurora mendeteksi penggunaan secara otomatis dan akan bertumbuh secara elastis hingga 128 TB tanpa memicu downtime atau konfigurasi manual.

Aurora Serverless: v1 vs. v2 #

AWS menyediakan opsi Aurora Serverless untuk membebaskan kita dari keharusan memilih ukuran memori/CPU server database di awal. Kapasitas database akan naik dan turun secara otomatis mengikuti fluktuasi beban query.

Ada perbedaan arsitektur yang sangat signifikan antara generasi pertama (v1) dengan generasi kedua (v2):

1. Aurora Serverless v1 #

  • Metode Scaling: Menggunakan alokasi step-based (misalnya melipatgandakan kapasitas dari 2 ACU langsung ke 4 ACU, lalu 8 ACU). Proses scaling membutuhkan waktu beberapa detik hingga menit karena AWS harus menyiapkan instans baru di latar belakang.
  • Fitur Auto-Pause: Dapat turun hingga 0 ACU (Pause) jika tidak ada aktivitas koneksi sama sekali selama periode waktu tertentu (misalnya 5 menit). Ketika request baru masuk kembali, database akan terbangun kembali (resume) dengan jeda cold start sekitar 10–25 detik.
  • Use Case Terbaik: Lingkungan development, staging, atau aplikasi internal kantor yang tidak digunakan pada malam hari.
  • Metode Scaling: Scaling berjalan secara instant (hitungan milidetik) dan sangat halus (fine-grained), misalnya naik dari 1.2 ACU ke 1.3 ACU secara dinamis mengikuti beban kerja CPU actual.
  • Tanpa Auto-Pause: v2 tidak mendukung fitur auto-pause ke nol. Batas kapasitas minimum yang didukung adalah 0.5 ACU (setara dengan RAM ~1 GB) untuk menjaga agar database selalu aktif tanpa risiko cold start.
  • Fitur Multi-AZ & Read Replica: v2 dapat dipadukan dengan Provisioned Reader dan mendukung replikasi multi-region secara global database.
  • Use Case Terbaik: Beban kerja produksi skala besar, REST API publik dengan traffic spiky, e-commerce, dan aplikasi enterprise.

Definisi ACU (Aurora Capacity Unit): 1 ACU merepresentasikan alokasi memori sebesar ~2 GB RAM beserta proporsi daya komputasi CPU dan bandwidth jaringan yang sesuai.

Konektivitas Serverless: Peran RDS Proxy #

Salah satu masalah arsitektur terbesar ketika menghubungkan fungsi FaaS (seperti AWS Lambda) langsung ke database relasional adalah kehabisan kuota koneksi (connection exhaustion).

Database PostgreSQL atau MySQL membatasi jumlah koneksi aktif (biasanya maksimal beberapa ratus koneksi). Setiap kali fungsi Lambda dipanggil, ia akan membuka satu koneksi baru ke database. Jika terjadi lonjakan traffic yang memicu 1.000 instans Lambda berjalan secara paralel, database akan kehabisan koneksi seketika dan menolak transaksi berikutnya (connection refused).

flowchart TD
    subgraph LambdaSpike["Siklus Scaling Lambda (Spiky)"]
        L1["Lambda Instance 1"]
        L2["Lambda Instance 2"]
        L3["Lambda Instance N"]
    end
    
    subgraph VPC["Virtual Private Cloud"]
        Proxy["Amazon RDS Proxy<br/>(Mengelola Connection Pool)"]
        
        subgraph AuroraCluster["Aurora Serverless v2 Cluster"]
            DBWriter["Writer Node<br/>(Scaling: 0.5 - 16 ACU)"]
            DBReader["Reader Node<br/>(Read Replica)"]
        end
        
        L1 -->|Koneksi Singkat| Proxy
        L2 -->|Koneksi Singkat| Proxy
        L3 -->|Koneksi Singkat| Proxy
        
        Proxy -->|Koleksi Koneksi Stabil| DBWriter
        Proxy -->|Koleksi Koneksi Stabil| DBReader
    end

Keunggulan Amazon RDS Proxy: #

  • Connection Pooling: RDS Proxy berada di tengah-tengah antara Lambda dan database. Ia mengelola ribuan koneksi dari Lambda dan menyalurkannya kembali ke database melalui sekumpulan (pool) kecil koneksi database yang stabil dan persisten.
  • Kecepatan Failover: Jika writer node Aurora mengalami kegagalan, RDS Proxy secara otomatis mengalihkan koneksi ke reader node (yang dinaikkan statusnya menjadi writer baru) tanpa memutus koneksi aplikasi di sisi Lambda.

Contoh Kode Implementasi: Koneksi via RDS Proxy #

Berikut adalah contoh kode Node.js yang mendemonstrasikan cara aman menghubungkan fungsi Lambda ke database Aurora PostgreSQL menggunakan RDS Proxy dan mengambil kredensial database secara otomatis dari AWS Secrets Manager menggunakan token IAM.

// BENAR: Menggunakan RDS Proxy + Secrets Manager + Token IAM Database
import { PG } from 'pg';
import { SecretsManagerClient, GetSecretValueCommand } from "@aws-sdk/client-secrets-manager";

const secretsClient = new SecretsManagerClient({ region: "ap-southeast-1" });
const SECRET_ARN = process.env.DB_SECRET_ARN;
const PROXY_ENDPOINT = process.env.RDS_PROXY_ENDPOINT;

let dbClient = null;

async function getDatabaseCredentials() {
    console.log("Mengambil kredensial database dari Secrets Manager...");
    const data = await secretsClient.send(new GetSecretValueCommand({ SecretId: SECRET_ARN }));
    return JSON.parse(data.SecretString);
}

async function initializeDbClient() {
    if (!dbClient) {
        const credentials = await getDatabaseCredentials();
        
        dbClient = new PG.Client({
            host: PROXY_ENDPOINT, // ✓ Menghubungkan ke RDS Proxy endpoint, bukan ke database langsung
            port: 5432,
            database: credentials.dbname,
            user: credentials.username,
            password: credentials.password,
            ssl: {
                rejectUnauthorized: true // ✓ Selalu aktifkan verifikasi sertifikat SSL di production
            }
        });
        
        await dbClient.connect();
        console.log("Sukses terhubung ke database via RDS Proxy.");
    }
}

export const handler = async (event) => {
    try {
        await initializeDbClient();
        
        const result = await dbClient.query("SELECT NOW()");
        
        return {
            statusCode: 200,
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ 
                success: true, 
                dbTime: result.rows[0].now 
            })
        };
    } catch (error) {
        console.error("Terjadi error koneksi database", error);
        return {
            statusCode: 500,
            body: JSON.stringify({ error: "Gagal memproses data" })
        };
    }
};

Ringkasan #

  • AWS Aurora memisahkan Compute dan Storage layer secara bersih, menduplikasi data sebanyak 6 salinan di 3 AZ, dan menskalakan ukuran disk secara otomatis hingga 128 TB.
  • Aurora Serverless v2 menawarkan skalabilitas komputasi yang sangat instan dan halus (dalam hitungan milidetik) berbasis ACU (Aurora Capacity Unit) dengan batas minimum 0.5 ACU.
  • Aurora Serverless v1 mendukung fitur auto-pause hingga 0 ACU, namun memiliki kendala jeda cold start saat terbangun kembali.
  • Amazon RDS Proxy sangat wajib digunakan untuk aplikasi serverless (Lambda) guna mencegah kehabisan koneksi (connection exhaustion) melalui fitur connection pooling.
  • Terapkan keamanan IAM Database Authentication dan integrasi Secrets Manager untuk mengamankan pertukaran token kredensial database saat runtime.

← Sebelumnya: Step Functions   Berikutnya: API Gateway →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact