Framework Arsitektur yang Baik: Pilar keandalan

Last reviewed 2025-02-14 UTC

Pilar keandalan dalam Google Cloud Framework Berarsitektur Baik memberikan prinsip dan rekomendasi untuk membantu Anda mendesain, men-deploy, dan mengelola workload yang andal di Google Cloud.

Dokumen ini ditujukan untuk arsitek cloud, developer, engineer platform, administrator, dan site reliability engineer.

Keandalan adalah kemampuan sistem untuk secara konsisten menjalankan fungsi yang dimaksudkan dalam kondisi yang ditentukan dan mempertahankan layanan tanpa gangguan. Praktik terbaik untuk keandalan mencakup redundansi, desain yang toleran terhadap kesalahan, pemantauan, dan proses pemulihan otomatis.

Sebagai bagian dari keandalan, ketahanan adalah kemampuan sistem untuk menahan dan memulihkan diri dari kegagalan atau gangguan yang tidak terduga, sekaligus mempertahankan performa. FiturGoogle Cloud , seperti deployment multi-regional, pencadangan otomatis, dan solusi pemulihan dari bencana, dapat membantu Anda meningkatkan ketahanan sistem.

Keandalan penting untuk strategi cloud Anda karena banyak alasan, termasuk berikut ini:

  • Periode nonaktif minimal: Periode nonaktif dapat menyebabkan hilangnya pendapatan, penurunan produktivitas, dan kerusakan reputasi. Arsitektur yang tangguh dapat membantu memastikan sistem dapat terus berfungsi selama terjadi kegagalan atau pulih secara efisien dari kegagalan.
  • Pengalaman pengguna yang ditingkatkan: Pengguna mengharapkan interaksi yang lancar dengan teknologi. Sistem yang tangguh dapat membantu mempertahankan performa dan ketersediaan yang konsisten, serta memberikan layanan yang andal meskipun saat permintaan tinggi atau terjadi masalah yang tidak terduga.
  • Integritas data: Kegagalan dapat menyebabkan kehilangan data atau kerusakan data. Sistem yang tangguh menerapkan mekanisme seperti pencadangan, redundansi, dan replikasi untuk melindungi data serta memastikan data tetap akurat dan dapat diakses.
  • Kelangsungan bisnis: Bisnis Anda mengandalkan teknologi untuk operasi penting. Arsitektur yang tangguh dapat membantu memastikan kelangsungan setelah terjadi kegagalan parah, yang memungkinkan fungsi bisnis berlanjut tanpa gangguan yang signifikan dan mendukung pemulihan yang cepat.
  • Kepatuhan: Banyak industri memiliki persyaratan peraturan untuk ketersediaan sistem dan perlindungan data. Arsitektur yang tangguh dapat membantu Anda memenuhi standar ini dengan memastikan sistem tetap beroperasi dan aman.
  • Biaya jangka panjang yang lebih rendah: Arsitektur yang tangguh memerlukan investasi di awal, tetapi ketahanan dapat membantu mengurangi biaya dari waktu ke waktu dengan mencegah periode nonaktif yang mahal, menghindari perbaikan reaktif, dan memungkinkan penggunaan resource yang lebih efisien.

Pola pikir organisasi

Untuk membuat sistem Anda andal, Anda memerlukan rencana dan strategi yang sudah ditetapkan. Strategi ini harus mencakup edukasi dan otoritas untuk memprioritaskan keandalan bersama dengan inisiatif lainnya.

Tetapkan ekspektasi yang jelas bahwa seluruh organisasi bertanggung jawab atas keandalan, termasuk pengembangan, pengelolaan produk, operasi, rekayasa platform, dan rekayasa keandalan situs (SRE). Bahkan grup yang berfokus pada bisnis, seperti pemasaran dan penjualan, dapat memengaruhi keandalan.

Setiap tim harus memahami target keandalan dan risiko aplikasi mereka. Tim harus bertanggung jawab terhadap persyaratan ini. Konflik antara keandalan dan pengembangan fitur produk reguler harus diprioritaskan dan diselesaikan sesuai dengan eskalasinya.

Rencanakan dan kelola keandalan secara holistik, di semua fungsi dan tim Anda. Pertimbangkan untuk menyiapkan Cloud Centre of Excellence (CCoE) yang mencakup pilar keandalan. Untuk mengetahui informasi selengkapnya, lihat Mengoptimalkan perjalanan cloud organisasi Anda dengan Pusat Keunggulan Cloud.

Area fokus untuk keandalan

Aktivitas yang Anda lakukan untuk mendesain, men-deploy, dan mengelola sistem yang andal dapat dikategorikan dalam area fokus berikut. Setiap prinsip dan rekomendasi keandalan dalam pilar ini relevan dengan salah satu area fokus tersebut.

  • Penetapan cakupan: Untuk memahami sistem Anda, lakukan analisis mendetail terhadap arsitekturnya. Anda perlu memahami komponen, cara kerja dan interaksinya, cara data dan tindakan mengalir melalui sistem, dan apa yang bisa salah. Mengidentifikasi potensi kegagalan, hambatan, dan risiko, yang membantu Anda mengambil tindakan untuk memitigasi masalah tersebut.
  • Pengamatan: Untuk membantu mencegah kegagalan sistem, terapkan pengamatan dan pemantauan yang komprehensif dan berkelanjutan. Melalui pengamatan ini, Anda dapat memahami tren dan mengidentifikasi potensi masalah secara proaktif.
  • Respons: Untuk mengurangi dampak kegagalan, respons dengan tepat dan pulihkan secara efisien. Respons otomatis juga dapat membantu mengurangi dampak kegagalan. Bahkan dengan perencanaan dan kontrol, kegagalan masih dapat terjadi.
  • Pembelajaran: Untuk membantu mencegah kegagalan berulang, pelajari setiap pengalaman dan ambil tindakan yang sesuai.

