Strategi perutean di DynamoDB - Amazon DynamoDB

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Strategi perutean di DynamoDB

Mungkin bagian paling rumit dari deployment tabel global adalah mengelola perutean permintaan. Permintaan harus dikirim dari pengguna akhir ke Wilayah yang dipilih terlebih dahulu, lalu dirutekan dengan cara tertentu. Permintaan menemukan beberapa tumpukan layanan di Wilayah tersebut, termasuk lapisan komputasi yang mungkin terdiri dari penyeimbang beban yang didukung oleh AWS Lambda fungsi, wadah, atau node Amazon Elastic Compute Cloud (Amazon EC2), dan mungkin layanan lain termasuk database lain. Lapisan komputasi tersebut berkomunikasi dengan DynamoDB yang dilakukan menggunakan titik akhir lokal untuk Wilayah tersebut. Data dalam tabel global direplikasi ke semua Wilayah lain yang berpartisipasi, dan setiap Wilayah memiliki tumpukan layanan serupa di sekitar tabel DynamoDB-nya.

Tabel global menyediakan salinan lokal dari data yang sama untuk setiap tumpukan di berbagai Wilayah. Sebaiknya Anda merancang tumpukan tunggal dalam satu Wilayah dan mengantisipasi melakukan panggilan jarak jauh ke titik akhir DynamoDB Wilayah sekunder jika tabel DynamoDB lokal mengalami masalah. Ini bukan praktik terbaik. Jika ada masalah di satu Wilayah yang disebabkan oleh DynamoDB (atau, kemungkinan besar, disebabkan oleh sesuatu yang lain di tumpukan atau oleh layanan lain yang bergantung pada DynamoDB), yang terbaik adalah merutekan pengguna akhir ke Wilayah lain untuk diproses dan menggunakan lapisan komputasi Wilayah lain, yang akan berbicara dengan titik akhir DynamoDB lokalnya. Pendekatan ini rute di sekitar Wilayah bermasalah seluruhnya. Untuk memastikan ketahanan, Anda memerlukan replikasi di beberapa Wilayah: replikasi lapisan komputasi serta lapisan data.

Ada banyak teknik alternatif untuk merutekan permintaan pengguna akhir ke suatu Wilayah untuk diproses. Pilihan optimal bergantung pada mode tulis dan pertimbangan failover Anda. Bagian ini membahas empat opsi: berbasis klien, lapisan komputasi, Route 53, dan Global Accelerator.

Perutean permintaan berbasis klien

Dengan routing permintaan berbasis klien, yang diilustrasikan dalam diagram berikut, klien pengguna akhir (aplikasi, halaman web dengan JavaScript, atau klien lain) melacak titik akhir aplikasi yang valid (misalnya, titik akhir Amazon API Gateway daripada titik akhir DynamoDB literal) dan menggunakan logika tertanam sendiri untuk memilih Wilayah untuk berkomunikasi. Ini mungkin memilih berdasarkan seleksi acak, latensi terendah yang diamati, pengukuran bandwidth tertinggi yang diamati, atau pemeriksaan kesehatan yang dilakukan secara lokal.

Diagram cara kerja penulisan ke target pilihan klien.

Sebagai keuntungan, routing permintaan berbasis klien dapat beradaptasi dengan hal-hal seperti kondisi lalu lintas internet publik dunia nyata untuk beralih Wilayah jika melihat kinerja yang menurun. Klien harus mengetahui semua titik akhir potensial, tetapi peluncuran titik akhir Regional baru bukanlah hal yang sering terjadi.

Dengan menulis ke mode Wilayah mana pun, klien dapat secara sepihak memilih titik akhir yang disukai. Jika aksesnya ke satu Wilayah terganggu, klien dapat merutekan ke titik akhir lain.

Dengan mode tulis ke satu Wilayah, klien memerlukan mekanisme untuk merutekan penulisannya ke wilayah yang sedang aktif. Ini bisa menjadi dasar seperti menguji secara empiris wilayah mana yang saat ini menerima penulisan (mencatat penolakan penulisan dan kembali ke alternatif) atau serumit memanggil koordinator global untuk menanyakan status aplikasi saat ini (mungkin dibangun di atas Amazon Application Recovery Controller (ARC) (ARC) kontrol perutean yang menyediakan sistem berbasis kuorum 5 wilayah untuk mempertahankan status global untuk kebutuhan seperti ini). Klien dapat memutuskan apakah pembacaan dapat dikirim ke Wilayah mana pun untuk konsistensi akhir atau harus dirutekan ke wilayah aktif untuk konsistensi yang kuat. Untuk informasi selengkapnya, lihat Cara kerja Route 53.

