Google Cloud Well-Architected Framework: Keandalan

Last reviewed 2025-02-14 UTC

Pilar keandalan dalam Google Cloud Framework Arsitektur yang 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 engineer keandalan situs.

Keandalan adalah kemampuan sistem untuk secara konsisten menjalankan fungsi yang dimaksudkan dalam kondisi yang ditentukan dan mempertahankan layanan yang tidak terganggu. Praktik terbaik untuk keandalan mencakup redundansi, desain fault-tolerant, pemantauan, dan proses pemulihan otomatis.

Sebagai bagian dari keandalan, ketahanan adalah kemampuan sistem untuk bertahan dan pulih dari kegagalan atau gangguan yang tidak terduga, sekaligus mempertahankan performa. Google Cloud Fitur, seperti deployment multi-regional, pencadangan otomatis, dan solusi disaster recovery, dapat membantu Anda meningkatkan ketahanan sistem.

Keandalan penting bagi strategi cloud Anda karena banyak alasan, termasuk hal berikut:

  • Periode nonaktif minimal: Periode nonaktif dapat menyebabkan hilangnya pendapatan, menurunnya produktivitas, dan kerusakan reputasi. Arsitektur yang tangguh dapat membantu memastikan sistem dapat terus berfungsi selama 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 bahkan saat permintaan tinggi atau masalah yang tidak terduga.
  • Integritas data: Kegagalan dapat menyebabkan hilangnya data atau kerusakan data. Sistem yang tangguh menerapkan mekanisme seperti pencadangan, redundansi, dan replika untuk melindungi data dan memastikan data tetap akurat dan dapat diakses.
  • Kelangsungan bisnis: Bisnis Anda mengandalkan teknologi untuk operasi penting. Arsitektur yang tangguh dapat membantu memastikan kelangsungan setelah kegagalan besar, 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 awal, tetapi ketahanan dapat membantu mengurangi biaya dari waktu ke waktu dengan mencegah downtime yang mahal, menghindari perbaikan reaktif, dan memungkinkan penggunaan resource yang lebih efisien.

Pola pikir organisasi