Prinsip inti

Rekomendasi dalam pilar keandalan Framework yang Dirancang dengan Baik dipetakan ke prinsip inti berikut:

Kontributor

Penulis:

Kontributor lainnya:

Mendefinisikan keandalan berdasarkan tujuan pengalaman pengguna

Prinsip ini dalam pilar keandalan Google Cloud Framework yang Dirancang dengan Baik membantu Anda menilai pengalaman pengguna, lalu memetakan temuan ke sasaran dan metrik keandalan.

Prinsip ini relevan dengan area fokus penentuan cakupan keandalan.

Ringkasan prinsip

Alat observasi menyediakan data dalam jumlah besar, tetapi tidak semua data tersebut terkait langsung dengan dampak pada pengguna. Misalnya, Anda mungkin mengamati penggunaan CPU yang tinggi, operasi server yang lambat, atau bahkan tugas yang error. Namun, jika masalah ini tidak memengaruhi pengalaman pengguna, maka masalah tersebut tidak dianggap sebagai gangguan.

Untuk mengukur pengalaman pengguna, Anda harus membedakan antara perilaku sistem internal dan masalah yang dihadapi pengguna. Fokus pada metrik seperti rasio keberhasilan permintaan pengguna. Jangan hanya mengandalkan metrik yang berfokus pada server, seperti penggunaan CPU, yang dapat menyebabkan kesimpulan yang menyesatkan tentang keandalan layanan Anda. Keandalan sejati berarti pengguna dapat menggunakan aplikasi atau layanan Anda secara konsisten dan efektif.

Rekomendasi

Untuk membantu Anda mengukur pengalaman pengguna secara efektif, pertimbangkan rekomendasi di bagian berikut.

Mengukur pengalaman pengguna

Untuk benar-benar memahami keandalan layanan Anda, prioritaskan metrik yang mencerminkan pengalaman sebenarnya pengguna Anda. Misalnya, ukur rasio keberhasilan kueri pengguna, latensi aplikasi, dan tingkat error.

Sebaiknya kumpulkan data ini langsung dari perangkat atau browser pengguna. Jika pengumpulan data langsung ini tidak memungkinkan, geser titik pengukuran secara progresif lebih jauh dari pengguna dalam sistem. Misalnya, Anda dapat menggunakan load balancer atau layanan frontend sebagai titik pengukuran. Pendekatan ini membantu Anda mengidentifikasi dan mengatasi masalah sebelum masalah tersebut dapat memengaruhi pengguna Anda secara signifikan.

Menganalisis perjalanan pengguna

Untuk memahami cara pengguna berinteraksi dengan sistem Anda, Anda dapat menggunakan alat pelacakan seperti Cloud Trace. Dengan mengikuti perjalanan pengguna melalui aplikasi Anda, Anda dapat menemukan hambatan dan masalah latensi yang dapat menurunkan kualitas pengalaman pengguna. Cloud Trace mengumpulkan data performa mendetail untuk setiap hop dalam arsitektur layanan Anda. Data ini membantu Anda mengidentifikasi dan mengatasi masalah performa secara lebih efisien, yang dapat menghasilkan pengalaman pengguna yang lebih andal dan memuaskan.

Menetapkan target keandalan yang realistis

Prinsip dalam pilar keandalan Google Cloud Framework Berarsitektur Baik ini membantu Anda menentukan sasaran keandalan yang layak secara teknis untuk workload Anda di Google Cloud.

Prinsip ini relevan dengan area fokus penentuan cakupan keandalan.

Ringkasan prinsip

Rancang sistem Anda agar cukup andal untuk membuat pengguna merasa puas. Mungkin terlihat berlawanan dengan intuisi, tetapi sasaran keandalan 100% sering kali bukan strategi yang paling efektif. Keandalan yang lebih tinggi dapat menghasilkan biaya yang jauh lebih tinggi, baik dalam hal investasi finansial maupun potensi batasan pada inovasi. Jika pengguna sudah puas dengan tingkat layanan saat ini, maka upaya untuk meningkatkan kepuasan lebih lanjut mungkin akan menghasilkan laba atas investasi yang rendah. Sebagai gantinya, Anda dapat membelanjakan resource dengan lebih baik di tempat lain.

Anda perlu menentukan tingkat keandalan yang membuat pengguna Anda merasa puas, dan menentukan titik saat biaya peningkatan inkremental mulai lebih besar daripada manfaatnya. Saat Anda menentukan tingkat keandalan yang memadaiini, Anda dapat mengalokasikan sumber daya secara strategis dan berfokus pada fitur dan peningkatan yang memberikan nilai lebih besar bagi pengguna Anda.

Rekomendasi

Untuk menetapkan target keandalan yang realistis, pertimbangkan rekomendasi di subbagian berikut.

Menerima beberapa kegagalan dan memprioritaskan komponen

Usahakan ketersediaan tinggi seperti waktu beroperasi 99,99%, tetapi jangan menetapkan target waktu beroperasi 100%. Akui bahwa beberapa kegagalan tidak dapat dihindari.

Selisih antara waktu aktif 100% dan target 99,99% adalah toleransi untuk kegagalan. Perbedaan ini sering disebut sebagai anggaran error. Anggaran error dapat membantu Anda mengambil risiko dan berinovasi, yang merupakan hal mendasar bagi bisnis apa pun agar tetap kompetitif.

Prioritaskan keandalan komponen paling penting dalam sistem. Terima bahwa komponen yang kurang penting dapat memiliki toleransi yang lebih tinggi terhadap kegagalan.

Menyeimbangkan keandalan dan biaya

Untuk menentukan tingkat keandalan yang optimal bagi sistem Anda, lakukan analisis biaya-manfaat yang menyeluruh.

Pertimbangkan faktor-faktor seperti persyaratan sistem, konsekuensi kegagalan, dan toleransi risiko organisasi Anda untuk aplikasi tertentu. Jangan lupa untuk mempertimbangkan metrik pemulihan dari bencana, seperti batas waktu pemulihan (RTO) dan toleransi durasi kehilangan data (RPO). Tentukan tingkat keandalan yang dapat diterima dalam anggaran dan batasan lainnya.

Cari cara untuk meningkatkan efisiensi dan mengurangi biaya tanpa mengorbankan fitur keandalan penting.

Membangun sistem dengan ketersediaan tinggi melalui redundansi resource

Prinsip ini dalam pilar keandalan Google Cloud Framework yang Dirancang dengan Baik memberikan rekomendasi untuk merencanakan, membangun, dan mengelola redundansi resource, yang dapat membantu Anda menghindari kegagalan.

Prinsip ini relevan dengan area fokus penentuan cakupan keandalan.

Ringkasan prinsip

Setelah memutuskan tingkat keandalan yang Anda butuhkan, Anda harus mendesain sistem untuk menghindari titik kegagalan tunggal. Setiap komponen penting dalam sistem harus direplikasi di beberapa mesin, zona, dan region. Misalnya, database penting tidak boleh berada di satu region saja, dan server metadata tidak boleh di-deploy di satu zona atau region saja. Dalam contoh tersebut, jika satu-satunya zona atau region mengalami pemadaman, sistem akan mengalami pemadaman global.

Rekomendasi

Untuk membangun sistem yang redundan, pertimbangkan rekomendasi di subbagian berikut.

Mengidentifikasi domain kegagalan dan mereplikasi layanan

Petakan domain kegagalan sistem Anda, dari VM individual hingga region, dan desain untuk redundansi di seluruh domain kegagalan.

Untuk memastikan ketersediaan tinggi, distribusikan dan replikasi layanan dan aplikasi Anda di beberapa zona dan region. Konfigurasi sistem untuk failover otomatis guna memastikan layanan dan aplikasi terus tersedia jika terjadi pemadaman layanan zona atau region.

Untuk contoh arsitektur multi-zona dan multi-region, lihat Mendesain infrastruktur yang andal untuk workload Anda di Google Cloud.

Mendeteksi dan mengatasi masalah dengan cepat

Terus lacak status domain yang gagal untuk mendeteksi dan mengatasi masalah dengan cepat.

Anda dapat memantau status layanan saat ini di semua region menggunakan Google Cloud Dasbor Service Health. Google Cloud Anda juga dapat melihat insiden yang relevan dengan project Anda menggunakan Personalized Service Health. Anda dapat menggunakan load balancer untuk mendeteksi kondisi resource dan merutekan traffic secara otomatis ke backend yang berfungsi dengan baik. Untuk mengetahui informasi selengkapnya, lihat Ringkasan health check.

Menguji skenario failover

Seperti latihan menghadapi kebakaran, simulasikan kegagalan secara rutin untuk memvalidasi efektivitas strategi replikasi dan failover Anda.

Untuk mengetahui informasi selengkapnya, lihat Menyimulasikan pemadaman layanan zona untuk MIG regional dan Menyimulasikan kegagalan zona di cluster regional GKE.

Memanfaatkan skalabilitas horizontal

Prinsip dalam pilar keandalan Google Cloud Framework yang Dirancang dengan Baik ini memberikan rekomendasi untuk membantu Anda menggunakan skalabilitas horizontal. Dengan menggunakan skalabilitas horizontal, Anda dapat membantu memastikan bahwa workload di Google Cloud dapat diskalakan secara efisien dan mempertahankan performa.

Prinsip ini relevan dengan area fokus penentuan cakupan keandalan.

Ringkasan prinsip

Mendesain ulang sistem Anda ke arsitektur horizontal. Untuk mengakomodasi pertumbuhan traffic atau data, Anda dapat menambahkan lebih banyak resource. Anda juga dapat menghapus resource saat tidak digunakan.

Untuk memahami nilai penskalaan horizontal, pertimbangkan batasan penskalaan vertikal.

Skenario umum untuk penskalaan vertikal adalah menggunakan database MySQL sebagai database utama dengan data penting. Seiring meningkatnya penggunaan database, diperlukan lebih banyak RAM dan CPU. Pada akhirnya, database mencapai batas memori di mesin host, dan perlu diupgrade. Proses ini mungkin perlu diulang beberapa kali. Masalahnya adalah ada batasan ketat terkait seberapa besar database dapat berkembang. Ukuran VM tidak tidak terbatas. Database dapat mencapai titik ketika tidak mungkin lagi menambahkan lebih banyak resource.

Meskipun resource tidak terbatas, VM besar dapat menjadi titik tunggal kegagalan. Masalah apa pun pada VM database utama dapat menyebabkan respons error atau menyebabkan gangguan di seluruh sistem yang memengaruhi semua pengguna. Hindari titik tunggal kegagalan, seperti yang dijelaskan dalam Membangun sistem dengan ketersediaan tinggi melalui redundansi resource.

Selain batas penskalaan ini, penskalaan vertikal cenderung lebih mahal. Biaya dapat meningkat secara eksponensial saat mesin dengan daya komputasi dan memori yang lebih besar diperoleh.

Sebaliknya, penskalaan horizontal dapat lebih murah. Potensi penskalaan horizontal hampir tidak terbatas dalam sistem yang dirancang untuk penskalaan.

Rekomendasi

Untuk bertransisi dari arsitektur VM tunggal ke arsitektur multi-mesin horizontal, Anda harus merencanakan dengan cermat dan menggunakan alat yang tepat. Untuk membantu Anda mencapai penskalaan horizontal, pertimbangkan rekomendasi di subbagian berikut.

Menggunakan layanan terkelola

Layanan terkelola menghilangkan kebutuhan untuk mengelola penskalaan horizontal secara manual. Misalnya, dengan grup instance terkelola (MIG) Compute Engine, Anda dapat menambahkan atau menghapus VM untuk menskalakan aplikasi secara horizontal. Untuk aplikasi dalam container, Cloud Run adalah platform serverless yang dapat menskalakan container stateless Anda secara otomatis berdasarkan traffic yang masuk.

Mempromosikan desain modular

Komponen modular dan antarmuka yang jelas membantu Anda menskalakan setiap komponen sesuai kebutuhan, bukan menskalakan seluruh aplikasi. Untuk mengetahui informasi selengkapnya, lihat Mempromosikan desain modular dalam pilar pengoptimalan performa.

Menerapkan desain stateless

Desain aplikasi agar stateless, yang berarti tidak ada data yang disimpan secara lokal. Dengan begitu, Anda dapat menambahkan atau menghapus instance tanpa mengkhawatirkan konsistensi data.

Mendeteksi potensi kegagalan dengan menggunakan kemampuan observasi

Prinsip dalam pilar keandalan Google Cloud Framework yang Dirancang dengan Baik ini memberikan rekomendasi untuk membantu Anda mengidentifikasi secara proaktif area tempat terjadinya error dan kegagalan.

Prinsip ini relevan dengan pengamatan area fokus keandalan.

Ringkasan prinsip

Untuk mempertahankan dan meningkatkan keandalan workload Anda di Google Cloud, Anda perlu menerapkan kemampuan observasi yang efektif dengan menggunakan metrik, log, dan trace.

  • Metrik adalah pengukuran numerik aktivitas yang ingin Anda lacak untuk aplikasi Anda pada interval waktu tertentu. Misalnya, Anda mungkin ingin melacak metrik teknis seperti rasio permintaan dan rasio error, yang dapat digunakan sebagai indikator tingkat layanan (SLI). Anda mungkin juga perlu melacak metrik bisnis khusus aplikasi seperti pesanan yang dilakukan dan pembayaran yang diterima.
  • Log adalah rekaman stempel waktu dari peristiwa diskrit yang terjadi dalam aplikasi atau sistem. Peristiwa dapat berupa kegagalan, error, atau perubahan status. Log dapat mencakup metrik, dan Anda juga dapat menggunakan log untuk SLI.
  • Rekaman aktivitas mewakili perjalanan satu pengguna atau transaksi melalui sejumlah aplikasi terpisah atau komponen aplikasi. Misalnya, komponen ini bisa berupa microservice. Rekaman aktivitas membantu Anda melacak komponen yang digunakan dalam perjalanan, lokasi terjadinya hambatan, dan durasi perjalanan.

Metrik, log, dan trace membantu Anda memantau sistem secara berkelanjutan. Pemantauan komprehensif membantu Anda mengetahui lokasi dan alasan terjadinya error. Anda juga dapat mendeteksi potensi kegagalan sebelum terjadi error.

Rekomendasi

Untuk mendeteksi potensi kegagalan secara efisien, pertimbangkan rekomendasi di subbagian berikut.

Mendapatkan insight yang komprehensif

Untuk melacak metrik utama seperti waktu respons dan tingkat error, gunakan Cloud Monitoring dan Cloud Logging. Alat ini juga membantu Anda memastikan bahwa metrik secara konsisten memenuhi kebutuhan workload Anda.

Untuk membuat keputusan berbasis data, analisis metrik layanan default untuk memahami dependensi komponen dan dampaknya terhadap performa beban kerja secara keseluruhan.

Untuk menyesuaikan strategi pemantauan, buat dan publikasikan metrik Anda sendiri menggunakan Google Cloud SDK.

Melakukan pemecahan masalah proaktif

Terapkan penanganan error yang andal dan aktifkan logging di semua komponen beban kerja Anda di Google Cloud. Aktifkan log seperti log akses Cloud Storage dan Log Aliran VPC.