Dengan mode tulis ke Wilayah Anda, klien perlu menentukan wilayah asal kumpulan data yang digunakannya. Misalnya, jika klien berhubungan dengan akun pengguna dan setiap akun pengguna ditempatkan di suatu Wilayah, klien dapat meminta titik akhir yang sesuai dari sistem login global.

Misalnya, perusahaan jasa keuangan yang membantu pengguna mengelola keuangan bisnisnya melalui web dapat menggunakan tabel global dengan mode tulis ke Wilayah Anda. Setiap pengguna harus masuk ke layanan pusat. Layanan tersebut mengembalikan kredensial dan titik akhir untuk Wilayah tempat kredensial tersebut akan berfungsi. Kredensialnya valid untuk waktu yang singkat. Setelah itu, halaman web otomatis menegosiasikan aktivitas masuk baru, yang memberikan peluang untuk mengalihkan aktivitas pengguna ke Wilayah baru.

Perutean permintaan lapisan komputasi

Dengan routing permintaan compute-layer, diilustrasikan dalam diagram berikut, kode yang berjalan di lapisan komputasi menentukan apakah akan memproses permintaan secara lokal atau meneruskannya ke salinan dirinya sendiri yang berjalan di Wilayah lain. Saat Anda menggunakan mode tulis ke satu Wilayah, lapisan komputasi mungkin mendeteksi bahwa itu bukan Region aktif dan mengizinkan operasi baca lokal sambil meneruskan semua operasi tulis ke Wilayah lain. Kode lapisan komputasi ini harus mengetahui topologi data dan aturan perutean, dan menegakkannya dengan andal, berdasarkan pengaturan terbaru yang menentukan Wilayah mana yang aktif untuk data mana. Tumpukan perangkat lunak luar di Wilayah tidak harus mengetahui bagaimana permintaan baca dan tulis dirutekan oleh layanan mikro. Dalam desain yang kuat, Wilayah penerima memvalidasi apakah Wilayah tersebut merupakan wilayah primer saat ini untuk operasi tulis. Jika tidak, maka akan muncul kesalahan yang menunjukkan bahwa status global perlu diperbaiki. Wilayah penerima mungkin juga melakukan buffering pada operasi tulis untuk sementara waktu jika Wilayah utama sedang dalam proses perubahan. Dalam semua kasus, tumpukan komputasi di suatu Wilayah hanya menulis ke titik akhir DynamoDB lokalnya, tetapi tumpukan komputasi tersebut mungkin berkomunikasi satu sama lain.

Diagram perutean permintaan lapisan komputasi.

Vanguard Group menggunakan sistem yang disebut Global Orchestration and Status Tool (GOaST) dan perpustakaan bernama Global Multi-Region library (GMRlib) untuk proses routing ini, seperti yang disajikan di re:Invent 2022. Mereka menggunakan model primer follow-the-sun tunggal. GOaST mempertahankan keadaan global, mirip dengan kontrol routing ARC yang dibahas di bagian sebelumnya. Ini menggunakan tabel global untuk melacak Wilayah mana yang merupakan Wilayah utama dan kapan sakelar utama berikutnya dijadwalkan. Semua operasi baca dan tulis dilalui GMRlib, yang berkoordinasi dengan GOa ST. GMRlib memungkinkan operasi baca dilakukan secara lokal, pada latensi rendah. Untuk operasi tulis, GMRlib periksa apakah Wilayah lokal adalah Wilayah utama saat ini. Jika ya, operasi tulis selesai secara langsung. Jika tidak, GMRlib teruskan tugas menulis ke GMRlib dalam Wilayah utama. Pustaka penerima tersebut mengonfirmasi bahwa ia juga menganggap dirinya sebagai Wilayah utama dan menimbulkan kesalahan jika bukan, yang menunjukkan penundaan penyebaran dengan keadaan global. Pendekatan ini memberikan manfaat validasi dengan tidak menulis langsung ke titik akhir DynamoDB jarak jauh.

