Halaman ini memberikan panduan tentang cara optimal menggunakan Memorystore for Valkey. Halaman ini juga menunjukkan potensi masalah yang harus dihindari.
Praktik terbaik manajemen memori
Bagian ini menjelaskan strategi untuk mengelola memori instance agar Memorystore for Valkey berfungsi secara efisien untuk aplikasi Anda.
Konsep manajemen memori
Menulis beban - Volume dan kecepatan saat Anda menambahkan atau memperbarui kunci pada instance Valkey. Beban tulis Anda dapat berkisar dari normal hingga sangat tinggi, bergantung pada kasus penggunaan Valkey dan pola penggunaan aplikasi.
Kebijakan penghapusan - Memorystore for Valkey menggunakan kebijakan penghapusan
volatile-lru. Anda dapat menggunakan perintah Valkey seperti perintah EXPIRE untuk menetapkan penghapusan kunci.
Memantau instance yang memiliki beban tulis normal
Lihat metrik /instance/cpu/maximum_utilization. Jika /instance/cpu/maximum_utilization adalah
pada level 100% atau lebih rendah, instance Valkey akan berperforma baik saat Anda menggunakan beban tulis normal.
Namun, jika penggunaan memori mendekati 100% dan Anda memperkirakan penggunaan data akan meningkat, Anda harus meningkatkan ukuran instance untuk memberi ruang bagi data baru.
Memantau instance yang memiliki beban tulis yang tinggi
Lihat metrik /instance/memory/maximum_utilization. Bergantung pada tingkat keparahan beban tulis Anda yang tinggi, instance Anda dapat mengalami masalah performa pada nilai minimum berikut:
Beban tulis yang sangat tinggi dapat mengalami masalah jika
/instance/memory/maximum_utilizationmencapai 65% atau lebih tinggi.Pemuatan tulis yang cukup tinggi dapat mengalami masalah jika
/instance/memory/maximum_utilizationmencapai 85% atau lebih tinggi.
Dalam skenario ini, Anda harus meningkatkan ukuran instance untuk meningkatkan performa.
Jika Anda mengalami masalah, atau khawatir instance Anda memiliki beban tulis yang tinggi, hubungi Dukungan Google Cloud.
Sharding penskalaan
Saat Menskalakan jumlah shard dalam instance, Anda harus melakukan penskalaan selama periode penulisan yang rendah. Penskalaan selama periode beban tulis yang 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 cache ditemukan. Namun, dalam situasi ini, Anda tidak perlu khawatir akan kehilangan data, karena penghapusan kunci sudah diperkirakan.
Untuk kasus penggunaan Valkey di mana Anda tidak ingin kehilangan kunci, sebaiknya hanya perkecil 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 lipat memori yang digunakan oleh data. Dengan kata lain, Anda harus menyediakan shard yang cukup untuk 1,5 kali jumlah data yang saat ini ada dalam instance Anda. Anda dapat menggunakan metrik /instance/memory/total_used_memory untuk melihat jumlah data yang tersimpan dalam instance Anda.
Praktik terbaik penggunaan CPU
Jika terjadi pemadaman layanan zona yang tidak terduga, hal ini dapat mengurangi resource CPU instance karena hilangnya kapasitas dari node di zona yang tidak tersedia. Sebaiknya gunakan instance yang sangat tersedia. Menggunakan dua replika per shard (bukan satu replika per shard) akan memberikan resource CPU tambahan selama pemadaman. Selain itu, sebaiknya kelola penggunaan CPU node agar 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 primer dan replika menggunakan metrik Main Thread CPU Seconds /instance/cpu/maximum_utilization.
Bergantung pada jumlah replika yang Anda sediakan per node, kami merekomendasikan /instance/cpu/maximum_utilization target penggunaan CPU berikut:
- Untuk instance dengan 1 replika per node, Anda harus menargetkan nilai
/instance/cpu/maximum_utilization0,5 detik untuk yang utama dan replika. - Untuk instance dengan 2 replika per node, Anda harus menargetkan nilai
/instance/cpu/maximum_utilization, yakni 0,9 detik untuk yang utama dan 0,5 detik untuk replika.
Jika nilai metrik melebihi rekomendasi ini, sebaiknya tingkatkan jumlah shard atau replika dalam instance Anda.
Perintah Valkey yang mahal untuk CPU
Anda harus menghindari perintah Valkey yang mahal untuk dijalankan karena berbagai alasan. Bagian ini memberikan contoh alasan beberapa perintah itu mahal, tetapi ini ini bukanlah daftar lengkap.
Perintah yang beroperasi di seluruh keyspace
- KEYS
Perintah yang beroperasi pada {i>keyset<i} dengan panjang variabel
- LRANGE
- ZRANGE
- SEGERA
Perintah yang memblokir eksekusi skrip
- EVALUASI
- EVALSHA
Risiko menggunakan perintah yang mahal
- Latensi tinggi dan waktu tunggu klien.
- Tekanan memori disebabkan oleh perintah yang meningkatkan penggunaan memori.
- Kehilangan data selama replikasi dan sinkronisasi node, karena memblokir thread utama Valkey.
- Health check kelaparan, kemampuan observasi, dan replikasi.
Praktik terbaik klien Valkey
Aplikasi Anda harus menggunakan klien Valkey yang peka cluster saat terhubung ke instance Memorystore for Valkey. Untuk mengetahui contoh klien yang peka 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 tepat dan menghindari overhead performa yang disebabkan oleh pengalihan.
Pemetaan klien
Klien harus mendapatkan daftar lengkap slot dan node yang dipetakan di situasi berikut:
Saat klien diinisialisasi, klien harus mengisi slot awal ke node pemetaan peta Google.
Saat pengalihan
MOVEDditerima dari server, seperti dalam situasi failover saat semua slot yang dilayani oleh node utama sebelumnya diambil alih oleh replika, atau melakukan sharding ulang saat slot dipindahkan dari sumber utama ke node utama target.Saat error
CLUSTERDOWNditerima dari server atau koneksi ke server tertentu, waktu tunggu akan habis secara terus-menerus.Saat error
READONLYditerima dari server. Hal ini dapat terjadi ketika didemosikan menjadi replika.Selain itu, klien harus memperbarui topologi secara berkala untuk menjaga agar klien tetap siap untuk setiap perubahan dan mempelajari perubahan yang mungkin tidak mengakibatkan pengalihan / error dari server, seperti saat node replika baru ditambahkan. Perlu diketahui bahwa setiap koneksi yang basi juga harus ditutup sebagai bagian dari pembaruan 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 diperluas.
Ukuran respons untuk perintah penemuan klien dapat bervariasi berdasarkan topologi dan ukuran 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 secara tak terbatas.
Refresh topologi node ini mahal di server Valkey, tetapi juga penting untuk ketersediaan aplikasi. Oleh karena itu, penting untuk memastikan bahwa setiap klien membuat permintaan penemuan tunggal pada waktu tertentu (dan cache menghasilkan dalam memori), dan jumlah klien yang membuat permintaan tetap dibatasi untuk menghindari kelebihan beban server.
Misalnya, saat aplikasi klien memulai 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 dicoba lagi. Hal ini dapat merender server Valkey yang tidak responsif untuk jangka waktu yang lama, sehingga menyebabkan penggunaan CPU yang sangat tinggi.
Menghindari penemuan berlebihan di Valkey
Untuk mengurangi dampak yang disebabkan oleh banyaknya koneksi dan penemuan yang tiba-tiba permintaan, sebaiknya lakukan hal berikut:
Implementasikan kumpulan koneksi klien dengan ukuran terbatas dan kecil untuk mengikat jumlah koneksi masuk serentak dari klien aplikasi.
Ketika klien memutuskan sambungan dari server karena waktu tunggu habis, coba lagi dengan backoff eksponensial dengan jitter. Hal ini membantu menghindari banyak klien membebani server secara bersamaan.
Menggunakan endpoint discovery Memorystore for Valkey untuk menjalankan node penemuan. Endpoint penemuan sangat tersedia dan memiliki load balancing di semua node dalam instance. Selain itu, titik akhir penemuan berupaya untuk mengarahkan permintaan penemuan node ke node dengan topologi jaringan.
Praktik terbaik persistensi
Bagian ini menjelaskan praktik terbaik untuk persistensi.
Persistensi RDB
Untuk mendapatkan hasil terbaik dalam mencadangkan instance dengan snapshot RDB, Anda harus menggunakan praktik terbaik berikut:
Manajemen memori
Snapshot RDB menggunakan garpu proses dan 'copy-on-write' untuk mengambil snapshot data node. Tergantung pada pola penulisan ke node, memori yang digunakan dari node bertambah saat halaman yang disentuh oleh operasi tulis disalin. Dalam kasus terburuk, jejak memori bisa dua kali lipat ukuran data dalam node.
Untuk memastikan node memiliki memori yang cukup untuk menyelesaikan snapshot, Anda harus menyimpan atau menetapkan maxmemory pada 80% kapasitas node sehingga 20% dicadangkan untuk overhead. Lihat Memantau instance yang memiliki beban tulis yang tinggi untuk mempelajari lebih lanjut. Overhead memori ini, selain snapshot Pemantauan, membantu Anda mengelola beban kerja agar mendapatkan snapshot yang sukses.
Snapshot tidak berlaku
Memulihkan node dari snapshot yang sudah tidak berlaku dapat menyebabkan masalah performa untuk aplikasi Anda karena aplikasi mencoba merekonsiliasi sejumlah besar kunci usang atau perubahan lain pada database Anda seperti perubahan skema. Jika tidak ingin memulihkan snapshot yang usang, 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 dijalankan selama periode traffic instance rendah jika Anda merasa nyaman dengan snapshot yang lebih jarang.
Misalnya, jika instance Anda memiliki traffic yang 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 sering, Anda harus mengevaluasi dampak performa dengan cermat, 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 pemadaman
Gangguan zona cenderung tidak memengaruhi instance Anda. Dengan menempatkan semua node dalam satu zona, kemungkinan pemadaman layanan zona yang memengaruhi server Anda akan menurun dari 100% menjadi 33%. Hal ini karena ada kemungkinan 33% zona tempat lokasi instance tidak aktif, berbeda dengan kemungkinan 100% node yang berada di zona yang tidak tersedia akan terdampak.
Pemulihan cepat
Jika terjadi pemadaman layanan di zona, pemulihan akan disederhanakan. Anda dapat merespons dengan cepat menyediakan instance baru di zona yang berfungsi dan mengalihkan aplikasi untuk operasi dengan gangguan minimal.