Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Langkah-langkah pemecahan masalah umum dan praktik terbaik dengan ElastiCache
Topik berikut memberikan saran pemecahan masalah untuk kesalahan dan masalah yang mungkin Anda temui saat menggunakan. ElastiCache Jika Anda menemukan masalah yang tidak tercantum di sini, Anda dapat menggunakan tombol umpan balik di halaman ini untuk melaporkannya.
Topik
Masalah koneksi
Jika Anda tidak dapat terhubung ke ElastiCache cache Anda, pertimbangkan salah satu dari berikut ini:
Menggunakan TLS: Jika Anda mengalami koneksi macet saat mencoba terhubung ke ElastiCache titik akhir Anda, Anda mungkin tidak menggunakan TLS di klien Anda. Jika Anda menggunakan ElastiCache Tanpa Server, enkripsi dalam perjalanan selalu diaktifkan. Pastikan klien Anda menggunakan TLS untuk terhubung ke cache. Pelajari lebih lanjut tentang menghubungkan ke cache yang diaktifkan TLS.
VPC: ElastiCache cache hanya dapat diakses dari dalam VPC. Pastikan bahwa EC2 instance dari mana Anda mengakses cache dan ElastiCache cache dibuat dalam VPC yang sama. Atau, Anda harus mengaktifkan peering VPC antara VPC tempat instance Anda EC2 berada dan VPC tempat Anda membuat cache.
Grup keamanan: ElastiCache menggunakan grup keamanan untuk mengontrol akses ke cache Anda. Pertimbangkan hal berikut:
Pastikan bahwa grup keamanan yang digunakan oleh ElastiCache cache Anda memungkinkan akses masuk ke sana dari EC2 instance Anda. Lihat di sini untuk mempelajari cara mengatur aturan masuk di grup keamanan Anda dengan benar.
Pastikan bahwa grup keamanan yang digunakan oleh ElastiCache cache Anda memungkinkan akses ke port cache Anda (6379 dan 6380 untuk tanpa server, dan 6379 secara default untuk dirancang sendiri). ElastiCache menggunakan port ini untuk menerima perintah Valkey atau Redis OSS. Pelajari lebih lanjut tentang cara mengatur akses port di sini.
Jika koneksi terus sulit, lihat Masalah koneksi persisten langkah-langkah lain.
Kesalahan klien Valkey atau Redis OSS
ElastiCache Tanpa server hanya dapat diakses menggunakan klien yang mendukung protokol mode cluster Valkey atau Redis OSS. Cluster yang dirancang sendiri dapat diakses dari klien dalam mode mana pun, tergantung pada konfigurasi cluster.
Jika Anda mengalami kesalahan pada klien Anda, pertimbangkan hal berikut:
Mode cluster: Jika Anda mengalami kesalahan atau kesalahan CROSSLOT dengan perintah SELECT
, Anda mungkin mencoba mengakses cache Cluster Mode Enabled dengan klien Valkey atau Redis OSS yang tidak mendukung protokol Cluster. ElastiCache Tanpa server hanya mendukung klien yang mendukung protokol cluster Valkey atau Redis OSS. Jika Anda ingin menggunakan Valkey atau Redis OSS di “Cluster Mode Disabled” (CMD), maka Anda harus mendesain cluster Anda sendiri. Kesalahan CROSSLOT: Jika Anda mengalami
ERR CROSSLOT Keys in request don't hash to the same slotkesalahan, Anda mungkin mencoba mengakses kunci yang tidak termasuk dalam slot yang sama dalam cache mode Cluster. Sebagai pengingat, ElastiCache Serverless selalu beroperasi dalam Mode Cluster. Operasi multi-kunci, transaksi, atau skrip Lua yang melibatkan beberapa kunci hanya diperbolehkan jika semua kunci yang terlibat berada dalam slot hash yang sama.
Memecahkan masalah latensi tinggi di Tanpa Server ElastiCache
Jika beban kerja Anda tampaknya mengalami latensi tinggi, Anda dapat menganalisis CloudWatch SuccessfulReadRequestLatency dan SuccessfulWriteRequestLatency metrik untuk memeriksa apakah latensi terkait dengan Tanpa Server. ElastiCache Metrik ini mengukur latensi yang internal ke ElastiCache Tanpa Server - latensi sisi klien dan waktu perjalanan jaringan antara klien Anda dan titik akhir Tanpa ElastiCache Server tidak disertakan.
Memecahkan masalah latensi sisi klien
Jika Anda melihat peningkatan latensi di sisi klien tetapi tidak ada peningkatan CloudWatch SuccessfulReadRequestLatency dan SuccessfulWriteRequestLatency metrik yang sesuai yang mengukur latensi sisi server, pertimbangkan hal berikut:
Pastikan grup keamanan memungkinkan akses ke port 6379 dan 6380: ElastiCache Tanpa server menggunakan port 6379 untuk titik akhir primer dan port 6380 untuk titik akhir pembaca. Beberapa klien membuat konektivitas ke kedua port untuk setiap koneksi baru, bahkan jika aplikasi Anda tidak menggunakan fitur Baca dari Replika. Jika grup keamanan Anda tidak mengizinkan akses masuk ke kedua port, maka pembentukan koneksi dapat memakan waktu lebih lama. Pelajari lebih lanjut tentang cara mengatur akses port di sini.
Memecahkan masalah latensi sisi server
Beberapa variabilitas dan lonjakan sesekali seharusnya tidak menjadi perhatian. Namun, jika Average statistik menunjukkan peningkatan tajam dan berlanjut, Anda harus memeriksa AWS Health Dashboard dan Dashboard Personal Health Anda untuk informasi lebih lanjut. Jika perlu, pertimbangkan untuk membuka kasus dukungan dengan Dukungan.
Pertimbangkan praktik dan strategi terbaik berikut untuk mengurangi latensi:
Aktifkan Baca dari Replika: Jika aplikasi Anda mengizinkannya, sebaiknya aktifkan fitur “Baca dari Replika” di klien Valkey atau Redis OSS Anda untuk menskalakan pembacaan dan mencapai latensi yang lebih rendah. Saat diaktifkan, ElastiCache Serverless mencoba merutekan permintaan baca Anda ke replika node cache yang berada di Availability Zone (AZ) yang sama dengan klien Anda, sehingga menghindari latensi jaringan lintas-AZ. Perhatikan, bahwa mengaktifkan fitur Baca dari Replika di klien Anda menandakan bahwa aplikasi Anda akhirnya menerima konsistensi data. Aplikasi Anda mungkin menerima data lama untuk beberapa waktu jika Anda mencoba membaca setelah menulis ke kunci.
Pastikan aplikasi Anda di-deploy AZs sama dengan cache Anda: Anda dapat mengamati latensi sisi klien yang lebih tinggi jika aplikasi Anda tidak di-deploy AZs sama dengan cache Anda. Saat Anda membuat cache tanpa server, Anda dapat menyediakan subnet dari mana aplikasi Anda akan mengakses cache, dan ElastiCache Tanpa Server membuat VPC Endpoint di subnet tersebut. Pastikan aplikasi Anda digunakan dalam hal yang sama AZs. Jika tidak, aplikasi Anda mungkin mengalami lompatan lintas-AZ saat mengakses cache yang menghasilkan latensi sisi klien yang lebih tinggi.
Gunakan kembali koneksi: Permintaan ElastiCache tanpa server dibuat melalui koneksi TCP yang diaktifkan TLS menggunakan protokol RESP. Memulai koneksi (termasuk mengautentikasi koneksi, jika dikonfigurasi) membutuhkan waktu sehingga latensi permintaan pertama lebih tinggi dari biasanya. Permintaan melalui koneksi yang sudah diinisialisasi memberikan ElastiCache latensi rendah yang konsisten. Untuk alasan ini, Anda harus mempertimbangkan untuk menggunakan penyatuan koneksi atau menggunakan kembali koneksi Valkey atau Redis OSS yang ada.
Kecepatan penskalaan: ElastiCache Tanpa server secara otomatis menskalakan seiring dengan bertambahnya tingkat permintaan Anda. Peningkatan besar secara tiba-tiba dalam tingkat permintaan, lebih cepat daripada kecepatan skala ElastiCache Tanpa Server, dapat mengakibatkan peningkatan latensi untuk beberapa waktu. ElastiCache Tanpa server biasanya dapat meningkatkan tingkat permintaan yang didukung dengan cepat, membutuhkan waktu hingga 10-12 menit untuk menggandakan tingkat permintaan.
Periksa perintah yang berjalan lama: Beberapa perintah Valkey atau Redis OSS, termasuk skrip Lua atau perintah pada struktur data besar, dapat berjalan untuk waktu yang lama. Untuk mengidentifikasi perintah ini, ElastiCache menerbitkan metrik tingkat perintah. Dengan ElastiCache Tanpa Server Anda dapat menggunakan metrik.
BasedECPUsPermintaan Terbatas: Saat permintaan dibatasi di ElastiCache Tanpa Server, Anda mungkin mengalami peningkatan latensi sisi klien dalam aplikasi Anda. Saat permintaan dibatasi di ElastiCache Tanpa Server, Anda akan melihat peningkatan metrik Tanpa Server. ThrottledRequests ElastiCache Tinjau bagian di bawah ini untuk memecahkan masalah permintaan yang dibatasi.
Distribusi kunci dan permintaan yang seragam: ElastiCache Untuk Valkey dan Redis OSS, distribusi kunci atau permintaan per slot yang tidak merata dapat menghasilkan slot panas yang dapat menghasilkan latensi tinggi. ElastiCache Tanpa server mendukung hingga 30.000 ECPUs /detik (90.000 ECPUs /detik saat menggunakan Read from Replica) pada satu slot, dalam beban kerja yang mengeksekusi perintah SET/GET sederhana. Sebaiknya evaluasi distribusi kunci dan permintaan Anda di seluruh slot dan memastikan distribusi yang seragam jika tingkat permintaan Anda melebihi batas ini.
Memecahkan masalah pembatasan di Tanpa Server ElastiCache
Dalam arsitektur berorientasi layanan dan sistem terdistribusi, membatasi kecepatan pemrosesan panggilan API oleh berbagai komponen layanan disebut throttling. Ini menghaluskan lonjakan, mengontrol ketidakcocokan dalam throughput komponen, dan memungkinkan pemulihan yang lebih dapat diprediksi ketika ada peristiwa operasional yang tidak terduga. ElastiCache Tanpa server dirancang untuk jenis arsitektur ini, dan sebagian besar klien Valkey atau Redis OSS memiliki percobaan ulang bawaan untuk permintaan yang dibatasi. Throttling pada tingkat tertentu belum tentu menjadi masalah bagi aplikasi Anda, tetapi throttling yang terus-menerus pada bagian alur kerja data Anda yang sensitif terhadap latensi dapat berdampak negatif terhadap pengalaman pengguna dan mengurangi efisiensi sistem secara keseluruhan.
Saat permintaan dibatasi di ElastiCache Tanpa Server, Anda akan melihat peningkatan metrik Tanpa Server. ThrottledRequests ElastiCache Jika Anda melihat sejumlah besar permintaan terbatas, pertimbangkan hal berikut:
Kecepatan penskalaan: ElastiCache Tanpa server secara otomatis menskalakan saat Anda menelan lebih banyak data atau meningkatkan tingkat permintaan Anda. Jika aplikasi Anda menskalakan lebih cepat daripada kecepatan skala Tanpa Server, permintaan Anda mungkin terhambat saat ElastiCache Tanpa Server menskalakan untuk mengakomodasi beban kerja Anda. ElastiCache ElastiCache Tanpa server biasanya dapat meningkatkan ukuran penyimpanan dengan cepat, membutuhkan waktu hingga 10-12 menit untuk menggandakan ukuran penyimpanan di cache Anda.
Distribusi kunci dan permintaan yang seragam: Dalam ElastiCache, distribusi kunci atau permintaan per slot yang tidak merata dapat menghasilkan slot panas. Slot panas dapat mengakibatkan pembatasan permintaan jika tingkat permintaan ke satu slot melebihi 30.000 ECPUs /detik, dalam beban kerja yang mengeksekusi perintah SET/GET sederhana.
Baca dari Replika: Jika aplikasi Anda mengizinkannya, pertimbangkan untuk menggunakan fitur “Baca dari Replika”. Sebagian besar klien Valkey atau Redis OSS dapat dikonfigurasi ke” pembacaan skala “untuk mengarahkan pembacaan ke node replika. Fitur ini memungkinkan Anda untuk menskalakan lalu lintas baca. Selain itu ElastiCache Tanpa Server secara otomatis merutekan pembacaan dari permintaan replika ke node di Availability Zone yang sama dengan aplikasi Anda sehingga latensi lebih rendah. Ketika Read from Replica diaktifkan, Anda dapat mencapai hingga 90.000 ECPUs /detik pada satu slot, untuk beban kerja dengan perintah SET/GET sederhana.
Topik Terkait
