Pilih desain ketersediaan lintas zona dan region

Mulai dari operasi pengguna

High availability (HA) bertujuan menjaga layanan tetap dapat digunakan meskipun komponen gagal. Tentukan makna dapat digunakan sebelum memilih arsitektur. Halaman reservasi yang berhasil dimuat sementara semua permintaan reservasi gagal bukan layanan reservasi yang tersedia.

Tetapkan service level objective (SLO) untuk operasi penting. Tentukan permintaan yang dihitung, arti keberhasilan, dan periode pengukuran. SLA layanan cloud menjelaskan komitmen penyedianya. SLA tersebut tidak membuktikan ketersediaan terukur aplikasi Anda.

Sebagai ilustrasi, ketersediaan berbasis waktu sebesar 99,9% mengizinkan ketidaktersediaan selama 43,2 menit dalam bulan 30 hari. SLO berbasis permintaan memiliki penyebut yang berbeda. Tidak satu pun ukuran tersebut menyatakan jumlah data yang boleh hilang atau menjamin durasi maksimum setiap gangguan.

Pahami batas kegagalan

AWS Availability Zone (AZ) adalah lokasi infrastruktur terisolasi dalam sebuah Region. Satu Region mencakup beberapa AZ. Desain multi-region mendistribusikan komponen workload lintas Region. Penyedia lain memiliki batas dan perilaku layanan sendiri; periksa layanan yang dipilih.

Ini adalah kemungkinan desain, bukan jaminan ketersediaan. Label tidak membuktikan bahwa setiap komponen yang diperlukan menggunakan batas yang dimaksud.

Telusuri seluruh jalur permintaan

Pertimbangkan layanan reservasi fiktif. Replika web berjalan dalam dua AZ. Keduanya menggunakan satu database dan satu gateway keluar di AZ A. Gateway diperlukan untuk memanggil penyedia pembayaran.

Jika AZ A gagal, replika web di AZ B mungkin tetap sehat sementara reservasi tetap gagal. Tim harus menilai database, jalur jaringan, penyedia identitas, dependensi pembayaran, dan routing. Periksa mode database terkelola yang sebenarnya: replikasi, failover, dan perilaku komponen pembaca berbeda menurut produk dan konfigurasi.

Periksa juga kapasitas. Sumber daya yang bertahan harus menangani beban yang diperlukan. Desain yang mengandalkan penyediaan kapasitas saat insiden bergantung pada kuota, sumber daya yang tersedia, dan operasi control plane.

Jalankan latihan terkendali dengan batas, kondisi penghentian, dan penanggung jawab yang jelas. Verifikasi reservasi lengkap, termasuk rekonsiliasi pembayaran. Catat permintaan yang gagal dan waktu untuk memulihkan operasi yang dapat digunakan.

Tentukan apakah Region lain menyelesaikan masalah

Operasi multi-region menambah transfer data, sumber daya duplikat, koordinasi deployment, dan pekerjaan operasi. Active/passive menjaga satu lingkungan siap menerima traffic. Active/active melayani traffic di lebih dari satu lingkungan. Kesiapan dan perilaku data yang diperlukan berbeda.

Untuk layanan reservasi, penulisan bersamaan menimbulkan pertanyaan: dapatkah dua Region menjual kursi yang sama? Tentukan pihak yang berwenang menetapkan reservasi dan perilaku saat replikasi terputus. “Replikasi database” bukan jawaban lengkap.

Periksa lokasi data yang diizinkan, kunci enkripsi, sertifikat, DNS, secret, dan layanan eksternal. Gangguan pada layanan identitas yang digunakan bersama atau rilis yang bermasalah dapat memengaruhi beberapa Region. Lebih banyak lokasi tidak menghilangkan setiap penyebab kegagalan bersama.

Hubungkan ketersediaan dengan pemulihan

HA menangani kegagalan tertentu selama operasi. Disaster recovery memulihkan layanan yang dapat digunakan beserta datanya setelah kejadian yang mengganggu. Layanan multi-region tetap memerlukan rencana pemulihan untuk penghapusan atau kerusakan data.

Dokumentasikan skenario kegagalan yang dipilih dan skenario yang risikonya diterima bisnis. Jaga keselarasan pengujian dan definisi infrastruktur saat aplikasi berubah. Lanjutkan ke RTO, RPO, dan disaster recovery.