Praktik terbaik untuk desain tabel global DynamoDB

Ada dua versi tabel global: versi saat ini Tabel Global versi 2019.11.21 (Saat ini) (kadang-kadang disebut “V2"), dan Versi tabel global 2017.11.29 (Legacy) (kadang-kadang disebut “V1"). Panduan ini berfokus secara khusus pada versi terbaru, V2.

Tanpa menggunakan tabel global, DynamoDB adalah layanan Regional. Ini memiliki ketersediaan tinggi dan secara intrinsik memiliki ketahanan terhadap kegagalan infrastruktur suatu Wilayah, termasuk kegagalan seluruh zona ketersediaan (AZ). Tabel DynamoDB wilayah tunggal memiliki Perjanjian Tingkat Layanan ketersediaan 99,99% https://aws.amazon.com/dynamodb/sla/ (). SLA

Dengan penggunaan tabel global, DynamoDB memungkinkan tabel mereplikasi datanya di antara dua Wilayah atau lebih. Tabel DynamoDB Multi-wilayah memiliki ketersediaan 99,999%. SLA Dengan perencanaan yang tepat, tabel global dapat membantu menciptakan arsitektur yang tangguh dan menolak kegagalan Regional.

Tabel global menggunakan model replikasi aktif-aktif. Dari perspektif DynamoDB, tabel di setiap Wilayah memiliki kedudukan yang sama untuk menerima permintaan baca dan tulis. Setelah menerima permintaan penulisan, tabel replika lokal akan mereplikasi penulisan tersebut ke Wilayah yang berpartisipasi lainnya di latar belakang.

Item direplikasi satu per satu. Item yang diperbarui dalam satu transaksi mungkin tidak direplikasi bersama.

Setiap partisi tabel di Wilayah sumber mereplikasi penulisannya secara paralel dengan setiap partisi lainnya. Urutan penulisan dalam Wilayah jarak jauh mungkin tidak cocok dengan urutan penulisan yang terjadi dalam Wilayah sumber. Untuk informasi selengkapnya tentang partisi tabel, lihat postingan blog Penskalaan DynamoDB: Dampak partisi, hot key, dan pemisahan panas terhadap performa.

Item yang baru ditulis biasanya disebarkan ke semua tabel replika dalam hitungan detik. Wilayah terdekat cenderung menyebarkan lebih cepat.

Amazon CloudWatch menyediakan ReplicationLatency metrik untuk setiap pasangan Wilayah. Ini dihitung berdasarkan item yang tiba dan membandingkan waktu kedatangannya dengan waktu penulisan awal serta menghitung rata-ratanya. Pengaturan waktu disimpan CloudWatch di dalam Wilayah sumber. Melihat pengaturan waktu rata-rata dan maksimum dapat membantu menentukan jeda replikasi rata-rata dan terburuk. Tidak ada SLA latensi ini.

Jika item yang sama diperbarui pada waktu yang hampir bersamaan (dalam jendela ReplicationLatency ini) di dua Wilayah yang berbeda, dan penulisan kedua terjadi sebelum penulisan pertama direplikasi, ada potensi konflik penulisan. Tabel global menyelesaikan konflik demikian dengan mekanisme penulis terakhir menang, berdasarkan timestamp penulisan. Penulisan pertama “kalah” dengan penulisan kedua. Konflik ini tidak dicatat dalam CloudWatch atau AWS CloudTrail.

Setiap item memiliki timestamp tulis terakhir yang disimpan sebagai properti sistem privat. Pendekatan penulis terakhir menang diimplementasikan menggunakan penulisan bersyarat yang mengharuskan timestamp item masuk lebih besar daripada timestamp item yang ada.

Tabel global akan mereplikasi semua item ke semua Wilayah yang berpartisipasi. Jika ingin memiliki cakupan replikasi yang berbeda, Anda dapat membuat beberapa tabel berbeda dan memasukkan Wilayah yang berpartisipasi yang berbeda ke masing-masing tabel.

