Perubahan ukuran klaster online

Resharding melibatkan proses menambahkan dan menghapus serpihan atau simpul ke klaster Anda dan mendistribusikan ulang keyspace. Sebagai hasilnya, beberapa hal 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 beberapa langkah berikut.

Sebelum memulai resharding, sebaiknya lakukan yang berikut:

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

• Dapatkan notifikasi awal untuk masalah penskalaan – Resharding adalah operasi komputasi yang intensif. Karena ini, sebaiknya jaga pemanfaatan CPU di bawah 80 persen pada instans multicore dan kurang dari 50 persen pada instans inti tunggal selama resharding. Pantau metrik ElastiCache untuk Redis dan mulai resharding sebelum aplikasi Anda mulai mengalami masalah penskalaan. Metrik yang berguna untuk melacak adalah CPUUtilization, NetworkBytesIn, NetworkBytesOut, CurrConnections, NewConnections, FreeableMemory, SwapUsage, dan BytesUsedForCacheItems.

• 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 selama jam bukan 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 timeout klien – Beberapa klien mungkin mengalami latensi yang lebih tinggi selama perubahan ukuran klaster secara online. Anda dapat membuat konfigurasi pustaka klien dengan batas waktu yang lebih tinggi agar waktu sistem memiliki waktu untuk terhubung bahkan dalam kondisi beban yang lebih tinggi pada server. Dalam beberapa kasus, mungkin ada baiknya untuk membuka sejumlah besar koneksi ke server. Dalam kasus ini, pertimbangkan untuk menambahkan mundur eksponensial untuk menyambung logika kembali. Melakukan hal ini dapat membantu mencegah lonjakan koneksi baru di server pada waktu yang sama.

• Muat Fungsi Anda di setiap shard — Saat menskalakan klaster, ElastiCache akan secara otomatis mereplikasi Fungsi yang dimuat di salah satu simpul yang ada (dipilih secara acak) ke simpul baru. Jika klaster Anda memiliki Redis 7.0 atau yang lebih baru dan aplikasi Anda menggunakan Fungsi Redis, sebaiknya muat semua fungsi Anda ke semua serpihan sebelum melakukan penskalaan ke luar agar klaster Anda tidak berakhir dengan fungsi yang berbeda pada serpihan yang berbeda.

Setelah resharding, perhatikan hal berikut:

• Penskalaan ke dalam mungkin berhasil sebagian jika memori tidak cukup pada serpihan target. Jika hal tersebut terjadi, tinjau memori yang tersedia dan coba lagi operasi, jika perlu. Data pada serpihan target tidak akan dihapus.

• 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 di dalam skrip Lua selama operasi resharding. Sebelum Redis 6, perintah BRPOPLPUSH tidak didukung jika beroperasi pada slot yang dimigrasi.