Multi-Region fundamental 2: Memahami data

Mengelola data adalah masalah yang tidak sepele ketika Anda mengadopsi arsitektur Multi-region. Jarak geografis antar Wilayah memberlakukan latensi yang tidak dapat dihindari yang bermanifestasi sebagai waktu yang diperlukan untuk mereplikasi data di seluruh Wilayah. Pertukaran antara ketersediaan, konsistensi data, dan memperkenalkan latensi yang lebih tinggi ke dalam beban kerja yang menggunakan arsitektur Multi-wilayah akan diperlukan. Apakah Anda menggunakan replikasi asinkron atau sinkron, Anda perlu memodifikasi aplikasi Anda untuk menangani perubahan perilaku yang diterapkan teknologi replikasi. Tantangan seputar konsistensi dan latensi data membuatnya sangat sulit untuk mengambil aplikasi yang sudah ada yang dirancang untuk satu Wilayah dan menjadikannya Multi-wilayah. Memahami persyaratan konsistensi data dan pola akses data untuk beban kerja tertentu sangat penting untuk menimbang trade-off.

2.a: Memahami persyaratan konsistensi data

Teorema CAP memberikan referensi untuk alasan tentang trade-off antara konsistensi data, ketersediaan, dan partisi jaringan. Hanya dua dari persyaratan ini yang dapat dipenuhi pada saat yang sama untuk beban kerja. Menurut definisi, arsitektur Multi-region mencakup partisi jaringan antar Wilayah, jadi Anda harus memilih antara ketersediaan dan konsistensi.

Jika Anda memilih ketersediaan data di seluruh Wilayah, Anda tidak akan mengalami latensi yang signifikan selama operasi penulisan transaksional, karena ketergantungan pada replikasi asinkron dari data komit antar Wilayah menghasilkan pengurangan konsistensi di seluruh Wilayah hingga replikasi selesai. Dengan replikasi asinkron, ketika ada kegagalan di Wilayah primer, ada kemungkinan besar bahwa operasi penulisan akan menunggu replikasi dari Wilayah primer. Hal ini menyebabkan skenario di mana data terbaru tidak tersedia sampai replikasi dilanjutkan, dan proses rekonsiliasi diperlukan untuk menangani transaksi dalam penerbangan yang tidak mereplikasi dari Wilayah yang mengalami gangguan. Skenario ini membutuhkan pemahaman logika bisnis Anda dan menciptakan proses khusus untuk memutar ulang transaksi atau membandingkan penyimpanan data antar Wilayah.

Untuk beban kerja yang disukai replikasi asinkron, Anda dapat menggunakan layanan seperti Amazon Aurora dan Amazon DynamoDB untuk replikasi lintas wilayah asinkron. Baik database global Amazon Aurora dan tabel global Amazon DynamoDB memiliki metrik CloudWatchAmazon default untuk membantu memantau kelambatan replikasi. Database global Aurora terdiri dari satu Wilayah utama tempat data Anda ditulis, dan hingga lima Wilayah sekunder hanya-baca. Tabel global DynamoDB terdiri dari tabel replika multi-aktif di sejumlah Wilayah tempat data Anda ditulis dan dibaca.

Rekayasa beban kerja untuk memanfaatkan arsitektur berbasis peristiwa merupakan manfaat bagi strategi Multi-wilayah, karena itu berarti bahwa beban kerja dapat merangkul replikasi data asinkron dan memungkinkan rekonstruksi status dengan memutar ulang peristiwa. Karena layanan streaming dan pesan menyangga data payload pesan dalam satu Wilayah, proses failover atau failback Regional harus menyertakan mekanisme untuk mengarahkan aliran data masukan klien. Proses ini juga harus mendamaikan muatan dalam penerbangan atau tidak terkirim yang disimpan di Wilayah yang mengalami gangguan tersebut.

Jika Anda memilih persyaratan konsistensi CAP dan menggunakan database yang direplikasi secara sinkron di seluruh Wilayah untuk mendukung aplikasi Anda yang berjalan secara bersamaan dari beberapa Wilayah, Anda menghapus risiko kehilangan data dan menjaga agar data tetap sinkron antar Wilayah. Namun, ini memperkenalkan karakteristik latensi yang lebih tinggi, karena penulisan perlu berkomitmen untuk lebih dari satu Wilayah, dan Wilayah dapat berjarak ratusan atau ribuan mil dari satu sama lain. Anda perlu memperhitungkan karakteristik latensi ini dalam desain aplikasi Anda. Selain itu, replikasi sinkron dapat memperkenalkan peluang kegagalan yang berkorelasi karena penulisan perlu berkomitmen pada lebih dari satu Wilayah agar berhasil. Jika ada gangguan dalam satu Wilayah, Anda perlu membentuk kuorum agar penulisan berhasil. Ini biasanya melibatkan pengaturan database Anda di tiga Wilayah dan membuat kuorum dua dari tiga Wilayah. Teknologi seperti Paxos dapat membantu mereplikasi dan melakukan data secara serempak tetapi membutuhkan investasi pengembang yang signifikan.

Ketika penulisan melibatkan replikasi sinkron di beberapa Wilayah untuk memenuhi persyaratan konsistensi yang kuat, latensi tulis meningkat dengan urutan besarnya. Latensi tulis yang lebih tinggi bukanlah sesuatu yang biasanya dapat Anda perbaiki ke dalam aplikasi tanpa perubahan signifikan, seperti meninjau kembali strategi timeout dan coba lagi untuk aplikasi Anda. Idealnya, itu harus dipertimbangkan ketika aplikasi pertama kali dirancang. Untuk beban kerja multi-wilayah di mana replikasi sinkron adalah prioritas,AWS Partner solusi dapat membantu.

2.b: Memahami pola akses data

