Halaman ini menjelaskan cara Memorystore for Redis melakukan pemeliharaan pada instance. Panduan ini juga memberikan informasi dan rekomendasi konfigurasi yang harus diketahui aplikasi klien Anda untuk memanfaatkan desain pemeliharaan tanpa downtime di Memorystore for Valkey. Rekomendasi ini berlaku untuk instance dengan ketersediaan tinggi dan instance tanpa replika. Namun, kami sangat merekomendasikan konfigurasi ketersediaan tinggi untuk semua kasus penggunaan produksi.
Memorystore for Valkey rutin mengupdate instance untuk memastikan layanan tersebut andal, berperforma, aman, dan terbaru. Update ini disebut pemeliharaan. Pemeliharaan dikelola sepenuhnya oleh layanan dan dirancang agar tidak berdampak pada periode nonaktif.
Pemeliharaan biasanya termasuk dalam kategori berikut:
- Fitur Memorystore. Untuk meluncurkan beberapa fitur, Memorystore memerlukan update pemeliharaan.
- Patch sistem operasi. Kami terus memantau kerentanan keamanan yang baru teridentifikasi di sistem operasi. Setelah ditemukan, kami melakukan patch pada sistem operasi untuk melindungi Anda dari risiko baru.
- Patch database. Pemeliharaan dapat mencakup update Valkey untuk meningkatkan karakteristik keamanan, performa, dan keandalan instance di luar yang disediakan OSS Valkey.
Mengonfigurasi aplikasi klien
Untuk mengonfigurasi aplikasi klien Anda agar mendapatkan performa dan ketersediaan terbaik selama pemeliharaan, ikuti langkah-langkah berikut:
- Gunakan dan konfigurasikan klien pihak ketiga Anda sesuai dengan panduan di Praktik terbaik klien untuk memastikan bahwa pemeliharaan terjadwal tidak memengaruhi aplikasi klien. Konfigurasi klien yang kami rekomendasikan dapat menghindari reset koneksi melalui pembaruan topologi inline berkala dan rotasi koneksi latar belakang.
- Uji aplikasi klien Anda dengan serangkaian operasi update (seperti penskalaan ke dalam atau ke luar, perubahan jumlah replika) saat menjalankan beban kerja perwakilan di node utama dan replika, serta memantau dampak klien. Update ini menguji logika pembaruan topologi inline pada klien, dampak sinkronisasi penuh, penemuan node baru, dan kemampuan penghapusan node yang ada. Pengujian membantu memastikan bahwa klien pihak ketiga dikonfigurasi dengan benar untuk menghindari dampak negatif pada aplikasi Anda.
Pemeliharaan terjadwal
Memorystore for Valkey memanfaatkan strategi siklus proses pembuatan sebelum penghapusan dan deployment bertahap untuk menghindari dampak periode nonaktif akibat pemeliharaan terjadwal Memorystore pada instance Valkey Anda. Pemeliharaan tanpa periode nonaktif dicapai dengan menggunakan kemampuan pengalihan permintaan dari protokol cluster OSS Valkey bersama dengan mekanisme Memorystore berikut:
- Failover terkoordinasi tanpa kehilangan data
- Penghapusan node yang halus untuk memungkinkan klien mengikuti pembaruan topologi node tanpa dampak ketersediaan
- Endpoint PSC instance tidak terpengaruh oleh pemeliharaan. Untuk informasi selengkapnya tentang endpoint PSC, lihat Endpoint instance.
Perilaku layanan yang dijelaskan di bagian berikut hanya berlaku untuk pemeliharaan terjadwal. Untuk informasi tentang dampak peristiwa yang tidak terencana seperti kegagalan hardware, lihat Perilaku klien selama failover yang tidak terencana.
Masa pemeliharaan default
Secara default, Memorystore akan mengupdate instance dalam periode berikut sesuai dengan zona waktu instance:
Periode hari kerja (Hari Senin sampai hari Jumat): 22.00-06.00
Periode akhir pekan: Hari Jumat, 22.00 hingga hari Senin, 06.00
Strategi deployment bertahap
Deployment Memorystore untuk Valkey dilakukan dengan cakupan yang terus meningkat, dan pada kecepatan yang memungkinkan deteksi kegagalan cukup awal untuk memitigasi dampak dan membangun keyakinan stabilitas. Waktu pembuatan (waktu selama update diterapkan dan dipantau sebelum dianggap berhasil dan dilanjutkan) terintegrasi di seluruh kumpulan instance Memorystore pada skala layanan. Selain itu, waktu pembuatan diintegrasikan dalam instance di seluruh zona dalam region (beberapa fault-domain) untuk mengurangi cakupan dampak, jika ada.
Untuk instance yang dikonfigurasi untuk ketersediaan tinggi, maksimal satu fault domain/zona akan diupdate pada waktu tertentu untuk memastikan bahwa shard instance, termasuk utama dan replika, memiliki ketersediaan tinggi selama update. Selain itu, hanya beberapa node Valkey yang diperbarui pada waktu tertentu. Update menggunakan mekanisme siklus proses create-before-destroy untuk memaksimalkan stabilitas instance. Strategi ini memberikan manfaat paling besar saat mengupdate instance dengan banyak shard. Hanya menerapkan pembaruan ke sebagian kecil dari keseluruhan ruang kunci pengguna pada waktu tertentu akan memaksimalkan ketersediaan data.
Strategi siklus proses Create-Before-Destroy
Instance Valkey memiliki beberapa shard. Setiap shard memiliki satu node utama dan nol atau beberapa node replika. Memorystore menggunakan proses berikut untuk memperbarui node Valkey utama atau replika yang ada di shard:
- Memorystore untuk Valkey pertama-tama menambahkan replika yang benar-benar baru dengan update software terbaru ke shard. Memorystore membuat node yang sepenuhnya baru, bukan memperbarui node yang ada, untuk memastikan kapasitas yang disediakan dipertahankan jika terjadi kegagalan bootstrap yang tidak terduga.
- Jika node dalam shard yang akan diperbarui adalah node utama, node tersebut akan dikonversi menjadi replika terlebih dahulu sebelum dihapus menggunakan failover terkoordinasi.
- Selanjutnya, Memorystore akan menghapus replika yang menggunakan software sebelumnya.
- Proses ini diulang untuk setiap node dalam instance.
Strategi create-before-destroy membantu mempertahankan kapasitas instance yang disediakan, dibandingkan dengan deployment rolling standar yang diupdate secara langsung, tetapi mengakibatkan pemadaman ketersediaan (dan terkadang kehilangan data) untuk aplikasi klien. Untuk shard tanpa replika, Memorystore for Redis masih menyediakan replika baru terlebih dahulu, mengoordinasikan failover, dan terakhir mengganti node utama shard yang ada.
Langkah 1: Tambahkan replika Valkey
Langkah pertama mekanisme create-before-destroy adalah menambahkan node replika dengan software terbaru menggunakan mekanisme Valkey OSS sinkronisasi penuh untuk menyalin data dari node utama ke node replika. Hal ini dilakukan dengan melakukan fork pada proses turunan dan memanfaatkan replikasi tanpa disk untuk mem-bootstrap replika.
Anda dapat memanfaatkan arsitektur skala horizontal instance dengan menyediakan lebih banyak shard untuk mengurangi ukuran ruang kunci dalam node. Memiliki set data yang lebih kecil per node membantu mengurangi dampak latensi fork dari operasi sinkronisasi penuh. Hal ini juga mempercepat penyalinan data di seluruh node.
Langkah 2: Failover utama terkoordinasi
Jika node Valkey yang perlu diperbarui adalah node utama, Memorystore akan terlebih dahulu menjalankan failover terkoordinasi ke node replika yang baru ditambahkan, lalu melanjutkan dengan penghapusan node. Selama failover terkoordinasi, klien dan node Valkey bekerja sama dan menggunakan strategi berikut untuk menghindari periode nonaktif aplikasi:
- Permintaan klien yang masuk diblokir sementara di node utama, sehingga memberikan waktu untuk memastikan replika yang ada disinkronkan 100% dengan node utama.
- Replika menyelesaikan proses pemilihan untuk mengambil alih peran utama.
- Node utama sebelumnya, yang kini menjadi replika, akan membatalkan pemblokiran permintaan yang ada dan mengalihkan permintaan tersebut ke node utama yang baru dipilih menggunakan protokol cluster OSS Valkey. Setiap permintaan baru yang dikirim ke node replika sebelumnya akan terus dialihkan ke node utama baru.
- Klien yang kompatibel dengan Valkey akan memuat ulang topologi dalam memorinya. Fungsi ini mempelajari alamat endpoint utama baru, dan tidak lagi memerlukan pengalihan.
Failover terkoordinasi biasanya memerlukan waktu puluhan milidetik. Namun, data yang sedang ditransfer yang menunggu untuk dihapus ke replika dan total ukuran instance Anda dapat meningkatkan latensi failover. Ukuran instance dapat memengaruhi konvergensi di seluruh node utama, yang memengaruhi pengambilan keputusan dalam memilih node utama baru.
Langkah 3: Hapus replika Valkey
Langkah terakhir dari mekanisme create-before-destroy adalah menghapus node replika di software sebelumnya. Penghapusan node secara tiba-tiba akan berdampak pada aplikasi klien karena klien meng-cache informasi endpoint dan topologi instance. Memorystore untuk Valkey telah mendesain penghapusan replika Valkey agar berjalan dengan lancar agar aplikasi klien dapat memuat ulang topologinya sebelum mengalami penonaktifan node hard. Topologi disesuaikan untuk memungkinkan klien mempelajari replika baru, tetapi juga melupakan replika yang akan dihapus sebelumnya.
Node replika yang menjalankan software sebelumnya akan dipertahankan selama periode pembuangan tertentu, biasanya dalam hitungan menit, selama periode tersebut node akan mulai mengalihkan permintaan baca yang masuk ke node utama shard-nya. Hal ini memungkinkan klien pihak ketiga memuat ulang topologi node dan mempelajari endpoint replika baru. Jika klien mencoba menjangkau node yang dihapus setelah periode pembuangan, upaya tersebut akan gagal, yang pada akhirnya memicu pembaruan topologi node pada klien yang terhubung sehingga klien tersebut dapat mempelajari perubahan replika. Pembaruan baru topologi node tidak melihat node replika yang akan dihapus.