Penulisan akan diterima di Wilayah lokal meskipun Wilayah replika sedang offline atau ReplicationLatency berkembang. Tabel lokal terus mencoba mereplikasi item ke tabel jarak jauh hingga setiap item berhasil.

Jika suatu Wilayah menjadi offline sepenuhnya, ketika kemudian kembali online, semua replikasi keluar dan masuk yang tertunda akan dicoba ulang. Tidak ada tindakan khusus yang diperlukan untuk mengembalikan sinkronisasi tabel. Mekanisme penulis terakhir menang memastikan data pada akhirnya akan menjadi konsisten.

Anda dapat menambahkan Region baru ke tabel DynamoDB kapan saja. DynamoDB akan menangani sinkronisasi awal dan replikasi yang sedang berlangsung. Jika suatu Wilayah dihapus, meskipun itu adalah Wilayah asli, hanya tabel untuk Wilayah tersebut yang akan dihapus.

DynamoDB tidak memiliki titik akhir global. Semua permintaan dibuat ke titik akhir regional, yang kemudian mengakses instans tabel global yang bersifat lokal di Wilayah tersebut.

Panggilan ke DynamoDB tidak boleh dilakukan lintas Wilayah. Praktik terbaiknya adalah lapisan komputasi di satu Wilayah hanya mengakses titik akhir DynamoDB lokal untuk Wilayah tersebut secara langsung. Jika masalah terdeteksi dalam Wilayah, apakah masalah tersebut ada di lapisan DynamoDB atau di tumpukan sekitarnya, maka lalu lintas pengguna akhir harus diarahkan ke lapisan komputasi berbeda yang dihosting di Wilayah yang berbeda. Berkat replikasi tabel global, Wilayah yang berbeda sudah memiliki salinan lokal data yang sama untuk digunakan secara lokal. Dalam beberapa situasi, lapisan komputasi di satu Wilayah dapat meneruskan permintaan ke lapisan komputasi Wilayah lain untuk diproses, tetapi lapisan komputasi ini tidak boleh mengakses titik akhir DynamoDB jarak jauh secara langsung. Untuk informasi selengkapnya tentang kasus penggunaan khusus ini, lihat Perutean permintaan lapisan komputasi.

Pembacaan berlatensi rendah. Anda dapat menempatkan salinan data lebih dekat ke pengguna akhir untuk mengurangi latensi jaringan selama pembacaan. Cache tetap baru seperti nilai ReplicationLatency.

Penulisan berlatensi lebih rendah. Anda dapat menulis ke wilayah terdekat untuk mengurangi latensi jaringan dan waktu yang dibutuhkan untuk menghasilkan penulisan. Lalu lintas tulis harus dirutekan dengan hati-hati untuk memastikan tidak ada konflik. Teknik perutean dibahas lebih detail di Minta perutean dengan tabel global DynamoDB.

Peningkatan ketahanan dan pemulihan bencana. Anda dapat mengevakuasi suatu Wilayah (memindahkan sebagian atau semua permintaan ke Wilayah tersebut) jika Wilayah tersebut mengalami penurunan kinerja atau pemadaman penuh, dengan Objektif Titik Pemulihan (RPO) dan Tujuan Waktu Pemulihan (RTO) diukur dalam hitungan detik. Menggunakan tabel global juga meningkatkan DynamoDB dari 99,99% menjadi SLA 99,999%.

Migrasi Wilayah yang mulus. Anda dapat menambahkan Wilayah baru lalu menghapus Wilayah lama untuk memigrasikan deployment dari satu Wilayah ke Wilayah lainnya, tanpa adanya waktu henti pada lapisan data. Misalnya, Anda dapat menggunakan tabel global DynamoDB agar sistem manajemen pesanan mencapai pemrosesan latensi rendah yang andal dalam skala tinggi sekaligus menjaga ketahanan terhadap kegagalan AZ dan Regional.