Bisnis di sektor event management dan ticketing menghadapi tantangan terkait lonjakan trafik ekstrem di waktu tertentu (seperti saat memulai penjualan tiket) dan penggunaan nyaris nol di luar periode tersebut. Infrastruktur on-premises tradisional membuat perusahaan harus berinvestasi besar untuk kapasitas yang hanya digunakan sesaat sehingga membuat biaya operasional tinggi dan pemborosan sumber daya.
Menurut laporan AWS Economics Center, organisasi yang bermigrasi ke cloud menghemat 30-50 persen dari total biaya IT dan meningkatkan agility operasional hingga 37 persen berkat kemampuan skalabiltias otomatis dan optimasi berbasis penggunaan.
Artikel ini menyajikan use case implementasi Amazon Aurora Serverless sebagai database utama untuk skenario event-based seperti ticketing.
Ringkasan Use Case: Tantangan dan Kebutuhan
Sebuah perusahaan event organizer memiliki aplikasi ticketing yang hanya aktif selama beberapa kali dalam setahun. Memasuki periode event, traffic melonjak berkali-kali lipat, sementara saat idle kapasitas menurun drastis hingga mendekati nol.
Untuk menangani kebutuhan lonjakan traffic, Amazon Aurora Serverless dapat membantu perusahaan event organizer menyesuaikan beban transaksi ketika terjadi lonjakan dan saat idle. Dengan arsitektur database auto-scaling, perusahaan event organizer dapat menyesuaikan kapasitas sesuai permintaan tanpa downtime hingga menurunkan penggunaan hingga 0 ACU (Aurora Capacity Unit) saat idle, sehingga biaya berhenti ketika tidak digunakan.
Langkah-langkah Implementasi Amazon Aurora Serverless
Untuk memulai proses implementasi Amzaon Aurora Serverless, perusahaan event organizer dapat melakukan langkah-langkah berikut.
1. Membuat Subnet Group
Pertama buat DB Subnet Group untuk menentukan subnet dalam VPC yang akan digunakan oleh cluster Aurora. Pilih subnet di beberapa Availability Zone (AZ) untuk high availability. Umumnya minimal 2-3 subnet di AZ berbeda agar Aurora dapat menempatkan compute dan storage secara redundan.
2. Buat Database, Pilih Engine Aurora MySQL
Saat membuat database, penulis bisa memilih Amazon Aurora (MySQL-compatible). Aurora tersedia dalam dua varian engine utama: Aurora MySQL-compatible dan Aurora PostgreSQL-compatible yang sama-sama memiliki fitur seperti distributed storage, high throughput, dan fast crash recovery.
Perbedaan utama keduanya yakni Aurora MySQL-compatible lebih cocok untuk aplikasi yang menggunakan MySQL atau migrasi mudah, sementara Aurora MpostgreSQL-compatible cocok untuk aplikasi yang menggunakan PostgreSQL. Selain engine klasik (provisioned), tersedia juga Aurora Serverless V2 yang berguna untuk beban bersifat bursty atau event based.
3. Password & AWS Secrets Manager
Amankan kredensial database menggunakan AWS Secrets Manager atau self-managed password yang lebih sederhana, namun membutuhkan proses rotation dan penyimpanan yang aman. Berikut tiga kelebihan utama Secrets Manager:
- Menyimpan dan otomatis me-rotate password (opsional).
- Integrasi mudah dengan aplikasi via SDK/API, dan IAM.
- Mengurangi risiko kredensial hard-coded.
4. Aurora Serverless v2 dan ACU (Aurora Capacity Unit)
Aurora Serverless v2 mendukung auto scaling granular berbasis ACU. Misalnya, Anda dapat menetapkan rentang 0–8 ACU: saat tidak ada trafik, sistem idle tanpa biaya compute; saat terjadi lonjakan trafik, Aurora otomatis menambah kapasitas tanpa intervensi manual demi memastikan performa tetap stabil.
5. High Availability dan Read Replica
Untuk menjaga read scalability dan ketersediaan tinggi, Anda dapat menambahkan read replica di Availability Zone berbeda. Aurora dapat secara otomatis melakukan failover ke replica saat node utama mengalami gangguan, memastikan uptime optimal bagi pengguna. Sebaiknya buat minimal 1 replica di AZ berbeda untuk meningkatkan ketersediaan baca dan gunakan auto failover pada konfigurasi cluster jika instance writer gagal. Pastikan juga untuk pilih VPC dan subnet group yang sebelumnya telah dibuat agar cluster berada di jaringan yang benar.
6. Security Group dan RDS Data API
Batasi akses inbound database hanya dari sumber yang diperlukan. Aurora Serverless juga menyediakan RDS Data API, yang memungkinkan integrasi aman melalui HTTPS tanpa perlu connection pooling tradisional sehingga cocok untuk aplikasi berbasis AWS Lambda atau aplikasi tanpa jaringan langsung ke VPC tanpa koneksi langsung ke database. Demi alasan keamanan, pastikan menggunakan IAM untuk membatasi akses DATA API dan jika memungkinkan traffic internal berada di VPC private.
7. Performance Insights & Enhanced Monitoring
Aktifkan Performance Insights untuk memantau query level paling berat dan Enhanced Monitoring untuk observasi metrik sistem seperti CPU, memory, dan I/O. Kedua tools ini penting untuk menjaga retensi lebih lama yang bisa dikarenakan biaya tambahan dan kemungkinan menambah biaya tergantung pada frekuensi sampling dan retensi. Sangat direkomendasikan untuk mengaktifkan kedua tools untuk troubleshooting dan mematikan atau mengatur retensi ketika sudah stabil demi mengurangi biaya.
8. Log Export
Integrasi dengan Amazon CloudWatch Logs untuk pengaturan log exports untuk keperluan monitoring, troubleshooting, dan audit keamanan. Setiap log memiliki fungsi berbeda sebagai berikut:
- Audit log: menyimpan informasti aktivitas pengguna di database, termasuk siapa yang mengakses, waktu akses, dan aktivitas yang dilakukan untuk kebutuhan keamanan dan audit kepatuhan.
- Error log: menyimpan error yang terjadi di sistem database untuk mengidentifikasi penyebab masalah teknis.
- General log: berisi informasi umum mengenai aktivitas server MySQL atau database lain, seperti perintah SQL yang dijalankan untuk debugging query.
- IAM DB auth error log: mencatat kesalahan ketika menggunakan IAM authentication untuk koneksi database.
- Instance log: log terkait instance RDS yang berisi data operasional atau event pesan dari sistem.
- Slow query log: menyimpan catatan query SQL yang membutuhkan waktu lama untuk dieksekusi sehingga berguna untuk mengoptimalkan performa database.
9. Konfigurasi Tambahan
Pengaturan lanjutan yang menentukan konfigurasi, backup, keamanan, hingga maintenance yang mencakup:
a) Database Option
Berfungsi untuk mendefinisikan parameter dan konfigurasi awal database.
- Initial database name: Menentukan nama awal database yang otomatis akan dibuat di dalam instance RDS. Jika kosong, database dibuat tanpa database default.
- DB cluster parameter group: mengatur parameter pada tingkat cluster, termasuk pengaturan replikasi dan konfigurasi umum di seluruh instance dalam cluster.
- DB parameter group: mengatur konfigurasi khusus di setiap instance database (seperti ukuran cache, timeout, max connections, dsb).
- Option group: digunakan untuk menambahkan fitur tambahan pada database (misalnya audit plugin, Oracle, SQL Server features, MySQL plugins atau integrasi dengan layanan lain).
- Failover priority: menentukan urutan preferensi instance replika (reader instance) yang dijadikan sebagai primary instance ketika terjadi kegagalan.
- Pengaturan “no preference” berarti AWS akan memilih secara otomatis.
b) Backup & Encryption at Rest
Pengaturan untuk mengontrol bagaimana dan berapa lama backup otomatis dapat tersimpan.
- Backup retention period: menentukan lamanya auto backup tersimpan di database AWS.
- Copy tags to snapshots: menyalin tag dari database ke snapshot untuk melacak dan manajemen biaya.
- Enable encryption: mengaktifkan enkripsi data di penyimpanan database menggunakan AWS KMS (Key Management Service) untuk meningkatkan keamanan data yang tersimpan dan backup.
- AWS KMS key: menentukan key yang digunakan untuk enkripsi dengan pilihan default AWS/RDS.
c) Backtrack
Memungkinkan pengguna untuk mengembalikan database ke titik waktu tertentu tanpa perlu me-restore dari backup snapshot. Fitur ini berguna untuk pemulihan cepat dari kesalahan logika (seperti penghapusan data yang tidak sengaja), termasuk aktivasi penambahan biaya karena AWS menyimpan perubahan data tambahan untuk rewind.
d) Maintenance
Bagian ini mengatur pemeliharaan database secara otomatis, termasuk enable auto minor version upgrade dan maintenance window. Aktivasi enable auto minor version upgrade dapat secara otomatis memperbarui versi minor dari engine agar selalu mendapatkan security patch dan meningkatkan stabilitas terbaru. Sementara maintenance window dapat menentukan waktu khusus untuk penerapan patch atau update, saat memilih “no preference” maka AWS dapat menjadwalkan waktu secara otomatis.
10. Review & Create (step wizard akhir)
Tahap terakhir membuat cluster untuk mengecek semua konfigurasi, mencakup engine, VPC/subnet, security group, ACU min/max, monitoring, backup encryption kemudian klik “create”. Pastikan semua pengaturan sudah sesuai kebijakan keamanan dan kebutuhan performa.
11. Database Berhasil Dibuat
Setelah pembuatan, cluster Aurora Serverless berada dalam kondisi standby bila minimal ACU = 0 dan belum ada koneksi aktif. Artinya tidak ada compute berjalan sehingga biaya komputasi mendekati nol (hanya biaya storage dan backup). Meskipun compute standby, storage tetap dikenakan biaya dan connection pool atau warm-up diperlukan ketika koneksi pertama sehingga sedikit delay ketika cold start.
12. Deploy Aplikasi Ticketing & Pengujian Awal
Penulis men-deploy aplikasi ticketing ke EC2 dan mengarahkan koneksi ke cluster Aurora dengan langkah pengujian sebagai berikut:
- Akses aplikasi dari internet
- Lakukan pembelian tiket dengan memasukkan data untuk memastikan koneksi dan kredensial.
- Saat koneksi berhasil, data akan masuk ke database.
13. Muncul Koneksi – ACU Naik
Setelah transaksi atau koneksi aktif, cluster akan memulai compute dan ACU meningkat dari 0 sesuai kebutuhan. Pada fase in perlu dilakukan monitoring ACU melalui metrik ServerlessDatabasecapacity, monitoring connection, CPU, query latency, dan throughput. Jika respons lambat, cek ulang query yang berat (bisa dicek melalui performance insight) dan lakukan tuning atau indexing.
14. Simulasi Load (Script)
Berikutnya penulis dapat menjalankan script untuk load test seperti selama periode acara terjadi untuk memprediksi lonjakan trafik yang dapat terjadi hingga ratusan kali lipat. Langkah ini dilakukan untuk memastikan autoscaling bekerja hingga ACU maksimal dan mengidentifikasi bottleneck (connection limits, slow queries, I/O). Gunakan tools load testing terkontrol seperti K6, Locust, atau JMeter untuk memastikan batas keamanan agar tidak merusak data produksi.
15. DB Scale ke Maximum ACU
Ketika load tinggi, Aurora Serverless v2 akan menskalakan hingga mencapai ACU maksimal yang telah diatur sebelumnya sehingga database dapat melayani puncak trafik tanpa downtime. Perhatikan latensi scale-up dan penurunan performa sementara ketika scaling, jika mencapai limit maka naikkan maksimal ACU atau optimasi query.
16. Setelah Event Selesai, Kembalikan ACU ke 0 (Standby)
Setelah periode acara selesai, matikan script dan turunkan sistem ACU secara bertahap hingga mencapai nilai minimal (0), sehingga biaya komputasi berhenti dikenakan.
Penutup & Catatan Implementasi
Implementasi Amazon Aurora Serverless menggunakan AWS Secrets Manager untuk menyimpan kredensial database secara aman dan mengaktifkan fitur rotasi otomatis demi meminimalkan risiko kebocoran data. Pastikan untuk membatasi akses ketat dengan mengatur “Security Group” dan menggunakan kebijakan IAM berbasis least privilege sehingga hanya pihak berwenang dapat mengakses database.
Aktifkan Performance Insights dan Enhanced Monitoring untuk memudahkan proses monitoring dan troubleshooting, sesuaikan periode retensi data untuk mengelola biaya operasional secara efisien. Tentukan batas minimal dan maksimal ACU sesuai profil workload untuk aplikasi berbasis event-driven, terapkan nilai minimal 0 dan maksimal sesuai perkiraan puncak beban.
Manfaatkan read replica untuk menangani skenario dengan intensitas reading tinggi, sehingga kinerja database utama tetap optimal. Lakukan load testing secara terencana sebelum menghadapi periode ketika terjadi lonjakan traffic untuk memastikan sistem siap menangani beban tersebut. Siapkan runbook operasional sebagai panduan ketika terjadi masalah pada mekanisme autoscaling dengan menambah batas maksimal ACU sementara atau scale-out pada read replica.
Ingin tahu lebih dalam atau butuh panduan lanjutan terkait tutorial ini? Hubungi tim CDT untuk berdiskusi bagaimana solusi ini bisa diadaptasi sesuai kebutuhan Anda.
Penulis: Jaya Adilman
Editor: Ervina Anggraini – Content Writer CTI Group
