Praktik terbaik untuk Memorystore for Redis Cluster

Halaman ini memberikan panduan tentang cara menggunakan Memorystore for Redis Cluster secara optimal. Halaman ini juga menunjukkan potensi masalah yang harus dihindari.

Catatan: Untuk melihat contoh konfigurasi klien cluster Redis, lihat Contoh kode library klien.

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 tulis dapat berkisar dari normal hingga sangat tinggi, bergantung pada kasus penggunaan Redis dan pola penggunaan aplikasi.

• Kebijakan penghapusan - Memorystore for Redis Cluster menggunakan volatile-lru kebijakan penghapusan. Anda dapat menggunakan perintah seperti perintah EXPIRE untuk menetapkan penghapusan 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 berfungsi dengan 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_utilization mencapai 65% atau lebih tinggi.

• Beban tulis yang cukup tinggi dapat mengalami masalah jika /cluster/memory/maximum_utilization mencapai 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 tulis yang tinggi, hubungi Google Cloud Dukungan.

Menskalakan shard

Saat Anda Menskalakan jumlah shard dalam instance, Anda harus menskalakan selama periode penulisan rendah. Menskalakan 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. Namun, dalam situasi ini, Anda tidak perlu khawatir kehilangan data, karena penghapusan kunci sudah diperkirakan.

Untuk kasus penggunaan Redis yang tidak ingin kehilangan kunci, Anda hanya boleh menurunkan skala ke cluster yang lebih kecil yang masih memiliki ruang yang cukup 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 shard yang cukup untuk 1,5 kali jumlah data 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 pengurangan resource CPU untuk cluster Anda karena kapasitas yang hilang dari node di zona yang tidak tersedia. Sebaiknya gunakan cluster dengan ketersediaan tinggi. Menggunakan beberapa replika per shard (bukan satu replika per shard) akan menyediakan resource CPU tambahan selama pemadaman. Anda dapat memiliki hingga lima replika per shard.

Selain itu, sebaiknya kelola penggunaan CPU node sehingga node memiliki overhead CPU yang cukup untuk menangani traffic tambahan dari kapasitas yang hilang jika terjadi pemadaman zona yang tidak terduga. Anda harus memantau penggunaan CPU untuk instance utama dan replika menggunakan metrik Detik CPU Thread Utama /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, targetkan nilai /cluster/cpu/maximum_utilization sebesar 0,5 detik untuk instance utama dan 0,5 detik untuk replika.
• Untuk instance dengan dua replika per node atau lebih, targetkan nilai /cluster/cpu/maximum_utilization sebesar 0,9 detik untuk instance utama dan 0,5 detik untuk setiap replika.

Jika nilai untuk metrik melebihi rekomendasi ini, sebaiknya tingkatkan jumlah shard di instance Anda. Jika Anda memiliki kurang dari lima replika untuk instance, Anda juga dapat meningkatkan jumlah replika, hingga maksimum lima replika.

Jika cluster Anda mengalami penggunaan CPU yang tinggi atau resource cluster habis (misalnya, karena memiliki terlalu banyak koneksi), cluster mungkin berperilaku tidak semestinya dan metrik eksternal mungkin tidak ada.

Perintah Redis yang memerlukan banyak resource

Sebaiknya hindari penggunaan perintah Redis yang memerlukan 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, observabilitas, dan replikasi yang tidak memadai

Tabel berikut mencantumkan contoh perintah Redis yang memerlukan banyak resource dan memberikan alternatif yang hemat resource.

Tips: Selain memerlukan banyak resource, seiring bertambahnya ukuran data total, biaya penggunaan perintah ini juga akan meningkat.

Untuk menemukan perintah yang berjalan lama yang Anda gunakan, gunakan SLOWLOG. Alat ini memberi Anda daftar perintah yang membutuhkan waktu paling lama untuk dijalankan. Dengan demikian, Anda mengetahui perintah yang menyebabkan masalah latensi. Untuk menentukan alternatif yang hemat resource untuk perintah ini, lihat tabel berikut.

Kategori	Perintah yang memerlukan banyak resource	Alternatif yang hemat resource
Jalankan untuk seluruh keyspace	KEYS	SCAN
Jalankan untuk 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
Blokir eksekusi skrip	EVAL	Pastikan skrip Anda tidak berjalan tanpa batas.
	EVALSHA	Pastikan skrip Anda tidak berjalan tanpa batas.
Hapus file dan link	DEL	UNLINK
Publikasikan dan berlangganan	PUBLISH	SPUBLISH
	SUBSCRIBE	SSUBSCRIBE

Praktik terbaik klien Redis

Aplikasi Anda harus menggunakan klien Redis yang mendukung cluster saat terhubung ke instance Memorystore for Redis Cluster. Untuk contoh klien yang mendukung cluster dan contoh konfigurasi, lihat Contoh kode library klien. Klien Anda harus mempertahankan peta slot hash ke node yang sesuai di 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 slot awal ke pemetaan node.

• Saat pengalihan MOVED diterima dari server, seperti dalam situasi failover saat semua slot yang ditayangkan oleh node utama sebelumnya diambil alih oleh replika, atau re-sharding saat slot dipindahkan dari node utama sumber ke node utama target.

• Saat error CLUSTERDOWN diterima dari server atau koneksi ke server tertentu mengalami waktu tunggu secara terus-menerus.

• Saat error READONLY diterima dari server. Hal ini dapat terjadi saat instance utama diturunkan ke replika.

• Selain itu, klien harus memperbarui topologi secara berkala agar klien tetap siap untuk perubahan apa pun dan mempelajari perubahan yang mungkin tidak menyebabkan pengalihan atau error dari server, seperti saat node replika baru ditambahkan. Perhatikan bahwa koneksi yang tidak aktif juga harus ditutup sebagai bagian dari pembaruan topologi untuk mengurangi kebutuhan 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 diperluas.

Ukuran respons untuk perintah penemuan klien cluster dapat bervariasi berdasarkan ukuran dan topologi cluster. Cluster 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.

Pembaruan 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, 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 penggunaan CPU yang sangat tinggi.

Menghindari kelebihan beban penemuan di Redis

Untuk mengurangi dampak yang disebabkan oleh masuknya permintaan koneksi dan penemuan secara tiba-tiba, sebaiknya lakukan hal berikut:

• Terapkan pool koneksi klien dengan ukuran 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 yang membebani server secara bersamaan.

• Gunakan endpoint penemuan Memorystore for Redis Cluster untuk melakukan penemuan cluster. Endpoint penemuan memiliki ketersediaan yang tinggi dan memiliki load balancing 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 penambahan replika

Untuk mendapatkan hasil terbaik dalam mencadangkan instance dengan snapshot RDB atau menambahkan replika ke instance, gunakan praktik terbaik berikut:

Pengelolaan memori

Snapshot RDB menggunakan fork proses dan 'copy-on-write' mechanism untuk mengambil snapshot data node. Bergantung pada pola penulisan ke node, memori yang digunakan 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% dari kapasitas node sehingga 20% dicadangkan untuk overhead. Overhead memori ini, selain memantau snapshot, membantu Anda mengelola workload agar snapshot berhasil. Selain itu, saat Anda menambahkan replika, kurangi traffic tulis sebanyak mungkin. Lihat Memantau cluster yang memiliki beban tulis tinggi untuk mempelajari lebih lanjut.

Catatan: Jika Anda menambahkan replika ke cluster yang menggunakan lebih dari 80% memori maksimum cluster, operasi akan gagal dan Anda akan menerima pesan error.

Untuk mengatasi masalah ini, kurangi penggunaan memori cluster Anda dengan salah satu cara berikut:

• Turunkan jejak memori cluster Anda menjadi kurang dari 80% memori maksimum yang diizinkan node.
• Ubah jenis node untuk cluster Anda sehingga memiliki lebih banyak memori.

Setelah penggunaan memori cluster Anda berada di bawah nilai minimum 80%, tambahkan replika lagi.

Snapshot yang tidak aktif

Memulihkan node dari snapshot yang tidak aktif dapat menyebabkan masalah performa untuk aplikasi Anda saat mencoba merekonsiliasi sejumlah besar kunci yang tidak aktif 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 workload, 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 tidak keberatan 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 yang konstan dan memerlukan snapshot yang sering, Anda harus mengevaluasi dampak performa dengan cermat, dan mempertimbangkan manfaat penggunaan snapshot RDB untuk workload.

Menambahkan replika

Menambahkan replika memerlukan snapshot RDB. Untuk mengetahui informasi selengkapnya tentang snapshot RDB, lihat Pengelolaan memori.

Kapan harus menggunakan cluster zona tunggal

Jika Anda mengonfigurasi cluster sehingga tidak menggunakan replika, sebaiknya gunakan cluster zona tunggal. Berikut alasannya:

Biaya dan performa

