Faktor utama yang mendorong pertimbangan kelangsungan bisnis untuk sistem penting adalah membantu organisasi menjadi tangguh dan melanjutkan operasi bisnisnya selama dan setelah peristiwa kegagalan. Dengan mereplikasi sistem dan data di beberapa region geografis dan menghindari titik tunggal kegagalan, Anda dapat meminimalkan risiko bencana alam yang memengaruhi infrastruktur lokal. Skenario kegagalan lainnya mencakup kegagalan sistem yang parah, serangan keamanan siber, atau bahkan error konfigurasi sistem.
Mengoptimalkan sistem agar dapat menahan kegagalan sangat penting untuk membangun kelangsungan bisnis yang efektif. Keandalan sistem dapat dipengaruhi oleh beberapa faktor, termasuk, tetapi tidak terbatas pada, performa, ketahanan, ketersediaan waktu aktif, keamanan, dan pengalaman pengguna. Untuk informasi selengkapnya tentang cara merancang dan mengoperasikan layanan yang andal di Google Cloud, lihat kolom keandalan dari Framework Arsitektur Google Cloud dan elemen penyusun keandalan di Google Cloud.
Pola arsitektur ini bergantung pada deployment aplikasi yang redundan di beberapa lingkungan komputasi. Dalam pola ini, Anda men-deploy aplikasi yang sama di beberapa lingkungan komputasi dengan tujuan meningkatkan keandalan. Kelangsungan bisnis dapat didefinisikan sebagai kemampuan organisasi untuk melanjutkan fungsi atau layanan bisnis utamanya pada tingkat yang dapat diterima yang telah ditentukan sebelumnya setelah peristiwa yang mengganggu.
Pemulihan dari bencana (DR) dianggap sebagai bagian dari kelangsungan bisnis, yang secara eksplisit berfokus pada memastikan bahwa sistem IT yang mendukung fungsi bisnis penting beroperasi sesegera mungkin setelah gangguan. Secara umum, strategi dan rencana DR sering membantu membentuk strategi kelangsungan bisnis yang lebih luas. Dari sudut pandang teknologi, saat Anda mulai membuat strategi pemulihan dari bencana, analisis dampak bisnis Anda harus menentukan dua metrik utama: tujuan titik pemulihan (RPO) dan batas waktu pemulihan (RTO). Untuk panduan lebih lanjut tentang penggunaan Google Cloud untuk mengatasi pemulihan dari bencana, lihat Panduan perencanaan pemulihan dari bencana.
Makin kecil nilai target RPO dan RTO, makin cepat layanan dapat pulih dari gangguan dengan kehilangan data minimal. Namun, hal ini menyiratkan biaya yang lebih tinggi karena berarti membangun sistem redundan. Sistem redundan yang mampu melakukan replikasi data mendekati real-time dan beroperasi pada skala yang sama setelah peristiwa kegagalan, meningkatkan kompleksitas, overhead administratif, dan biaya.
Keputusan untuk memilih strategi DR atau pola harus didasarkan pada analisis dampak bisnis. Misalnya, kerugian finansial yang timbul dari downtime selama beberapa menit saja bagi organisasi jasa keuangan mungkin jauh melebihi biaya penerapan sistem DR. Namun, bisnis di industri lain mungkin mengalami periode nonaktif selama berjam-jam tanpa dampak bisnis yang signifikan.
Saat Anda menjalankan sistem yang sangat penting di pusat data lokal, salah satu pendekatan DR adalah mempertahankan sistem standby di pusat data kedua di region yang berbeda. Namun, pendekatan yang lebih hemat biaya adalah menggunakan lingkungan komputasi berbasis cloud publik untuk tujuan failover. Pendekatan ini adalah pendorong utama pola hybrid kelangsungan bisnis. Cloud dapat sangat menarik dari sudut pandang biaya, karena memungkinkan Anda menonaktifkan beberapa infrastruktur DR saat tidak digunakan. Untuk mendapatkan solusi DR dengan biaya lebih rendah, solusi cloud memungkinkan bisnis menerima potensi peningkatan nilai RPO dan RTO.
Diagram sebelumnya mengilustrasikan penggunaan cloud sebagai lingkungan pemulihan dari bencana atau kegagalan ke lingkungan lokal.
Varian yang kurang umum (dan jarang diperlukan) dari pola ini adalah pola multi-cloud kelangsungan bisnis. Dalam pola tersebut, lingkungan produksi menggunakan satu penyedia cloud dan lingkungan DR menggunakan penyedia cloud lain. Dengan men-deploy salinan workload di beberapa penyedia cloud, Anda dapat meningkatkan ketersediaan melebihi kemampuan deployment multi-region.
Mengevaluasi DR di beberapa cloud dibandingkan menggunakan satu penyedia cloud dengan region yang berbeda memerlukan analisis menyeluruh terhadap beberapa pertimbangan, termasuk hal berikut:
- Kemudahan dikelola
- Keamanan
- Kelayakan secara keseluruhan.
- Biaya
- Potensi biaya transfer data keluar dari lebih dari satu penyedia cloud dapat mahal dengan komunikasi antar-cloud yang berkelanjutan.
- Mungkin ada volume traffic yang tinggi saat mereplikasi database.
- TCO dan biaya pengelolaan infrastruktur jaringan antar-cloud.
Jika data Anda harus tetap berada di negara Anda untuk memenuhi persyaratan peraturan, menggunakan penyedia cloud kedua yang juga berada di negara Anda sebagai DR dapat menjadi opsi. Penggunaan penyedia cloud kedua tersebut mengasumsikan bahwa tidak ada opsi untuk menggunakan lingkungan on-premise guna membuat penyiapan hybrid. Untuk menghindari pembuatan ulang arsitektur solusi cloud, sebaiknya penyedia cloud kedua Anda menawarkan semua kemampuan dan layanan yang diperlukan di region.
Pertimbangan desain
- Ekspektasi DR: Target RPO dan RTO yang ingin dicapai bisnis Anda harus mendorong arsitektur DR dan perencanaan build.
- Arsitektur solusi: Dengan pola ini, Anda perlu mereplikasi fungsi dan kemampuan yang ada di lingkungan lokal untuk memenuhi ekspektasi DR Anda. Oleh karena itu, Anda perlu menilai kelayakan dan kemampuan rehosting, pemfaktoran ulang, atau re-arsitektur aplikasi untuk memberikan fungsi dan performa yang sama (atau lebih dioptimalkan) di lingkungan cloud.
- Mendesain dan mem-build: Mem-build zona landing hampir selalu menjadi prasyarat untuk men-deploy workload perusahaan di lingkungan cloud. Untuk mengetahui informasi selengkapnya, lihat Desain zona landing di Google Cloud.
Pemanggilan DR: Penting bagi desain dan proses DR Anda untuk mempertimbangkan pertanyaan berikut:
- Apa yang memicu skenario DR? Misalnya, DR mungkin dipicu oleh kegagalan fungsi atau sistem tertentu di situs utama.
- Bagaimana failover ke lingkungan DR dipanggil? Apakah ini proses persetujuan manual, atau dapat diotomatiskan untuk mencapai target RTO yang rendah?
- Bagaimana mekanisme notifikasi dan deteksi kegagalan sistem harus dirancang untuk memanggil failover sesuai dengan RTO yang diharapkan?
- Bagaimana traffic dialihkan ke lingkungan DR setelah kegagalan terdeteksi?
Validasi jawaban Anda atas pertanyaan-pertanyaan ini melalui pengujian.
Pengujian: Uji dan evaluasi failover ke DR secara menyeluruh. Pastikan hal tersebut memenuhi ekspektasi RPO dan RTO Anda. Tindakan ini dapat memberi Anda lebih banyak keyakinan untuk memanggil DR jika diperlukan. Setiap kali perubahan atau update baru dilakukan pada solusi teknologi atau proses, lakukan pengujian lagi.
Keterampilan tim: Satu atau beberapa tim teknis harus memiliki keterampilan dan keahlian untuk membuat, mengoperasikan, dan memecahkan masalah beban kerja produksi di lingkungan cloud, kecuali jika lingkungan Anda dikelola oleh pihak ketiga.
Kelebihan
Penggunaan Google Cloud untuk kelangsungan bisnis menawarkan beberapa keuntungan:
- Google Cloud memiliki banyak region di seluruh dunia yang dapat dipilih, Anda dapat menggunakannya untuk mencadangkan atau mereplikasi data ke situs lain dalam benua yang sama. Anda juga dapat mencadangkan atau mereplikasi data ke situs di benua yang berbeda.
- Google Cloud menawarkan kemampuan untuk menyimpan data di Cloud Storage dalam bucket dual-region atau multi-region. Data disimpan secara redundan di setidaknya dua region geografis
yang terpisah. Data yang disimpan di bucket dual-region dan multi-region direplikasi di seluruh region geografis menggunakan replikasi default.
- Bucket dual-region menyediakan redundansi geografis untuk mendukung kontinuitas bisnis dan rencana DR. Selain itu, untuk mereplikasi lebih cepat, dengan RPO yang lebih rendah, objek yang disimpan di dual-region dapat secara opsional menggunakan replikasi turbo di seluruh region tersebut.
- Demikian pula, replikasi multi-region memberikan redundansi di beberapa region, dengan menyimpan data Anda dalam batas geografis multi-region.
- Memberikan satu atau beberapa opsi berikut untuk mengurangi belanja modal
dan biaya operasional guna membangun DR:
- Instance VM yang dihentikan hanya dikenai biaya penyimpanan dan jauh lebih murah daripada instance VM yang berjalan. Artinya, Anda dapat meminimalkan biaya pemeliharaan sistem standby cold.
- Model bayar per penggunaan Google Cloud berarti Anda hanya membayar kapasitas penyimpanan dan komputasi yang benar-benar Anda gunakan.
- Kemampuan elastisitas, seperti penskalaan otomatis, memungkinkan Anda secara otomatis menskalakan atau memperkecil lingkungan DR sesuai kebutuhan.
Misalnya, diagram berikut menunjukkan aplikasi yang berjalan di lingkungan lokal (produksi) yang menggunakan komponen pemulihan di Google Cloud dengan Compute Engine, Cloud SQL, dan Cloud Load Balancing. Dalam skenario ini, database disediakan sebelumnya menggunakan database berbasis VM atau menggunakan database terkelola Google Cloud, seperti Cloud SQL, untuk pemulihan yang lebih cepat dengan replikasi data berkelanjutan. Anda dapat meluncurkan VM Compute Engine dari snapshot yang telah dibuat sebelumnya untuk mengurangi biaya selama operasi normal. Dengan penyiapan ini, dan setelah peristiwa kegagalan, DNS harus mengarah ke alamat IP eksternal Cloud Load Balancing.
Agar aplikasi dapat beroperasi di cloud, Anda perlu menyediakan VM web dan aplikasi. Bergantung pada tingkat RTO yang ditargetkan dan kebijakan perusahaan, seluruh proses untuk memanggil DR, menyediakan beban kerja di cloud, dan mengubah rute traffic, dapat diselesaikan secara manual atau otomatis.
Untuk mempercepat dan mengotomatiskan penyediaan infrastruktur, pertimbangkan untuk mengelola infrastruktur sebagai kode. Anda dapat menggunakan Cloud Build, yang merupakan layanan continuous integration, untuk menerapkan manifes Terraform secara otomatis ke lingkungan Anda. Untuk informasi selengkapnya, lihat artikel Mengelola infrastruktur sebagai kode dengan Terraform, Cloud Build, dan GitOps.
Praktik terbaik
Saat Anda menggunakan pola kelangsungan bisnis, pertimbangkan praktik terbaik berikut:
- Buat rencana pemulihan dari bencana yang mendokumentasikan infrastruktur Anda beserta prosedur failover dan pemulihan.
- Pertimbangkan tindakan berikut berdasarkan analisis dampak bisnis Anda dan
target RPO dan RTO yang diperlukan yang diidentifikasi:
- Tentukan apakah pencadangan data ke Google Cloud sudah memadai, atau apakah Anda perlu mempertimbangkan strategi DR lain (sistem standby cold, warm, atau hot).
- Tentukan layanan dan produk yang dapat Anda gunakan sebagai elemen penyusun untuk rencana DR.
- Buat skenario DR yang berlaku untuk aplikasi dan data sebagai bagian dari strategi DR yang Anda pilih.
- Pertimbangkan untuk menggunakan pola handover jika Anda hanya mencadangkan data. Atau, pola mesh mungkin menjadi opsi yang baik untuk mereplikasi arsitektur jaringan lingkungan yang ada.
- Minimalkan dependensi antara sistem yang berjalan di lingkungan berbeda, terutama saat komunikasi ditangani secara sinkron. Dependensi ini dapat memperlambat performa dan mengurangi ketersediaan keseluruhan.
Hindari masalah split brain. Jika mereplikasi data secara dua arah di seluruh lingkungan, Anda mungkin akan terkena masalah split-brain. Masalah split-brain terjadi saat dua lingkungan yang mereplikasi data secara dua arah kehilangan komunikasi satu sama lain. Pemisahan ini dapat menyebabkan sistem di kedua lingkungan menyimpulkan bahwa lingkungan lain tidak tersedia dan bahwa sistem tersebut memiliki akses eksklusif ke data. Hal ini dapat menyebabkan modifikasi data yang bertentangan. Ada dua cara umum untuk menghindari masalah split-brain:
- Menggunakan lingkungan komputasi ketiga. Lingkungan ini memungkinkan sistem memeriksa kuorum sebelum mengubah data.
Izinkan modifikasi data yang bertentangan untuk direkonsiliasi setelah konektivitas dipulihkan.
Dengan database SQL, Anda dapat menghindari masalah split-brain dengan membuat instance utama asli tidak dapat diakses sebelum klien mulai menggunakan instance utama baru. Untuk informasi selengkapnya, lihat Pemulihan dari bencana (disaster recovery) database Cloud SQL.
Pastikan sistem CI/CD dan repositori artefak tidak menjadi titik tunggal kegagalan. Saat satu lingkungan tidak tersedia, Anda tetap harus dapat men-deploy rilis baru atau menerapkan perubahan konfigurasi.
Buat semua workload bersifat portabel saat menggunakan sistem standby. Semua beban kerja harus dapat dipindah-pindah (jika didukung oleh aplikasi dan memungkinkan) sehingga sistem tetap konsisten di seluruh lingkungan. Anda dapat mencapai pendekatan ini dengan mempertimbangkan container dan Kubernetes. Dengan menggunakan edisi Google Kubernetes Engine (GKE) Enterprise, Anda dapat menyederhanakan build dan operasi.
Integrasikan deployment sistem standby ke dalam pipeline CI/CD Anda. Integrasi ini membantu memastikan bahwa versi dan konfigurasi aplikasi konsisten di seluruh lingkungan.
Pastikan perubahan DNS diterapkan dengan cepat dengan mengonfigurasi DNS Anda dengan nilai time to live yang cukup singkat sehingga Anda dapat mengalihkan pengguna ke sistem standby saat terjadi bencana.
Pilih kebijakan DNS dan kebijakan perutean yang sesuai dengan arsitektur dan perilaku solusi Anda. Selain itu, Anda dapat menggabungkan beberapa load balancer regional dengan kebijakan perutean DNS untuk membuat arsitektur load balancing global untuk berbagai kasus penggunaan, termasuk penyiapan campuran.
Gunakan beberapa penyedia DNS. Saat menggunakan beberapa penyedia DNS, Anda dapat:
- Tingkatkan ketersediaan dan ketahanan aplikasi dan layanan Anda.
Sederhanakan deployment atau migrasi aplikasi hybrid yang memiliki dependensi di seluruh lingkungan lokal dan cloud dengan konfigurasi DNS multi-penyedia.
Google Cloud menawarkan solusi open source berdasarkan octoDNS untuk membantu Anda menyiapkan dan mengoperasikan lingkungan dengan beberapa penyedia DNS. Untuk informasi selengkapnya, lihat DNS publik multi-penyedia menggunakan Cloud DNS.
Gunakan load balancer saat menggunakan sistem standby untuk membuat failover otomatis. Perlu diingat bahwa hardware load balancer dapat mengalami kegagalan.
Gunakan Cloud Load Balancing, bukan load balancer hardware, untuk mendukung beberapa skenario yang terjadi saat menggunakan pola arsitektur ini. Permintaan klien internal atau permintaan klien eksternal dapat dialihkan ke lingkungan utama atau lingkungan DR berdasarkan metrik yang berbeda, seperti pemisahan traffic berbasis bobot. Untuk mengetahui informasi selengkapnya, lihat Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal global.
Pertimbangkan untuk menggunakan Cloud Interconnect atau Cross-Cloud Interconnect jika volume transfer data keluar dari Google Cloud ke lingkungan lain tinggi. Cloud Interconnect dapat membantu mengoptimalkan performa konektivitas dan mungkin mengurangi biaya transfer data keluar untuk traffic yang memenuhi kondisi tertentu. Untuk mengetahui informasi selengkapnya, lihat Harga Cloud Interconnect.
Pertimbangkan untuk menggunakan solusi partner pilihan Anda di Google Cloud Marketplace untuk membantu memfasilitasi pencadangan data, replikasi, dan tugas lainnya yang memenuhi persyaratan Anda, termasuk target RPO dan RTO.
Uji dan evaluasi skenario pemanggilan DR untuk memahami seberapa mudah aplikasi dapat pulih dari peristiwa bencana jika dibandingkan dengan nilai RTO target.
Mengenkripsi komunikasi saat dalam proses pengiriman. Untuk melindungi informasi sensitif, sebaiknya mengenkripsi semua komunikasi dalam pengiriman. Jika enkripsi diperlukan di lapisan konektivitas, berbagai opsi tersedia berdasarkan solusi konektivitas hybrid yang dipilih. Opsi ini mencakup tunnel VPN, VPN dengan ketersediaan tinggi (HA) melalui Cloud Interconnect, dan MACsec untuk Cloud Interconnect.