Keandalan: Perencanaan penanganan bencana
Dokumen ini menjelaskan penerapan keandalan dalam perencanaan penanganan bencana. Meskipun istilah bencana ini dapat menimbulkan gambaran tentang bencana alam, tetapi cakupan bagian ini membahas kegagalan spesifik akibat kehilangan sebuah mesin hingga kehilangan menyeluruh di suatu region. Peristiwa pertama adalah kejadian sehari-hari yang ditangani BigQuery secara otomatis, sedangkan peristiwa yang kedua adalah sesuatu yang mungkin harus ditangani oleh pelanggan dalam mendesain arsitektur mereka jika diperlukan. Memahami cakupan perencanaan penanganan bencana yang berhubungan dengan tanggung jawab pelanggan sangatlah penting.
BigQuery menawarkan SLA waktu beroperasi 99,99% yang terdepan di industri. Hal ini dimungkinkan oleh arsitektur regional BigQuery yang menulis data di dua zona berbeda dan menyediakan kapasitas komputasi redundan. Penting untuk diingat bahwa SLA BigQuery sama untuk region, misalnya us-central1, dan multi-region, misalnya AS.
Penanganan skenario otomatis
Karena BigQuery adalah layanan regional, BigQuery bertanggung jawab untuk menangani hilangnya mesin atau bahkan seluruh zona secara otomatis. Fakta bahwa BigQuery dibuat di atas zona dibuat abstrak dari pengguna.
Kehilangan mesin
Kegagalan mesin adalah kejadian sehari-hari dalam skala operasional Google. BigQuery dirancang untuk menangani kegagalan mesin secara otomatis tanpa memengaruhi zona penampung.
Pada dasarnya, eksekusi kueri dibagi menjadi tugas-tugas kecil yang dapat dikirim secara paralel ke banyak mesin. Hilangnya atau penurunan performa mesin secara tiba-tiba ditangani secara otomatis dengan mengirim ulang pekerjaan ke mesin yang berbeda. Pendekatan tersebut penting untuk mengurangi latensi tail.
BigQuery menggunakan encoding Reed–Solomon untuk menyimpan salinan zona data Anda secara efisien dan tahan lama. Dalam peristiwa yang sangat jarang terjadi, yaitu ketika beberapa kegagalan mesin menyebabkan hilangnya salinan zona, data juga disimpan dengan cara yang sama di setidaknya satu zona lainnya. Dalam kasus semacam ini, BigQuery akan mendeteksi masalah dan membuat salinan zonal data baru untuk memulihkan redundansi.
Kehilangan Zona
Ketersediaan dasar resource komputasi di zona tertentu tidak cukup untuk memenuhi SLA waktu beroperasi 99,99% BigQuery. Oleh karena itu, BigQuery menyediakan redundansi zona otomatis untuk slot data dan komputasi. Meskipun tidak umum terjadi, gangguan zona dalam waktu singkat dapat terjadi. Namun, otomatisasi BigQuery akan melakukan failover kueri ke zona lain dalam waktu satu atau dua menit setelah gangguan parah. Kueri yang sedang berlangsung mungkin tidak akan segera dipulihkan, tetapi kueri yang baru dikeluarkan akan segera dipulihkan. Hal ini akan termanifestasi karena kueri yang sedang berlangsung yang memerlukan waktu lama untuk diselesaikan sementara kueri yang baru dikeluarkan dapat selesai dengan cepat.
Meskipun suatu zona tidak tersedia untuk jangka waktu yang lebih lama, kehilangan data tidak akan terjadi karena BigQuery menulis data secara sinkron ke dua zona. Jadi, bahkan saat terjadi kehilangan di level zona, pelanggan tidak akan mengalami gangguan layanan.
Jenis kegagalan
Ada dua jenis kegagalan, kegagalan ringan dan kegagalan berat.
Kegagalan ringan adalah kekurangan operasional saat hardware tidak hancur. Contohnya meliputi kegagalan daya, partisi jaringan, atau kerusakan mesin. Secara umum, BigQuery tidak boleh kehilangan data jika terjadi kegagalan sementara.
Kegagalan besar adalah kekurangan operasional saat hardware hancur. Kegagalan berat lebih parah daripada kegagalan ringan. Contoh kegagalan berat mencakup kerusakan akibat banjir, serangan teroris, gempa bumi, dan badai.
Ketersediaan dan ketahanan
Saat membuat set data BigQuery, Anda memilih lokasi untuk menyimpan data. Lokasi ini adalah salah satu dari berikut:
- Wilayah: lokasi geografis tertentu, seperti Iowa (
us-central1) atau Montréal (northamerica-northeast1). - Multi-region: area geografis luas yang berisi dua atau beberapa tempat geografis, seperti Amerika Serikat (
US) atau Eropa (EU).
Dalam kedua kasus tersebut, BigQuery secara otomatis menyimpan salinan data Anda di dua zona Google Cloud yang berbeda dalam satu region di lokasi yang dipilih.
Selain redundansi penyimpanan, BigQuery juga mempertahankan kapasitas komputasi yang berlebihan di beberapa zona. Dengan menggabungkan penyimpanan redundan dan komputasi di berbagai zona ketersediaan, BigQuery memberikan ketersediaan tinggi dan ketahanan.
Jika terjadi kegagalan tingkat mesin, BigQuery akan terus berjalan dengan penundaan tidak lebih dari beberapa milidetik. Semua kueri yang sedang berjalan akan terus diproses. Jika terjadi kegagalan zona ringan atau berat, kemungkinan tidak akan ada kehilangan data. Namun, kueri yang sedang berjalan mungkin gagal dan harus dikirim ulang. Kegagalan zona ringan, seperti akibat pemadaman listrik, transformator yang hancur, atau partisi jaringan, merupakan jalur yang telah teruji dengan baik dan secara otomatis dimitigasi dalam beberapa menit.
Kegagalan regional ringan, seperti hilangnya konektivitas jaringan di seluruh region, akan mengakibatkan hilangnya ketersediaan hingga wilayah tersebut kembali online, tetapi tidak mengakibatkan hilangnya data. Kegagalan regional berat, misalnya, jika bencana menghancurkan seluruh region, dapat mengakibatkan hilangnya data yang disimpan di region tersebut. BigQuery tidak secara otomatis menyediakan cadangan atau replika data Anda di region geografis lain. Anda dapat membuat salinan set data lintas region untuk meningkatkan strategi pemulihan dari bencana.
Untuk mempelajari lokasi set data BigQuery lebih lanjut, baca artikel Pertimbangan lokasi.
Skenario yang memerlukan perencanaan atau pemulihan
Kehilangan wilayah
BigQuery tidak menawarkan ketahanan atau ketersediaan dalam peristiwa hilangnya region fisik yang sangat tidak mungkin terjadi sebelumnya. Hal ini berlaku untuk konfigurasi "region dan multi-region". Oleh karena itu, mempertahankan ketahanan dan ketersediaan di bawah skenario semacam itu memerlukan perencanaan pelanggan. Dalam kasus kehilangan sementara, seperti pemadaman jaringan, ketersediaan redundan harus dipertimbangkan jika SLA 99,99% BigQuery tidak dianggap memadai.
Untuk menghindari hilangnya data saat terjadi kehilangan regional yang destruktif, Anda perlu mencadangkan data ke lokasi geografis lain. Misalnya, Anda dapat mengekspor snapshot data ke Google Cloud Storage secara berkala di region lain yang berbeda secara geografis. Hal ini dapat dilakukan seperti yang dijelaskan dalam Kasus penggunaan pemrosesan data batch.
Dalam kasus multi-region BigQuery, Anda harus menghindari pencadangan ke region dalam cakupan multi-region. Misalnya, jangan cadangkan data Anda yang ada di AS ke region us-central1. Region dan multi-region mungkin menggunakan domain gagal yang sama dan mengalami nasib yang sama ketika terjadi bencana. Sebagai gantinya, cadangkan data ke region non-AS, seperti northamerica-northeast1. Jika persyaratan residensi data mengharuskan cadangan disimpan di AS, sebaiknya Anda menyambungkan dua region seperti us-central1 dan us-east1.
Untuk menghindari ketidaktersediaan yang diperpanjang, Anda harus menyediakan replika dan slot di dua lokasi BigQuery yang terpisah secara geografis. Serupa dengan di atas, hindari penggabungan region dan multi-region, karena keduanya mungkin memiliki nasib yang sama saat terjadi bencana.
Arsitektur yang paling andal untuk penyiapan yang redundan region adalah menjalankan hot-hot, yang juga disebut sebagai aktif-aktif. Ini berarti beban kerja Anda berjalan secara paralel di region utama dan sekunder. Meskipun lebih mahal, hal ini memastikan bahwa region sekunder mendapatkan verifikasi berkelanjutan dan akan berfungsi jika Anda perlu melakukan failover. Jika ketersediaan selama pemadaman layanan regional tidak menjadi masalah, pencadangan data ke region lain akan memastikan ketahanan.
Penghapusan yang tidak disengaja atau kerusakan data
Berdasarkan arsitektur kontrol konkurensi multiversi BigQuery, BigQuery mendukung perjalanan waktu. Dengan fitur ini, Anda dapat membuat kueri data dari waktu mana pun selama tujuh hari terakhir. Hal ini memungkinkan pemulihan data secara mandiri yang salah dihapus, diubah, atau rusak dalam jangka waktu 7 hari. Perjalanan waktu bahkan dapat digunakan pada tabel yang telah dihapus.
BigQuery juga mendukung kemampuan untuk membuat snapshot tabel. Dengan fitur ini, Anda dapat secara eksplisit mencadangkan data dalam region yang sama untuk waktu yang lebih lama dari periode perjalanan 7 hari. Snapshot hanyalah sebuah operasi metadata dan tidak menghasilkan byte penyimpanan tambahan. Meskipun dapat menambahkan perlindungan terhadap penghapusan yang tidak disengaja, hal ini tidak meningkatkan ketahanan data.
Kasus penggunaan untuk pemulihan dari bencana
Analisis real-time
Dalam kasus penggunaan ini, data streaming diserap dari log endpoint ke BigQuery secara terus-menerus. Perlindungan terhadap ketidaktersediaan BigQuery yang diperluas untuk seluruh region memerlukan replikasi data dan slot penyediaan secara terus-menerus di region yang berbeda. Mengingat arsitekturnya tahan terhadap ketidaktersediaan BigQuery akibat penggunaan Pub/Sub dan Dataflow di jalur penyerapan, tingkat redundansi yang tinggi ini mungkin tidak sepadan dengan biaya.
Dengan asumsi pengguna telah mengonfigurasi data BigQuery di us-east4 untuk diekspor setiap malam dengan menggunakan tugas ekspor ke Cloud Storage pada kelas Archive Storage di us-central1. Hal ini memberikan pencadangan yang andal andai terjadi kehilangan data yang drastis di us-east4. Dalam hal ini, Toleransi Jumlah Data yang Hilang (Recovery Point Objective/RPO) adalah 24 jam, karena cadangan yang terakhir diekspor dapat berusia hingga 24 jam dalam kasus terburuk. Batas Waktu Pemulihan (Recovery Time Objective/RTO) kemungkinan adalah hari, karena data perlu dipulihkan dari cadangan Cloud Storage ke BigQuery di us-central1. Jika BigQuery akan disediakan di region yang berbeda dari tempat cadangan ditempatkan, data harus ditransfer ke region ini terlebih dahulu. Perhatikan juga bahwa kecuali Anda telah membeli slot redundan di region pemulihan terlebih dahulu, mungkin ada penundaan tambahan saat menyediakan kapasitas BigQuery yang diperlukan, bergantung pada jumlah yang diminta.
Pemrosesan data batch
Untuk kasus penggunaan ini, sangat penting untuk bisnis bahwa laporan harian diselesaikan sebelum batas waktu tetap yang harus dikirim ke badan pengatur. Menerapkan redundansi dengan menjalankan dua instance terpisah dari seluruh pipeline pemrosesan kemungkinan akan sepadan. Penggunaan dua region terpisah, misalnya us-west1 dan us-east4, memberikan pemisahan geografis dan dua domain kegagalan independen jika suatu region tidak tersedia lagi atau bahkan kemungkinan terjadi hilangnya region permanen.
Dengan asumsi bahwa laporan perlu dikirim tepat sekali, kita harus merekonsiliasi kasus yang diharapkan dari kedua pipeline yang berhasil diselesaikan. Strategi yang wajar adalah memilih hasil dari penyelesaian pipeline terlebih dahulu, misalnya dengan memberi tahu topik Pub/Sub jika berhasil. Atau, timpa hasilnya dan buat versi ulang objek Cloud Storage. Jika pipeline yang nanti selesai menulis data rusak, Anda dapat memulihkannya dengan memulihkan versi yang ditulis oleh pipeline yang diselesaikan terlebih dahulu dari Cloud Storage.