Pengenalan Redundansi Data & Rencana Pemulihan Bencana (DRP) 📝

Hari ini, kita akan membahas strategi redundansi data dan rencana pemulihan bencana untuk mengatasi aplikasi enterprise berukuran kecil hingga menengah, yang biasanya merupakan aplikasi monolitik yang berjalan pada satu server. Tujuan dari rencana pemulihan bencana adalah untuk mengurangi masalah utama yang memecahkan aplikasi dan membuatnya tidak dapat digunakan. Rencana ini harus memulihkan aplikasi secepat mungkin sehingga pengguna dapat terus menggunakan aplikasi seperti biasa.

Untuk redundansi data, ini akan membantu mencapai tujuan dari rencana pemulihan. Tanpa redundansi data, kita tidak dapat mencapai tujuan dari rencana pemulihan. Secara sederhana, DR adalah cadangan data dalam bentuk apa pun.

Redundansi Data 🗂

Menurut techopedia, redundansi data berarti ”keadaan yang dibuat di dalam database atau teknologi penyimpanan data di mana data yang sama disimpan di dua tempat terpisah.” Redundansi data dapat terjadi secara tidak sengaja atau disengaja untuk tujuan pencadangan dan pemulihan. Dalam blog ini, kita akan membahas DR, yang sengaja dibuat untuk tujuan pencadangan dan pemulihan.

Biasanya, ketika ada anggaran yang lebih besar tersedia, kita dapat memulai server lain yang mengkloning server database utama dan secara berkala menyinkronkan data tersebut ke server cadangan. Tetapi demi efisiensi biaya, kami mencoba untuk mendekatinya dengan strategi DR yang lain.

Ini merupakan strategi redundansi data kami yang sederhana dan hemat biaya

1. Menyiapkan simple storage service (AWS S3, Google Cloud Storage, etc.)
2. Secara berkala, dump data dari sistem basis data utama
3. Kirim hasil dump tersebut ke teknologi penyimpanan pilihan
4. Selesai 😁

Mungkin ini bukan pendekatan terbaik untuk membuat strategi redundansi/data backup, tetapi pendekatan ini seimbang dengan tujuan utama DR itu sendiri dengan efisiensi biaya. Membuat layanan penyimpanan sederhana jauh lebih murah daripada membuat server database yang baru.

Meskipun terlihat sederhana, kami masih memerlukan manajemen penyimpanan otomatis untuk backup. Untuk itu, kami perlu menerapkan strategi yang dapat membersihkan backup lama yang tidak terpakai. Di @elanode, kami selalu berusaha menyeimbangkan kebutuhan klien kami, memenuhi praktik terbaik industri, dan mempertimbangkan biaya, sehingga DR ini menjadi strategi de facto untuk mencapai backup yang dapat diandalkan sambil menyeimbangkan anggaran dan kebutuhan klien.

Rencana Pemulihan Bencana / Disaster Recovery Plan 📖

Rencana pemulihan mungkin agak lebih kompleks daripada strategi DR di atas. DRP terdiri dari beberapa langkah manual, gambar dasar server yang telah dikonfigurasi sebelumnya, skrip otomatis, application base image, kontainer, dan sebagainya. Kami mencoba membuat konfigurasi aplikasi kami se-konsisten mungkin untuk mengurangi ketidaksesuaian antara setiap penyebaran produksi. Perlu diingat bahwa rencana ini dimaksudkan untuk aplikasi UKM dengan lalu lintas rendah hingga sedang dan dapat menoleransi waktu henti aplikasi sampai pada batas tertentu.

Secara garis besar dengan rincian perkiraan waktu, ini merupakan rencana yang biasa kami terapkan untuk aplikasi full stack monolith yang berjalan pada satu server:

1. Tentukan apakah server dapat dipulihkan dalam waktu sebentar (~3 mins.)
2. Menyalakan server baru dengan skrip otomatis dan image pra-konfigurasi (~10 mins.)
   • Dalam waktu yang bersamaan, ambil data backup terakhir
   • Melakukan pengalihan DNS ke server baru (300 detik TTL records)
3. Install / mengalihkan pipeline deployment untuk image aplikasi & containers ke server baru (~5 mins.)
4. Pulihkan data backup dengan skrip otomatis (~5 mins.)
5. Uji coba aplikasi yang baru saja ter-deploy (~5 mins.)

Tentu saja, ini bukanlah rencana yang paling cepat atau paling canggih. Namun, pada kenyataannya, kebanyakan aplikasi dapat mentolerir beberapa waktu tidak aktif. Berdasarkan pengalaman kami, ini seharusnya sudah cukup memadai karena rencana ini dimaksudkan sebagai upaya terakhir untuk menyelesaikan masalah besar pada aplikasi.

Dalam mempertimbangkan kebutuhan dan anggaran klien, kami harus mempertimbangkan beberapa faktor, seperti efektivitas biaya. Sampai saat ini, ini adalah pendekatan terbaik kami secara keseluruhan. Jika tersedia anggaran yang lebih besar, kami dapat mencoba opsi lain seperti mengambil snapshot server secara berkala, menyiapkan pusat pemulihan bencana dengan server backup, dan melakukan load balancing ke server backup. Namun, opsi-opsi ini hanya cocok untuk aplikasi yang lebih besar dengan trafik yang lebih tinggi, dan itu cerita untuk lain kesempatan!