Multi-Region fundamental 4: Kesiapan operasional

Mengoperasikan beban kerja Multi-wilayah adalah tugas kompleks yang disertai dengan tantangan operasional yang khusus untuk arsitektur Multi-wilayah. Ini termasuk Akun AWS manajemen, proses penerapan retooled, menciptakan strategi observabilitas Multi-wilayah, membuat dan menguji proses pemulihan, dan kemudian mengelola biaya. Tinjauan Kesiapan Operasional (ORR) dapat membantu tim menyiapkan beban kerja untuk produksi, baik itu berjalan di satu Wilayah atau di beberapa Wilayah.

4.a: manajemen Akun AWS

Untuk menerapkan beban kerja di seluruh wilayah Wilayah AWS, pastikan ada paritas di semua Layanan AWS kuota dalam akun di seluruh Wilayah. Pertama, identifikasi semua Layanan AWS yang merupakan bagian dari arsitektur, lihat penggunaan yang direncanakan di Wilayah siaga, dan kemudian bandingkan penggunaan yang direncanakan dengan penggunaan saat ini. Dalam beberapa kasus, jika Wilayah siaga belum pernah digunakan sebelumnya, Anda dapat mereferensikan kuota layanan default untuk memahami titik awal. Kemudian, di seluruh layanan yang akan digunakan, mintalah peningkatan kuota dengan menggunakan konsol Service Quotas (diperlukan login) atau. APIs

Konfigurasikan peran AWS Identity and Access Management (IAM) di setiap Wilayah untuk memberikan operator, perkakas otomatisasi, dan izin Layanan AWS yang sesuai untuk sumber daya dalam Wilayah siaga. Untuk mencapai isolasi Regional untuk arsitektur Multi-region, isolasi peran berdasarkan Wilayah. Pastikan izin sudah ada sebelum ditayangkan dengan Wilayah siaga.

4.b: Praktik penyebaran

Kemampuan Multi-Region dapat mempersulit penerapan beban kerja ke beberapa Wilayah. Anda perlu memastikan bahwa Anda menyebarkan ke satu Wilayah pada satu waktu. Misalnya, jika Anda menggunakan pendekatan aktif-pasif, Anda harus menerapkan ke Wilayah utama terlebih dahulu dan kemudian ke Wilayah siaga. AWS CloudFormationmembantu Anda menyebarkan infrastruktur ke satu atau beberapa Wilayah, dan dapat disesuaikan sesuai dengan kebutuhan Anda. AWS CodePipelinemembantu Anda membangun pipeline berkelanjutanintegration/continuous delivery (CI/CD), yang memiliki tindakan Lintas wilayah yang memungkinkan penerapan ke Wilayah yang berbeda dari Wilayah tempat pipeline berada. Ini, dikombinasikan dengan strategi penerapan yang kuat seperti biru/hijau, memungkinkan penerapan downtime minimum hingga nol.

Namun, penyebaran kemampuan stateful dapat menjadi lebih kompleks ketika status aplikasi atau data tidak dieksternalisasi ke penyimpanan persisten. Dalam situasi ini, sesuaikan proses penyebaran dengan hati-hati agar sesuai dengan kebutuhan Anda. Rancang pipeline penyebaran dan proses untuk diterapkan ke satu Wilayah pada satu waktu alih-alih menyebarkan ke beberapa Wilayah secara bersamaan. Ini mengurangi kemungkinan kegagalan yang berkorelasi antar Daerah. Untuk mempelajari teknik yang digunakan Amazon untuk mengotomatiskan penerapan perangkat lunak, lihat artikel AWS Builders' Library Mengotomatiskan penerapan yang aman dan hands-off.

4.c: Observabilitas

Ketika Anda merancang untuk Multi-region, pertimbangkan bagaimana Anda akan memantau kesehatan semua komponen di setiap Wilayah untuk mendapatkan pandangan holistik tentang kesehatan Regional. Ini dapat mencakup metrik pemantauan untuk kelambatan replikasi, yang bukan merupakan pertimbangan untuk beban kerja wilayah Tunggal.

Saat Anda membangun arsitektur Multi-wilayah, pertimbangkan untuk mengamati kinerja beban kerja dari Wilayah siaga juga. Ini termasuk pemeriksaan kesehatan dan kenari (pengujian sintetis) yang berjalan dari Wilayah siaga untuk memberikan pandangan luar tentang kesehatan Wilayah primer. Selain itu, Anda dapat menggunakan Amazon CloudWatch Internet Monitor untuk memahami keadaan jaringan eksternal dan kinerja beban kerja Anda dari sudut pandang pengguna akhir. Wilayah utama harus memiliki observabilitas yang sama untuk memantau Wilayah siaga.

Burung kenari dari Wilayah siaga harus memantau metrik pengalaman pelanggan untuk menentukan kesehatan beban kerja secara keseluruhan. Ini diperlukan karena jika ada masalah di Wilayah primer, observabilitas di primer dapat terganggu dan akan memengaruhi kemampuan Anda untuk menilai kesehatan beban kerja.

Dalam hal ini, mengamati di luar Wilayah itu dapat memberikan wawasan. Metrik ini harus digulung menjadi dasbor yang tersedia di setiap Wilayah dan alarm yang dibuat di setiap Wilayah. Karena CloudWatchmerupakan layanan Regional, memiliki alarm di kedua Wilayah merupakan persyaratan. Data pemantauan ini akan digunakan untuk membuat panggilan untuk gagal dari primer ke Region siaga.

4.d: Proses dan prosedur

Waktu terbaik untuk menjawab pertanyaan, “Kapan saya harus gagal?” Jauh sebelum Anda membutuhkannya. Tentukan rencana pemulihan yang mencakup orang, proses, dan teknologi jauh sebelum suatu masalah, dan uji secara teratur. Tentukan kerangka keputusan pemulihan. Jika ada proses pemulihan yang dipraktikkan dengan baik dan waktu untuk pemulihan dipahami dengan baik, Anda dapat memilih untuk memulai proses pemulihan dengan menggunakan failover yang memenuhi target RTO. Titik waktu ini bisa segera setelah masalah dengan aplikasi di Wilayah utama diidentifikasi, atau bisa lebih jauh menjadi peristiwa ketika opsi pemulihan dalam aplikasi di Wilayah telah habis.

Tindakan failover itu sendiri harus 100 persen otomatis, tetapi keputusan untuk mengaktifkan failover harus dibuat oleh manusia — biasanya sejumlah kecil individu yang telah ditentukan dalam organisasi. Orang-orang ini harus mempertimbangkan kehilangan data dan informasi tentang acara tersebut. Juga, kriteria untuk failover perlu didefinisikan dengan jelas dan dipahami secara global dalam organisasi. Untuk menentukan dan menyelesaikan proses ini, Anda dapat menggunakan AWS Systems Manager runbook, yang memungkinkan end-to-end otomatisasi lengkap dan memastikan konsistensi proses yang berjalan selama pengujian dan failover.

Runbook ini harus tersedia di Wilayah primer dan siaga untuk memulai proses failover atau failback. Ketika otomatisasi ini ada, tentukan dan ikuti irama pengujian reguler. Ini memastikan bahwa ketika ada peristiwa aktual, respons mengikuti proses yang terdefinisi dengan baik dan dipraktikkan yang dipercaya oleh organisasi. Penting juga untuk mempertimbangkan toleransi yang ditetapkan untuk proses rekonsiliasi data. Konfirmasikan bahwa proses yang diusulkan memenuhi persyaratan RPO/RTO yang ditetapkan.

4.e: Pengujian

Memiliki pendekatan pemulihan yang belum teruji sama dengan tidak memiliki pendekatan pemulihan. Tingkat pengujian dasar adalah menjalankan prosedur pemulihan untuk mengganti Wilayah operasi untuk aplikasi Anda. Terkadang ini disebut sebagai pendekatan rotasi aplikasi. Kami menyarankan Anda membangun kemampuan untuk mengubah Wilayah ke postur operasi normal Anda; Namun, tes ini saja tidak cukup.

Pengujian ketahanan juga penting untuk memvalidasi pendekatan pemulihan aplikasi. Ini melibatkan menyuntikkan skenario kegagalan tertentu, memahami bagaimana aplikasi dan proses pemulihan Anda bereaksi, dan kemudian menerapkan mitigasi apa pun yang diperlukan jika pengujian tidak berjalan sesuai rencana. Menguji prosedur pemulihan Anda tanpa adanya kesalahan tidak akan memberi tahu Anda bagaimana aplikasi Anda berperilaku secara keseluruhan ketika kesalahan terjadi. Anda harus mengembangkan rencana untuk menguji pemulihan Anda terhadap skenario kegagalan yang diharapkan. AWS Fault Injection Servicemenyediakan daftar skenario yang terus bertambah untuk membantu Anda memulai.

Ini sangat penting untuk aplikasi ketersediaan tinggi, di mana pengujian yang ketat diperlukan untuk memastikan bahwa target kelangsungan bisnis terpenuhi. Menguji kemampuan pemulihan secara proaktif mengurangi risiko kegagalan dalam produksi, yang membangun keyakinan bahwa aplikasi dapat mencapai waktu pemulihan terbatas yang diinginkan. Pengujian rutin juga membangun keahlian operasional, yang memungkinkan tim pulih dengan cepat dan andal dari pemadaman saat terjadi. Melatih elemen manusia, atau proses, dari pendekatan pemulihan Anda sama pentingnya dengan aspek teknis.

