Database di Server Terpisah, Kapan Perlu Dipisah?

Memisahkan database berarti aplikasi (web server, PHP, Node.js, dan sejenisnya) berjalan di satu server, sedangkan MySQL, MariaDB, atau PostgreSQL berjalan di server lain, dan keduanya berkomunikasi lewat jaringan. Ini langkah yang sangat umum saat aplikasi mulai tumbuh.

Yang dipertaruhkan cukup nyata. Memisah terlalu cepat menambah biaya, latensi, dan satu server lagi untuk dirawat, tanpa hasil yang terasa. Memisah terlambat membuat aplikasi dan database saling mencekik saat trafik naik, dan perubahan arsitektur dilakukan dalam keadaan darurat. Jadi pertanyaannya bukan "apakah memisah itu bagus", tapi "apakah sekarang waktunya".

Apa untung dan ruginya memisah database?

Keuntungan

• Sumber daya tidak berebut. Database suka RAM untuk cache (misalnya buffer pool InnoDB), sementara proses PHP atau Node.js juga butuh RAM saat trafik naik. Di satu server, lonjakan trafik bisa membuat database kehabisan memori, atau sebaliknya.
• Bisa menambah server aplikasi. Kalau aplikasi perlu dua atau lebih server di belakang load balancer, semuanya harus memakai satu database bersama. Itu hanya bisa bila database berada di server sendiri.
• Penyetelan lebih leluasa. Server database bisa diberi disk yang cepat, RAM besar, dan setelan yang khusus untuk database. Setelan yang paling berpengaruh dibahas di setelan MySQL dan MariaDB.
• Keamanan berlapis. Server database tidak perlu menerima koneksi dari internet sama sekali. Kalau server aplikasi dibobol lewat celah di website, penyerang belum otomatis memegang seluruh sistem database.
• Perawatan terpisah. Update aplikasi, restart web server, atau ganti versi PHP tidak menyentuh database, begitu juga sebaliknya.

Kerugian

• Latensi jaringan per query. Di satu server, query lewat socket lokal hampir tanpa jeda. Di server terpisah, setiap query menempuh perjalanan jaringan. Satu query tidak terasa, tapi halaman yang menjalankan ratusan query kecil (pola N+1) bisa melambat nyata.
• Biaya bertambah. Ada server kedua, dan idealnya jaringan privat di antara keduanya.
• Titik kegagalan bertambah. Kini ada dua server yang harus menyala bersamaan. Memisah tidak otomatis membuat sistem lebih tahan gangguan.
• Konfigurasi lebih banyak. Akses jaringan, firewall, user dengan host tertentu, dan enkripsi koneksi harus diatur dengan benar.

Perbandingan pilihan arsitektur

Database terkelola adalah variasi dari memisah: server database tetap terpisah, tetapi backup, pembaruan, dan pemantauannya diurus penyedia. Bedanya dengan menjalankan sendiri di VPS dijelaskan di apa itu cloud database.

Tanda-tanda sudah waktunya memisah

Perhatikan pola ini selama beberapa minggu, bukan satu kejadian:

• RAM sering hampir habis di jam sibuk, dan proses database atau PHP sesekali dimatikan sistem karena kehabisan memori.
• CPU tinggi dan sulit memastikan siapa penyebabnya karena aplikasi dan database sama-sama sibuk.
• Kamu berencana menambah server aplikasi atau memasang load balancer.
• Ada lebih dari satu aplikasi yang memakai database yang sama.
• Ada tuntutan keamanan agar data tidak berada di server yang menghadap publik.

Sebaliknya, bila masalahnya adalah query lambat, memindahkan database ke server lain jarang menolong. Query yang tidak memakai indeks tetap lambat di mana pun ia berjalan. Periksa slow query log dan indeks lebih dulu.

Kapan tetap satu server, kapan dipisah?

Tetap di satu server bila aplikasi masih kecil sampai menengah, hanya ada satu server aplikasi, dan RAM serta CPU masih longgar. Menaikkan spesifikasi server yang sama sering kali lebih murah dan lebih sederhana daripada menambah server. Banyak toko online dan aplikasi internal berjalan baik bertahun-tahun dengan arsitektur ini.

Pisahkan bila tanda-tanda di atas sudah konsisten, terutama rencana menambah server aplikasi. Letakkan kedua server di pusat data dan jaringan privat yang sama agar latensinya kecil. Bila tim kecil dan tidak ingin merawat server database sendiri, pilih database terkelola. Setelah dipisah, langkah berikutnya untuk ketahanan adalah replikasi database ke server cadangan.

Bagaimana memisahkannya dengan aman?

Langkah besarnya:

1. Siapkan server database baru di lokasi dan jaringan privat yang sama dengan server aplikasi.
2. Pasang versi database yang sama dengan yang dipakai sekarang, lalu sesuaikan setelannya dengan RAM server baru.
3. Atur agar database hanya mendengarkan di IP privat, dan firewall hanya mengizinkan IP server aplikasi.
4. Buat user database dengan host terbatas, misalnya 'app'@'10.0.0.10', bukan '%'.
5. Uji koneksi dan kecepatan dari server aplikasi, idealnya di lingkungan uji dulu.
6. Pada jam sepi, hentikan penulisan sebentar, salin data dengan dump terbaru, ubah alamat database di konfigurasi aplikasi, lalu jalankan.
7. Pantau beberapa hari, dan pastikan backup kini mengambil dari server database yang baru.

Rincian pengaturan akses jaringan MySQL ada di membuka akses remote MySQL dengan aman.