Saat mengonfigurasi logging, pertimbangkan biaya terkait. Untuk mengontrol biaya logging, Anda dapat mengonfigurasi filter pengecualian pada sink log untuk mengecualikan log tertentu agar tidak disimpan.

Mengoptimalkan pemanfaatan resource

Pantau penggunaan CPU, metrik I/O jaringan, dan metrik I/O disk untuk mendeteksi resource yang kurang dan terlalu banyak disediakan di layanan seperti GKE, Compute Engine, dan Dataproc. Untuk mengetahui daftar lengkap layanan yang didukung, lihat Ringkasan Cloud Monitoring.

Memprioritaskan pemberitahuan

Untuk pemberitahuan, berfokuslah pada metrik penting, tetapkan nilai minimum yang sesuai untuk meminimalkan kelelahan akibat pemberitahuan, dan pastikan respons tepat waktu terhadap masalah signifikan. Pendekatan yang ditargetkan ini memungkinkan Anda mempertahankan keandalan workload secara proaktif. Untuk mengetahui informasi selengkapnya, lihat Ringkasan pemberitahuan.

Desain untuk penurunan kualitas yang baik

Prinsip dalam pilar keandalan Google Cloud Framework yang Dirancang dengan Baik ini memberikan rekomendasi untuk membantu Anda mendesain Google Cloud workload agar gagal dengan baik.

Prinsip ini relevan dengan area fokus respons keandalan.

Ringkasan prinsip

Penurunan kualitas yang lancar adalah pendekatan desain di mana sistem yang mengalami beban tinggi terus berfungsi, meskipun dengan performa atau akurasi yang berkurang. Degradasi yang lancar memastikan ketersediaan sistem yang berkelanjutan dan mencegah kegagalan total, meskipun pekerjaan sistem tidak optimal. Saat beban kembali ke tingkat yang dapat dikelola, sistem akan melanjutkan fungsi penuh.

Misalnya, selama periode beban tinggi, Google Penelusuran memprioritaskan hasil dari halaman web yang berperingkat lebih tinggi, sehingga berpotensi mengorbankan akurasi. Saat beban menurun, Google Penelusuran menghitung ulang hasil penelusuran.

Rekomendasi

Untuk mendesain sistem agar menurun dengan baik, pertimbangkan rekomendasi di subbagian berikut.

Menerapkan throttling

Pastikan replika Anda dapat menangani kelebihan beban secara independen dan dapat membatasi permintaan masuk selama skenario traffic tinggi. Pendekatan ini membantu Anda mencegah kegagalan beruntun yang disebabkan oleh perubahan pada kelebihan traffic antar-zona.

Gunakan alat seperti Apigee untuk mengontrol jumlah permintaan API selama waktu dengan traffic tinggi. Anda dapat mengonfigurasi aturan kebijakan untuk mencerminkan cara Anda ingin mengurangi skala permintaan.

Menghapus permintaan berlebih lebih awal

Konfigurasi sistem Anda untuk membatalkan permintaan berlebih di lapisan frontend guna melindungi komponen backend. Menghilangkan beberapa permintaan mencegah kegagalan global dan memungkinkan sistem pulih dengan lebih baik.Dengan pendekatan ini, beberapa pengguna mungkin mengalami error. Namun, Anda dapat meminimalkan dampak gangguan, berbeda dengan pendekatan seperti pemutusan sirkuit, yang akan menghentikan semua traffic selama terjadi kelebihan beban.

Menangani error sebagian dan percobaan ulang

Bangun aplikasi Anda untuk menangani error sebagian dan percobaan ulang dengan lancar. Desain ini membantu memastikan bahwa sebanyak mungkin traffic ditayangkan selama skenario beban tinggi.

Skenario kelebihan beban pengujian

Untuk memvalidasi bahwa mekanisme pembatasan dan penurunan permintaan berfungsi secara efektif, simulasikan kondisi kelebihan beban secara rutin di sistem Anda. Pengujian membantu memastikan bahwa sistem Anda siap menghadapi lonjakan traffic di dunia nyata.

Memantau lonjakan traffic

Gunakan alat analisis dan pemantauan untuk memprediksi dan merespons lonjakan traffic sebelum meningkat menjadi kelebihan beban. Deteksi dan respons dini dapat membantu mempertahankan ketersediaan layanan selama periode permintaan tinggi.

Lakukan pengujian untuk pemulihan dari kegagalan

Prinsip dalam pilar keandalan Google Cloud Framework yang Dirancang dengan Baik ini memberikan rekomendasi untuk membantu Anda mendesain dan menjalankan pengujian untuk pemulihan jika terjadi kegagalan.

Prinsip ini relevan dengan area fokus pembelajaran keandalan.

Ringkasan prinsip

Untuk memastikan bahwa sistem Anda dapat pulih dari kegagalan, Anda harus menjalankan pengujian secara berkala yang mencakup failover regional, roll back rilis, dan pemulihan data dari cadangan.

Pengujian ini membantu Anda mempraktikkan respons terhadap peristiwa yang menimbulkan risiko besar terhadap keandalan, seperti pemadaman listrik di seluruh wilayah. Pengujian ini juga membantu Anda memverifikasi bahwa sistem Anda berperilaku seperti yang diinginkan selama terjadi gangguan.

