Skenario 5 angka 9 (99,999%) atau lebih tinggi dengan waktu pemulihan kurang dari satu menit

Tujuan ketersediaan untuk aplikasi ini hampir tidak memerlukan waktu henti atau kehilangan data untuk waktu tertentu. Aplikasi yang dapat memiliki tujuan ketersediaan ini antara lain, aplikasi perbankan, investasi, keuangan, pemerintah, dan aplikasi penting bagi bisnis yang merupakan bisnis inti dari usaha yang menghasilkan pendapatan sangat besar. Keinginan untuk memiliki penyimpanan data yang sangat konsisten dan redundansi lengkap di semua lapisan. Kami telah memilih penyimpanan data berbasis SQL. Tetapi, dalam beberapa skenario, kami akan kesulitan untuk mencapai RPO yang sangat kecil. Jika Anda dapat mempartisi data Anda, mungkin tidak akan ada kehilangan data. Ini mungkin mengharuskan Anda untuk menambahkan latensi dan logika aplikasi untuk memastikan Anda memiliki data yang konsisten antara lokasi geografis, serta kemampuan untuk memindahkan atau menyalin data antara partisi. Melakukan partisi ini mungkin akan lebih mudah jika Anda menggunakan basis data NoSQL.

Kami dapat meningkatkan ketersediaan lebih lanjut dengan menggunakan pendekatan Active-Active di beberapa Wilayah AWS. Beban kerja ini akan di-deploy di semua Wilayah yang diinginkan yang stabil secara statistik di seluruh wilayah (sehingga wilayah yang tersisa dapat menangani beban dengan kehilangan satu wilayah). Satu perutean mengarahkan lalu lintas ke lokasi geografis dengan kondisi bagus dan otomatis mengubah tujuan ketika lokasinya tidak berkondisi bagus, serta menghentikan sementara lapisan replikasi data. Amazon Route 53 menawarkan pemeriksaan kondisi dengan interval 10 detik serta menawarkan TTL pada set catatan Anda hingga sesingkat satu detik.

Pantau sumber daya

Sama seperti skenario 3½ angka 9, ditambah peringatan ketika Wilayah dideteksi tidak berkondisi bagus, dan lalu lintas dirutekan menjauh darinya.

Beradaptasi dengan perubahan dalam permintaan

Sama seperti skenario 3½ angka 9.

Implementasikan perubahan

Alur deployment akan memiliki kumpulan pengujian penuh, termasuk uji performa, beban, dan injeksi kegagalan. Kami akan melakukan deploy pembaruan menggunakan canary atau deployment blue/green ke satu zona isolasi setiap kali, di satu Wilayah sebelum memulai di yang lain. Selama deployment, versi lama kasih akan dijalankan pada instans untuk memfasilitasi pengembalian lebih cepat ke versi sebelumnya. Deployment bersifat sepenuhnya otomatis, termasuk pengembalian ke yang sebelumnya jika KPI menunjukkan ada masalah. Pemantauan akan mencakup metrik kesuksesan serta memberikan peringatan ketika masalah timbul.

Akan ada runbook untuk pelacakan performa dan persyaratan pelaporan yang ketat. Jika operasi yang sukses memiliki kecenderungan untuk gagal agar memenuhi tujuan ketersediaan atau performa, playbook akan digunakan untuk menetapkan apa yang menyebabkan kecenderungan tersebut. Akan ada playbook untuk insiden keamanan dan mode kegagalan yang tidak ditemukan. Juga akan ada playbook untuk menetapkan akar masalah dari kegagalan.

Tim yang membangun situs web juga mengoperasikan situs web. Tim tersebut akan mengidentifikasi koreksi kesalahan setiap kegagalan yang tidak terduga dan memprioritaskan deployment perbaikan setelah perbaikan diimplementasikan. Kami juga akan melibatkan AWS Support untuk Manajemen Peristiwa Infrastruktur.

Cadangkan data

Sama seperti skenario 3½ angka 9.

Rancang untuk ketangguhan

Aplikasi harus dibangun menggunakan pola ketangguhan perangkat lunak/aplikasi. Mungkin saja banyak lapisan perutean lain dapat diperlukan untuk mengimplementasikan ketersediaan yang dibutuhkan. Kompleksitas implementasi tambahan ini tidak boleh diremehkan. Aplikasi akan diimplementasikan dalam zona isolasi kesalahan deployment, dan dipartisi dan di-deploy sedemikian sehingga bahkan peristiwa di semua Wilayah tidak akan memengaruhi semua pelanggan.

Uji ketangguhan

Kami akan memvalidasi arsitektur melalui aktivitas game menggunakan runbook untuk memastikan kami dapat menjalankan tugas dan tidak menyimpang dari prosedur.

