REL10-BP01 Menyebarkan beban kerja ke beberapa lokasi - AWS Kerangka Well-Architected

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

REL10-BP01 Menyebarkan beban kerja ke beberapa lokasi

Distribusikan sumber daya dan data beban kerja ke beberapa Zona Ketersediaan atau, jika diperlukan, ke beberapa Wilayah AWS. Lokasi tersebut dapat beragam sesuai kebutuhan.

Salah satu prinsip dasar untuk desain layanan AWS adalah menghindari titik tunggal kegagalan dalam infrastruktur fisik yang mendasarinya. Hal ini memotivasi kami untuk membangun sistem dan perangkat lunak yang menggunakan beberapa Zona Ketersediaan dan tahan terhadap kegagalan yang terjadi di satu zona. Dengan cara yang serupa, sistem dibangun agar tahan terhadap kegagalan yang terjadi di satu simpul komputasi, satu volume penyimpanan, atau satu instans basis data. Saat membangun sistem yang bergantung pada komponen yang berlebihan, penting untuk memastikan bahwa komponen beroperasi secara independen, dan dalam kasus, secara mandiri. Wilayah AWS Manfaat yang diperoleh dengan melakukan kalkulasi ketersediaan teoretis dengan komponen redundan hanya valid jika dapat dibuktikan kebenarannya.

Zona Ketersediaan (AZs)

Wilayah AWS terdiri dari beberapa Availability Zone yang dirancang untuk independen satu sama lain. Setiap Zona Ketersediaan dipisahkan oleh jarak fisik yang cukup dari zona lain untuk menghindari skenario kegagalan terkait yang disebabkan oleh bahaya-bahaya lingkungan seperti kebakaran, banjir, dan tornado. Setiap Zona Ketersediaan juga memiliki infrastruktur fisik yang independen: koneksi khusus ke daya utilitas, sumber daya cadangan mandiri, layanan mekanis independen, dan konektivitas jaringan independen di dalam dan di luar Zona Ketersediaan. Desain ini membatasi kesalahan yang terjadi dalam salah satu sistem agar hanya berdampak pada satu AZ saja. Meskipun terpisah secara geografis, Zona Ketersediaan berada di wilayah yang sama yang akan memungkinkan jaringan mempunyai latensi rendah dan throughput tinggi. Seluruh Wilayah AWS (di semua Availability Zone, yang terdiri dari beberapa pusat data yang independen secara fisik) dapat diperlakukan sebagai target penerapan logis tunggal untuk beban kerja Anda, termasuk kemampuan untuk mereplikasi data secara sinkron (misalnya, antar database). Hal ini memungkinkan Anda untuk menggunakan Zona Ketersediaan dalam konfigurasi aktif/aktif atau aktif/siaga.

Zona Ketersediaan bersifat independen, dan oleh karena itu ketersediaan beban kerja akan meningkat saat beban kerja dirancang untuk menggunakan beberapa zona. Beberapa AWS layanan (termasuk pesawat data EC2 instans Amazon) digunakan sebagai layanan zona ketat di mana mereka telah berbagi nasib dengan Availability Zone tempat mereka berada. EC2Contoh Amazon di sisi lain tidak AZs akan terpengaruh dan terus berfungsi. Dengan cara yang serupa, jika terjadi kesalahan di Zona Ketersediaan yang menyebabkan basis data Amazon Aurora gagal, instans Aurora replika baca di AZ yang tidak terdampak dapat dipindahkan ke AZ utama secara otomatis. Sebaliknya, layanan AWS regional seperti Amazon DynamoDB secara internal menggunakan beberapa Zona Ketersediaan dalam konfigurasi aktif/aktif guna mencapai tujuan desain ketersediaan untuk layanan tersebut, tanpa perlu mengonfigurasi penempatan AZ.

Diagram yang menampilkan arsitektur multi-tingkat di-deploy di tiga Zona Ketersediaan. Perhatikan bahwa Amazon S3 dan Amazon DynamoDB selalu Multi-AZ secara otomatis. ELBJuga dikerahkan ke ketiga zona.

Gambar 9: Arsitektur multitingkat di-deploy di tiga Zona Ketersediaan. Perhatikan bahwa Amazon S3 dan Amazon DynamoDB selalu Multi-AZ secara otomatis. ELBJuga dikerahkan ke ketiga zona.