Agar sistem Anda andal, Anda memerlukan rencana dan strategi yang mapan. Strategi ini harus mencakup pendidikan 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, engineering platform, dan site reliability engineering (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 atas persyaratan ini. Konflik antara keandalan dan pengembangan fitur produk reguler harus diprioritaskan dan dieskalasi sebagaimana mestinya.

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

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 ini.

  • Penentuan cakupan: Untuk memahami sistem Anda, lakukan analisis mendetail terhadap arsitekturnya. Anda perlu memahami komponen, cara kerjanya, dan interaksinya, cara data dan tindakan mengalir melalui sistem, serta hal yang dapat terjadi. Identifikasi potensi kegagalan, bottleneck, 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 pulih secara efisien. Respons otomatis juga dapat membantu mengurangi dampak kegagalan. Meskipun dengan perencanaan dan kontrol, kegagalan masih dapat terjadi.
  • Pembelajaran: Untuk membantu mencegah kegagalan berulang, pelajari setiap pengalaman, dan lakukan tindakan yang sesuai.

Prinsip inti

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

Kontributor

Penulis:

Kontributor lainnya:

Menentukan keandalan berdasarkan sasaran pengalaman pengguna

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

Prinsip ini relevan dengan cakupan area fokus keandalan.

Ringkasan prinsip

Alat observabilitas memberikan data dalam jumlah besar, tetapi tidak semua data terkait langsung dengan dampaknya terhadap 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, masalah tersebut tidak akan menyebabkan pemadaman layanan.

Untuk mengukur pengalaman pengguna, Anda perlu 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 yang sebenarnya 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 pengguna yang sebenarnya. Misalnya, ukur rasio keberhasilan kueri pengguna, latensi aplikasi, dan rasio error.

Idealnya, kumpulkan data ini langsung dari perangkat atau browser pengguna. Jika pengumpulan data langsung ini tidak memungkinkan, geser titik pengukuran Anda secara bertahap 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 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 dapat menemukan bottleneck dan masalah latensi yang dapat menurunkan 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 yang realistis untuk keandalan

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

Prinsip ini relevan dengan cakupan area fokus keandalan.

Ringkasan prinsip

Desain sistem Anda agar cukup andal untuk kepuasan pengguna. Hal ini 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 keuangan maupun potensi batasan pada inovasi. Jika pengguna sudah puas dengan tingkat layanan saat ini, upaya untuk meningkatkan kepuasan lebih lanjut mungkin akan menghasilkan laba atas investasi yang rendah. Sebagai gantinya, Anda dapat menggunakan resource dengan lebih baik di tempat lain.

Anda perlu menentukan tingkat keandalan yang memuaskan pengguna, dan menentukan titik saat biaya peningkatan inkremental mulai melebihi manfaatnya. Saat menentukan tingkat keandalan yang memadai ini, Anda dapat mengalokasikan resource secara strategis dan berfokus pada fitur serta peningkatan yang memberikan nilai lebih besar kepada pengguna.

Rekomendasi

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

Menerima beberapa kegagalan dan memprioritaskan komponen

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

Kesenjangan antara waktu aktif 100% dan target 99,99% adalah toleransi untuk kegagalan. Kesenjangan ini sering disebut 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 yang paling penting dalam sistem. Terima bahwa komponen yang kurang penting dapat memiliki toleransi kegagalan yang lebih tinggi.

Menyeimbangkan keandalan dan biaya

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

Pertimbangkan faktor-faktor seperti persyaratan sistem, konsekuensi kegagalan, dan toleransi risiko organisasi Anda untuk aplikasi tertentu. Jangan lupa untuk mempertimbangkan metrik disaster recovery, 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 yang penting.

Membuat sistem yang selalu tersedia melalui redundansi resource

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

Prinsip ini relevan dengan cakupan area fokus keandalan.

Ringkasan prinsip

Setelah menentukan tingkat keandalan yang diperlukan, 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 dapat ditempatkan di satu region saja, dan server metadata tidak dapat di-deploy di satu zona atau region saja. Dalam contoh tersebut, jika satu zona atau region mengalami pemadaman layanan, sistem akan mengalami pemadaman layanan global.

Rekomendasi

Untuk membuat sistem redundan, pertimbangkan rekomendasi dalam subbagian berikut.

Mengidentifikasi domain kegagalan dan mereplikasi layanan

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

Untuk memastikan ketersediaan tinggi, distribusikan dan replikasi layanan serta aplikasi Anda di beberapa zona dan region. Konfigurasikan sistem untuk failover otomatis guna memastikan bahwa 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

Lacak terus status domain kegagalan Anda untuk mendeteksi dan mengatasi masalah dengan cepat.

Anda dapat memantau status Google Cloud layanan saat ini di semua region menggunakan Google Cloud dasbor Service Health. 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 ke backend yang berfungsi dengan baik secara otomatis. Untuk mengetahui informasi selengkapnya, lihat Ringkasan health check.

Menguji skenario failover

Seperti simulasi kebakaran, simulasikan kegagalan secara rutin untuk memvalidasi efektivitas strategi replika dan failover Anda.

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

Manfaatkan skalabilitas horizontal

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

Prinsip ini relevan dengan cakupan area fokus keandalan.

Ringkasan prinsip

Buat ulang arsitektur sistem Anda menjadi 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, lebih banyak RAM dan CPU diperlukan. Pada akhirnya, database mencapai batas memori di mesin host, dan perlu diupgrade. Proses ini mungkin perlu diulang beberapa kali. Masalahnya adalah ada batas ketat terkait jumlah database yang dapat tumbuh. Ukuran VM tidak terbatas. Database dapat mencapai titik saat tidak dapat 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 pemadaman layanan seluruh sistem yang memengaruhi semua pengguna. Hindari titik tunggal kegagalan, seperti yang dijelaskan dalam Mem-build sistem yang sangat tersedia melalui redundansi resource.

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

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

Rekomendasi

Untuk bertransisi dari satu arsitektur VM ke arsitektur beberapa mesin horisontal, Anda perlu merencanakan dengan cermat dan menggunakan alat yang tepat. Untuk membantu Anda mencapai penskalaan horizontal, pertimbangkan rekomendasi dalam 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 otomatis menskalakan container stateless Anda 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 informasi selengkapnya, lihat Mempromosikan desain modular di pilar pengoptimalan performa.

Mengimplementasikan desain stateless

Desain aplikasi agar stateless, yang berarti tidak ada data yang disimpan secara lokal. Hal ini memungkinkan Anda menambahkan atau menghapus instance tanpa mengkhawatirkan konsistensi data.

Mendeteksi potensi kegagalan menggunakan kemampuan observasi

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

Prinsip ini relevan dengan area fokus observasi keandalan.

Ringkasan prinsip

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

  • 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 catatan peristiwa terpisah yang terjadi dalam aplikasi atau sistem dengan stempel waktu. Peristiwa tersebut dapat berupa kegagalan, error, atau perubahan status. Log mungkin menyertakan 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 dapat berupa microservice. Trace membantu Anda melacak komponen yang digunakan dalam perjalanan, lokasi bottleneck, dan berapa lama perjalanan berlangsung.

Metrik, log, dan rekaman aktivitas membantu Anda memantau sistem secara berkelanjutan. Pemantauan komprehensif membantu Anda mengetahui tempat dan penyebab terjadinya error. Anda juga dapat mendeteksi potensi kegagalan sebelum error terjadi.

Rekomendasi

Untuk mendeteksi potensi kegagalan secara efisien, pertimbangkan rekomendasi dalam 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 beban kerja Anda.

Untuk membuat keputusan berbasis data, analisis metrik layanan default guna 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 Anda mengonfigurasi logging, pertimbangkan biaya terkait. Untuk mengontrol biaya logging, Anda dapat mengonfigurasi filter pengecualian di 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 berlebih dalam layanan seperti GKE, Compute Engine, dan Dataproc. Untuk mengetahui daftar lengkap layanan yang didukung, lihat ringkasan Cloud Monitoring.

Memprioritaskan pemberitahuan

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

Desain untuk degradasi halus

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

Prinsip ini relevan dengan area fokus respons keandalan.

Ringkasan prinsip

Degradasi halus adalah pendekatan desain saat sistem yang mengalami beban tinggi terus berfungsi, mungkin dengan performa atau akurasi yang berkurang. Degradasi halus 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 memiliki peringkat lebih tinggi, yang berpotensi mengorbankan beberapa akurasi. Saat beban menurun, Google Penelusuran akan menghitung ulang hasil penelusuran.

Rekomendasi

Untuk mendesain sistem Anda agar mengalami degradasi yang halus, 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 pergeseran traffic berlebih di antara zona.

Gunakan alat seperti Apigee untuk mengontrol kecepatan permintaan API selama waktu dengan traffic tinggi. Anda dapat mengonfigurasi aturan kebijakan untuk mencerminkan cara Anda ingin menskalakan kembali permintaan.

Menghapus permintaan berlebih lebih awal

Konfigurasikan sistem Anda untuk menghapus permintaan berlebih di lapisan frontend guna melindungi komponen backend. Menghapus beberapa permintaan akan mencegah kegagalan global dan memungkinkan sistem pulih dengan lebih baik.Dengan pendekatan ini, beberapa pengguna mungkin mengalami error. Namun, Anda dapat meminimalkan dampak pemadaman, berbeda dengan pendekatan seperti pemutusan sirkuit, yang semua traffic-nya terputus selama overload.

Menangani error sebagian dan percobaan ulang

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

Menguji skenario kelebihan beban

Untuk memvalidasi bahwa mekanisme throttle dan drop permintaan berfungsi secara efektif, simulasikan kondisi overload 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 overload. Deteksi dan respons awal dapat membantu mempertahankan ketersediaan layanan selama periode permintaan tinggi.

Melakukan pengujian untuk pemulihan dari kegagalan

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

Prinsip ini relevan dengan area fokus pembelajaran keandalan.

Ringkasan prinsip

Untuk memastikan sistem Anda dapat pulih dari kegagalan, Anda harus menjalankan pengujian secara berkala yang mencakup failover regional, rollback rilis, dan pemulihan data dari pencadangan.

Pengujian ini membantu Anda berlatih merespons peristiwa yang menimbulkan risiko besar terhadap keandalan, seperti pemadaman seluruh wilayah. Pengujian ini juga membantu Anda memverifikasi bahwa sistem Anda berperilaku seperti yang diinginkan selama gangguan.

Jika seluruh region tidak aktif, 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 penggantian. Anda perlu memverifikasi bahwa data yang direplikasi selalu yang terbaru, sehingga pengguna tidak mengalami kehilangan data atau kerusakan sesi. Sistem load balancing juga harus dapat mengalihkan traffic ke region failover kapan saja tanpa gangguan layanan. Untuk meminimalkan periode nonaktif setelah pemadaman layanan regional, engineer operasi juga harus dapat secara manual dan efisien mengalihkan traffic pengguna dari suatu wilayah, 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 Anda mendesain dan menjalankan pengujian untuk pemulihan kegagalan, pertimbangkan rekomendasi dalam subbagian berikut.

Menentukan tujuan dan cakupan pengujian

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

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

Tentukan komponen, layanan, atau region 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 dalam produksi, pastikan Anda telah menyiapkan langkah-langkah keamanan, seperti pemantauan otomatis dan prosedur rollback manual.

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

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

Beri tahu pemangku kepentingan, termasuk operasi, DevOps, dan pemilik aplikasi, tentang jadwal, cakupan, dan potensi dampak pengujian. Berikan estimasi linimasa dan perilaku yang diharapkan selama pengujian kepada pemangku kepentingan.

Menyimulasikan skenario kegagalan

Merencanakan dan menjalankan 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 pemadaman jaringan di seluruh wilayah menggunakan aturan firewall atau pembatasan API berdasarkan cakupan pengujian Anda. Tingkatkan skenario kegagalan secara bertahap untuk mengamati perilaku sistem dalam berbagai kondisi.

Lakukan pengujian beban bersama dengan skenario kegagalan untuk mereplikasi penggunaan di dunia nyata selama pemadaman. 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 alat Google Cloud 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. Identifikasi degradasi 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 kegagalan, lalu bandingkan data ini dengan RTO yang ditentukan dan dokumentasikan kesenjangan apa pun.

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

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

Mendokumentasikan dan menganalisis hasil

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

Menyoroti bottleneck, titik tunggal kegagalan, atau perilaku tidak terduga yang diamati selama pengujian. Untuk membantu memprioritaskan perbaikan, kategorikan masalah berdasarkan keparahan dan dampaknya.

Sarankan peningkatan pada arsitektur sistem, mekanisme failover, atau penyiapan pemantauan. Berdasarkan temuan pengujian, perbarui kebijakan dan playbook failover yang relevan. Mempresentasikan laporan postmortem kepada pemangku kepentingan. Laporan harus menyampulkan hasil, pelajaran yang didapat, dan langkah berikutnya. Untuk informasi selengkapnya, lihat Melakukan postmortem yang menyeluruh.

Melakukan iterasi dan peningkatan

Untuk memvalidasi keandalan dan ketahanan yang berkelanjutan, rencanakan pengujian berkala (misalnya, setiap kuartal).

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

Otomatiskan pengujian failover 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 proses pengujian dan ketahanan sistem.

Melakukan pengujian untuk pemulihan dari kehilangan data

Prinsip ini dalam pilar keandalan Google Cloud Framework dengan Arsitektur yang Baik 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 sistem Anda dapat pulih dari situasi saat data hilang atau rusak, Anda perlu menjalankan pengujian untuk skenario tersebut. Kejadian kehilangan data mungkin disebabkan oleh bug software atau beberapa jenis bencana alam. Setelah peristiwa tersebut, Anda perlu memulihkan data dari cadangan dan mengaktifkan kembali semua layanan menggunakan data yang baru dipulihkan.

Sebaiknya gunakan tiga kriteria untuk menilai keberhasilan atau kegagalan jenis pengujian 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 Anda mendesain dan menjalankan pengujian untuk memulihkan dari kehilangan data, pertimbangkan rekomendasi di subbagian berikut.

Memverifikasi konsistensi pencadangan dan menguji proses pemulihan

Anda perlu memverifikasi bahwa pencadangan 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 pencadangan, pulihkan di lingkungan non-produksi. Untuk memastikan pencadangan dapat dipulihkan secara efisien dan data yang dipulihkan memenuhi persyaratan aplikasi, simulasikan skenario pemulihan data secara berkala. Dokumentasikan langkah-langkah untuk pemulihan data, dan latih tim Anda untuk menjalankan langkah-langkah tersebut secara efektif selama kegagalan.

Menjadwalkan pencadangan rutin dan sering

Untuk meminimalkan kehilangan data selama pemulihan dan memenuhi target RPO, Anda harus memiliki pencadangan terjadwal secara rutin. Tetapkan frekuensi pencadangan yang sesuai dengan RPO Anda. Misalnya, jika RPO Anda adalah 15 menit, jadwalkan pencadangan agar berjalan minimal 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 terus-menerus 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 pencadangan Anda dan mengonfirmasi bahwa cadangan tersebut disimpan di lokasi yang aman dan andal. Pastikan cadangan direplikasi di beberapa region untuk ketahanan tambahan.

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 informasi selengkapnya, lihat Panduan perencanaan pemulihan dari bencana (disaster recovery).

Melakukan postmortem yang menyeluruh

Prinsip ini dalam pilar keandalan Google Cloud Framework dengan Arsitektur yang Baik memberikan rekomendasi untuk membantu Anda melakukan postmortem yang efektif setelah 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, akar penyebabnya, dan tindakan lanjutan untuk mencegah insiden terulang. Tujuan postmortem adalah untuk belajar dari kesalahan dan bukan mencari-cari kesalahan.

Diagram berikut menunjukkan alur kerja postmortem:

Alur kerja postmortem.

Alur kerja postmortem mencakup langkah-langkah berikut:

  • Membuat postmortem
  • Menangkap fakta
  • Mengidentifikasi dan menganalisis akar masalah
  • Merencanakan masa depan
  • Menjalankan rencana

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

  • Downtime atau penurunan kualitas yang terlihat oleh pengguna di luar batas tertentu.
  • Segala jenis kehilangan data.
  • Intervensi dari engineer yang siap siaga, seperti rollback rilis atau perubahan rute traffic.
  • Waktu penyelesaian di atas nilai minimum yang ditentukan.
  • Kegagalan pemantauan, yang biasanya menyiratkan penemuan insiden manual.

Rekomendasi

Tentukan kriteria post-mortem sebelum insiden terjadi sehingga semua orang tahu kapan post-mortem diperlukan.

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

Melakukan postmortem tanpa menyalahkan

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

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

  • Masukan yang menyalahkan: "Kita perlu menulis ulang seluruh sistem backend yang rumit. Aplikasi ini mengalami error setiap minggu selama tiga kuartal terakhir dan saya yakin kita semua sudah lelah memperbaikinya secara terpisah. Serius, jika saya dipanggil lagi, saya akan menulis ulang sendiri…"
  • Feedback tanpa menyalahkan: "Item tindakan untuk menulis ulang seluruh sistem backend mungkin benar-benar mencegah halaman ini terus terjadi. Manual pemeliharaan untuk versi ini cukup panjang dan sangat sulit untuk dipelajari sepenuhnya. Saya yakin engineer piket kami di masa mendatang akan berterima kasih kepada kami."

Membuat laporan postmortem dapat dibaca oleh semua audiens yang dituju

Untuk setiap informasi yang ingin 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.

Menghindari solusi yang rumit atau terlalu canggih

Sebelum Anda mulai mempelajari solusi untuk suatu masalah, evaluasi pentingnya masalah dan kemungkinan terjadinya masalah tersebut lagi. Menambahkan kompleksitas ke sistem untuk memecahkan masalah yang tidak mungkin terjadi lagi dapat menyebabkan peningkatan instabilitas.

Bagikan laporan post-mortem 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 terulang akan berkurang.