Perutean permintaan Route 53

Amazon Application Recovery Controller (ARC) adalah teknologi Domain Name Service (DNS). Dengan RouteĀ 53, klien meminta titik akhir dengan mencari nama domain DNS yang dikenal, dan RouteĀ 53 mengembalikan alamat IP yang sesuai dengan titik akhir regional yang dianggap paling tepat. Ini diilustrasikan dalam diagram berikut. Route 53 memiliki daftar panjang kebijakan perutean yang digunakan untuk menentukan Wilayah yang sesuai. Itu juga dapat melakukan routing failover untuk merutekan lalu lintas dari Wilayah yang gagal pemeriksaan kesehatan.

Diagram perutean permintaan lapisan komputasi.

Dengan mode tulis ke Wilayah mana pun, atau jika digabungkan dengan perutean permintaan lapisan komputasi di backend, Route 53 dapat diberi akses penuh untuk mengembalikan Wilayah berdasarkan aturan internal kompleks seperti Wilayah dalam kedekatan jaringan terdekat, atau kedekatan geografis terdekat, atau pilihan lainnya.

Dengan menulis ke satu mode Wilayah, Anda dapat mengonfigurasi Route 53 untuk mengembalikan Wilayah yang sedang aktif (menggunakan Route 53 ARC). Jika klien ingin terhubung ke Region pasif (misalnya, untuk operasi baca), itu bisa mencari nama DNS yang berbeda.

catatan

Klien menyimpan alamat IP dalam respons dari Route 53 selama waktu yang ditunjukkan oleh pengaturan waktu untuk tayang (TTL) pada nama domain. TTL yang lebih panjang memperpanjang sasaran waktu pemulihan (RTO) bagi semua klien untuk mengenali titik akhir baru. Nilai 60 detik adalah tipikal untuk penggunaan failover. Tidak semua perangkat lunak dengan sempurna mematuhi kedaluwarsa DNS TTL, dan mungkin ada beberapa tingkat cache DNS, seperti pada sistem operasi, mesin virtual, dan aplikasi.

Dengan mode tulis ke Wilayah Anda, sebaiknya hindari Route 53 kecuali Anda juga menggunakan perutean permintaan lapisan komputasi.

Perutean permintaan Global Accelerator

Dengan AWS Global Accelerator, diilustrasikan dalam diagram berikut, klien mencari nama domain terkenal di Route 53. Namun, alih-alih mendapatkan kembali alamat IP yang sesuai dengan titik akhir Regional, klien menerima alamat IP statis anycast yang merutekan ke lokasi AWS tepi terdekat. Mulai dari lokasi edge tersebut, semua lalu lintas dirutekan di jaringan AWS privat dan ke beberapa titik akhir (seperti penyeimbang beban atau API Gateway) di Wilayah yang dipilih berdasarkan aturan perutean yang dikelola dalam Global Accelerator. Dibandingkan dengan perutean berdasarkan aturan Route 53, perutean permintaan Global Accelerator memiliki latensi yang lebih rendah karena mengurangi jumlah lalu lintas di internet publik. Selain itu, karena Global Accelerator tidak bergantung pada kedaluwarsa DNS TTL untuk mengubah aturan perutean, ia dapat menyesuaikan perutean lebih cepat.

Diagram cara kerja penulisan klien dengan Global Accelerator.

Dengan mode tulis ke Wilayah mana pun, atau jika dikombinasikan dengan perutean permintaan lapisan komputasi di back-end, Global Accelerator dapat bekerja dengan lancar. Klien terhubung ke lokasi edge terdekat dan tidak perlu khawatir dengan Wilayah mana yang menerima permintaan.

Dengan tulis ke satu Wilayah, aturan perutean Global Accelerator harus mengirimkan permintaan ke Wilayah yang sedang aktif. Anda dapat menggunakan pemeriksaan kondisi yang secara artifisial melaporkan kegagalan pada Wilayah yang tidak diperhitungkan sebagai Wilayah aktif oleh sistem global Anda. Seperti halnya DNS, nama domain DNS alternatif dapat digunakan untuk merutekan permintaan baca jika permintaan tersebut dapat berasal dari Wilayah mana pun.

Dengan mode tulis ke Wilayah Anda, sebaiknya hindari Global Accelerator kecuali Anda juga menggunakan perutean permintaan lapisan komputasi.