Langkah-langkah pemecahan masalah umum dan praktik terbaik

Masalah koneksi

Jika Anda tidak dapat terhubung ke ElastiCache cache Anda, pertimbangkan salah satu dari berikut ini:

1. 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 di sini.

2. VPC: ElastiCache cache hanya dapat diakses dari dalam VPC. Pastikan bahwa instans EC2 dari mana Anda mengakses cache dan cache dibuat dalam VPC yang sama. ElastiCache Atau, Anda harus mengaktifkan peering VPC antara VPC tempat instans EC2 Anda berada dan VPC tempat Anda membuat cache.

3. Grup keamanan: ElastiCache menggunakan grup keamanan untuk mengontrol akses ke cache Anda. Pertimbangkan hal berikut:

   1. Pastikan bahwa grup keamanan yang digunakan oleh ElastiCache cache Anda memungkinkan akses masuk ke sana dari instans EC2 Anda. Lihat di sini untuk mempelajari cara mengatur aturan masuk di grup keamanan Anda dengan benar.

   2. 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 Redis OSS. Pelajari lebih lanjut tentang cara mengatur akses port di sini.

Kesalahan klien Redis OSS

ElastiCache Tanpa server hanya dapat diakses menggunakan klien Redis OSS yang mendukung protokol mode cluster Redis OSS. Cluster yang dirancang sendiri dapat diakses dari klien Redis OSS dalam mode mana pun, tergantung pada konfigurasi cluster.

Jika Anda mengalami kesalahan Redis OSS di klien Anda, pertimbangkan hal berikut:

1. Mode cluster: Jika Anda mengalami kesalahan atau kesalahan CROSSLOT dengan perintah SELECT Redis OSS, Anda mungkin mencoba mengakses cache Cluster Mode Enabled dengan klien Redis OSS yang tidak mendukung protokol Redis OSS Cluster. ElastiCache Tanpa server hanya mendukung klien Redis OSS yang mendukung protokol cluster Redis OSS. Jika Anda ingin menggunakan Redis OSS di “Cluster Mode Disabled” (CMD), maka Anda harus mendesain cluster Anda sendiri.

2. Kesalahan CROSSLOT: Jika Anda mengalami ERR CROSSLOT Keys in request don't hash to the same slot kesalahan, 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.

Untuk praktik terbaik tambahan seputar mengonfigurasi klien Redis OSS, silakan tinjau posting blog ini.

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 AWS Support.

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 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 dalam AZ yang sama dengan cache Anda: Anda dapat mengamati latensi sisi klien yang lebih tinggi jika aplikasi Anda tidak di-deploy di AZ yang 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 disebarkan di AZ yang sama. 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 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 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. BasedECPUs

• Permintaan 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: Dalam ElastiCache (Redis OSS), distribusi kunci atau permintaan per slot yang tidak merata dapat menghasilkan slot panas yang dapat mengakibatkan latensi tinggi. ElastiCache Tanpa server mendukung hingga 30.000 ECPUS/detik (90.000 ECPU/detik saat menggunakan Baca dari Replika) pada satu slot, dalam beban kerja yang menjalankan 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 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 (Redis OSS), 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 ECPU/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 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 ECPU/detik pada satu slot, untuk beban kerja dengan perintah SET/GET sederhana.

Topik Terkait

• Langkah pemecahan masalah tambahan

• ElastiCache praktik terbaik dan strategi caching