Praktik terbaik: Mengubah ukuran klaster secara online

Resharding melibatkan proses menambahkan dan menghapus serpihan atau simpul ke klaster Anda dan mendistribusikan ulang keyspace. Oleh karena itu, ada beberapa hal yang memiliki dampak pada operasi resharding, seperti beban pada klaster, pemanfaatan memori, dan ukuran keseluruhan data. Untuk pengalaman terbaik, sebaiknya ikuti praktik terbaik klaster secara keseluruhan untuk distribusi pola beban kerja seragam. Selain itu, sebaiknya lakukan langkah-langkah berikut.

Sebelum memulai resharding, sebaiknya lakukan hal berikut:

• Uji aplikasi Anda – Uji perilaku aplikasi Anda selama resharding di lingkungan staging jika memungkinkan.

• Dapatkan notifikasi awal untuk masalah penskalaan – Resharding adalah operasi sarat komputasi. Karena itu, kami merekomendasikan untuk menjaga pemanfaatan CPU di bawah 80 persen pada instance multicore dan kurang dari 50 persen pada instance inti tunggal selama resharding. Pantau metrik MemoryDB dan memulai resharding sebelum aplikasi Anda mulai mengamati masalah penskalaan. Metrik yang berguna untuk dilacak adalah CPUUtilization, NetworkBytesIn, NetworkBytesOut, CurrConnections, NewConnections, FreeableMemory, SwapUsage, dan BytesUsedForMemoryDB.

• Pastikan untuk menyediakan memori yang cukup sebelum penskalaan ke dalam – Jika Anda melakukan penskalaan ke dalam, pastikan memori pada serpihan yang akan dipertahankan tersedia setidaknya 1,5 kali dari memori yang akan digunakan pada serpihan yang akan dihapus.

• Mulai resharding di luar jam puncak – Praktik ini membantu mengurangi dampak latensi dan throughput pada klien selama operasi resharding. Hal ini juga membantu untuk menyelesaikan resharding lebih cepat karena lebih banyak sumber daya dapat digunakan untuk distribusi ulang slot.

• Tinjau perilaku waktu habis klien – Beberapa klien mungkin mengalami latensi yang lebih tinggi selama perubahan ukuran klaster online. Anda dapat mengonfigurasi pustaka klien dengan waktu habis yang lebih tinggi agar sistem memiliki waktu untuk terhubung bahkan dalam kondisi beban yang lebih tinggi pada server. Dalam beberapa kasus, mungkin sebaiknya buka sejumlah besar koneksi ke server. Dalam kasus ini, pertimbangkan untuk menambahkan backoff eksponensial ke logika koneksi ulang. Melakukan hal ini dapat membantu mencegah lonjakan koneksi baru di server pada waktu yang sama.

Selama resharding, sebaiknya melakukan hal berikut:

• Hindari perintah yang menghabiskan banyak daya komputasi – Hindari menjalankan operasi yang sarat komputasi dan I/O, seperti perintah KEYS dan SMEMBERS. Pendekatan ini disarankan karena operasi ini meningkatkan beban pada klaster dan memiliki dampak pada performa klaster. Sebagai gantinya, gunakan perintah SCAN dan SSCAN.

• Ikuti praktik terbaik Lua – Hindari menjalankan skrip Lua terlalu lama, dan selalu nyatakan kunci yang digunakan dalam skrip Lua di depan. Pendekatan ini disarankan untuk menentukan bahwa skrip Lua tidak menggunakan perintah cross slot. Pastikan bahwa kunci yang digunakan dalam skrip Lua adalah milik slot yang sama.

Setelah resharding, perhatikan hal berikut:

• Penskalaan ke dalam mungkin berhasil sebagian jika memori tidak cukup pada serpihan target. Jika hasil seperti itu terjadi, tinjau memori yang tersedia dan coba lagi operasi itu, jika perlu.

• Slot dengan item besar tidak dimigrasikan. Secara khusus, slot dengan item yang lebih besar dari 256 MB pasca-serialisasi tidak dimigrasikan.

• Perintah FLUSHALL dan FLUSHDB tidak didukung dalam skrip Lua selama operasi resharding.