Jika seluruh region tidak berfungsi, Anda harus melakukan failover semua traffic ke region lain. Selama operasi normal beban kerja Anda, saat data diubah, data tersebut harus disinkronkan dari region utama ke region failover. Anda harus memverifikasi bahwa data yang direplikasi selalu terbaru, sehingga pengguna tidak mengalami kehilangan data atau gangguan sesi. Sistem load balancing juga harus dapat mengalihkan traffic ke region failover kapan saja tanpa gangguan layanan. Untuk meminimalkan periode nonaktif setelah gangguan regional, teknisi operasi juga harus dapat mengalihkan traffic pengguna dari suatu wilayah secara manual dan efisien dalam waktu sesingkat mungkin. Operasi ini terkadang disebut menguras region, yang berarti Anda menghentikan traffic masuk ke region dan memindahkan semua traffic ke tempat lain.

Rekomendasi

Saat mendesain dan menjalankan pengujian untuk pemulihan dari kegagalan, pertimbangkan rekomendasi di subbagian berikut.

Tentukan tujuan dan cakupan pengujian

Tentukan dengan jelas apa yang ingin Anda capai dari pengujian. Misalnya, tujuan Anda dapat mencakup hal berikut:

  • Validasi batas waktu pemulihan (RTO) dan batas titik pemulihan (RPO). Untuk mengetahui detailnya, lihat Dasar-dasar perencanaan DR.
  • Menilai ketahanan sistem dan fault tolerance dalam berbagai skenario kegagalan.
  • Uji efektivitas mekanisme failover otomatis.

Tentukan komponen, layanan, atau region mana yang termasuk dalam cakupan pengujian. Cakupan dapat mencakup tingkat aplikasi tertentu seperti frontend, backend, dan database, atau dapat mencakup resource Google Cloud tertentu seperti instance Cloud SQL atau cluster GKE. Cakupan juga harus menentukan dependensi eksternal, seperti API pihak ketiga atau interkoneksi cloud.

Menyiapkan lingkungan untuk pengujian

Pilih lingkungan yang sesuai, sebaiknya lingkungan staging atau sandbox yang mereplikasi penyiapan produksi Anda. Jika Anda melakukan pengujian di produksi, pastikan Anda menyiapkan langkah-langkah keamanan, seperti pemantauan otomatis dan prosedur rollback manual.

Buat rencana cadangan. Buat snapshot atau cadangan database dan layanan penting untuk mencegah kehilangan data selama pengujian. Pastikan tim Anda siap melakukan intervensi manual jika mekanisme failover otomatis gagal.

Untuk mencegah gangguan pengujian, pastikan peran IAM, kebijakan, dan konfigurasi failover Anda disiapkan dengan benar. Pastikan izin yang diperlukan sudah ada untuk alat dan skrip pengujian.

Memberi tahu pemangku kepentingan, termasuk operasi, DevOps, dan pemilik aplikasi, tentang jadwal, cakupan, dan potensi dampak pengujian. Memberikan perkiraan linimasa dan perilaku yang diharapkan selama pengujian kepada pemangku kepentingan.

Menyimulasikan skenario kegagalan

Rencanakan dan jalankan kegagalan menggunakan alat seperti Chaos Monkey. Anda dapat menggunakan skrip kustom untuk menyimulasikan kegagalan layanan penting seperti penonaktifan node utama di cluster GKE multi-zona atau instance Cloud SQL yang dinonaktifkan. Anda juga dapat menggunakan skrip untuk menyimulasikan gangguan jaringan di seluruh wilayah dengan menggunakan aturan firewall atau pembatasan API berdasarkan cakupan pengujian Anda. Tingkatkan skenario kegagalan secara bertahap untuk mengamati perilaku sistem dalam berbagai kondisi.

Perkenalkan pengujian beban bersama dengan skenario kegagalan untuk mereplikasi penggunaan di dunia nyata selama gangguan. Uji dampak kegagalan beruntun, seperti perilaku sistem frontend saat layanan backend tidak tersedia.

Untuk memvalidasi perubahan konfigurasi dan menilai ketahanan sistem terhadap kesalahan manusia, uji skenario yang melibatkan kesalahan konfigurasi. Misalnya, jalankan pengujian dengan setelan failover DNS yang salah atau izin IAM yang salah.

Memantau perilaku sistem

Pantau cara load balancer, health check, dan mekanisme lainnya merutekan ulang traffic. Gunakan Google Cloud alat seperti Cloud Monitoring dan Cloud Logging untuk merekam metrik dan peristiwa selama pengujian.

Amati perubahan latensi, tingkat error, dan throughput selama dan setelah simulasi kegagalan, serta pantau dampak performa secara keseluruhan. Mengidentifikasi penurunan kualitas atau inkonsistensi dalam pengalaman pengguna.

Pastikan log dibuat dan pemberitahuan dipicu untuk peristiwa utama, seperti gangguan layanan atau failover. Gunakan data ini untuk memverifikasi efektivitas sistem pemberitahuan dan respons insiden Anda.

Memverifikasi pemulihan terhadap RTO dan RPO Anda

Ukur berapa lama waktu yang diperlukan sistem untuk melanjutkan operasi normal setelah terjadi kegagalan, lalu bandingkan data ini dengan RTO yang ditentukan dan dokumentasikan setiap kesenjangan.

Pastikan integritas dan ketersediaan data sesuai dengan RPO. Untuk menguji konsistensi database, bandingkan snapshot atau cadangan database sebelum dan setelah terjadi kegagalan.

