Praktik terbaik untuk Memorystore for Valkey

Halaman ini memberikan panduan tentang cara menggunakan Memorystore for Valkey 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 Valkey berfungsi secara efisien untuk aplikasi Anda.

Konsep pengelolaan memori

• Penggunaan memori: jumlah memori yang digunakan instance Anda. Anda memiliki kapasitas memori tetap. Anda dapat menggunakan metrik untuk memantau jumlah memori yang Anda gunakan.

• Kebijakan pengusiran: Memorystore for Valkey menggunakan kebijakan pengusiran volatile-lru. Anda dapat menggunakan perintah Valkey seperti perintah EXPIRE untuk menetapkan penghapusan untuk kunci.

Memantau penggunaan memori untuk instance

Untuk memantau penggunaan memori instance Memorystore for Valkey, sebaiknya lihat metrik /instance/memory/maximum_utilization. Jika penggunaan memori instance mendekati 80% dan Anda memperkirakan penggunaan data akan meningkat, lakukan penskalaan instance untuk menyediakan ruang bagi data baru.

Jika instance memiliki penggunaan memori yang tinggi, lakukan hal berikut untuk meningkatkan performa:

• Tingkatkan ukuran instance.
• Turunkan parameter konfigurasi maxmemory.

Jika Anda mengalami masalah, hubungi Google Cloud Customer Care.

Menskalakan shard dalam Mode Cluster Diaktifkan

Saat menskalakan jumlah shard dalam instance, sebaiknya Anda melakukan penskalaan selama periode penulisan rendah. Menskalakan selama periode penggunaan tinggi dapat memberikan tekanan memori pada instance Anda karena overhead memori yang disebabkan oleh replikasi atau migrasi slot.

Jika kasus penggunaan Valkey Anda menggunakan penghapusan kunci, penskalaan ke ukuran instance 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 Valkey yang tidak ingin kehilangan kunci, Anda hanya boleh melakukan penskalaan ke bawah ke instance yang lebih kecil yang masih memiliki cukup ruang untuk data Anda. Jumlah partisi target baru Anda harus memungkinkan setidaknya 1,5 kali memori yang digunakan oleh data. Dengan kata lain, Anda harus menyediakan cukup banyak shard untuk 1,5 kali jumlah data di instance Anda. Anda dapat menggunakan metrik /instance/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 instance Anda karena hilangnya kapasitas dari node di zona yang tidak tersedia. Sebaiknya gunakan instance dengan ketersediaan tinggi. Menggunakan beberapa replika per shard (bukan satu replika per shard) akan menyediakan resource CPU tambahan selama gangguan. Anda dapat memiliki hingga lima replika per shard.

Selain itu, sebaiknya kelola penggunaan CPU node agar 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 primer dan replika menggunakan metrik Main Thread CPU Seconds /instance/cpu/maximum_utilization.

Bergantung pada jumlah replika yang Anda sediakan per node, kami merekomendasikan target penggunaan CPU /instance/cpu/maximum_utilization berikut:

• Untuk instance dengan satu replika per node, targetkan nilai /instance/cpu/maximum_utilization sebesar 0,5 detik untuk replika utama dan 0,5 detik untuk replika.
• Untuk instance dengan dua replika per node atau lebih, targetkan nilai /instance/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 memiliki kurang dari lima replika untuk instance, Anda juga dapat meningkatkan jumlah replika, hingga maksimum lima replika.

Perintah Valkey yang memerlukan banyak resource

Sebaiknya hindari penggunaan perintah Valkey 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 Valkey diblokir
• Health check yang tidak berjalan, kemampuan pengamatan, dan replikasi

Tabel berikut mencantumkan contoh perintah Valkey yang membutuhkan banyak resource dan memberikan alternatif yang lebih hemat resource.

Tips: Selain memerlukan banyak resource, seiring dengan bertambahnya ukuran total data Anda, 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 paling lama dijalankan. Dengan demikian, Anda mengetahui perintah yang menyebabkan masalah latensi. Untuk menentukan alternatif perintah yang hemat resource, lihat tabel berikut.

Kategori	Perintah yang memerlukan banyak resource	Alternatif yang hemat resource
Jalankan untuk seluruh keyspace	KEYS	SCAN
Menjalankan 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
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 Valkey

Menghindari kelebihan beban koneksi di Valkey

Untuk mengurangi dampak yang disebabkan oleh lonjakan koneksi yang tiba-tiba, sebaiknya lakukan hal berikut:

• Tentukan ukuran kumpulan koneksi klien yang paling sesuai untuk Anda. Ukuran awal yang baik untuk setiap klien adalah satu koneksi per node Valkey. Kemudian, Anda dapat melakukan tolok ukur untuk melihat apakah lebih banyak koneksi membantu tanpa membatasi jumlah koneksi maksimum yang diizinkan.

• Saat klien terputus dari server karena batas waktu server habis, coba lagi dengan backoff eksponensial dengan jitter. Hal ini membantu menghindari beberapa klien membebani server secara bersamaan.

Untuk instance yang Mengaktifkan Mode Cluster

Aplikasi Anda harus menggunakan klien Valkey yang kompatibel dengan cluster saat terhubung ke instance Memorystore untuk Valkey dengan Mode Cluster Diaktifkan. 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 di instance untuk mengirim permintaan ke node yang benar. Tindakan ini mencegah overhead performa yang disebabkan oleh pengalihan.

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.

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

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

