Halaman ini memberikan panduan tentang cara menggunakan Memorystore for Redis Cluster secara optimal. Halaman ini juga menunjukkan potensi masalah yang harus dihindari.
Praktik terbaik pengelolaan memori
Bagian ini menjelaskan strategi untuk mengelola memori instance sehingga Memorystore for Redis Cluster berfungsi secara efisien untuk aplikasi Anda.
Konsep pengelolaan memori
Beban tulis - Volume dan kecepatan saat Anda menambahkan atau memperbarui kunci di cluster Redis. Beban penulisan Anda dapat berkisar dari normal hingga sangat tinggi, bergantung pada kasus penggunaan Redis dan pola penggunaan aplikasi Anda.
Kebijakan pengusiran - Memorystore for Redis Cluster menggunakan
volatile-lrukebijakan pengusiran. Anda dapat menggunakan perintah seperti perintah EXPIRE untuk menetapkan penghapusan untuk kunci.
Memantau cluster yang memiliki beban tulis normal
Lihat metrik /cluster/memory/maximum_utilization. Jika /cluster/memory/maximum_utilization berada pada 100% atau lebih rendah, cluster Redis Anda akan berperforma baik saat Anda menggunakan beban tulis normal.
Namun, jika penggunaan memori Anda mendekati 100% dan Anda memperkirakan penggunaan data akan meningkat, Anda harus meningkatkan ukuran cluster untuk menyediakan ruang bagi data baru.
Memantau cluster yang memiliki beban tulis tinggi
Lihat metrik /cluster/memory/maximum_utilization. Bergantung pada tingkat keparahan beban tulis tinggi, cluster Anda dapat mengalami masalah performa pada nilai minimum berikut:
Beban tulis yang sangat tinggi dapat mengalami masalah jika
/cluster/memory/maximum_utilizationmencapai 65% atau lebih tinggi.Beban penulisan yang cukup tinggi dapat mengalami masalah jika
/cluster/memory/maximum_utilizationmencapai 85% atau lebih tinggi.
Dalam skenario ini, Anda harus meningkatkan ukuran cluster untuk meningkatkan performa.
Jika Anda mengalami masalah, atau khawatir instance Anda memiliki beban penulisan yang tinggi, hubungi Google Cloud Dukungan.
Menskalakan shard
Saat Menskalakan jumlah shard dalam instance, Anda harus melakukan penskalaan selama periode penulisan rendah. Penskalaan selama periode beban tulis tinggi dapat memberikan tekanan memori pada instance Anda karena overhead memori yang disebabkan oleh replikasi atau migrasi slot.
Jika kasus penggunaan Redis Anda menggunakan penghapusan kunci, penskalaan ke ukuran cluster yang lebih kecil dapat mengurangi rasio hit cache Anda. Namun, dalam situasi ini, Anda tidak perlu khawatir kehilangan data karena penghapusan kunci memang diharapkan.
Untuk kasus penggunaan Redis yang tidak ingin kehilangan kunci, Anda hanya boleh melakukan penskalaan ke bawah ke kluster yang lebih kecil yang masih memiliki cukup ruang untuk data Anda. Jumlah shard target baru Anda harus memungkinkan setidaknya 1,5 kali memori yang digunakan oleh data. Dengan kata lain, Anda harus menyediakan cukup shard untuk 1,5 kali jumlah data yang saat ini ada di cluster Anda. Anda dapat menggunakan metrik /cluster/memory/total_used_memory untuk melihat jumlah data yang disimpan di instance Anda.
Praktik terbaik penggunaan CPU
Jika terjadi pemadaman zona yang tidak terduga, hal ini akan menyebabkan penurunan resource CPU untuk cluster Anda karena hilangnya kapasitas dari node di zona yang tidak tersedia. Sebaiknya gunakan cluster ketersediaan tinggi. Menggunakan dua replika per shard (bukan satu replika per shard) memberikan resource CPU tambahan selama dan saat terjadi gangguan. Selain itu, sebaiknya kelola penggunaan CPU node sehingga node memiliki overhead CPU yang cukup untuk menangani traffic tambahan dari kapasitas yang hilang jika terjadi gangguan zonal yang tidak terduga. Anda harus memantau penggunaan CPU untuk instance utama dan replika menggunakan metrik /cluster/cpu/maximum_utilization.
Bergantung pada jumlah replika yang Anda sediakan per node, sebaiknya gunakan target penggunaan CPU /cluster/cpu/maximum_utilization berikut:
- Untuk instance dengan satu replika per node, tetapkan nilai
/cluster/cpu/maximum_utilizationsebesar 0,5 detik untuk instance utama dan 0,5 detik untuk replika, saat replika ditetapkan sebagai replika baca. - Untuk instance dengan dua replika per node, targetkan nilai
/cluster/cpu/maximum_utilizationsebesar 0,8 detik untuk replika utama dan 0,5 detik untuk setiap replika.
Jika nilai metrik melebihi rekomendasi ini, sebaiknya tingkatkan jumlah shard atau replika di instance Anda.
Perintah Redis yang memerlukan banyak resource
Sebaiknya hindari penggunaan perintah Redis yang membutuhkan banyak resource. Penggunaan perintah ini dapat menyebabkan masalah performa berikut:
- Latensi tinggi dan waktu tunggu klien
- Tekanan memori yang disebabkan oleh perintah yang meningkatkan penggunaan memori
- Kehilangan data selama replikasi dan sinkronisasi node karena thread utama Redis diblokir
- Health check yang tidak berjalan, kemampuan pengamatan, dan replikasi
Tabel berikut mencantumkan contoh perintah Redis yang intensif resource dan memberikan alternatif yang hemat resource.
| Kategori | Perintah yang memerlukan banyak resource | Alternatif yang hemat resource |
|---|---|---|
| Jalankan untuk seluruh keyspace | KEYS |
SCAN |
| Menjalankan keyset dengan panjang variabel | LRANGE |
Batasi ukuran rentang yang Anda gunakan untuk kueri. |
ZRANGE |
Batasi ukuran rentang yang Anda gunakan untuk kueri. | |
HGETALL |
HSCAN |
|
SMEMBERS |
SSCAN |
|
| Memblokir eksekusi skrip | EVAL |
Pastikan skrip Anda tidak berjalan tanpa batas waktu. |
EVALSHA |
Pastikan skrip Anda tidak berjalan tanpa batas waktu. | |
| Menghapus file dan link | DELETE |
UNLINK |
| Publikasikan dan berlangganan | PUBLISH |
SPUBLISH |
SUBSCRIBE |
SSUBSCRIBE |
Praktik terbaik klien Redis
Aplikasi Anda harus menggunakan klien Redis yang kompatibel dengan cluster saat terhubung ke instance Memorystore for Redis Cluster. Untuk contoh klien yang kompatibel dengan cluster dan contoh konfigurasi, lihat Contoh kode library klien. Klien Anda harus mempertahankan peta slot hash ke node yang sesuai dalam cluster untuk mengirim permintaan ke node yang tepat dan menghindari overhead performa yang disebabkan oleh pengalihan cluster.
Pemetaan klien
Klien harus mendapatkan daftar lengkap slot dan node yang dipetakan dalam situasi berikut:
Saat diinisialisasi, klien harus mengisi pemetaan slot awal ke node.
Pengalihan
MOVEDditerima dari server, seperti dalam situasi failover saat semua slot yang ditayangkan oleh node utama sebelumnya diambil alih oleh replika, atau saat melakukan kembali sharding ketika slot dipindahkan dari node utama sumber ke node utama target.Saat error
CLUSTERDOWNditerima dari server atau koneksi ke server tertentu terus mengalami waktu tunggu habis.Saat error
READONLYditerima dari server. Hal ini dapat terjadi saat primer diturunkan menjadi replika.Selain itu, klien harus memuat ulang topologi secara berkala agar klien tetap siap untuk perubahan apa pun dan mempelajari perubahan yang mungkin tidak mengakibatkan pengalihan/kesalahan dari server, seperti saat node replika baru ditambahkan. Perhatikan bahwa koneksi yang tidak aktif juga harus ditutup sebagai bagian dari refresh topologi untuk mengurangi kebutuhan untuk menangani koneksi yang gagal selama runtime perintah.
Penemuan klien
Penemuan klien biasanya dilakukan dengan mengeluarkan perintah CLUSTER SLOT, CLUSTER NODE, atau CLUSTER SHARDS ke server Redis. Sebaiknya gunakan perintah CLUSTER SHARDS. CLUSTER SHARDS menggantikan perintah CLUSTER SLOTS (tidak digunakan lagi), dengan memberikan representasi cluster yang lebih efisien dan dapat di-extend.
Ukuran respons untuk perintah penemuan klien cluster dapat bervariasi berdasarkan ukuran dan topologi cluster. Klaster yang lebih besar dengan lebih banyak node akan menghasilkan respons yang lebih besar. Oleh karena itu, penting untuk memastikan bahwa jumlah klien yang melakukan penemuan topologi cluster tidak bertambah tanpa batas.
Penyegaran topologi ini mahal di server Redis, tetapi juga penting untuk ketersediaan aplikasi. Oleh karena itu, penting untuk memastikan bahwa setiap klien membuat satu permintaan penemuan pada waktu tertentu (dan menyimpan hasil dalam memori), dan jumlah klien yang membuat permintaan tetap dibatasi untuk menghindari kelebihan beban server.
Misalnya, saat aplikasi klien dimulai atau kehilangan koneksi dari server dan harus melakukan penemuan cluster, salah satu kesalahan umum adalah aplikasi klien membuat beberapa permintaan koneksi ulang dan penemuan tanpa menambahkan backoff eksponensial saat mencoba lagi. Hal ini dapat membuat server Redis tidak responsif dalam jangka waktu yang lama, sehingga menyebabkan pemakaian CPU yang sangat tinggi.
Menghindari kelebihan beban penemuan di Redis
Untuk mengurangi dampak yang disebabkan oleh lonjakan permintaan koneksi dan penemuan secara tiba-tiba, sebaiknya lakukan hal berikut:
Terapkan kumpulan koneksi klien dengan ukuran yang terbatas dan kecil untuk membatasi jumlah koneksi masuk serentak dari aplikasi klien.
Saat klien terputus dari server karena waktu tunggu habis, coba lagi dengan backoff eksponensial dengan jitter. Hal ini membantu menghindari beberapa klien membebani server secara bersamaan.
Gunakan endpoint penemuan Memorystore for Redis Cluster untuk melakukan penemuan cluster. Endpoint penemuan sangat tersedia dan di-load balance di semua node dalam cluster. Selain itu, endpoint penemuan mencoba merutekan permintaan penemuan cluster ke node dengan tampilan topologi terbaru.
Praktik terbaik persistensi
Bagian ini menjelaskan praktik terbaik untuk persistensi.
Persistensi RDB dan menambahkan replika
Untuk mendapatkan hasil terbaik saat mencadangkan instance Anda dengan snapshot RDB atau menambahkan replika ke instance Anda, gunakan praktik terbaik berikut:
Pengelolaan memori
Snapshot RDB menggunakan fork proses dan mekanisme'copy-on-write' untuk mengambil snapshot data node. Bergantung pada pola penulisan ke node, memori yang digunakan oleh node akan bertambah saat halaman yang disentuh oleh penulisan disalin. Jejak memori dapat mencapai dua kali ukuran data di node.
Untuk memastikan node memiliki memori yang cukup untuk menyelesaikan snapshot, pertahankan atau tetapkan maxmemory pada 80% kapasitas node sehingga 20% dicadangkan untuk overhead. Overhead memori ini, selain snapshot pemantauan, membantu Anda mengelola workload agar memiliki snapshot yang berhasil. Selain itu, saat Anda menambahkan replika, kurangi traffic tulis sebanyak mungkin. Lihat Memantau cluster yang memiliki beban penulisan tinggi untuk mempelajari lebih lanjut.
Snapshot usang
Memulihkan node dari snapshot yang tidak valid dapat menyebabkan masalah performa untuk aplikasi Anda karena aplikasi mencoba merekonsiliasi sejumlah besar kunci yang tidak valid atau perubahan lain pada database Anda seperti perubahan skema. Jika Anda khawatir tentang pemulihan dari snapshot yang tidak aktif, Anda dapat menonaktifkan fitur persistensi RDB. Setelah Anda mengaktifkan kembali persistensi, snapshot akan diambil pada interval snapshot terjadwal berikutnya.
Dampak performa snapshot RDB
Bergantung pada pola beban kerja Anda, snapshot RDB dapat memengaruhi performa instance dan meningkatkan latensi untuk aplikasi Anda. Anda dapat meminimalkan dampak performa snapshot RDB dengan menjadwalkannya untuk berjalan selama periode traffic instance rendah jika Anda merasa nyaman dengan snapshot yang lebih jarang.
Misalnya, jika instance Anda memiliki traffic rendah dari pukul 01.00 hingga 04.00, Anda dapat menetapkan waktu mulai ke pukul 03.00 dan menetapkan interval ke 24 jam.
Jika sistem Anda memiliki beban konstan dan memerlukan snapshot yang sering, Anda harus mengevaluasi dengan cermat dampak performa, dan mempertimbangkan manfaat penggunaan snapshot RDB untuk beban kerja.
Menambahkan replika
Menambahkan replika memerlukan snapshot RDB. Untuk mengetahui informasi selengkapnya tentang snapshot RDB, lihat Pengelolaan memori.
Pilih instance zona tunggal jika instance Anda tidak menggunakan replika
Saat mengonfigurasi instance tanpa replika, sebaiknya gunakan arsitektur zona tunggal untuk meningkatkan keandalan. Berikut alasannya:
Meminimalkan dampak gangguan
Pemadaman layanan zona cenderung tidak memengaruhi instance Anda. Dengan menempatkan semua node dalam satu zona, kemungkinan pemadaman zona yang memengaruhi server Anda akan berkurang dari 100% menjadi 33%. Hal ini karena ada peluang 33% zona tempat instance Anda berada mengalami gangguan, dibandingkan dengan peluang 100% bahwa node yang berada di zona yang tidak tersedia akan terpengaruh.
Pemulihan cepat
Jika terjadi pemadaman layanan zona, pemulihan akan disederhanakan. Anda dapat merespons dengan cepat menyediakan instance baru di zona yang berfungsi dan mengalihkan aplikasi untuk operasi yang tidak terlalu terganggu.
Praktik terbaik Lettuce
Bagian ini menjelaskan praktik terbaik untuk menggunakan Lettuce guna terhubung ke instance Memorystore for Redis Cluster.
Memperbarui nilai parameter
Saat Anda menggunakan Lettuce, ubah parameter validateClusterNodeMembership menjadi
false. Jika tidak, saat topologi berubah, Anda mungkin mengalami error unknownPartition