Pola akses data beban kerja bersifat intensif baca atau intensif tulis. Memahami karakteristik ini untuk beban kerja tertentu akan membantu Anda memilih arsitektur Multi-wilayah yang sesuai.

Untuk beban kerja intensif baca seperti konten statis yang sepenuhnya hanya-baca, Anda dapat mencapai arsitektur Multi-wilayah aktif-aktif yang memiliki kompleksitas rekayasa lebih sedikit jika dibandingkan dengan beban kerja intensif tulis. Menyajikan konten statis di tepi dengan menggunakan jaringan pengiriman konten (CDN) memastikan ketersediaan dengan menyimpan konten yang paling dekat dengan pengguna akhir; menggunakan set fitur seperti failover asal di Amazon CloudFront dapat membantu mencapai hal ini. Pilihan lainnya adalah menerapkan stateless compute di beberapa Wilayah dan menggunakan DNS untuk merutekan pengguna ke Wilayah terdekat untuk membaca konten. Anda dapat menggunakan Amazon Route 53 dengan kebijakan perutean geolokasi untuk mencapai hal ini.

Untuk beban kerja intensif baca yang memiliki persentase lalu lintas baca yang lebih besar daripada lalu lintas tulis, Anda dapat menggunakan strategi baca lokal, tulis global. Ini berarti bahwa semua permintaan tulis masuk ke database di Wilayah tertentu, data direplikasi secara asinkron ke semua Wilayah lain, dan pembacaan dapat dilakukan di Wilayah mana pun. Pendekatan ini membutuhkan beban kerja untuk merangkul konsistensi akhirnya, karena pembacaan lokal mungkin menjadi basi sebagai akibat dari peningkatan latensi untuk replikasi penulisan lintas wilayah.

Database global Aurora dapat membantu penyediaan replika baca di Wilayah siaga yang hanya dapat menangani semua lalu lintas baca secara lokal, dan menyediakan satu penyimpanan data utama di Wilayah tertentu untuk menangani lalu lintas tulis. Data direplikasi secara asinkron dari database utama ke database siaga (baca replika), dan database siaga dapat dipromosikan ke primer jika Anda perlu gagal dalam operasi ke Wilayah siaga. Anda juga dapat menggunakan DynamoDB dalam pendekatan ini. Tabel global DynamoDB dapat menyediakan tabel replika di seluruh Wilayah yang dapat setiap skala untuk mendukung volume lalu lintas baca atau tulis lokal. Ketika aplikasi menulis data ke tabel replika di satu wilayah, DynamoDB otomatis menyebarkan aktivitas tulis tersebut ke tabel replika lain di Wilayah lain. Dengan konfigurasi ini, data direplikasi secara asinkron dari Wilayah primer yang ditentukan ke tabel replika di Wilayah siaga. Tabel replika di Wilayah mana pun selalu dapat menerima penulisan, jadi mempromosikan Region siaga ke primer dikelola di tingkat aplikasi. Sekali lagi, beban kerja harus mencakup konsistensi akhirnya, yang mungkin mengharuskannya ditulis ulang jika tidak dirancang untuk ini sejak awal.

Untuk beban kerja intensif tulis, Wilayah utama harus dipilih dan kemampuan untuk gagal ke Wilayah siaga harus direkayasa ke dalam beban kerja. Dibandingkan dengan pendekatan aktif-aktif, pendekatan siaga primer memiliki trade-off tambahan. Ini karena untuk arsitektur aktif-aktif, beban kerja harus ditulis ulang untuk menangani perutean cerdas ke Wilayah, membangun afinitas sesi, memastikan transaksi idempoten, dan menangani potensi konflik.

Sebagian besar beban kerja yang menggunakan pendekatan Multi-wilayah untuk ketahanan tidak memerlukan pendekatan aktif-aktif. Anda dapat menggunakan strategi sharding untuk memberikan peningkatan ketahanan dengan membatasi ruang lingkup dampak penurunan nilai di seluruh basis klien. Jika Anda dapat secara efektif menghancurkan basis klien, Anda dapat memilih Wilayah primer yang berbeda untuk setiap pecahan. Misalnya, Anda dapat membelah klien sehingga setengah dari klien selaras dengan Wilayah satu dan setengahnya selaras dengan Wilayah dua. Dengan memperlakukan Regions sebagai sel, Anda dapat membuat pendekatan sel Multi-region, yang menghasilkan pengurangan cakupan dampak untuk beban kerja Anda. Untuk informasi selengkapnya, lihat presentasi AWS re:Invent tentang pendekatan ini.

Anda dapat menggabungkan pendekatan sharding dengan pendekatan siaga utama untuk memberikan kemampuan failover untuk pecahan. Anda perlu merekayasa proses failover yang diuji ke dalam beban kerja dan proses untuk rekonsiliasi data juga, untuk memastikan konsistensi transaksional dari penyimpanan data setelah failover. Ini dibahas secara lebih rinci nanti dalam panduan ini.

Panduan utama

• Ada kemungkinan besar bahwa penulisan yang tertunda untuk replikasi tidak akan dilakukan ke Wilayah siaga ketika ada kegagalan. Data tidak akan tersedia sampai replikasi dilanjutkan (dengan asumsi replikasi asinkron).

• Sebagai bagian dari failover, proses rekonsiliasi data akan diperlukan untuk memastikan bahwa status yang konsisten secara transaksional dipertahankan untuk penyimpanan data yang menggunakan replikasi asinkron. Ini membutuhkan logika bisnis tertentu dan bukan sesuatu yang ditangani oleh penyimpanan data itu sendiri.

• Ketika konsistensi yang kuat diperlukan, beban kerja perlu dimodifikasi untuk mentolerir latensi yang diperlukan dari penyimpanan data yang mereplikasi secara sinkron.