• Saat error READONLY diterima dari server. Hal ini dapat terjadi saat primer diturunkan menjadi replika.

• Selain itu, klien harus memperbarui topologi secara berkala agar klien tetap siap untuk perubahan apa pun dan mempelajari perubahan yang mungkin tidak mengakibatkan pengalihan atau error 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 menangani koneksi yang gagal selama runtime perintah.

Penemuan klien

Penemuan klien biasanya dilakukan dengan mengeluarkan perintah SLOTS, NODES, atau CLUSTER SHARDS ke server Valkey. Sebaiknya gunakan perintah CLUSTER SHARDS. CLUSTER SHARDS menggantikan perintah SLOTS (tidak digunakan lagi), dengan memberikan representasi instance yang lebih efisien dan dapat di-extend.

Ukuran respons untuk perintah penemuan klien dapat bervariasi berdasarkan ukuran dan topologi instance. Instance 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 node tidak bertambah tanpa batas.

Pembaruan topologi node ini mahal di server Valkey, 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 node, 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 Valkey tidak responsif dalam jangka waktu yang lama, sehingga menyebabkan pemakaian CPU yang sangat tinggi.

Menggunakan endpoint penemuan untuk penemuan node

Gunakan endpoint penemuan Memorystore for Valkey untuk melakukan penemuan node. Endpoint penemuan sangat tersedia dan di-load balance di semua node dalam instance. Selain itu, endpoint penemuan mencoba merutekan permintaan penemuan node ke node dengan tampilan topologi terbaru.

Untuk instance dengan Mode Cluster Dinonaktifkan

Saat terhubung ke instance Cluster Mode Disabled, aplikasi Anda harus terhubung ke endpoint utama untuk menulis ke instance dan mengambil penulisan terbaru. Aplikasi Anda juga dapat terhubung ke endpoint pembaca untuk membaca dari replika dan mengisolasi traffic dari node utama.

Jika Anda menggunakan strategi create-before-destroy saat melakukan pemeliharaan pada instance, Anda mungkin menerima pesan error berikut:

READONLY You can't write against a read only replica.

Untuk mengatasi masalah ini, hentikan koneksi ke instance Anda. Kemudian, buat ulang koneksi.

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 bisa 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 memantau snapshot, membantu Anda mengelola workload agar snapshot berhasil. Selain itu, saat Anda menambahkan replika, kurangi traffic tulis sebanyak mungkin. Untuk mengetahui informasi selengkapnya, lihat Memantau penggunaan memori untuk instance.

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

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

• Kurangi jejak memori instance Anda hingga kurang dari 80% dari memori maksimum yang diizinkan node.
• Skalakan jenis node untuk instance Anda agar memiliki lebih banyak memori.

Setelah penggunaan memori instance Anda berada di bawah batas 80%, tambahkan replika lagi.

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 agar 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, sebaiknya Anda mengevaluasi dengan cermat dampak performa dan mempertimbangkan manfaat penggunaan snapshot RDB untuk beban kerja.

Menambahkan replika

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

Kapan harus menggunakan instance zona tunggal

Jika Anda mengonfigurasi instance agar tidak menggunakan replika, sebaiknya gunakan instance zona tunggal. Berikut alasannya:

Biaya dan performa

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

Meminimalkan dampak pemadaman

Jika Anda memilih instance zona tunggal, pemadaman layanan per 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%. Ada peluang 33% bahwa zona tempat instance 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 layanan zona untuk instance zona tunggal, Memorystore for Valkey akan menyederhanakan pemulihan data Anda. Anda dapat menyediakan instance baru di zona yang berfungsi dengan cepat dan mengalihkan aplikasi untuk operasi yang tidak terganggu.

Mengaktifkan Transport Layer Security (TLS)

Bagian ini menjelaskan manfaat keamanan dan implikasi performa dari 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 dalam pengiriman: Enkripsi bawaanGoogle Cloudmelindungi traffic dalam jaringan Google di tingkat infrastruktur. Namun, hal ini melibatkan pemberian 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 lebih besar atas kunci dan proses enkripsi Anda.
• Perlindungan token autentikasi: Jika Anda menggunakan autentikasi IAM, mengaktifkan TLS akan meminimalkan risiko pemaparan dan kebocoran token autentikasi Anda.

Implikasi performa

TLS memengaruhi performa dengan cara berikut:

• Membuat koneksi: Klien dan server yang telah membuat sesi TLS dapat melanjutkan sesi tanpa mengulangi proses pembuatan koneksi yang intensif sumber daya antara klien dan server. Dengan mengaktifkan kelanjutan TLS, Anda mengurangi overhead pembuatan koneksi antara klien dan server.

  Jika Anda tidak membuat kelanjutan TLS, maka pembuatan koneksi akan membutuhkan 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 untuk Valkey mencoba membuat ulang koneksi yang waktunya habis, sehingga meningkatkan resource yang digunakan untuk membuat koneksi.

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

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 mengurangi overhead untuk membuat koneksi. Koneksi antara klien dan server hanya diperlukan untuk koneksi awal. Namun, perluasan ukuran instance klien secara 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 instance Anda.