Praktik terbaik untuk desain tabel global DynamoDB

Tabel global dibangun berdasarkan jejak global Amazon DynamoDB untuk memberi Anda basis data yang terkelola sepenuhnya, multi-Wilayah, dan multi-aktif yang memberikan performa baca dan tulis yang cepat serta lokal, untuk aplikasi global berskala besar. Dengan tabel global, data Anda akan direplikasi secara otomatis di seluruh AWS wilayah pilihan Anda. Karena tabel global menggunakan DynamoDB API yang ada, tidak diperlukan perubahan pada aplikasi Anda. Tidak ada biaya atau komitmen di muka untuk menggunakan tabel global, dan Anda hanya membayar untuk sumber daya yang Anda gunakan.

Topik

• Panduan preskriptif untuk desain tabel global DynamoDB
• Fakta kunci tentang desain tabel global DynamoDB
• Kasus penggunaan
• Mode tulis dengan tabel global
• Meminta perutean dengan tabel global
• Mengevakuasi Wilayah dengan tabel global
• Perencanaan kapasitas throughput untuk tabel global
• Daftar periksa persiapan untuk tabel global dan Pertanyaan yang Sering Diajukan

Panduan preskriptif untuk desain tabel global DynamoDB

Penggunaan tabel global yang efisien memerlukan pertimbangan yang cermat terhadap faktor-faktor seperti mode tulis pilihan Anda, model perutean, dan proses evakuasi. Anda harus melengkapi aplikasi Anda di setiap Wilayah dan siap menyesuaikan rute atau melakukan evakuasi untuk menjaga kesehatan global. Sehingga Anda akan mendapatkan kumpulan data yang terdistribusi secara global dengan pembacaan dan penulisan latensi rendah serta perjanjian tingkat layanan 99,999%.

Fakta kunci tentang 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 99,99% ketersediaan https://aws.amazon.com/dynamodb/sla/Perjanjian Tingkat Layanan (SLA).

• Dengan penggunaan tabel global, DynamoDB memungkinkan tabel mereplikasi datanya di antara dua Wilayah atau lebih. Tabel DynamoDB multi-Wilayah memiliki 99,999% ketersediaan 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 pada 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.

Kasus penggunaan

Tabel global memberikan manfaat umum ini:

• 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 Meminta perutean dengan tabel global.

• Peningkatan ketahanan dan pemulihan bencana. Anda dapat mengevakuasi suatu Wilayah (memindahkan beberapa atau semua permintaan ke Wilayah tersebut) jika Wilayah tersebut mengalami penurunan performa atau penghentian total, dengan sasaran titik pemulihan (RPO) dan sasaran waktu pemulihan (RTO) diukur dalam detik. Penggunaan tabel global juga meningkatkan SLA DynamoDB dari 99,99% menjadi 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.