Mengevakuasi Wilayah dengan tabel global

Evakuasi suatu Wilayah adalah proses memigrasikan aktivitas baca dan tulis keluar dari Wilayah tersebut. Ini paling sering merupakan aktivitas tulis, dan terkadang aktivitas baca.

Mengevakuasi Wilayah aktif

Anda dapat memutuskan untuk mengevakuasi Wilayah aktif karena sejumlah alasan. Evakuasi dapat menjadi bagian dari aktivitas bisnis biasa seperti jika Anda menggunakan mode follow-the-sun tulis ke satu Wilayah. Evakuasi juga bisa disebabkan oleh keputusan bisnis untuk mengubah Wilayah yang sedang aktif, sebagai respons terhadap kegagalan tumpukan perangkat lunak di luar DynamoDB, atau karena Anda menghadapi masalah umum seperti latensi yang lebih tinggi dari biasanya di dalam Wilayah.

Dengan mode tulis ke Wilayah mana pun, mengevakuasi Wilayah aktif sangatlah mudah. Anda dapat merutekan lalu lintas ke Wilayah alternatif melalui sistem perutean apa pun, dan membiarkan operasi tulis yang telah terjadi di Wilayah yang dievakuasi direplikasi seperti biasa.

Dengan mode tulis ke satu Wilayah dan tulis ke Wilayah Anda, Anda harus memastikan semua penulisan ke Wilayah aktif telah direkam sepenuhnya, diproses streaming, dan disebarkan secara global sebelum memulai penulisan di Wilayah aktif yang baru. Hal ini diperlukan untuk memastikan bahwa penulisan di masa mendatang bertentangan dengan versi data terbaru.

Katakanlah Wilayah A aktif dan Wilayah B pasif (baik untuk tabel lengkap atau untuk item yang ditempatkan di Wilayah A). Mekanisme umum untuk melakukan evakuasi adalah dengan menjeda operasi tulis ke A, menunggu cukup lama hingga operasi tersebut disebarkan sepenuhnya ke B, memperbarui tumpukan arsitektur untuk mengenali B sebagai aktif, lalu melanjutkan operasi tulis ke B. Tidak ada metrik yang menunjukkan kepastian mutlak bahwa Wilayah A telah sepenuhnya mereplikasi datanya ke Wilayah B. Jika Wilayah A sehat, menjeda operasi tulis ke Wilayah A dan menunggu 10 kali nilai maksimum terbaru metrik ReplicationLatency biasanya sudah cukup untuk menentukan bahwa replikasi tersebut selesai. Jika Wilayah A tidak sehat dan menunjukkan area lain mengalami peningkatan latensi, Anda dapat memilih kelipatan waktu tunggu yang lebih besar.

Mengevakuasi Wilayah offline

Ada kasus khusus yang perlu dipertimbangkan: bagaimana jika Wilayah A offline sepenuhnya tanpa pemberitahuan? Hal ini sangat kecil kemungkinannya, tetapi tetap perlu dipertimbangkan. Jika hal ini terjadi, operasi tulis apa pun di Wilayah A yang belum disebarkan akan ditahan dan disebarkan setelah Wilayah A kembali online. Operasi tulis tidak hilang, tetapi penyebarannya tertunda tanpa batas waktu.

Cara melanjutkan peristiwa ini merupakan keputusan aplikasi. Untuk kelangsungan bisnis, operasi tulis mungkin perlu diteruskan ke Wilayah B utama yang baru. Namun, jika item di Wilayah B menerima pembaruan sementara ada penyebaran operasi tulis yang tertunda untuk item tersebut dari Wilayah A, penyebaran tersebut akan disembunyikan di model penulis terakhir menang. Pembaruan apa pun di Wilayah B mungkin menyembunyikan permintaan tulis yang masuk.

Dengan mode tulis ke Wilayah mana pun, pembacaan dan penulisan dapat dilanjutkan di Wilayah B, dengan keyakinan bahwa item di Wilayah A pada akhirnya akan disebarkan ke Wilayah B dan mengenali potensi item yang hilang hingga Wilayah A kembali online. Jika memungkinkan, Anda harus mempertimbangkan untuk memutar ulang lalu lintas tulis terbaru (misalnya, menggunakan sumber peristiwa hulu) untuk mengisi celah dari operasi tulis yang mungkin hilang dan membiarkan resolusi konflik penulis terakhir menang menekan penyebaran akhir dari operasi tulis yang masuk.

Dengan mode tulis lainnya, Anda harus mempertimbangkan sejauh mana pekerjaan dapat dilanjutkan dengan sedikit out-of-date pandangan dunia. Beberapa operasi tulis berdurasi pendek, seperti yang dilacak oleh ReplicationLatency, akan hilang hingga Wilayah A kembali online. Apakah bisnis bisa maju? Dalam beberapa kasus penggunaan, bisa, tetapi pada kasus lainnya mungkin tidak bisa, tanpa mekanisme mitigasi tambahan.