Evaluasi pemulihan layanan dan pastikan semua layanan dipulihkan ke kondisi fungsional dengan gangguan minimal bagi pengguna.

Mendokumentasikan dan menganalisis hasil

Mendokumentasikan setiap langkah pengujian, skenario kegagalan, dan perilaku sistem yang sesuai. Sertakan stempel waktu, log, dan metrik untuk analisis mendetail.

Soroti hambatan, titik tunggal kegagalan, atau perilaku tak terduga yang diamati selama pengujian. Untuk membantu memprioritaskan perbaikan, kategorikan masalah berdasarkan tingkat keparahan dan dampaknya.

Sarankan peningkatan pada arsitektur sistem, mekanisme failover, atau konfigurasi pemantauan. Berdasarkan temuan pengujian, perbarui kebijakan dan playbook failover yang relevan. Menyajikan laporan postmortem kepada pemangku kepentingan. Laporan harus meringkas hasil, pelajaran yang didapat, dan langkah selanjutnya. Untuk mengetahui informasi selengkapnya, lihat Lakukan postmortem menyeluruh.

Lakukan iterasi dan peningkatan

Untuk memvalidasi keandalan dan ketahanan berkelanjutan, rencanakan pengujian berkala (misalnya, setiap tiga bulan).

Jalankan pengujian dalam berbagai skenario, termasuk perubahan infrastruktur, update software, dan peningkatan beban traffic.

Otomatiskan pengujian failover dengan menggunakan pipeline CI/CD untuk mengintegrasikan pengujian keandalan ke dalam siklus proses pengembangan Anda.

Selama postmortem, gunakan masukan dari pemangku kepentingan dan pengguna akhir untuk meningkatkan kualitas proses pengujian dan ketahanan sistem.

Melakukan pengujian untuk pemulihan dari kehilangan data

Prinsip dalam pilar keandalan Google Cloud Framework yang Dirancang dengan Baik ini memberikan rekomendasi untuk membantu Anda mendesain dan menjalankan pengujian untuk pemulihan dari kehilangan data.

Prinsip ini relevan dengan area fokus pembelajaran keandalan.

Ringkasan prinsip

Untuk memastikan bahwa sistem Anda dapat pulih dari situasi saat data hilang atau rusak, Anda perlu menjalankan pengujian untuk skenario tersebut. Kasus kehilangan data dapat disebabkan oleh bug software atau beberapa jenis bencana alam. Setelah peristiwa tersebut, Anda perlu memulihkan data dari cadangan dan mengaktifkan kembali semua layanan dengan menggunakan data yang baru dipulihkan.

Sebaiknya gunakan tiga kriteria untuk menilai keberhasilan atau kegagalan jenis uji pemulihan ini: integritas data, batas waktu pemulihan (RTO), dan toleransi jumlah data yang hilang (RPO). Untuk mengetahui detail tentang metrik RTO dan RPO, lihat Dasar-dasar perencanaan DR.

Tujuan pengujian pemulihan data adalah untuk memverifikasi secara berkala bahwa organisasi Anda dapat terus memenuhi persyaratan kelangsungan bisnis. Selain mengukur RTO dan RPO, pengujian pemulihan data harus mencakup pengujian seluruh stack aplikasi dan semua layanan infrastruktur penting dengan data yang dipulihkan. Hal ini diperlukan untuk mengonfirmasi bahwa seluruh aplikasi yang di-deploy berfungsi dengan benar di lingkungan pengujian.

Rekomendasi

Saat mendesain dan menjalankan pengujian untuk pemulihan dari kehilangan data, pertimbangkan rekomendasi di subbagian berikut.

Memverifikasi konsistensi pencadangan dan menguji proses pemulihan

Anda harus memverifikasi bahwa cadangan Anda berisi snapshot data yang konsisten dan dapat digunakan yang dapat Anda pulihkan untuk segera mengaktifkan kembali aplikasi. Untuk memvalidasi integritas data, siapkan pemeriksaan konsistensi otomatis untuk dijalankan setelah setiap pencadangan.

Untuk menguji cadangan, pulihkan cadangan di lingkungan non-produksi. Untuk memastikan pencadangan Anda dapat dipulihkan secara efisien dan data yang dipulihkan memenuhi persyaratan aplikasi, simulasikan skenario pemulihan data secara rutin. Mendokumentasikan langkah-langkah pemulihan data, dan melatih tim Anda untuk menjalankan langkah-langkah tersebut secara efektif selama terjadi kegagalan.

Menjadwalkan pencadangan rutin dan sering

Untuk meminimalkan kehilangan data selama pemulihan dan memenuhi target RPO, Anda harus menjadwalkan pencadangan secara rutin. Tetapkan frekuensi pencadangan yang sesuai dengan RPO Anda. Misalnya, jika RPO Anda adalah 15 menit, jadwalkan pencadangan agar berjalan setidaknya setiap 15 menit. Optimalkan interval pencadangan untuk mengurangi risiko kehilangan data.

Gunakan Google Cloud alat seperti Cloud Storage, pencadangan otomatis Cloud SQL, atau pencadangan Spanner untuk menjadwalkan dan mengelola pencadangan. Untuk aplikasi penting, gunakan solusi pencadangan yang hampir berkelanjutan seperti pemulihan point-in-time (PITR) untuk Cloud SQL atau pencadangan inkremental untuk set data besar.

Menentukan dan memantau RPO