Meskipun pesawat AWS kontrol biasanya menyediakan kemampuan untuk mengelola sumber daya di seluruh Wilayah (beberapa Availability Zone), pesawat kontrol tertentu (termasuk Amazon EC2 dan AmazonEBS) memiliki kemampuan untuk memfilter hasil ke satu Availability Zone. Saat hal ini sudah dilakukan, permintaan hanya diproses di Zona Ketersediaan tertentu, mengurangi eksposur gangguan di Zona Ketersediaan lainnya. AWS CLI Contoh ini menggambarkan mendapatkan informasi EC2 instans Amazon hanya dari Zona Ketersediaan us-east-2c:

AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c

AWS Local Zones

AWS Local Zones bertindak mirip dengan Availability Zone Wilayah AWS dalam masing-masing sehingga mereka dapat dipilih sebagai lokasi penempatan untuk AWS sumber daya zona seperti subnet dan EC2 instance. Apa yang membuat mereka istimewa adalah bahwa mereka tidak berada di tempat yang terkait Wilayah AWS, tetapi dekat dengan populasi besar, industri, dan pusat TI di mana tidak Wilayah AWS ada saat ini. Namun, zona-zona ini tetap mampu mempertahankan bandwidth yang tinggi, mengamankan koneksi yang ada di antara beban kerja di zona lokal dan yang dijalankan di Wilayah AWS. Anda harus menggunakan Zona Lokal AWS untuk melakukan deployment beban kerja secara lebih dekat dengan pengguna untuk persyaratan latensi rendah.

Amazon Global Edge Network

Amazon Global Edge Network terdiri dari lokasi edge yang ada di kota-kota di seluruh dunia. Amazon CloudFront menggunakan jaringan ini untuk mengirimkan konten kepada pengguna akhir dengan latensi lebih rendah. AWS Global Accelerator memungkinkan Anda membuat titik akhir beban kerja di lokasi tepi ini untuk memberikan orientasi ke jaringan AWS global yang dekat dengan pengguna Anda. Amazon API Gateway memungkinkan API titik akhir yang dioptimalkan tepi menggunakan CloudFront distribusi untuk memfasilitasi akses klien melalui lokasi tepi terdekat.

Wilayah AWS

Wilayah AWS dirancang untuk menjadi otonom, oleh karena itu, untuk menggunakan pendekatan Multi-wilayah Anda akan menyebarkan salinan layanan khusus untuk setiap Wilayah.

Pendekatan banyak Wilayah adalah umum untuk strategi pemulihan bencana guna memenuhi tujuan-tujuan pemulihan ketika peristiwa skala besar satu kali terjadi. Lihat Rencana Pemulihan Bencana (DR) untuk informasi selengkapnya tentang strategi ini. Namun di sini, kami berfokus pada ketersediaan, yang berupaya memberikan tujuan waktu aktif rata-rata (mean uptime) dari waktu ke waktu. Untuk tujuan ketersediaan tinggi, arsitektur multi-wilayah umumnya akan dirancang menjadi aktif/aktif, dengan setiap salinan layanan (di wilayah masing-masing) yang aktif (melayani permintaan).

Rekomendasi

Tujuan-tujuan ketersediaan untuk sebagian besar beban kerja dapat dipenuhi dengan menggunakan strategi Multi-AZ dalam satu Wilayah AWS. Pertimbangkan untuk menggunakan arsitektur multi-Wilayah hanya saat beban kerja memiliki persyaratan ketersediaan yang sangat tinggi, atau tujuan bisnis lain yang memerlukan arsitektur multi-Wilayah.

AWS memberi Anda kemampuan untuk mengoperasikan layanan lintas wilayah. Misalnya, AWS menyediakan replikasi data asinkron berkelanjutan dari data menggunakan Amazon Simple Storage Service (Amazon S3) Replikasi Simple Storage Service (Amazon S3), Amazon Read Replicas (termasuk Aurora Read Replicas), dan RDS Amazon DynamoDB Global Tables. Dengan replikasi berkelanjutan, versi data tersedia untuk bisa langsung digunakan di setiap Wilayah aktif.

