Multi-Region fundamental 3: Memahami dependensi beban kerja Anda

Beban kerja tertentu mungkin memiliki beberapa dependensi di Wilayah, seperti Layanan AWS digunakan, dependensi internal, dependensi pihak ketiga, dependensi jaringan, sertifikat, kunci, rahasia, dan parameter. Untuk memastikan pengoperasian beban kerja selama skenario kegagalan, seharusnya tidak ada ketergantungan antara Wilayah utama dan Wilayah siaga; masing-masing harus dapat beroperasi secara independen dari yang lain. Untuk mencapai hal ini, teliti semua dependensi dalam beban kerja untuk memastikan bahwa mereka tersedia di setiap Wilayah. Hal ini diperlukan karena kegagalan di Wilayah primer seharusnya tidak mempengaruhi Wilayah siaga. Selain itu, Anda harus memahami bagaimana beban kerja beroperasi ketika ketergantungan berada dalam keadaan terdegradasi atau sama sekali tidak tersedia, sehingga Anda dapat merekayasa solusi untuk menangani ini dengan tepat.

3.a: Layanan AWS

Saat Anda merancang arsitektur Multi-wilayah, penting untuk memahami apa Layanan AWS yang akan digunakan, fitur Multi-wilayah dari layanan tersebut, dan solusi apa yang Anda perlukan untuk merekayasa untuk mencapai tujuan Multi-wilayah. Misalnya, Amazon Aurora dan Amazon DynamoDB dapat mereplikasi data secara asinkron ke Wilayah siaga. Semua Layanan AWS dependensi harus tersedia di semua Wilayah tempat beban kerja akan dijalankan. Untuk mengonfirmasi bahwa layanan yang Anda gunakan tersedia di Wilayah yang diinginkan, tinjau daftar Layanan AWS berdasarkan Wilayah.

3.b: Ketergantungan internal dan pihak ketiga

Pastikan bahwa setiap dependensi internal beban kerja tersedia di Wilayah tempat mereka beroperasi. Misalnya, jika beban kerja terdiri dari banyak layanan mikro, identifikasi semua layanan mikro yang terdiri dari kemampuan bisnis dan verifikasi bahwa semua layanan mikro tersebut digunakan di setiap Wilayah tempat beban kerja beroperasi. Atau, tentukan strategi untuk menangani layanan mikro dengan anggun yang menjadi tidak tersedia.

Panggilan Lintas Wilayah antara layanan mikro dalam beban kerja tidak disarankan, dan isolasi Regional harus dipertahankan. Ini karena membuat dependensi lintas wilayah menambah risiko kegagalan yang berkorelasi, yang mengimbangi manfaat implementasi Regional yang terisolasi dari beban kerja. Dependensi lokal mungkin menjadi bagian dari beban kerja juga, jadi penting untuk memahami bagaimana karakteristik integrasi ini dapat berubah jika Wilayah utama berubah. Misalnya, jika Wilayah siaga terletak lebih jauh dari lingkungan lokal, peningkatan latensi mungkin berdampak negatif.

Memahami solusi perangkat lunak sebagai layanan (SaaS), kit pengembangan perangkat lunak (SDKs), dan dependensi produk pihak ketiga lainnya, dan mampu menjalankan skenario di mana dependensi ini terdegradasi atau tidak tersedia akan memberikan lebih banyak wawasan tentang bagaimana rantai sistem beroperasi dan berperilaku di bawah mode kegagalan yang berbeda. Dependensi ini dapat berada dalam kode aplikasi Anda, seperti mengelola rahasia secara eksternal dengan menggunakan AWS Secrets Manager, atau mereka dapat melibatkan solusi vault pihak ketiga (seperti HashiCorp), atau sistem otentikasi yang memiliki ketergantungan untuk login federasi. AWS IAM Identity Center

