Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Minta perutean dengan tabel global 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 (AmazonEC2), 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. Latensi yang terkait dengan lintas Wilayah mungkin 100 kali lebih tinggi dibandingkan akses lokal. back-and-forthSerangkaian 5 permintaan mungkin membutuhkan milidetik saat dilakukan secara lokal tetapi detik saat melintasi dunia. Sebaiknya rutekan pengguna akhir ke Wilayah lain untuk diproses. Untuk memastikan ketahanan, Anda memerlukan replikasi di beberapa Wilayah, dengan 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, klien pengguna akhir seperti aplikasi, halaman web dengan klien JavaScript lain akan melacak titik akhir aplikasi yang valid. Dalam hal ini yang akan menjadi titik akhir aplikasi seperti Amazon API Gateway daripada titik akhir DynamoDB literal. Klien pengguna akhir menggunakan logika tersematnya sendiri untuk memilih Wilayah mana yang akan berkomunikasi. Pengguna akhir tersebut dapat memilih berdasarkan pemilihan acak, latensi terendah yang diamati, pengukuran bandwidth tertinggi yang diamati, atau pemeriksaan kesehatan yang dilakukan secara lokal.
Keuntungan perutean permintaan berbasis klien adalah dapat adaptif terhadap hal-hal seperti kondisi lalu lintas internet publik di dunia nyata untuk berpindah Wilayah jika terjadi penurunan performa. Klien harus mengetahui semua titik akhir potensial, tetapi peluncuran titik akhir Regional baru bukanlah hal yang sering terjadi.
Dengan mode tulis ke Wilayah mana pun, klien dapat memilih titik akhir pilihannya secara sepihak. 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 Route 53 Application Recovery Controller (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 perutean permintaan lapisan komputasi, kode yang berjalan di lapisan komputasi memutuskan apakah kode akan memproses permintaan secara lokal, atau meneruskannya ke salinannya sendiri yang berjalan di Wilayah lain. Saat Anda menggunakan mode tulis ke satu Wilayah, lapisan komputasi dapat mendeteksi bahwa itu bukan wilayah yang aktif dan memungkinkan operasi baca lokal sekaligus meneruskan semua operasi tulis ke Wilayah lain. Kode lapisan komputasi ini harus mengetahui topologi data dan aturan perutean, serta menerapkannya secara andal berdasarkan pengaturan terbaru yang menentukan Wilayah yang aktif untuk data tertentu. Tumpukan perangkat lunak luar di dalam 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.
Dalam skenario ini, katakanlah perusahaan jasa keuangan menggunakan model follow-the-sun Single Primary. Mereka menggunakan sistem dan pustaka untuk proses perutean ini. Sistem mereka secara keseluruhan mempertahankan keadaan global, mirip AWS dengan kontrol ARC routing. Mereka menggunakan tabel global untuk melacak Wilayah yang merupakan Wilayah utama, dan kapan peralihan utama berikutnya dijadwalkan. Semua operasi baca dan tulis melalui pustaka, yang berkoordinasi dengan sistemnya. Pustaka memungkinkan operasi baca dilakukan secara lokal dengan latensi rendah. Untuk operasi tulis, aplikasi memeriksa apakah Wilayah lokal adalah Wilayah utama saat ini. Jika ya, operasi tulis selesai secara langsung. Jika tidak, pustaka meneruskan tugas tulis ke pustaka yang ada di Wilayah utama saat ini. 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 DNS domain yang terkenal, dan Route 53 mengembalikan alamat IP yang sesuai dengan titik akhir regional yang menurutnya paling tepat. Route 53 memiliki daftar kebijakan perutean yang digunakan untuk menentukan wilayah yang sesuai. Route 53 juga dapat melakukan perutean failover untuk merutekan lalu lintas dari wilayah yang gagal dalam pemeriksaan kondisi.
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, Route 53 dapat dikonfigurasi untuk mengembalikan wilayah yang saat ini aktif (menggunakan Route 53ARC).
catatan
Klien menyimpan alamat IP dalam respons dari Route 53 untuk waktu yang ditunjukkan oleh pengaturan time to live (TTL) pada nama domain. Yang lebih lama TTL memperpanjang tujuan 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 DNS TTL kedaluwarsa.
Dengan mode tulis ke Wilayah Anda, sebaiknya hindari Route 53 kecuali Anda juga menggunakan perutean permintaan lapisan komputasi.
Perutean permintaan Global Accelerator
Klien menggunakan AWS 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 halnyaDNS, dimungkinkan untuk menggunakan nama DNS domain alternatif untuk merutekan permintaan baca jika permintaan dapat berasal dari Wilayah mana pun.
Dengan mode tulis ke Wilayah Anda, sebaiknya hindari Global Accelerator kecuali Anda juga menggunakan perutean permintaan lapisan komputasi.