Rencanakan pemulihan bencana (DR)

Deployment Active-Active multi-wilayah dengan data dan infrastruktur beban kerja lengkap di beberapa wilayah. Menggunakan strategi lokal baca, global tulis, satu wilayah merupakan basis data utama untuk semua penulisan, dan data direplikasi untuk pembacaan ke wilayah lain. Jika wilayah DB utama gagal, DB baru harus digalakkan. Lokal baca, global tulis memiliki pengguna yang ditetapkan ke wilayah beranda di mana penulisan DB ditangani. Ini memungkinkan pengguna membaca atau menulis dari wilayah mana pun, tetapi memerlukan logika kompleks untuk mengelola potensi konflik data di seluruh penulisan di wilayah yang berbeda.

Ketika wilayah dideteksi tidak berkondisi bagus, lapisan perutean otomatis merutekan lalu lintas ke wilayah tersisa dengan kondisi bagus. Tidak diperlukan intervensi manual.

Penyimpanan data harus direplikasi antara Wilayah dengan cara yang dapat mengatasi potensi konflik. Alat dan proses otomatis akan harus dibuat untuk menyalin atau memindahkan data antara partisi karena alasan latensi dan untuk menyeimbangkan permintaan atau jumlah data dalam setiap partisi. Perbaikan resolusi konflik data juga akan memerlukan runbook operasional tambahan.

Tujuan desain ketersediaan

Kami berasumsi bahwa investasi besar dilakukan untuk mengotomatiskan semua pemulihan, dan pemulihan dapat diselesaikan dalam satu menit. Kami berasumsi tidak ada pemulihan yang dipicu secara manual, tetapi hingga satu tindakan pemulihan otomatis per kuartal. Ini menyiratkan empat menit per tahun untuk pemulihan. Kami berasumsi bahwa aplikasinya online terus selama pembaruan. Berdasarkan ini, tujuan desain ketersediaan 99,999%.

Ringkasan

Topik	Implementasi
Pantau sumber daya	Pemeriksaan kondisi di semua lapisan, termasuk kondisi DNS di tingkat Wilayah AWS, dan di KPI; peringatan dikirimkan ketika alarm yang dikonfigurasi terpicu; yang memberikan peringatan tentang semua kegagalan. Rapat operasional yang sangat teliti untuk mendeteksi tren dan mendesain tujuan dengan sukses.
Beradaptasi dengan perubahan dalam permintaan	ELB untuk tingkat aplikasi penskalaan otomatis dan web; penyimpanan penskalaan otomatis dan replika baca di beberapa zona di wilayah aktif dan pasif untuk Aurora RDS. Data dan infrastruktur disinkronkan antara Wilayah AWS untuk stabilitas statis.
Implementasikan perubahan	Deployment otomatis lewat canary atau pengembalian ke sebelumnya yang otomatis dan blue/green ketika KPI atau peringatan menunjukkan masalah yang tak terdeteksi dalam aplikasi, deployment dibuat ke satu zona isolasi dalam satu Wilayah AWS setiap kali.
Cadangkan data	Cadangan otomatis di setiap Wilayah AWS lewat RDS untuk memenuhi restorasi otomatis dan RPO yang dipraktikkan secara teratur dalam aktivitas game. Data S3 dan RDS Aurora secara otomatis dan asinkron direplikasi dari wilayah aktif ke wilayah pasif.
Rancang untuk ketangguhan	Zona isolasi kegagalan yang diimplementasikan untuk aplikasi; penskalaan otomatis untuk memberikan tingkat aplikasi dan web dengan pemulihan mandiri; RDS bersifat Multi-AZ; failover regional diotomatiskan.
Uji ketangguhan	Pengujian kesalahan zona isolasi dan komponen sudah dalam alur dan dipraktikkan dengan staf operasional secara teratur dalam aktivitas game; ada playbook untuk mendiagnosis masalah yang tak diketahui; dan ada proses Analisis Akar Masalah dengan jalur komunikasi untuk apa masalahnya, dan bagaimana masalah dikoreksi atau dicegah. Koreksi RCA diprioritaskan melebihi rilis fitur untuk deployment dan implementasi dengan segera.
Rencanakan pemulihan bencana (DR)	Active-Active di-deploy di minimal dua wilayah. Infrastruktur diskalakan sepenuhnya dan stabil secara statistik di seluruh wilayah. Data dipartisi dan disinkronkan di seluruh wilayah. Cadangan terenkripsi lewat RDS. Kegagalan wilayah dipraktikkan dalam aktivitas game, dan dikoordinasikan dengan AWS. Selama restorasi, basis data utama baru mungkin harus digalakkan.