Memecahkan masalah latensi di Amazon DynamoDB

Jika beban kerja Anda tampaknya mengalami latensi tinggi, Anda dapat menganalisis CloudWatch SuccessfulRequestLatency metrik, dan memeriksa latensi rata-rata untuk melihat apakah itu terkait dengan DynamoDB. Beberapa variabilitas dalam SuccessfulRequestLatency yang dilaporkan adalah normal, dan lonjakan yang terjadi sesekali (khususnya dalam statistik Maximum) tidak perlu dikhawatirkan. Namun, jika statistik Average menunjukkan peningkatan tajam dan terus berlanjut, Anda harus memeriksa Service Health Dashboard dan Personal Health Dashboard AWS Anda untuk informasi selengkapnya. Beberapa kemungkinan penyebabnya mencakup ukuran item di tabel Anda (item 1kb dan item 400kb akan bervariasi dalam latensi) atau ukuran kueri (10 item versus 100 item).

Jika perlu, pertimbangkan untuk membuka kasus dukungan dengan AWS Support, dan terus menilai opsi cadangan yang tersedia untuk aplikasi Anda (seperti evakuasi Wilayah jika Anda memiliki arsitektur multi-Wilayah) sesuai dengan runbook Anda. Anda harus mencatat ID permintaan untuk permintaan lambat untuk memberikan ID ini AWS Support ketika Anda membuka kasus dukungan.

Metrik SuccessfulRequestLatency hanya mengukur latensi yang bersifat internal pada layanan DynamoDB - aktivitas sisi klien dan waktu perjalanan jaringan tidak disertakan. Untuk mempelajari selengkapnya tentang latensi keseluruhan untuk panggilan dari klien Anda ke layanan DynamoDB, Anda dapat mengaktifkan pencatatan metrik latensi di AWS SDK Anda.

catatan

Untuk sebagian besar operasi tunggal (operasi yang berlaku pada satu item dengan menentukan sepenuhnya nilai kunci primer), DynamoDB memberikan Average SuccessfulRequestLatency milidetik satu digit. Nilai ini tidak termasuk overhead transport untuk kode pemanggil yang mengakses titik akhir DynamoDB. Untuk operasi data multi-item, latensi akan bervariasi berdasarkan faktor-faktor seperti ukuran set hasil, kompleksitas struktur data yang dikembalikan, dan ekspresi kondisi dan ekspresi filter apa pun yang diterapkan. Untuk operasi multi-item berulang pada kumpulan data yang sama dengan parameter yang sama, DynamoDB akan memberikan Average SuccessfulRequestLatency yang sangat konsisten.

Pertimbangkan satu atau beberapa strategi berikut untuk mengurangi latensi:

• Sesuaikan batas waktu permintaan dan perilaku percobaan ulang: Jalur dari klien Anda ke DynamoDB melintasi banyak komponen, yang masing-masing dirancang dengan mempertimbangkan redundansi. Pikirkan tentang cakupan ketahanan jaringan, batas waktu paket TCP, dan arsitektur terdistribusi DynamoDB itu sendiri. Perilaku SDK default dirancang untuk menemukan keseimbangan yang tepat untuk sebagian besar aplikasi. Jika latensi terbaik adalah prioritas tertinggi Anda, Anda harus mempertimbangkan untuk menyesuaikan waktu tunggu permintaan default dan pengaturan coba lagi untuk SDK Anda agar dapat melacak dengan cermat latensi umum untuk permintaan yang berhasil diukur oleh klien Anda. Permintaan yang memakan waktu jauh lebih lama dari biasanya kecil kemungkinannya untuk berhasil - jika Anda gagal cepat (fail fast) dan membuat permintaan baru, kemungkinan besar permintaan tersebut akan mengambil jalur yang berbeda dan mungkin berhasil dengan cepat. Ingatlah bahwa ada kerugian jika bersikap terlalu agresif dalam situasi ini. Diskusi bermanfaat mengenai topik ini dapat ditemukan di Menyetel pengaturan permintaan AWS Java SDK HTTP untuk aplikasi Amazon DynamoDB yang sadar latensi.

• Kurangi jarak antara klien dan titik akhir DynamoDB: Jika Anda memiliki pengguna yang tersebar secara global, pertimbangkan untuk menggunakan Tabel global - Replikasi multi-Wilayah untuk DynamoDB. Dengan tabel global, Anda dapat menentukan Wilayah AWS tempat Anda ingin tabel tersedia. Membaca data dari replika tabel global lokal dapat mengurangi latensi bagi pengguna Anda secara signifikan. Selain itu, pertimbangkan untuk menggunakan titik akhir gateway DynamoDB untuk menjaga lalu lintas klien Anda tetap dalam VPC Anda.

• Gunakan caching: Jika lalu lintas Anda banyak dibaca, pertimbangkan untuk menggunakan layanan caching, seperti Akselerasi dalam memori dengan DynamoDB Accelerator (DAX). DAX adalah cache dalam memori yang terkelola sepenuhnya dan memiliki ketersediaan tinggi untuk DynamoDB yang memberikan peningkatan performa hingga 10x, dari milidetik hingga mikrodetik, bahkan pada jutaan permintaan per detik.

• Gunakan kembali koneksi: Permintaan DynamoDB dibuat melalui sesi yang diautentikasi yang default ke HTTPS. Memulai koneksi membutuhkan waktu sehingga latensi permintaan pertama lebih tinggi dari biasanya. Permintaan melalui koneksi yang sudah diinisialisasi menghasilkan latensi rendah DynamoDB yang konsisten. Karena alasan ini, Anda mungkin ingin membuat permintaan GetItem "tetap hidup" setiap 30 detik jika tidak ada permintaan lain yang dibuat, untuk menghindari latensi dalam pembuatan koneksi baru.

• Gunakan pembacaan yang pada akhirnya konsisten: Jika aplikasi Anda tidak memerlukan bacaan sangat konsisten, pertimbangkan untuk menggunakan bacaan akhir konsisten secara default. Pembacaan akhir konsisten berbiaya lebih rendah dan juga kecil kemungkinannya mengalami peningkatan latensi sementara. Lihat informasi yang lebih lengkap di Konsistensi baca.