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.
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.
-
Layanan-layanan regional di-deploy secara permanen di seluruh Zona Ketersediaan.
-
Ini termasuk Amazon S3, Amazon DynamoDB, AWS Lambda dan (bila tidak terhubung ke a) VPC
-
-
Deploy kontainer Anda, instans, dan beban kerja berbasis fungsi ke beberapa Zona Ketersediaan. Gunakan penyimpanan data multi-zona, termasuk cache. Gunakan fitur Amazon EC2 Auto Scaling, penempatan ECS tugas Amazon, konfigurasi AWS Lambda fungsi saat berjalan di AndaVPC, dan ElastiCache cluster.
-
Gunakan subnet yang berada di Zona Ketersediaan terpisah saat Anda melakukan deployment grup Auto Scaling.
-
Gunakan parameter penempatan ECS tugas, menentukan grup subnet DB.
-
Gunakan subnet di beberapa Availability Zone saat Anda mengonfigurasi fungsi untuk dijalankan di. VPC
-
Gunakan beberapa Availability Zone dengan ElastiCache cluster.
-
-
-
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 re: Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah (09-R2) ARC2
-
Backup ke yang lain Wilayah AWS dapat menambahkan lapisan jaminan lain bahwa data akan tersedia saat dibutuhkan.
-
Beberapa beban kerja memiliki persyaratan berdasarkan regulasi yang mengharuskan penggunaan strategi multi-Wilayah.
-
-
-
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: