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 manajemen memori

Bagian ini menjelaskan strategi untuk mengelola memori instance sehingga Memorystore for Valkey berfungsi secara efisien untuk aplikasi Anda.

Konsep manajemen 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 penghapusan: Memorystore for Valkey menggunakan volatile-lru kebijakan penghapusan. Anda dapat menggunakan perintah Valkey seperti perintah EXPIRE untuk menetapkan penghapusan kunci.

Memantau penggunaan memori untuk instance

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

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

• Tingkatkan ukuran instance.
• Turunkan maxmemory parameter konfigurasi.

Jika Anda mengalami masalah, hubungi Google Cloud Layanan Pelanggan.

Menskalakan shard dalam Mode Cluster Diaktifkan

Saat Anda menskalakan jumlah shard dalam instance, sebaiknya lakukan penskalaan selama periode penulisan rendah. Penskalaan 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. Namun, dalam situasi ini, Anda tidak perlu khawatir kehilangan data, karena penghapusan kunci diharapkan.

Untuk kasus penggunaan Valkey yang tidak ingin kehilangan kunci, Anda hanya boleh menurunkan skala ke instance 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 dalam instance Anda. Anda dapat menggunakan metrik /instance/memory/total_used_memory untuk melihat jumlah data yang disimpan dalam instance Anda.

Praktik terbaik penggunaan CPU

Jika terjadi pemadaman layanan zona yang tidak terduga, hal ini akan menyebabkan pengurangan resource CPU untuk instance Anda karena hilangnya kapasitas dari node di zona yang tidak tersedia. Sebaiknya gunakan instance yang sangat tersedia. Menggunakan beberapa replika per shard (bukan satu replika per shard) akan menyediakan resource CPU tambahan selama pemadaman layanan. 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 layanan zona yang tidak terduga. Anda harus memantau penggunaan CPU untuk instance utama dan replika menggunakan metrik Detik CPU Thread Utama /instance/cpu/maximum_utilization.

Bergantung pada jumlah replika yang Anda sediakan per node, sebaiknya gunakan 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 instance 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 dalam instance Anda. Jika Anda memiliki kurang dari lima replika untuk instance Anda, Anda juga dapat meningkatkan jumlah replika, hingga maksimum lima replika.

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

Perintah Valkey yang memerlukan banyak resource

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

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

Tips: Selain memerlukan banyak resource, seiring 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 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	DELETE	UNLINK
Publikasikan dan langganan	PUBLISH	SPUBLISH
	SUBSCRIBE	SSUBSCRIBE

Praktik terbaik klien Valkey

Menghindari kelebihan beban koneksi di Valkey

Untuk mengurangi dampak yang disebabkan oleh masuknya koneksi secara 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 benchmark untuk melihat apakah koneksi yang lebih banyak membantu tanpa membuat jumlah koneksi maksimum yang diizinkan menjadi jenuh.

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

Untuk instance Mode Cluster Diaktifkan

Aplikasi Anda harus menggunakan klien Valkey yang mendukung cluster saat terhubung ke instance Memorystore for Valkey Mode Cluster Diaktifkan. 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 dalam instance untuk mengirim permintaan ke node yang benar. Hal 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 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 menjadi replika.

• Selain itu, klien harus memperbarui topologi secara berkala agar klien tetap siap untuk perubahan apa pun dan mempelajari perubahan yang mungkin tidak menghasilkan 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 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 diperluas.

Ukuran respons untuk perintah penemuan klien dapat bervariasi berdasarkan ukuran dan topologi instance. Instance yang lebih besar dengan lebih banyak node 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, 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 waktu yang lama, sehingga menyebabkan penggunaan 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 memiliki load balancing di semua node dalam instance. Selain itu, endpoint penemuan mencoba merutekan permintaan penemuan node ke node dengan tampilan topologi terbaru.

Untuk instance Mode Cluster Dinonaktifkan

Saat terhubung ke instance Mode Cluster Dinonaktifkan, 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 buat-sebelum-hapus saat Anda 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 dalam mencadangkan instance Anda dengan snapshot RDB atau menambahkan replika ke instance Anda, gunakan praktik terbaik berikut:

Manajemen 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% 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:

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

Setelah penggunaan memori instance Anda berada di bawah batas 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 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 pukul 03.00 dan menetapkan interval 24 jam.

Jika sistem Anda memiliki beban yang konstan dan memerlukan snapshot yang sering, sebaiknya evaluasi dengan cermat dampak performa dan pertimbangkan manfaat penggunaan snapshot RDB untuk workload.

Menambahkan replika

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

Kapan harus menggunakan instance zona tunggal

Jika Anda mengonfigurasi instance sehingga tidak menggunakan replika, sebaiknya gunakan instance 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 instance zona tunggal.

Meminimalkan dampak pemadaman layanan

Jika Anda memilih instance zona tunggal, pemadaman layanan zona cenderung tidak akan memengaruhi instance Anda. Dengan menempatkan semua node dalam satu zona, peluang pemadaman layanan zona yang memengaruhi server Anda akan turun 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 Anda untuk operasi yang tidak terlalu terganggu.

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 Anda.
• 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:

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

  Jika Anda tidak membuat kelanjutan TLS, pembuatan koneksi akan memerlukan banyak resource. Untuk koneksi baru dan yang sudah ada, banyak koneksi antara klien dan server dapat menyebabkan waktu tunggu koneksi. Hal ini dapat menyebabkan efek bola salju karena Memorystore for Valkey mencoba membuat ulang koneksi yang waktu tunggunya habis, yang meningkatkan resource yang digunakan untuk membuat 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 instance Anda 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 akan mengurangi overhead untuk membuat koneksi. Koneksi antara klien dan server hanya diperlukan untuk koneksi awal. Namun, perluasan ukuran instance 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 instance Anda.