Jasa Managed MongoDB

Setup replica set MongoDB dan mengapa satu node tidak cukup

Pekerjaan setup replica set MongoDB adalah hal pertama yang kami kerjakan pada instalasi node tunggal. Alasannya bukan hanya ketersediaan — replica set juga prasyarat untuk transaksi multi-dokumen dan untuk change stream, dua fitur yang sering dibutuhkan aplikasi tanpa disadari.

Jumlah anggotanya ganjil, minimal tiga, supaya pemilihan primary punya kuorum. Konfigurasi dua node ditambah satu arbiter kadang dipakai untuk menghemat, tetapi arbiter tidak menyimpan data — jadi kehilangan satu node data berarti tidak ada salinan lagi.

Untuk pembacaan yang berat, secondary bisa dipakai melayani kueri baca dengan `readPreference` yang tepat. Ini menggeser beban laporan dan analitik menjauh dari node yang melayani transaksi.

Tuning MongoDB: indeks lebih dulu, perangkat keras belakangan

Pekerjaan tuning MongoDB hampir selalu dimulai dari indeks, bukan dari menaikkan RAM. Yang kami lakukan pertama: menyalakan profiler pada ambang tertentu, membiarkannya berjalan beberapa hari, lalu memeriksa kueri mana yang menghabiskan total waktu terbanyak.

Yang dicari adalah `COLLSCAN` di rencana eksekusi — tanda MongoDB memeriksa seluruh koleksi karena tidak ada indeks yang cocok. Untuk kueri yang menyaring beberapa field sekaligus, indeks gabungan dengan urutan field yang benar sering memangkas waktu dari detik menjadi milidetik.

Setelah indeks beres, giliran memori. WiredTiger memakai cache yang secara bawaan setengah dari RAM dikurangi satu gigabita; pada server yang khusus untuk MongoDB, angka itu bisa dinaikkan. Yang harus dihindari kebalikannya — cache lebih besar dari data yang aktif diakses tidak menambah apa pun.

Indeks juga bisa berlebihan. Setiap indeks memperlambat penulisan dan memakan memori, jadi indeks yang tidak pernah dipakai — dan `$indexStats` bisa menunjukkannya — sebaiknya dihapus.

Sharding MongoDB: kapan benar-benar perlu

Sharding MongoDB membagi satu koleksi ke beberapa server, dan ia menambah kerumitan operasional secara signifikan: config server, router `mongos`, dan pemilihan shard key yang tidak bisa diubah dengan mudah setelah data masuk.

Karena itu jawaban kami untuk sebagian besar kasus adalah belum. Data yang masih bisa masuk ke memori satu server, atau yang bisa dipangkas dengan arsip data lama, hampir selalu lebih baik ditangani begitu.

Sharding masuk akal ketika volume data melampaui kapasitas satu mesin yang wajar, atau ketika laju penulisan sudah menjadi batas dan tidak bisa dinaikkan lagi. Kalau kondisi itu ada, pemilihan shard key jadi keputusan terpenting — kunci yang menghasilkan distribusi tidak merata membuat satu shard bekerja sendiri sementara yang lain menganggur.

Backup MongoDB otomatis dan uji pemulihannya

Cadangan dengan `mongodump` cukup untuk basis data kecil, tetapi pada volume besar ia lambat dan membebani node yang sedang melayani. Untuk itu backup MongoDB otomatis yang kami siapkan biasanya memakai snapshot volume atau `mongodump` yang diarahkan ke secondary, bukan ke primary.

Yang lebih menentukan daripada metodenya adalah pengujiannya. Cadangan dipulihkan ke lingkungan terpisah secara berkala, dan hasilnya diperiksa: jumlah dokumen per koleksi dibandingkan, indeks dipastikan ikut terbentuk.

Untuk kebutuhan pemulihan ke titik waktu tertentu, oplog perlu ikut dicadangkan. Tanpa itu, pemulihan hanya bisa ke waktu snapshot terakhir — yang berarti kehilangan data sejak saat itu.

MongoDB sendiri atau layanan terkelola vendor

Pertanyaan soal MongoDB Atlas Indonesia sering muncul: kenapa tidak memakai layanan resmi saja. Untuk banyak kasus itu memang pilihan yang wajar, dan kami akan mengatakannya bila cocok.

Yang membuat orang tetap memilih instalasi sendiri biasanya tiga hal: biaya pada volume besar, ketentuan penempatan data di Indonesia, atau kebutuhan latensi sangat rendah ke aplikasi yang berjalan di infrastruktur yang sama.

Kalau Anda memakai layanan vendor, pekerjaan kami bergeser — bukan mengurus servernya, tapi mengurus perancangan skema, indeks, dan pemantauan kueri. Bagian itu tidak hilang hanya karena servernya dikelola orang lain.

Keamanan instalasi MongoDB yang sering terlewat

Selain autentikasi, ada beberapa hal yang kami periksa dan setel pada setiap instalasi yang kami ambil alih.

• `bindIp` diarahkan hanya ke alamat yang perlu, bukan ke semua antarmuka.
• Peran pengguna dibuat sesuai kebutuhan aplikasi, bukan `root` untuk semua koneksi.
• Enkripsi dalam perjalanan diaktifkan bila lalu lintas melewati jaringan yang tidak sepenuhnya Anda kendalikan.
• Audit koneksi dinyalakan supaya sumber akses bisa ditelusuri.
• Antarmuka administrasi tidak dipublikasikan, dan aksesnya lewat jaringan privat.