Dengan menggunakan AWS CloudFormation, Anda dapat menentukan infrastruktur Anda dan menerapkannya secara konsisten di seluruh Akun AWS dan di seluruh Wilayah AWS. Dan AWS CloudFormation StackSets memperluas fungsi ini dengan memungkinkan Anda membuat, memperbarui, atau menghapus AWS CloudFormation tumpukan di beberapa akun dan wilayah dengan satu operasi. Untuk penerapan EC2 instans Amazon, (AMIAmazon Machine Image) digunakan untuk menyediakan informasi seperti konfigurasi perangkat keras dan perangkat lunak yang diinstal. Anda dapat menerapkan pipeline Amazon EC2 Image Builder yang membuat kebutuhan AMIs Anda dan menyalinnya ke wilayah aktif Anda. Ini memastikan bahwa Golden ini AMIs memiliki semua yang Anda butuhkan untuk menerapkan dan meningkatkan beban kerja Anda di setiap wilayah baru.

Untuk merutekan lalu lintas, Amazon Route 53 dan AWS Global Accelerator mengizinkan definisi kebijakan yang menentukan pengguna mana yang pergi ke titik akhir regional aktif mana. Dengan Akselerator Global, Anda dapat mengatur panggilan lalu lintas untuk mengontrol persentase lalu lintas yang diarahkan ke setiap titik akhir aplikasi. Route 53 mendukung pendekatan persentase ini, dan juga beberapa kebijakan lain yang tersedia termasuk kebijakan berbasis kedekatan geografis (geo-proximity) dan latensi. Global Accelerator secara otomatis memanfaatkan jaringan server AWS edge yang luas, untuk mengarahkan lalu lintas ke tulang punggung AWS jaringan sesegera mungkin, menghasilkan latensi permintaan yang lebih rendah.

Semua kemampuan ini dioperasikan untuk menjaga otonomi dari masing-masing Wilayah. Ada sangat sedikit pengecualian untuk pendekatan ini, termasuk layanan kami yang menyediakan pengiriman edge global (seperti Amazon CloudFront dan Amazon Route 53), bersama dengan pesawat kontrol untuk layanan AWS Identity and Access Management (IAM). Sebagian besar layanan dioperasikan sepenuhnya dalam satu Wilayah.

Pusat data on-premise

Untuk beban kerja yang berjalan di pusat data lokal, buat pengalaman hybrid jika memungkinkan. AWS Direct Connect menyediakan koneksi jaringan khusus dari tempat Anda untuk AWS memungkinkan Anda menjalankan keduanya.

Pilihan lain adalah menjalankan AWS infrastruktur dan layanan di tempat menggunakan AWS Outposts. AWS Outposts adalah layanan yang dikelola sepenuhnya yang memperluas AWS infrastruktur, AWS layananAPIs, dan alat ke pusat data Anda. Infrastruktur perangkat keras yang sama yang AWS Cloud digunakan di diinstal di pusat data Anda. AWS Outposts kemudian terhubung ke yang terdekat Wilayah AWS. Anda kemudian dapat menggunakan AWS Outposts untuk mendukung beban kerja Anda yang memiliki latensi rendah atau persyaratan pemrosesan data lokal.

Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan: Tinggi

Panduan implementasi

  • Gunakan beberapa Availability Zone dan Wilayah AWS. Distribusikan sumber daya dan data beban kerja ke beberapa Zona Ketersediaan atau, jika diperlukan, ke beberapa Wilayah AWS. Lokasi tersebut dapat beragam sesuai kebutuhan.

  • Jika beban kerja harus di-deploy di beberapa Wilayah, pilih strategi multi-Wilayah. Sebagian besar kebutuhan keandalan dapat dipenuhi dalam satu Wilayah AWS menggunakan strategi Multi-Availability Zone. Gunakan strategi multi-Wilayah untuk memenuhi kebutuhan bisnis, jika diperlukan.

  • AWS Outposts Evaluasi beban kerja Anda. Jika beban kerja memerlukan latensi rendah ke pusat data on-premise Anda atau memiliki persyaratan pemrosesan data lokal. Kemudian jalankan AWS infrastruktur dan layanan di tempat menggunakan AWS Outposts

  • Tentukan apakah AWS Local Zones membantu Anda memberikan layanan kepada pengguna Anda. Jika Anda memiliki persyaratan latensi rendah, lihat apakah AWS Local Zones terletak di dekat pengguna Anda. Jika iya, manfaatkan hal tersebut untuk melakukan deployment beban kerja dengan lebih dekat ke para pengguna itu.

Sumber daya

Dokumen terkait:

Video terkait: