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 Redis berfungsi secara efisien untuk aplikasi Anda.
Konsep pengelolaan memori
Beban tulis - Volume dan kecepatan saat Anda menambahkan atau memperbarui kunci di instance Valkey. Beban tulis Anda dapat berkisar dari normal hingga sangat tinggi, bergantung pada kasus penggunaan Valkey dan pola penggunaan aplikasi Anda.
Kebijakan penghapusan - Memorystore untuk 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
berada pada 100% atau lebih rendah, instance Valkey Anda akan berperforma baik saat Anda menggunakan beban tulis normal.
Namun, jika penggunaan memori mendekati 100% dan Anda memperkirakan penggunaan data akan meningkat, Anda harus menskalakan ukuran instance untuk menyediakan ruang bagi data baru.
Memantau instance yang memiliki beban tulis tinggi
Lihat metrik /instance/memory/maximum_utilization. Bergantung pada tingkat keparahan beban tulis 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.Beban tulis yang cukup tinggi dapat mengalami masalah jika
/instance/memory/maximum_utilizationmencapai 85% atau lebih tinggi.
Dalam skenario ini, Anda harus menskalakan ukuran instance untuk meningkatkan performa.
Jika Anda mengalami masalah, atau khawatir instance Anda memiliki beban operasi tulis yang tinggi, hubungi Dukungan Google Cloud.
Menskalakan shard
Saat Menskalakan jumlah shard di instance, Anda harus menskalakan 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 hit cache. Namun, dalam situasi ini, Anda tidak perlu khawatir kehilangan data, karena penghapusan kunci sudah diperkirakan.
Untuk kasus penggunaan Valkey jika Anda tidak ingin kehilangan kunci, Anda hanya boleh menskalakan 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 shard yang cukup 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 pemadaman layanan zona terjadi secara tidak terduga, hal ini akan mengurangi resource CPU untuk instance Anda karena kapasitas yang hilang dari node di zona yang tidak tersedia. Sebaiknya gunakan instance yang sangat tersedia. Menggunakan dua replika per shard (bukan satu replika per shard) akan menyediakan 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 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 1 replika per node, Anda harus menargetkan nilai
/instance/cpu/maximum_utilizationsebesar 0,5 detik untuk instance utama dan replika. - Untuk instance dengan 2 replika per node, Anda harus menargetkan nilai
/instance/cpu/maximum_utilization0,9 detik untuk replika utama dan 0,5 detik untuk replika.
Jika nilai untuk metrik melebihi rekomendasi ini, sebaiknya tingkatkan jumlah shard atau replika di instance Anda.
Perintah Valkey yang mahal CPU
Anda harus menghindari perintah Valkey yang mahal untuk dijalankan karena berbagai alasan. Bagian ini memberikan contoh alasan beberapa perintah mahal, tetapi daftar ini tidak lengkap.
Perintah yang beroperasi di seluruh ruang kunci
- KEYS
Perintah yang beroperasi pada kumpulan kunci dengan panjang variabel
- LRANGE
- ZRANGE
- HGETALL
Perintah yang memblokir eksekusi skrip
- EVAL
- EVALSHA
Risiko penggunaan perintah yang mahal
- Latensi tinggi dan waktu tunggu klien habis.
- Tekanan memori yang disebabkan oleh perintah yang meningkatkan penggunaan memori.
- Kehilangan data selama replikasi dan sinkronisasi node, karena memblokir thread utama Valkey.
- Health check, visibilitas, dan replikasi yang tidak memadai.
Praktik terbaik klien Valkey
Aplikasi Anda harus menggunakan klien Valkey yang mengetahui cluster saat terhubung ke instance Memorystore for Valkey. Untuk contoh klien yang mengetahui 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 dalam situasi berikut:
Saat diinisialisasi, klien harus mengisi slot awal ke pemetaan node.
Saat pengalihan
MOVEDditerima dari server, seperti dalam situasi failover saat semua slot yang ditayangkan oleh node utama sebelumnya diambilalih oleh replika, atau melakukan re-sharding saat slot dipindahkan dari node utama sumber ke node utama target.Saat error
CLUSTERDOWNditerima dari server atau koneksi ke server tertentu mengalami waktu tunggu habis secara terus-menerus.Saat error
READONLYditerima dari server. Hal ini dapat terjadi saat node utama diturunkan menjadi replika.Selain itu, klien harus memuat ulang topologi secara berkala agar klien tetap melakukan pemanasan untuk setiap perubahan dan mempelajari perubahan yang mungkin tidak menyebabkan pengalihan/ error dari server, seperti saat node replika baru ditambahkan. Perhatikan bahwa koneksi yang tidak berlaku 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 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 tumbuh 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 cache di memori), dan jumlah klien yang membuat permintaan harus tetap dibatasi untuk menghindari kelebihan beban server.
Misalnya, saat aplikasi klien memulai 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 selama jangka waktu yang lama, sehingga menyebabkan penggunaan CPU yang sangat tinggi.
Menghindari kelebihan penemuan di Valkey
Untuk mengurangi dampak yang disebabkan oleh lonjakan permintaan koneksi dan penemuan secara tiba-tiba, sebaiknya lakukan hal berikut:
Terapkan kumpulan 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 Valkey untuk melakukan penemuan node. Endpoint penemuan sangat tersedia dan diseimbangkan bebannya di semua node dalam instance. Selain itu, endpoint penemuan mencoba me-rutekan permintaan penemuan node ke node dengan tampilan topologi terbaru.
Praktik terbaik persistensi
Bagian ini menjelaskan praktik terbaik untuk persistensi.
Persistensi RDB
Untuk hasil terbaik saat mencadangkan instance 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 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 memadai untuk menyelesaikan snapshot, Anda harus mempertahankan atau menetapkan maxmemory pada 80% kapasitas node sehingga 20% dicadangkan untuk overhead. Lihat Memantau instance yang memiliki beban tulis tinggi untuk mempelajari lebih lanjut. Overhead memori ini, selain Snapshot pemantauan, membantu Anda mengelola beban kerja untuk mendapatkan snapshot yang berhasil.
Snapshot yang sudah tidak berlaku
Memulihkan node dari snapshot yang sudah tidak berlaku dapat menyebabkan masalah performa untuk aplikasi Anda saat mencoba merekonsiliasi sejumlah besar kunci yang sudah tidak berlaku atau perubahan lain pada database Anda seperti perubahan skema. Jika Anda khawatir tentang pemulihan dari snapshot yang sudah tidak berlaku, 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 yang 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 yang konstan dan memerlukan snapshot yang 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
Pemadaman layanan zona kemungkinan tidak akan memengaruhi instance Anda. Dengan menempatkan semua node dalam satu zona, kemungkinan pemadaman zona yang memengaruhi server Anda menurun dari 100% menjadi 33%. Hal ini karena ada kemungkinan 33% bahwa zona tempat instance Anda berada akan mengalami pemadaman layanan, dibandingkan dengan kemungkinan 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 menyediakan instance baru di zona yang berfungsi dengan cepat dan mengalihkan aplikasi untuk operasi yang terganggu secara minimal.