4.f: Biaya dan kompleksitas

Implikasi biaya dari arsitektur Multi-region didorong oleh penggunaan infrastruktur yang lebih tinggi, overhead operasional, dan waktu sumber daya. Seperti disebutkan sebelumnya, biaya infrastruktur di Wilayah siaga mirip dengan biaya infrastruktur di Wilayah primer saat pra-penyediaan, sehingga menggandakan total biaya Anda. Kapasitas penyediaan sehingga cukup untuk operasi sehari-hari tetapi masih memiliki kapasitas penyangga yang cukup untuk mentolerir lonjakan permintaan. Kemudian konfigurasikan batas yang sama di setiap Wilayah.

Selain itu, jika Anda mengadopsi arsitektur aktif-aktif, Anda mungkin harus membuat perubahan tingkat aplikasi untuk menjalankan aplikasi Anda dengan sukses dalam arsitektur Multi-region. Perubahan ini dapat memakan waktu dan intensif sumber daya untuk merancang dan mengoperasikan. Minimal, organisasi perlu meluangkan waktu untuk memahami ketergantungan teknis dan bisnis di setiap Wilayah, dan merancang proses failover dan failback.

Tim juga harus melalui latihan failover dan failback normal untuk merasa nyaman dengan runbook yang akan digunakan selama acara. Meskipun latihan ini sangat penting untuk mendapatkan hasil yang diharapkan dari investasi Multi-wilayah, mereka mewakili biaya peluang, dan mengambil waktu dan sumber daya dari kegiatan lain.

4.g: Strategi failover Multi-wilayah Organisasi

Wilayah AWS memberikan batas isolasi kesalahan yang mencegah kegagalan berkorelasi dan menahan dampak dari Layanan AWS gangguan, ketika terjadi, ke satu Wilayah. Anda dapat menggunakan batas kesalahan ini untuk membangun aplikasi Multi-wilayah yang terdiri dari replika independen yang terisolasi kesalahan di setiap Wilayah untuk membatasi skenario nasib bersama. Ini memungkinkan Anda untuk membangun aplikasi Multi-wilayah dan menggunakan berbagai pendekatan—mulai dari pencadangan dan pemulihan, lampu pilot, hingga aktif-aktif—untuk mengimplementasikan arsitektur Multi-wilayah Anda. Namun, aplikasi biasanya tidak beroperasi secara terpisah, jadi pertimbangkan komponen yang akan Anda gunakan dan dependensinya sebagai bagian dari strategi failover Anda. Umumnya, beberapa aplikasi bekerja sama untuk mendukung cerita pengguna, yang merupakan kemampuan khusus yang ditawarkan kepada pengguna akhir, seperti memposting gambar dan keterangan di aplikasi media sosial atau memeriksa di situs e-commerce. Karena itu, Anda harus mengembangkan strategi failover multi-wilayah organisasi yang menyediakan koordinasi dan konsistensi yang diperlukan untuk membuat pendekatan Anda berhasil.

Ada empat strategi tingkat tinggi yang dapat dipilih organisasi untuk memandu pendekatan Multi-wilayah. Ini terdaftar dari yang paling terperinci hingga pendekatan terluas:

• Failover tingkat komponen

• Failover aplikasi individual

• Failover grafik ketergantungan

• Seluruh failover portofolio aplikasi

Setiap strategi memiliki trade-off dan mengatasi tantangan yang berbeda, termasuk fleksibilitas pengambilan keputusan failover, kemampuan untuk menguji kombinasi failover, keberadaan perilaku modal, dan investasi organisasi dalam perencanaan dan implementasi. Untuk menyelami setiap strategi secara lebih rinci, lihat posting AWS blog Membuat strategi failover Multi-wilayah organisasi.

Panduan utama

• Tinjau semua Layanan AWS kuota untuk memastikan bahwa kuota tersebut berada dalam paritas di semua Wilayah di mana beban kerja akan beroperasi.

• Proses penyebaran harus menargetkan satu Wilayah pada satu waktu alih-alih melibatkan beberapa Wilayah secara bersamaan.

• Metrik tambahan seperti replikasi lag khusus untuk skenario Multi-wilayah dan harus dipantau.

• Memperluas pemantauan untuk beban kerja di luar Wilayah utama. Pantau metrik pengalaman pelanggan untuk setiap Wilayah, dan ukur data ini dari luar setiap Wilayah tempat beban kerja berjalan.

• Uji failover dan failback secara teratur. Terapkan satu runbook untuk proses failover dan failback dan gunakan untuk pengujian dan acara langsung. Runbook untuk pengujian dan acara langsung tidak boleh berbeda.

• Memahami trade-off dari strategi failover. Menerapkan grafik ketergantungan atau seluruh strategi portofolio aplikasi.