Tetapkan RPO yang jelas berdasarkan kebutuhan bisnis Anda, dan pantau kepatuhan terhadap RPO. Jika interval pencadangan melebihi RPO yang ditentukan, gunakan Cloud Monitoring untuk menyiapkan pemberitahuan.

Memantau kondisi pencadangan

Gunakan Google Cloud Layanan pencadangan dan DR atau alat serupa untuk melacak kondisi cadangan Anda dan mengonfirmasi bahwa cadangan tersebut disimpan di lokasi yang aman dan andal. Pastikan cadangan direplikasi di beberapa region untuk meningkatkan ketahanan.

Merencanakan skenario di luar pencadangan

Gabungkan pencadangan dengan strategi pemulihan dari bencana seperti penyiapan failover aktif-aktif atau replikasi lintas region untuk meningkatkan waktu pemulihan dalam kasus ekstrem. Untuk mengetahui informasi selengkapnya, lihat Panduan perencanaan pemulihan dari bencana.

Lakukan postmortem secara menyeluruh

Prinsip dalam pilar keandalan Google Cloud Framework yang Dirancang dengan Baik ini memberikan rekomendasi untuk membantu Anda melakukan postmortem yang efektif setelah terjadi kegagalan dan insiden.

Prinsip ini relevan dengan area fokus pembelajaran keandalan.

Ringkasan prinsip

Postmortem adalah catatan tertulis tentang insiden, dampaknya, tindakan yang diambil untuk memitigasi atau menyelesaikan insiden, penyebab utama, dan tindakan lanjutan untuk mencegah insiden terulang kembali. Tujuan postmortem adalah belajar dari kesalahan, bukan mencari-cari kesalahan.

Diagram berikut menunjukkan alur kerja postmortem:

Alur kerja postmortem.

Alur kerja postmortem mencakup langkah-langkah berikut:

  • Membuat postmortem
  • Menyampaikan fakta
  • Mengidentifikasi dan menganalisis akar penyebab
  • Merencanakan masa depan
  • Jalankan rencana

Lakukan analisis postmortem setelah peristiwa besar dan peristiwa non-besar seperti berikut:

  • Waktu nonaktif atau penurunan performa yang terlihat oleh pengguna di luar batas tertentu.
  • Kehilangan data dalam bentuk apa pun.
  • Intervensi dari engineer yang bertugas, seperti rollback rilis atau pengalihan traffic.
  • Waktu penyelesaian di atas nilai minimum yang ditentukan.
  • Kegagalan pemantauan, yang biasanya menyiratkan penemuan insiden secara manual.

Rekomendasi

Tentukan kriteria postmortem sebelum insiden terjadi agar semua orang tahu kapan postmortem diperlukan.

Untuk melakukan postmortem yang efektif, pertimbangkan rekomendasi di subbagian berikut.

Melakukan postmortem tanpa menyalahkan

Post-mortem yang efektif berfokus pada proses, alat, dan teknologi, serta tidak menyalahkan individu atau tim. Tujuan analisis post-mortem adalah untuk meningkatkan kualitas teknologi dan masa depan Anda, bukan untuk mencari tahu siapa yang bersalah. Semua orang pasti pernah melakukan kesalahan. Tujuannya adalah menganalisis kesalahan dan belajar darinya.

Contoh berikut menunjukkan perbedaan antara masukan yang menyalahkan dan masukan tanpa menyalahkan:

  • Masukan yang menyalahkan: "Kita perlu menulis ulang seluruh sistem backend yang rumit ini! Hal ini terjadi setiap minggu selama tiga kuartal terakhir dan saya yakin kita semua sudah lelah memperbaiki masalah satu per satu. Sungguh, kalau saya dipanggil sekali lagi, saya akan menulis ulang sendiri…"
  • Masukan tanpa menyalahkan: "Item tindakan untuk menulis ulang seluruh sistem backend mungkin dapat mencegah terjadinya masalah ini di halaman tersebut. Panduan pemeliharaan untuk versi ini cukup panjang dan sangat sulit untuk dipelajari sepenuhnya. Saya yakin engineer yang bertugas di masa mendatang akan berterima kasih kepada kita!"

Buat laporan postmortem dapat dibaca oleh semua audiens yang dituju

Untuk setiap informasi yang berencana Anda sertakan dalam laporan, nilai apakah informasi tersebut penting dan diperlukan untuk membantu audiens memahami apa yang terjadi. Anda dapat memindahkan data dan penjelasan tambahan ke lampiran laporan. Peninjau yang memerlukan informasi lebih lanjut dapat memintanya.

Hindari solusi yang rumit atau terlalu canggih

Sebelum Anda mulai mencari solusi untuk suatu masalah, evaluasi pentingnya masalah tersebut dan kemungkinan masalah itu akan muncul kembali. Menambahkan kompleksitas pada sistem untuk memecahkan masalah yang kemungkinan tidak akan terjadi lagi dapat menyebabkan ketidakstabilan yang meningkat.

Bagikan postmortem seluas mungkin

Untuk memastikan masalah tidak tetap tidak terselesaikan, publikasikan hasil postmortem kepada audiens yang luas dan dapatkan dukungan dari manajemen. Nilai post-mortem sebanding dengan pembelajaran yang terjadi setelah post-mortem. Jika lebih banyak orang belajar dari insiden, kemungkinan kegagalan serupa akan berulang menjadi lebih kecil.