Misalnya, katakanlah Anda perlu mempertahankan saldo kredit yang tersedia tanpa gangguan bahkan setelah kegagalan Wilayah. Anda dapat membagi saldo menjadi dua item berbeda, satu ditempatkan di Wilayah A dan satu lagi di Wilayah B, masing-masing dimulai dengan setengah saldo yang tersedia. Ini akan menggunakan mode tulis ke Wilayah Anda. Pembaruan transaksional yang diproses di setiap Wilayah akan dituliskan pada salinan lokal saldo. Jika Wilayah A sepenuhnya offline, pekerjaan masih dapat dilanjutkan dengan pemrosesan transaksi di Wilayah B, dan operasi tulis akan terbatas pada bagian saldo yang disimpan di Wilayah B. Memisahkan saldo seperti ini menimbulkan kerumitan ketika saldo hampir habis atau kredit harus diseimbangkan kembali, tetapi hal ini memberikan satu contoh pemulihan bisnis yang aman bahkan dengan operasi tulis tertunda yang tidak pasti.

Contoh lain, misalkan Anda mengambil data formulir web. Anda dapat menggunakan Optimistic Concurrency Control (OCC) untuk menetapkan versi ke item data dan menyematkan versi terbaru ke formulir web sebagai bidang tersembunyi. Pada setiap pengiriman, operasi tulis berhasil hanya jika versi dalam basis data masih cocok dengan versi yang digunakan untuk membuat formulir. Jika versinya tidak cocok, formulir web bisa disegarkan (atau digabungkan secara hati-hati) berdasarkan versi saat ini dalam basis data, dan pengguna bisa melanjutkan lagi. OCCModel ini biasanya melindungi terhadap penimpaan klien lain dan menghasilkan versi baru dari data, tetapi juga dapat membantu selama failover di mana klien mungkin menemukan versi data yang lebih lama.

Misalkan Anda menggunakan timestamp sebagai versinya. Katakanlah formulir pertama kali dibuat pada Wilayah A pada pukul 12.00 tetapi (setelah failover) mencoba menulis ke Wilayah B dan mengetahui bahwa versi terbaru dalam basis data adalah 11.59. Dalam skenario ini, klien dapat menunggu versi 12.00 untuk disebarkan ke Wilayah B lalu menulis di atas versi tersebut, atau membangun pada 11.59 dan membuat versi 12.01 baru (yang, setelah ditulis, akan menyembunyikan versi yang masuk setelah Wilayah A pulih).

Contoh terakhir, perusahaan jasa keuangan menyimpan data tentang akun pelanggan dan transaksi keuangan mereka dalam basis data DynamoDB. Jika terjadi pemadaman total Wilayah A, mereka ingin memastikan bahwa aktivitas tulis apa pun yang terkait dengan akun mereka tersedia sepenuhnya di Wilayah B, atau ingin mengarantina akun mereka sebagai diketahui sebagian hingga Wilayah A kembali online. Alih-alih menghentikan semua bisnis, mereka memutuskan untuk menghentikan bisnis untuk sementara waktu, hanya pada sebagian kecil akun yang mereka anggap memiliki transaksi yang tidak disebarkan. Untuk mencapai hal ini, mereka menggunakan Wilayah ketiga, yang akan kita sebut Wilayah C. Sebelum memproses operasi tulis apa pun di Wilayah A, mereka menempatkan ringkasan singkat operasi yang tertunda tersebut (misalnya, jumlah transaksi baru untuk sebuah akun) di Wilayah C. Ringkasan ini cukup bagi Wilayah B untuk menentukan apakah pandangannya benar-benar mutakhir. Tindakan ini mengunci akun secara efektif sejak penulisan di Wilayah C hingga Wilayah A menerima operasi tulis dan Wilayah B menerimanya. Data di Wilayah C tidak digunakan kecuali sebagai bagian dari proses failover, setelah itu Wilayah B dapat memeriksa datanya dengan Wilayah C untuk mengetahui apakah ada akun yang kedaluwarsa. Akun tersebut akan ditandai sebagai dikarantina hingga pemulihan Wilayah A menyebarkan sebagian data ke Wilayah B.

Jika Wilayah C gagal, Wilayah D baru dapat dibuka untuk digunakan. Data di Wilayah C sangat sementara, dan setelah beberapa menit Wilayah D akan memiliki up-to-date catatan yang cukup tentang operasi penulisan dalam penerbangan untuk sepenuhnya berguna. Jika Wilayah B gagal, Wilayah A dapat terus menerima permintaan tulis yang bekerja sama dengan Wilayah C. Perusahaan ini bersedia menerima penulisan dengan latensi yang lebih tinggi (ke dua Wilayah: C dan kemudian A) dan beruntung memiliki model data yang status akunnya dapat dirangkum secara ringkas.