Memiliki redundansi dalam hal dependensi dapat meningkatkan ketahanan. Jika solusi SaaS atau ketergantungan pihak ketiga menggunakan primer Wilayah AWS yang sama dengan beban kerja, bekerjalah dengan vendor untuk menentukan apakah postur ketahanan mereka sesuai dengan kebutuhan Anda untuk beban kerja.

Selain itu, waspadai nasib bersama antara beban kerja dan dependensinya, seperti aplikasi pihak ketiga. Jika dependensi tidak tersedia di (atau dari) Wilayah sekunder setelah failover, beban kerja mungkin tidak pulih sepenuhnya.

3.c: Mekanisme failover

DNS biasanya digunakan sebagai mekanisme failover untuk mengalihkan lalu lintas dari Wilayah utama ke Wilayah siaga. Tinjau dan teliti secara kritis semua dependensi yang dibutuhkan mekanisme failover. Misalnya, jika beban kerja Anda menggunakan Amazon Route 53, memahami bahwa bidang kontrol di-host us-east-1 berarti Anda mengambil ketergantungan pada bidang kontrol di Wilayah tertentu. Ini tidak direkomendasikan sebagai bagian dari mekanisme failover jika Wilayah primer juga us-east-1 karena menciptakan satu titik kegagalan. Jika Anda menggunakan mekanisme failover lain, Anda harus memiliki pemahaman mendalam tentang skenario di mana failover tidak akan berfungsi seperti yang diharapkan, dan kemudian merencanakan kemungkinan atau mengembangkan mekanisme baru jika diperlukan. Tinjau posting blog Membuat Mekanisme Pemulihan Bencana Menggunakan Amazon Route 53 untuk mempelajari tentang pendekatan yang dapat Anda gunakan untuk gagal dengan sukses.

Sebagaimana dibahas di bagian sebelumnya, semua layanan mikro yang merupakan bagian dari kemampuan bisnis harus tersedia di setiap Wilayah di mana beban kerja digunakan. Sebagai bagian dari strategi failover, semua layanan mikro yang merupakan bagian dari kemampuan bisnis harus gagal bersama-sama untuk menghilangkan kemungkinan panggilan lintas wilayah. Atau, jika layanan mikro gagal secara independen, ada potensi perilaku yang tidak diinginkan seperti layanan mikro yang berpotensi melakukan panggilan lintas wilayah. Ini memperkenalkan latensi dan dapat menyebabkan beban kerja menjadi tidak tersedia selama batas waktu klien.

3.d: Ketergantungan konfigurasi

Sertifikat, kunci, rahasia, Amazon Machine Images (AMIs), gambar kontainer, dan parameter adalah bagian dari analisis dependensi yang diperlukan saat merancang untuk arsitektur Multi-region. Jika memungkinkan, yang terbaik adalah melokalkan komponen-komponen ini di setiap Wilayah sehingga mereka tidak memiliki nasib bersama antar Wilayah untuk dependensi ini. Misalnya, Anda harus memvariasikan tanggal kedaluwarsa sertifikat untuk mencegah skenario di mana sertifikat kedaluwarsa (dengan alarm disetel ke “beri tahu sebelumnya”) berdampak pada beberapa Wilayah.

Kunci enkripsi dan rahasia harus spesifik Wilayah juga. Dengan begitu, jika ada kesalahan dalam rotasi kunci atau rahasia, dampaknya terbatas pada Wilayah tertentu.

Terakhir, parameter beban kerja apa pun harus disimpan secara lokal agar beban kerja dapat diambil di Wilayah tertentu.

Panduan utama

• Arsitektur multi-wilayah mendapat manfaat dari pemisahan fisik dan logis antar Wilayah. Memperkenalkan dependensi lintas wilayah pada lapisan aplikasi merusak manfaat ini. Hindari ketergantungan seperti itu.

• Kontrol failover harus berfungsi tanpa dependensi pada Wilayah utama.

• Failover harus dikoordinasikan di seluruh perjalanan pengguna untuk menghapus kemungkinan peningkatan latensi dan ketergantungan panggilan lintas wilayah.