Jika meminimalkan biaya dan memiliki performa puncak untuk klien Anda yang berada di region yang sama adalah pendorong utama Anda, sebaiknya pilih cluster zona tunggal.

Meminimalkan dampak pemadaman

Jika Anda memilih cluster zona tunggal, pemadaman zona cenderung tidak akan memengaruhi cluster Anda. Dengan menempatkan semua node dalam satu zona, peluang pemadaman zona yang memengaruhi server Anda akan turun dari 100% menjadi 33%. Ada peluang 33% bahwa zona tempat cluster Anda berada akan mengalami gangguan, dibandingkan dengan peluang 100% bahwa node, yang berada di zona yang tidak tersedia, akan terpengaruh.

Pemulihan cepat

Jika terjadi pemadaman zona untuk cluster zona tunggal, Memorystore for Redis Cluster akan menyederhanakan pemulihan data Anda. Anda dapat menyediakan cluster baru di zona yang berfungsi dengan cepat dan mengalihkan aplikasi Anda 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 menggunakan Lettuce, ubah parameter validateClusterNodeMembership menjadi false. Jika tidak, saat topologi berubah, Anda mungkin akan mendapatkan error unknownPartition.

Mengaktifkan Transport Layer Security (TLS)

Bagian ini menjelaskan manfaat keamanan dan implikasi performa penggunaan Transport Layer Security (TLS), beserta rekomendasi untuk pengaktifannya.

Manfaat keamanan

Dengan menggunakan TLS, Anda akan mendapatkan manfaat keamanan berikut:

• Autentikasi Identity and Access Management (IAM): TLS menggunakan jenis autentikasi ini untuk melindungi dari serangan spoofing server, seperti serangan man-in-the-middle.
• Enkripsi saat transit: Google CloudEnkripsi bawaan melindungi traffic dalam jaringan Google di tingkat infrastruktur. Namun, hal ini melibatkan kepercayaan pada host dan stack jaringan Google. Meskipun enkripsi ini transparan dan diaktifkan secara default, enkripsi ini bukan end-to-end. Di sisi lain, TLS menggunakan enkripsi saat transit di lapisan aplikasi. Enkripsi end-to-end ini memberi Anda kontrol yang lebih besar atas kunci dan proses enkripsi.
• Perlindungan token autentikasi: Jika Anda menggunakan autentikasi IAM, mengaktifkan TLS akan meminimalkan risiko mengekspos dan membocorkan token autentikasi Anda.

Implikasi performa

TLS memengaruhi performa dengan cara berikut:

• Menetapkan koneksi: Klien dan server yang telah menetapkan sesi TLS dapat melanjutkan sesi tanpa mengulangi proses yang memerlukan banyak resource untuk menetapkan koneksi antara klien dan server. Dengan mengaktifkan kelanjutan TLS, Anda mengurangi overhead untuk menetapkan koneksi antara klien dan server.

  Jika Anda tidak menetapkan kelanjutan TLS, menetapkan koneksi akan memerlukan banyak resource. Untuk koneksi baru dan yang sudah ada, banyak koneksi antara klien dan server dapat menyebabkan waktu tunggu koneksi habis. Hal ini dapat menyebabkan efek bola salju karena Memorystore for Redis Cluster mencoba menetapkan kembali koneksi yang waktu tunggunya habis, yang meningkatkan resource yang digunakan untuk menetapkan koneksi.

• Mengenkripsi dan mendekripsi data: Enkripsi dan dekripsi data melibatkan operasi yang memerlukan banyak CPU yang memengaruhi klien dan server. Hal ini dapat mengurangi kapasitas cluster dan meningkatkan latensi cluster.

Rekomendasi

Saat mempertimbangkan apakah akan mengaktifkan TLS, sebaiknya evaluasi kebijakan keamanan Anda sambil mempertimbangkan manfaat dan kekurangan TLS. Jika Anda memilih untuk mengaktifkan TLS, perhatikan pertimbangan berikut:

• Mengaktifkan kelanjutan TLS akan mengurangi overhead untuk menetapkan koneksi. Koneksi antara klien dan server hanya diperlukan untuk koneksi awal. Namun, perluasan ukuran cluster klien yang tiba-tiba dapat menyebabkan gangguan singkat yang disebabkan oleh handshake penuh awal setiap host klien baru.
• Meskipun beberapa library klien mungkin tidak menawarkan kontrol bawaan untuk mengaktifkan TLS, Anda dapat menggunakan kode kustom untuk mengintegrasikan fungsi ini ke dalam cluster.