DynamoDB Global Tables: Replikasi Multi-Region Dijelaskan

Sebuah global table adalah sebuah tabel DynamoDB tunggal yang direplikasi di beberapa region AWS, di mana setiap replika bisa ditulis. DynamoDB menjaga mereka tetap sinkron secara otomatis — Anda mendapat pembacaan dan penulisan lokal berlatensi rendah di setiap region plus pemulihan bencana lintas-region, tanpa menjalankan replikasi Anda sendiri.

Dalam skenario audit-log, seorang pelanggan EU mengharuskan datanya tinggal di eu-west-1, sementara sisanya berjalan di us-east-1. Dan sebagai sebuah log kritis-kepatuhan, ia perlu bertahan dari sebuah pemadaman region penuh. Sebuah global table menjawab keduanya dengan satu fitur.

Bagaimana DynamoDB Global Tables bekerja?

DynamoDB Global Tables adalah sebuah tabel tunggal yang direplikasi di beberapa region AWS, di mana setiap replika bisa dibaca dan ditulis. DynamoDB menyinkronkan mereka secara otomatis lewat replikasi asinkron yang eventually consistent, meresolusi konflik last-writer-wins. Anda mendapat pembacaan dan penulisan lokal berlatensi rendah per region plus pemulihan bencana lintas-region, menopang SLA ketersediaan 99,999% DynamoDB.

• Multi-region, active-active. Setiap replika sepenuhnya bisa dibaca dan ditulis; penulisan di region mana pun berpropagasi ke yang lain.
• Dalam mode default, replikasi bersifat asinkron dan eventually consistent di seluruh region — biasanya dalam satu detik, tapi tidak instan. (Sebuah mode strong-consistency juga ada — lihat di bawah.)
• Konflik meresolusi last-writer-wins. Penulisan bersamaan ke item yang sama di dua region mendamaikan diri ke yang paling baru.
• Ia menopang SLA ketersediaan 99,999% — sebuah global table multi-region adalah konfigurasi berketersediaan-tertinggi DynamoDB.

Masalahnya: satu region tak cukup

Sebuah tabel single-region punya dua batasan yang tak bisa diterima audit log. Pertama, residensi data: event seorang pelanggan EU harus disimpan di EU, tapi aplikasi Anda berjalan di US. Kedua, pemulihan bencana: jika us-east-1 mengalami pemadaman, sebuah audit log single-region tak bisa dibaca dan tak bisa ditulis selama durasinya — persis saat Anda paling membutuhkan catatan apa yang terjadi.

Membangun salah satunya sendiri — replikasi lintas-region, failover, penanganan konflik — adalah sebuah proyek besar yang rawan-kesalahan. Global table menjadikannya sebuah pilihan konfigurasi.

Mekanika replikasi

Anda menambahkan sebuah region replika ke tabelnya; DynamoDB membuat sebuah salinan di sana dan menjaga semua replika tetap sinkron.

Dua aturan konsistensi mendefinisikan perilaku default (MREC):

• Replikasi lintas-region bersifat asinkron. Sebuah penulisan di us-east-1 diakui secara lokal, lalu dipropagasikan ke eu-west-1 — biasanya dalam satu detik, tapi sebuah pembacaan di region lain tepat setelah sebuah penulisan mungkin belum melihatnya. (Dalam mode MREC default, pembacaan strongly consistent tetap bekerja, tapi hanya di dalam satu region tunggal.)
• Konflik bersifat last-writer-wins. Jika item yang sama ditulis di dua region pada waktu yang hampir sama, DynamoDB menjaga penulisan dengan timestamp terbaru dan membuang yang lain.

Sebuah contoh yang dikerjakan: sebuah replika EU yang juga DR

Anda menambahkan eu-west-1 sebagai sebuah replika dari tabel audit-log. Kini:

Aplikasi pelanggan EU menulis ke dan membaca dari replika eu-west-1 lokal — latensi rendah dan data resident di-region. Replikasi yang sama yang memenuhi residensi sekaligus berperan sebagai pemulihan bencana: jika us-east-1 turun, replika eu-west-1 masih menahan log penuh dan melayani lalu lintas; Anda failover ke ia.

Karena audit log-nya append-only dan terpartisi-per-tenant, last-writer-wins pada dasarnya adalah non-isu di sini — event sebuah tenant tertentu ditulis dari satu region dan key event unik, jadi dua region jarang berlomba pada item yang sama. Itu bukan keberuntungan; itulah mengapa sebuah log append-only adalah salah satu kecocokan terbersih untuk global table. Sebuah counter yang mutable, sebaliknya, akan butuh kehati-hatian di bawah penulisan lintas-region yang bersamaan.

Lakukan di DynoTable

Setelah menambahkan sebuah replika Anda ingin mengonfirmasi datanya benar-benar mendarat di region baru dan cocok dengan sumbernya — bahwa replika EU benar-benar menahan event acme, dengan atribut yang benar, dan tidak tertinggal.

DynoTable terhubung ke region mana pun dengan kredensialnya sendiri, jadi Anda bisa mengarahkan satu jendela ke us-east-1 dan lainnya ke eu-west-1 dan membandingkan item tenant yang sama berdampingan untuk memverifikasi replikasi.

Anda bisa memprototipekan query per-region yang akan Anda jalankan terhadap setiap replika di Pembuat Ekspresi DynamoDB.

Jebakan dan langkah selanjutnya

• Jangan baca-tulisan-Anda-sendiri lintas region. Lag replikasi berarti sebuah penulisan di satu region mungkin tak muncul di region lain selama ~satu detik. Jangan tulis ke US lalu langsung baca dari EU berharap ia ada. Dalam mode MREC default, pembacaan strongly consistent bekerja hanya di dalam satu region tunggal; MRSC memperluas pembacaan strong lintas region.
• Last-writer-wins diam-diam membuang data. Untuk item mutable yang ditulis bersamaan di dua region, yang kalah dibuang tanpa kesalahan. Desain append-only atau single-writer-per-item (seperti audit log ini) menghindari masalahnya; state mutable bersama butuh sebuah desain yang sadar-konflik.
• Setiap replika berbiaya. Setiap region menyimpan sebuah salinan penuh dan menagih kapasitas dan storage-nya sendiri — sebuah replika kira-kira menggandakan biaya. Tambahkan region untuk kebutuhan residensi atau DR yang nyata, bukan secara default.
• Backup bersifat per-replika. Sebuah global table yang direstorasi menjadi sebuah tabel independen — rencanakan pemulihan per region. Lihat backup & point-in-time recovery DynamoDB.

Global table melindungi terhadap kehilangan sebuah region. Kekhawatiran operasional terakhir adalah melindungi terhadap kehilangan data — sebuah deploy buruk atau penghapusan tak sengaja — dengan backup & point-in-time recovery DynamoDB.

Unduh DynoTable untuk terhubung ke beberapa region dan memverifikasi replika global-table Anda menahan data yang sama.