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 perintahEXPIREuntuk 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 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 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 shard 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 yang saat ini ada 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 layanan 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 dua replika per shard (bukan satu replika per shard) memberikan resource CPU tambahan selama 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 primer dan replika menggunakan metrik Main Thread CPU Seconds /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 1 replika per node, Anda harus menargetkan nilai
/instance/cpu/maximum_utilizationsebesar 0,5 detik untuk primer dan replika. - Untuk instance dengan 2 replika per node, Anda harus menargetkan nilai
/instance/cpu/maximum_utilizationsebesar 0,9 detik untuk replika utama dan 0,5 detik untuk replika.
Jika nilai metrik melebihi rekomendasi ini, sebaiknya tingkatkan jumlah shard atau replika di instance Anda.
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 menggunakan banyak 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 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 koneksi tambahan membantu tanpa membebani 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. 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 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 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 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 pemanfaatan 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.
Praktik terbaik persistensi
Bagian ini menjelaskan praktik terbaik untuk persistensi.
Persistensi RDB
Untuk hasil terbaik saat mencadangkan instance Anda dengan snapshot RDB, Anda harus menggunakan 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. Dalam kasus terburuk, jejak memori dapat dua kali lipat ukuran data di node.
Untuk memastikan node memiliki memori yang cukup untuk menyelesaikan snapshot, Anda harus mempertahankan atau menyetel maxmemory pada 80% kapasitas node sehingga 20% dicadangkan untuk overhead. Untuk mengetahui informasi selengkapnya, lihat Memantau penggunaan memori untuk instance. Overhead memori ini, selain snapshot Monitoring, membantu Anda mengelola beban kerja agar memiliki snapshot yang berhasil.
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.
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.