Memecahkan masalah latensi di Amazon DynamoDB - Amazon DynamoDB

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

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 dan latensi median melalui metrik persentil (p50) untuk melihat apakah itu terkait dengan DynamoDB. Beberapa variabilitas dalam laporan SuccessfulRequestLatency adalah normal, dan lonjakan sesekali (terutama dalam Maximum statistik dan persentil tinggi) tidak boleh menjadi perhatian. Namun, jika Average statistik atau p50 (median) menunjukkan peningkatan tajam dan berlanjut, Anda harus memeriksa AWS Service Health Dashboard dan Personal Health Dashboard Anda untuk informasi lebih lanjut. Beberapa kemungkinan penyebab termasuk ukuran item di tabel Anda (item 1 KB dan item 400 KB akan bervariasi dalam latensi) atau ukuran kueri (10 item versus 100 item).

Metrik persentil (p99, p90, dll.) Dapat membantu Anda lebih memahami distribusi latensi Anda. Misalnya:

  • p50 (median) menunjukkan latensi tipikal untuk beban kerja Anda.

  • p90 menunjukkan bahwa 90 persen permintaan lebih cepat dari nilai ini.

  • p99 membantu mengidentifikasi latensi kasus terburuk yang memengaruhi 1 persen permintaan.

Nilai p99 tinggi dengan nilai p50 normal mungkin menunjukkan masalah sporadis yang memengaruhi sebagian kecil permintaan, sementara nilai p50 yang meningkat secara konsisten mungkin menunjukkan beberapa penurunan kinerja.

catatan

Untuk menganalisis nilai persentil kustom (seperti p99.9), Anda dapat memasukkan persentil yang diinginkan secara manual (misalnya, p99.9) di bidang statistik metrik. CloudWatch Ini memungkinkan Anda untuk mengevaluasi distribusi latensi di luar persentil default yang tercantum dalam dropdown.

Beberapa variasi dalam metrik latensi, terutama dalam persentil yang lebih tinggi, diharapkan dan dapat dilihat sebagai hasil dari operasi latar belakang berbasis DynamoDB yang membantu menjaga ketersediaan dan daya tahan tinggi untuk data Anda yang disimpan dalam tabel DynamoDB atau masalah infrastruktur sementara.

Jika perlu, pertimbangkan untuk membuka kasus dukungan dengan AWS Dukungan, dan terus menilai opsi mundur yang tersedia untuk aplikasi Anda (seperti evakuasi Wilayah jika Anda memiliki arsitektur Multi-wilayah) sesuai dengan runbook Anda. Anda harus mencatat permintaan IDs untuk permintaan lambat untuk menyediakan ini IDs AWS Dukungan ketika Anda membuka kasus dukungan.

SuccessfulRequestLatencyMetrik hanya mengukur latensi yang internal ke layanan DynamoDB — aktivitas sisi klien dan waktu perjalanan jaringan tidak disertakan. Untuk mempelajari lebih lanjut tentang latensi keseluruhan untuk panggilan dari klien ke layanan DynamoDB, Anda dapat mengaktifkan pencatatan metrik latensi di SDK. AWS

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:

  • Gunakan kembali koneksi: Permintaan DynamoDB dibuat melalui sesi yang diautentikasi melalui HTTPS secara default. Memulai koneksi memerlukan beberapa perjalanan pulang-pergi dan membutuhkan waktu sehingga latensi permintaan pertama lebih tinggi daripada permintaan berikut yang menggunakan kembali koneksi. Permintaan melalui koneksi yang sudah diinisialisasi menghasilkan latensi rendah DynamoDB yang konsisten. Untuk menghindari overhead latensi dalam membuat koneksi baru, Anda mungkin ingin menerapkan mekanisme “keep-alive” dengan mengirimkan GetItem permintaan setiap 30 detik jika tidak ada permintaan lain yang dibuat.

  • Gunakan pembacaan yang pada akhirnya konsisten: Jika aplikasi Anda tidak memerlukan bacaan sangat konsisten, pertimbangkan untuk menggunakan bacaan akhir konsisten secara default. Akhirnya pembacaan yang konsisten memiliki biaya lebih rendah dan dapat berasal dari beberapa zona ketersediaan, memungkinkan pemilihan zona ketersediaan yang ditempatkan bersama ke pemohon yang mengurangi latensi. Untuk informasi selengkapnya, lihat DynamoDB membaca konsistensi.

  • Terapkan lindung nilai permintaan: Untuk persyaratan latensi p99 yang sangat rendah, pertimbangkan untuk menerapkan lindung nilai permintaan. Dengan hedging permintaan, jika permintaan awal tidak menerima respons dengan cukup cepat, kirim permintaan setara kedua dan biarkan mereka berlomba, respons pertama menang. Ini meningkatkan latensi ekor dengan mengorbankan beberapa permintaan tambahan. Anda dapat memutuskan berapa lama menunggu sebelum mengirim permintaan kedua. Hedging lebih mudah dibaca. Untuk penulisan, gunakan pemesanan berbasis stempel waktu untuk memastikan permintaan lindung nilai diperlakukan sebagai terjadi pada saat upaya pertama, mencegah pembaruan. out-of-order Pendekatan ini telah dibahas di Timestamp menulis untuk lindung nilai tulis di Amazon DynamoDB.

  • Sesuaikan batas waktu permintaan dan perilaku coba lagi: Jalur dari klien Anda ke DynamoDB melintasi banyak komponen, masing-masing dirancang dengan mempertimbangkan redundansi. Pertimbangkan aspek-aspek berikut:

    • Ketahanan jaringan

    • Batas waktu paket TCP

    • Arsitektur terdistribusi DynamoDB

    Perilaku SDK default dioptimalkan untuk sebagian besar aplikasi. Namun, Anda dapat menerapkan strategi cepat gagal dan menyesuaikan pengaturan batas waktu. Permintaan yang memakan waktu jauh lebih lama dari biasanya cenderung tidak berhasil pada akhirnya. Dengan gagal cepat dan mencoba lagi, Anda dapat dengan cepat berhasil melalui jalan yang berbeda. Ini mirip dengan permintaan lindung nilai tetapi mengakhiri permintaan pertama alih-alih mengizinkannya untuk melanjutkan.

    Hindari pengaturan nilai batas waktu terlalu rendah. Batas waktu yang terlalu rendah dapat menyebabkan masalah ketersediaan yang disebabkan oleh klien. Misalnya, batas waktu soket 50 milidetik dapat menyebabkan kesalahan koneksi selama lonjakan latensi jaringan, seperti saat mendekati batas bandwidth EC2 instans Amazon untuk lalu lintas aliran tunggal. Pertimbangkan dengan cermat manfaat batas waktu yang lebih rendah terhadap potensi risiko ketersediaan aplikasi, dan lebih memilih lindung nilai daripada batas waktu singkat.

    Untuk diskusi bermanfaat tentang topik ini, lihat Menyetel setelan permintaan HTTP SDK AWS Java 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 mereplikasi tabel Anda ke AWS Wilayah tertentu di mana Anda ingin tabel tersedia. Anda dapat menempatkan salinan data lebih dekat ke pengguna akhir untuk mengurangi latensi jaringan selama operasi baca dan tulis. Untuk informasi selengkapnya tentang penggunaan tabel global DynamoDB secara efektif, lihat Menggunakan tabel global Amazon DynamoDB di Panduan Preskriptif. AWS

  • Gunakan caching: Jika lalu lintas Anda banyak dibaca, pertimbangkan untuk menggunakan salah satu layanan caching ini: