Ketersediaan tinggi dan replika

Halaman ini menjelaskan cara arsitektur Memorystore for Valkey menyediakan dan mendukung ketersediaan tinggi (HA). Halaman ini juga menjelaskan cara meningkatkan performa dan stabilitas instance dengan konfigurasi HA yang kami rekomendasikan.

Ketersediaan tinggi

Memorystore for Valkey dibangun di atas arsitektur yang sangat tersedia, tempat klien Anda mengakses node Memorystore for Valkey terkelola secara langsung. Klien Anda melakukannya dengan terhubung ke endpoint individual, seperti yang dijelaskan dalam Menghubungkan ke instance Memorystore for Valkey.

Menghubungkan ke shard secara langsung memberikan manfaat berikut:

  • Koneksi langsung menghindari hop perantara, yang meminimalkan waktu round-trip (latensi klien) antara klien Anda dan node Memorystore untuk Valkey.

  • Dalam Mode Cluster Diaktifkan, koneksi langsung menghindari titik tunggal kegagalan karena setiap shard dirancang untuk gagal secara independen. Misalnya, jika traffic dari beberapa klien membebani slot (bagian keyspace), kegagalan shard akan membatasi dampak pada shard yang bertanggung jawab untuk menyajikan slot.

Sebaiknya buat instance multi-zona dengan tingkat ketersediaan tinggi, bukan instance zona tunggal, karena keandalannya yang lebih baik. Namun, jika Anda memilih untuk menyediakan instance tanpa replika, sebaiknya pilih instance zona tunggal. Untuk mengetahui informasi selengkapnya, lihat Kapan harus menggunakan instance zona tunggal.

Untuk mengaktifkan ketersediaan tinggi bagi instance, Anda harus menyediakan minimal 1 replika untuk setiap shard. Anda dapat melakukannya saat Membuat instance, atau Anda dapat Menskalakan jumlah replika menjadi minimal 1 replika per shard. Replika menyediakan Failover otomatis selama pemeliharaan terencana dan kegagalan shard yang tidak terduga.

Sebaiknya konfigurasikan klien Anda sesuai dengan panduan dalam Praktik terbaik klien. Dengan menggunakan praktik terbaik yang direkomendasikan, klien Anda dapat menangani item berikut untuk instance Anda secara otomatis dan tanpa periode nonaktif:

  • Peran (failover otomatis)
  • Endpoint (penggantian node)
  • Perubahan penetapan slot terkait Mode Cluster Diaktifkan (penyebaran skala dan penurunan skala konsumen)

Replika

Instance Memorystore for Valkey dengan tingkat ketersediaan tinggi adalah resource regional. Memorystore for Valkey mendistribusikan VM utama dan replika shard di beberapa zona untuk melindungi dari pemadaman layanan di zona. Memorystore for Valkey mendukung instance dengan 0-5 replika per shard.

Anda dapat menggunakan replika untuk meningkatkan throughput baca dengan mengorbankan potensi keusangan data.

  • Mode Cluster Diaktifkan: Gunakan perintah READONLY untuk membuat koneksi yang memungkinkan klien Anda membaca dari replika.
  • Mode Cluster Dinonaktifkan: Hubungkan ke endpoint pembaca untuk terhubung ke salah satu replika yang tersedia.

Contoh Instance dengan Mode Cluster Diaktifkan

Diagram berikut mengilustrasikan contoh untuk instance Cluster Mode Enabled:

Contoh instance dengan tiga shard dan nol replika per shard

Instance Memorystore for Valkey Cluster Mode Enabled tanpa replika per shard, dan node yang dibagi secara merata di tiga zona.

Contoh instance dengan tiga shard dan satu replika per shard

Instance Memorystore for Valkey Cluster Mode Enabled dengan satu replika per shard, dan node yang dibagi secara merata di tiga zona.

Contoh instance dengan tiga shard dan beberapa replika per shard

Instance Memorystore for Valkey Cluster Mode Enabled dengan beberapa replika per shard, dan node yang dibagi secara merata di tiga zona.

Contoh Instance Cluster Mode Disabled

Diagram berikut mengilustrasikan contoh untuk instance Cluster Mode Disabled:

Contoh instance dengan beberapa replika

Instance Memorystore for Valkey Cluster Mode Disabled dengan beberapa replika dan node yang dibagi secara merata di tiga zona.

Pengaruh failover terhadap aplikasi Anda

Saat Memorystore for Valkey mempromosikan replika ke instance utama, Memorystore for Valkey akan menghentikan koneksi yang ada ke endpoint utama instance. Selama perbaikan otomatis dan peristiwa pemeliharaan, instance tidak tersedia selama rata-rata 30 detik.

Setelah instance tersedia, Memorystore for Valkey menggunakan string koneksi atau alamat IP yang sama untuk mengalihkan aplikasi Anda ke instance utama baru secara otomatis. Anda tidak perlu mengupdate aplikasi.

