Perubahan ukuran klaster online - Amazon ElastiCache

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Perubahan ukuran klaster online

Resharding melibatkan proses menambahkan dan menghapus serpihan atau simpul ke klaster Anda dan mendistribusikan ulang ruang kunci. 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 CPU pemanfaatan di bawah 80 persen pada instance multicore dan kurang dari 50 persen pada instance inti tunggal selama resharding. Pantau metrik ElastiCache (RedisOSS) dan mulai resharding sebelum aplikasi Anda mulai mengamati masalah penskalaan. Metrik yang berguna untuk dilacak 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 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.

  • Muat Functions Anda di setiap shard — Saat menskalakan klaster Anda, ElastiCache akan secara otomatis mereplikasi Fungsi yang dimuat di salah satu node yang ada (dipilih secara acak) ke node baru. Jika klaster Anda memiliki Valkey 7.2 ke atas, atau Redis OSS 7.0 atau lebih tinggi, dan aplikasi Anda menggunakan Fungsi, kami sarankan memuat semua fungsi Anda ke semua pecahan sebelum menskalakan sehingga cluster Anda tidak berakhir dengan fungsi yang berbeda pada pecahan 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 dalam skrip Lua selama operasi resharding. Sebelum Redis OSS 6, BRPOPLPUSH perintah tidak didukung jika beroperasi pada slot yang sedang dimigrasikan.