DynamoDB Global Tables

Sebuah global table adalah satu tabel DynamoDB yang direplikasi di beberapa region AWS, di mana setiap replika dapat ditulisi. DynamoDB menjaga mereka tetap sinkron secara otomatis — Anda mendapatkan pembacaan dan penulisan lokal berlatensi rendah di setiap region ditambah disaster recovery lintas region, tanpa menjalankan replikasi Anda sendiri.

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

Apa itu DynamoDB Global Tables?

DynamoDB Global Tables adalah satu tabel yang direplikasi di beberapa region AWS, di mana setiap replika dapat dibaca dan ditulisi. DynamoDB menyinkronkannya secara otomatis melalui replikasi asinkron yang eventually consistent, dan menyelesaikan konflik secara last-writer-wins. Anda mendapatkan pembacaan dan penulisan lokal berlatensi rendah di setiap region ditambah disaster recovery lintas region, yang mendukung SLA ketersediaan 99,999% DynamoDB.

• Multi-region, active-active. Setiap replika sepenuhnya dapat dibaca dan ditulisi; penulisan di region mana pun menyebar ke yang lain.
• Replikasi bersifat asinkron dan eventually consistent lintas region — biasanya dalam waktu satu detik, tetapi tidak instan.
• Konflik diselesaikan last-writer-wins. Penulisan konkuren ke Item yang sama di dua region direkonsiliasi ke yang paling baru.
• Ia mendukung SLA ketersediaan 99,999% — sebuah global table multi-region adalah konfigurasi ketersediaan tertinggi DynamoDB.

Masalahnya: satu region tidak cukup

Sebuah tabel single-region punya dua batas yang tidak bisa diterima audit log. Pertama, residensi data: event seorang pelanggan EU harus disimpan di EU, tetapi aplikasi Anda berjalan di AS. Kedua, disaster recovery: jika us-east-1 mengalami pemadaman, sebuah audit log single-region tidak dapat dibaca dan ditulisi selama durasinya — tepat saat Anda paling membutuhkan catatan tentang apa yang terjadi.

Membangun salah satunya sendiri — replikasi lintas region, failover, penanganan konflik — adalah proyek besar dan rawan kesalahan. Global tables membuatnya menjadi pilihan konfigurasi.

Cara kerja global tables

Anda menambahkan region replika ke tabel; DynamoDB membuat salinan di sana dan menjaga semua replika tetap sinkron. Menurut AWS DynamoDB FAQs, global tables menyediakan replikasi multi-region dengan hingga 99,999% ketersediaan, dan replika setiap region melayani pembacaan dan penulisan lokal.

Dua aturan konsistensi mendefinisikan perilakunya:

• Replikasi lintas region bersifat asinkron. Sebuah penulisan di us-east-1 diakui secara lokal, lalu disebarkan ke eu-west-1 — biasanya dalam waktu satu detik, tetapi pembacaan di region lain tepat setelah penulisan mungkin belum melihatnya. (Pembacaan strongly consistent tetap bekerja, tetapi hanya di dalam satu region.)
• Konflik adalah last-writer-wins. Jika Item yang sama ditulis di dua region pada waktu yang hampir bersamaan, DynamoDB menyimpan penulisan dengan timestamp terbaru dan membuang yang lain.

Contoh terkerjakan: replika EU yang juga DR

Anda menambahkan eu-west-1 sebagai replika tabel audit-log. Sekarang:

Aplikasi pelanggan EU menulis ke dan membaca dari replika eu-west-1 lokal — latensi rendah dan data residen di region. Replikasi yang sama yang memenuhi residensi berfungsi ganda sebagai disaster recovery: jika us-east-1 jatuh, replika eu-west-1 masih menyimpan log penuh dan melayani trafik; Anda melakukan failover ke sana.

Karena audit log bersifat append-only dan dipartisi per tenant, last-writer-wins pada dasarnya bukan masalah di sini — event tenant tertentu ditulis dari satu region dan event key bersifat unik, jadi dua region jarang berlomba pada Item yang sama. Itu bukan keberuntungan; itulah mengapa log append-only adalah salah satu kecocokan terbersih untuk global tables. Sebuah counter yang dapat berubah, sebaliknya, akan membutuhkan kehati-hatian di bawah penulisan lintas region yang konkuren.

Lakukan di DynoTable

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

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

Anda dapat membuat prototipe query per-region yang akan Anda jalankan terhadap setiap replika di DynamoDB Expression Builder.

Jebakan dan langkah berikutnya

• Jangan read-your-own-write lintas region. Replication lag berarti penulisan di satu region mungkin tidak muncul di region lain selama ~satu detik. Jangan menulis ke AS lalu langsung membaca dari EU dengan harapan itu; strong consistency hanya single-region.
• Last-writer-wins diam-diam menjatuhkan data. Untuk Item yang dapat berubah yang ditulis secara konkuren di dua region, yang kalah dibuang tanpa error. Desain append-only atau single-writer-per-item (seperti audit log ini) menghindari masalahnya; state yang dapat berubah dan dibagi membutuhkan desain yang sadar konflik.
• Setiap replika berbiaya. Setiap region menyimpan salinan penuh dan menagih kapasitas serta penyimpanannya 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 dipulihkan menjadi tabel independen — rencanakan pemulihan per region. Lihat backup & point-in-time recovery.

Global tables melindungi dari kehilangan sebuah region. Perhatian operasional terakhir adalah melindungi dari kehilangan data — deploy buruk atau penghapusan tidak sengaja — dengan backup & point-in-time recovery.

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