Layanan Zonal - Batas Isolasi Kesalahan AWS

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

Layanan Zonal

Availability Zone Independence (AZI) memungkinkan AWS untuk menawarkan layanan zona, seperti Amazon EC2 dan Amazon EBS. Layanan zonal adalah layanan yang menyediakan kemampuan untuk menentukan Availability Zone mana sumber daya digunakan. Layanan ini beroperasi secara independen di setiap Availability Zone dalam suatu Wilayah, dan yang lebih penting, gagal secara independen di setiap Availability Zone juga. Ini berarti bahwa komponen layanan dalam satu Availability Zone tidak mengambil dependensi pada komponen di Availability Zone lainnya. Kita dapat melakukan ini karena layanan zonal memiliki bidang data zona. Dalam beberapa kasus, seperti dengan EC2, layanan ini juga mencakup bidang kontrol zona untuk operasi yang selaras secara zona, seperti meluncurkan instans EC2. Untuk layanan tersebut, AWS juga menyediakan endpoint pesawat kontrol regional untuk memudahkan berinteraksi dengan layanan. Bidang kontrol regional juga menyediakan fungsionalitas cakupan regional serta berfungsi sebagai lapisan agregasi dan perutean di atas bidang kontrol zona. Ini ditunjukkan pada gambar berikut.

Gambar ini menunjukkan layanan zona dengan bidang kontrol dan bidang data yang terisolasi secara zona

Layanan zona dengan bidang kontrol dan bidang data yang terisolasi secara zona

Availability Zones memberi pelanggan kemampuan untuk mengoperasikan beban kerja produksi yang lebih tersedia, toleran terhadap kesalahan, dan skalabel daripada yang mungkin dilakukan dari satu pusat data. Ketika beban kerja menggunakan beberapa Availability Zone, pelanggan akan lebih terisolasi dan terlindungi dari masalah yang berdampak pada infrastruktur fisik Availability Zone tunggal. Ini membantu pelanggan untuk membangun layanan yang berlebihan di seluruh Availability Zone dan, jika dirancang dengan benar, tetap beroperasi meskipun satu Availability Zone mengalami kegagalan. Pelanggan dapat memanfaatkan AZI untuk menciptakan beban kerja yang sangat tersedia dan tangguh. Menerapkan AZI dalam arsitektur Anda membantu Anda memulihkan dengan cepat dari kegagalan Availability Zone yang terisolasi karena sumber daya Anda dalam satu Availability Zone meminimalkan atau menghilangkan interaksi dengan sumber daya di Availability Zone lainnya. Ini membantu menghapus dependensi lintas Availability Zone yang menyederhanakan evakuasi Availability Zone. Lihat Pola Ketahanan Multi-AZ Tingkat Lanjut untuk detail selengkapnya tentang pembuatan mekanisme evakuasi Availability Zone. Selain itu, Anda dapat memanfaatkan Availability Zone lebih lanjut dengan mengikuti beberapa praktik terbaik yang sama yang AWS digunakan untuk layanannya sendiri, seperti hanya menerapkan perubahan ke Availability Zone tunggal pada satu waktu atau menghapus Availability Zone dari layanan jika perubahan di Availability Zone berjalan buruk.

Stabilitas statis juga merupakan konsep penting untuk arsitektur Multi-Availability Zone. Salah satu mode kegagalan yang harus Anda rencanakan dengan arsitektur Multi-Availability Zone adalah hilangnya Availability Zone, yang dapat mengakibatkan hilangnya kapasitas Availability Zone. Jika Anda belum menyediakan kapasitas yang cukup untuk menangani hilangnya Availability Zone, ini dapat mengakibatkan kapasitas Anda yang tersisa kewalahan oleh beban saat ini. Selain itu, Anda harus bergantung pada bidang kontrol layanan zona yang Anda gunakan untuk mengganti kapasitas yang hilang, yang bisa kurang dapat diandalkan daripada desain yang stabil secara statis. Dalam hal ini, pra-penyediaan kapasitas ekstra yang cukup dapat membantu Anda stabil secara statis terhadap hilangnya domain kesalahan, seperti Availability Zone, dengan dapat melanjutkan operasi normal tanpa perlu perubahan dinamis.

Anda dapat memilih untuk menggunakan grup penskalaan otomatis instans EC2 yang diterapkan di beberapa Availability Zone untuk menskalakan masuk dan keluar secara dinamis, berdasarkan kebutuhan beban kerja Anda. Penskalaan otomatis berfungsi dengan baik untuk perubahan bertahap dalam penggunaan yang terjadi selama beberapa menit hingga puluhan menit. Namun, meluncurkan instans EC2 baru membutuhkan waktu, terutama jika instance Anda memerlukan bootstrap (seperti menginstal agen, binari aplikasi, atau file konfigurasi). Selama waktu ini, kapasitas Anda yang tersisa bisa kewalahan oleh beban saat ini. Selain itu, penerapan instans baru melalui penskalaan otomatis bergantung pada bidang kontrol EC2. Ini menghadirkan trade-off: Agar stabil secara statis terhadap hilangnya satu Availability Zone, Anda perlu menyediakan instans EC2 yang cukup di Availability Zone lainnya untuk menangani beban yang telah digeser dari Availability Zone yang terganggu, alih-alih mengandalkan penskalaan otomatis untuk menyediakan instans baru. Namun, kapasitas ekstra pra-penyediaan dapat menimbulkan biaya tambahan.

Misalnya, selama operasi normal, anggap beban kerja Anda memerlukan enam instance untuk melayani lalu lintas pelanggan di tiga Availability Zone. Agar stabil secara statis terhadap satu kegagalan Availability Zone, Anda akan menerapkan tiga instance di setiap Availability Zone, dengan total sembilan. Jika satu instance Availability Zone gagal, Anda masih memiliki enam yang tersisa dan dapat terus melayani lalu lintas pelanggan Anda tanpa perlu menyediakan dan mengonfigurasi instance baru selama kegagalan. Mencapai stabilitas statis untuk kapasitas EC2 Anda memiliki biaya tambahan, karena, dalam hal ini, Anda menjalankan 50% instance tambahan. Tidak semua layanan di mana Anda dapat menyediakan sumber daya pra-penyediaan akan dikenakan biaya tambahan, seperti pra-penyediaan bucket S3 atau pengguna. Anda perlu mempertimbangkan setiap trade-off penerapan stabilitas statis terhadap risiko melebihi waktu pemulihan yang diinginkan untuk beban kerja Anda.

AWS Local Zones dan Outposts membawa bidang data AWS layanan tertentu lebih dekat ke pengguna akhir. Pesawat kontrol untuk layanan ini berada di Wilayah induk. Instans Local Zone atau Outposts Anda akan memiliki dependensi bidang kontrol untuk layanan zona seperti EC2 dan EBS di Availability Zone tempat Anda membuat subnet Local Zone atau Outposts. Mereka juga akan memiliki ketergantungan pada pesawat kontrol Regional untuk layanan Regional seperti Elastic Load Balancing (ELB), grup keamanan, dan pesawat kontrol Kubernetes yang dikelola Amazon Elastic Kubernetes Service (Amazon EKS) (jika Anda menggunakan EKS). Untuk informasi tambahan khusus untuk Outposts, lihat dokumentasi dan dukungan dan pemeliharaan FAQ. Menerapkan stabilitas statis saat menggunakan Local Zones atau Outposts untuk membantu meningkatkan ketahanan untuk mengontrol gangguan atau gangguan pesawat dalam konektivitas jaringan ke Wilayah induk.