Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Multi-Region fundamental 3: Memahami dependensi beban kerja Anda

Beban kerja tertentu mungkin memiliki beberapa dependensi di Wilayah, seperti AWS layanan yang digunakan, dependensi internal, dependensi pihak ketiga, dependensi jaringan, sertifikat, kunci, rahasia, dan parameter. Untuk memastikan pengoperasian beban kerja selama skenario kegagalan, seharusnya tidak ada dependensi antara Wilayah primer dan Wilayah siaga; masing-masing harus dapat beroperasi secara independen satu sama lain. Untuk mencapai hal ini, semua dependensi dalam beban kerja harus diteliti untuk memastikan mereka tersedia di setiap Wilayah. Hal ini diperlukan karena kegagalan di Wilayah primer seharusnya tidak berdampak pada Wilayah siaga. Selain itu, pengetahuan tentang bagaimana beban kerja beroperasi ketika ketergantungan berada dalam keadaan terdegradasi atau sama sekali tidak tersedia sangat penting, sehingga solusi dapat direkayasa untuk menangani hal ini dengan tepat.

3a: layanan AWS 

Saat merancang arsitektur Multi-wilayah, pemahaman tentang AWS layanan spesifik yang akan digunakan diperlukan. Aspek pertama adalah memahami fitur apa yang dimiliki layanan untuk mengaktifkan Multi-wilayah, dan apakah solusi harus direkayasa untuk mencapai tujuan Multi-wilayah. Misalnya, dengan Amazon Aurora dan Amazon DynamoDB, ada fitur untuk mereplikasi data secara asinkron ke Wilayah siaga. Dependensi AWS layanan apa pun harus tersedia di semua Wilayah tempat beban kerja akan dijalankan. Untuk memastikan layanan yang akan digunakan tersedia di Wilayah yang diinginkan, tinjau Daftar Layanan Wilayah AWS al. 

3b: Dependensi internal dan pihak ketiga

Untuk setiap dependensi internal yang dimiliki beban kerja, pastikan itu tersedia dari Wilayah tempat beban kerja akan beroperasi. Misalnya, jika beban kerja terdiri dari banyak layanan mikro, berpengetahuan tentang semua layanan mikro yang terdiri dari kemampuan bisnis. Dari sana, pastikan bahwa semua layanan mikro tersebut dikerahkan di setiap Wilayah tempat beban kerja akan beroperasi.

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 meniadakan manfaat yang Anda coba capai dengan implementasi beban kerja Regional yang terisolasi. Dependensi lokal mungkin menjadi bagian dari beban kerja juga, jadi memahami bagaimana karakteristik integrasi ini dapat berubah jika Wilayah utama ingin berubah sangat penting. Misalnya, jika Wilayah siaga terletak lebih jauh dari lingkungan lokal, peningkatan latensi akan berdampak negatif.

Memahami solusi Perangkat Lunak sebagai Layanan (SaaS), kit pengembangan perangkat lunak (SDK), dan dependensi produk pihak ketiga lainnya, dan dapat 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 bisa berada dalam kode aplikasi dari bagaimana rahasia dikelola secara eksternal menggunakan AWS Secrets Manager, atau solusi vault pihak ketiga (seperti Hashicorp), hingga sistem otentikasi yang memiliki ketergantungan pada IAM Identity Center untuk login federasi.

Memiliki redundansi dalam hal dependensi dapat membantu meningkatkan ketahanan. Ada juga kemungkinan bahwa solusi SaaS atau ketergantungan pihak ketiga menggunakan primer yang sama dengan beban kerjaWilayah AWS. Jika ini masalahnya, Anda harus bekerja dengan vendor untuk menentukan apakah postur ketahanan mereka sesuai dengan persyaratan 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.

3c: Mekanisme failover

Domain Name System (DNS) biasanya digunakan sebagai mekanisme failover untuk mengalihkan lalu lintas dari Region utama ke Region standby. 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 di US-East-1 berarti Anda mengambil dependensi pada bidang kontrol di Wilayah tertentu. Ini tidak direkomendasikan sebagai bagian dari mekanisme failover jika Wilayah utama adalah AS-Timur-1 juga. Jika mekanisme failover lain digunakan, pemahaman mendalam tentang skenario apa pun di mana ia tidak akan beroperasi seperti yang diharapkan diperlukan. Setelah pemahaman ini terbentuk, rencanakan kontingensi atau kembangkan mekanisme baru jika diperlukan. Tinjau Membuat Mekanisme Pemulihan Bencana Menggunakan Amazon Route 53 untuk mempelajari pendekatan yang dapat Anda gunakan untuk failover dengan sukses.

Sebagaimana dibahas di bagian ketergantungan internal, semua layanan mikro yang merupakan bagian dari kemampuan bisnis harus tersedia di setiap Wilayah di mana beban kerja digunakan. Sebagai bagian dari strategi failover, kemampuan bisnis perlu gagal bersama untuk menghilangkan kemungkinan panggilan lintas wilayah. Atau, jika layanan mikro gagal secara independen, ini memperkenalkan potensi perilaku yang tidak diinginkan di mana layanan mikro berpotensi melakukan panggilan lintas wilayah, yang memperkenalkan latensi dan dapat menyebabkan beban kerja tidak tersedia jika terjadi batas waktu klien.

3d: Ketergantungan konfigurasi

Sertifikat, kunci, rahasia, dan parameter adalah bagian dari analisis ketergantungan yang diperlukan saat merancang untuk 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. Untuk sertifikat, kedaluwarsa harus bervariasi di antara mereka, dan jika mungkin, di setiap Wilayah, untuk menghindari skenario ketika sertifikat kedaluwarsa (dengan alarm diatur untuk memberitahukan 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