Selama failover, jika ada koneksi ke endpoint baca, Memorystore for Valkey akan menghentikan koneksi ke replika yang dipromosikan ke instance utama. Namun, Memorystore for Valkey tidak menghentikan koneksi ke replika lainnya. Setelah failover selesai dan replika baru tersedia, Memorystore for Valkey akan mengalihkan koneksi ke replika baru.

Failover otomatis

Failover otomatis dalam shard dapat terjadi karena pemeliharaan atau kegagalan tak terduga pada node utama. Selama failover, replika dipromosikan menjadi replika utama. Anda dapat mengonfigurasi replika secara eksplisit. Layanan ini juga dapat menyediakan replika tambahan untuk sementara selama pemeliharaan internal guna menghindari periode nonaktif.

Failover otomatis mencegah kehilangan data selama update pemeliharaan. Untuk mengetahui informasi selengkapnya tentang perilaku failover otomatis selama pemeliharaan, lihat Perilaku failover otomatis selama pemeliharaan.

Durasi failover dan perbaikan node

Failover otomatis dapat memerlukan waktu puluhan detik untuk peristiwa yang tidak direncanakan, seperti error proses node utama atau kegagalan hardware. Selama waktu ini, sistem akan mendeteksi kegagalan, dan memilih replika untuk menjadi replika utama baru.

Perbaikan node dapat memerlukan waktu beberapa menit agar layanan dapat mengganti node yang gagal. Hal ini berlaku untuk semua node utama dan replika. Untuk instance yang tidak memiliki ketersediaan tinggi (tidak ada replika yang disediakan), memperbaiki node utama yang gagal juga memerlukan waktu dalam hitungan menit.

Perilaku klien selama failover yang tidak direncanakan

Koneksi klien kemungkinan akan direset, bergantung pada sifat kegagalannya. Setelah pemulihan otomatis, Anda dapat mencoba kembali koneksi dengan backoff eksponensial untuk menghindari kelebihan beban pada node utama dan replika.

Klien yang menggunakan replika untuk throughput baca mungkin mengalami penurunan kapasitas sementara hingga node yang gagal diganti secara otomatis.

Operasi tulis yang hilang

Selama failover yang disebabkan oleh kegagalan yang tidak terduga, penulisan yang diakui mungkin hilang karena sifat asinkron protokol replikasi Valkey.

Aplikasi klien dapat memanfaatkan perintah Valkey WAIT untuk meningkatkan keamanan data di dunia nyata.

Dampak keyspace dari pemadaman layanan satu zona

Bagian ini menjelaskan dampak pemadaman layanan satu zona pada instance Memorystore for Valkey.

Instance multi-zona

  • Instance HA: Jika zona mengalami pemadaman layanan, seluruh keyspace akan tersedia untuk operasi baca dan tulis, tetapi karena beberapa replika baca tidak tersedia, kapasitas baca akan berkurang. Kami sangat menyarankan untuk menyediakan kapasitas cluster secara berlebihan agar instance memiliki kapasitas baca yang cukup, jika terjadi pemadaman layanan di satu zona yang jarang terjadi. Setelah pemadaman layanan berakhir, replika di zona yang terpengaruh akan dipulihkan dan kapasitas baca cluster akan kembali ke nilai yang dikonfigurasi. Untuk mengetahui informasi selengkapnya, lihat Pola untuk aplikasi yang skalabel dan andal.

  • Instance non-HA (tanpa replika): Jika zona mengalami pemadaman, bagian keyspace yang disediakan di zona yang terpengaruh akan mengalami penghapusan data, dan tidak tersedia untuk operasi tulis atau baca selama durasi pemadaman. Setelah pemadaman layanan berakhir, primer di zona yang terpengaruh akan dipulihkan dan kapasitas cluster akan kembali ke nilai yang dikonfigurasi.

Instance zona tunggal

  • Instance HA dan Non-HA: Jika zona tempat instance disediakan mengalami pemadaman layanan, cluster tidak akan tersedia dan data akan dihapus. Jika zona lain mengalami pemadaman, cluster akan terus melayani permintaan baca dan tulis.

Praktik terbaik

Bagian ini menjelaskan praktik terbaik untuk ketersediaan tinggi dan replika.

Menambahkan replika

Menambahkan replika memerlukan snapshot RDB. 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 seiring halaman yang disentuh oleh penulisan disalin. Jejak memori bisa mencapai dua kali lipat ukuran data di node.

Untuk memastikan node memiliki memori yang cukup untuk menyelesaikan snapshot, pertahankan atau tetapkan maxmemory pada 80% kapasitas node sehingga 20% dicadangkan untuk overhead. Overhead memori ini, selain memantau snapshot, membantu Anda mengelola workload agar snapshot berhasil. Selain itu, saat Anda menambahkan replika, turunkan traffic tulis sebanyak mungkin. Untuk mengetahui informasi selengkapnya, lihat Memantau penggunaan memori untuk instance.