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

Ketahanan di Amazon ElastiCache

Infrastruktur AWS global dibangun di sekitar AWS Wilayah dan Zona Ketersediaan. AWS Wilayah menyediakan beberapa Availability Zone yang terpisah secara fisik dan terisolasi, yang terhubung dengan latensi rendah, throughput tinggi, dan jaringan yang sangat redundan. Dengan Zona Ketersediaan, Anda dapat merancang dan mengoperasikan aplikasi dan basis data yang secara otomatis melakukan failover di antara Zona Ketersediaan tanpa gangguan. Zona Ketersediaan memiliki ketersediaan dan toleransi kesalahan yang lebih baik, dan dapat diskalakan dibandingkan infrastruktur biasa yang terdiri dari satu atau beberapa pusat data.

Untuk informasi selengkapnya tentang AWS Wilayah dan Availability Zone, lihat Infrastruktur AWS Global.

Selain infrastruktur AWS global, Amazon ElastiCache menawarkan beberapa fitur untuk membantu mendukung ketahanan data dan kebutuhan cadangan Anda.

Mitigasi Kegagalan

Saat merencanakan ElastiCache implementasi Amazon Anda, Anda harus merencanakan sehingga kegagalan memiliki dampak minimal pada aplikasi dan data Anda. Topik pada bagian ini membahas pendekatan yang dapat Anda ambil untuk melindungi aplikasi dan data Anda dari kegagalan.

Mitigasi Kegagalan saat Menjalankan Memcached

Saat menjalankan mesin Memcached, Anda memiliki opsi berikut untuk memperkecil dampak kegagalan. Terdapat dua jenis kegagalan yang harus diatasi dalam rencana mitigasi kegagalan Anda: kegagalan simpul dan kegagalan Zona Ketersediaan.

Mitigasi Kegagalan Simpul

Cache nirserver secara otomatis memitigasi kegagalan simpul dengan arsitektur Multi-AZ yang direplikasi sehingga kegagalan simpul terlihat jelas untuk aplikasi Anda. Untuk mengurangi dampak kegagalan simpul di klaster yang dirancang sendiri, sebarkan data cache Anda ke lebih banyak simpul. Karena klaster yang dirancang sendiri tidak mendukung replikasi, kegagalan simpul akan selalu mengakibatkan hilangnya beberapa data dari klaster Anda.

Saat Anda membuat cluster Memcached, Anda dapat membuatnya dengan 1 hingga 60 node, atau lebih dengan permintaan khusus. Melakukan partisi data pada sejumlah besar simpul berarti lebih sedikit data yang hilang jika ada simpul yang gagal. Misalnya jika Anda membuat partisi data Anda pada 10 simpul, maka setiap simpul akan menyimpan sekitar 10% dari data cache Anda. Dalam hal ini, kegagalan simpul akan menghilangkan sekitar 10% dari cache Anda yang perlu diganti saat simpul pengganti dibuat dan disediakan. Jika data yang sama disimpan pada cache di 3 simpul yang besar, maka kegagalan satu simpul akan menghilangkan sekitar 33% dari data cache Anda.

Untuk informasi tentang menentukan jumlah simpul dalam sebuah klaster Memcached, lihat Membuat klaster Memcached (konsol).

Mitigasi Kegagalan Zona Ketersediaan

Cache nirserver secara otomatis memitigasi kegagalan simpul dengan arsitektur Multi-AZ yang direplikasi sehingga kegagalan AZ terlihat jelas untuk aplikasi Anda.

Untuk mengurangi dampak kegagalan Zona Ketersediaan di klaster yang dirancang sendiri, tempatkan simpul Anda di sebanyak mungkin Zona Ketersediaan. Jika terjadi kegagalan AZ, Anda akan kehilangan data yang di-cache di AZ itu, bukan data yang di-cache di yang lain. AZs

Mengapa perlu banyak simpul?

Jika wilayah saya hanya memiliki 3 Zona Ketersediaan, mengapa saya memerlukan lebih dari 3 simpul karena jika satu AZ gagal, maka saya akan kehilangan sekitar sepertiga data saya?

Ini adalah pertanyaan yang sangat bagus. Ingat bahwa kita mencoba mengurangi dua jenis kegagalan yang berbeda, yaitu kegagalan simpul dan Zona Ketersediaan. Anda benar, jika data Anda tersebar di beberapa Zona Ketersediaan dan salah satu zona gagal, maka Anda akan kehilangan hanya data cache di AZ itu, terlepas dari jumlah simpul yang Anda miliki. Namun, jika satu simpul gagal, memiliki lebih banyak simpul akan mengurangi proporsi data yang hilang.

Tidak ada "rumus ajaib" untuk menentukan berapa banyak simpul diperlukan untuk klaster Anda. Anda harus menimbang dampak kehilangan data vs kemungkinan kegagalan vs biaya, dan mendapatkan kesimpulan Anda sendiri.

Untuk informasi tentang menentukan jumlah simpul dalam sebuah klaster Memcached, lihat Membuat klaster Memcached (konsol).

Untuk informasi lain tentang wilayah dan Availability Zone, lihat Memilih wilayah dan zona ketersediaan untuk ElastiCache.

Mengurangi Kegagalan saat Menjalankan Valkey atau Redis OSS

Saat menjalankan mesin Valkey atau Redis OSS, Anda memiliki opsi berikut untuk meminimalkan dampak kegagalan node atau Availability Zone.

Mitigasi Kegagalan Simpul

Cache nirserver secara otomatis memitigasi kegagalan simpul dengan arsitektur Multi-AZ sehingga kegagalan simpul terlihat jelas untuk aplikasi Anda. Klaster yang dirancang sendiri harus dikonfigurasi dengan tepat untuk mengurangi kegagalan simpul individual.

Untuk mengurangi dampak kegagalan node Valkey atau Redis OSS pada cluster yang dirancang sendiri, Anda memiliki opsi berikut:

Mengurangi Kegagalan: Grup Replikasi Valkey atau Redis OSS

Grup replikasi Valkey atau Redis OSS terdiri dari satu node utama yang aplikasi Anda dapat membaca dari dan menulis ke, dan dari 1 hingga 5 node replika read-only. Setiap kali data ditulis ke simpul primer, data ini juga diperbarui secara asinkron ke simpul replika baca.

Selama proses ini, aplikasi Anda dapat terus melakukan pembacaan dan penulisan menggunakan simpul lain.

Valkey atau Redis OSS Multi-AZ

Anda dapat mengaktifkan Multi-AZ pada grup replikasi Valkey atau Redis OSS Anda. Terlepas dari apakah Anda memiliki Multi-AZ yang aktif atau tidak, primer yang gagal akan terdeteksi dan diganti secara otomatis. Namun prosesnya akan berbeda tergantung apakah Multi-AZ aktif atau tidak.

Melakukan failover ke simpul replika umumnya lebih cepat daripada membuat dan menyediakan simpul primer baru. Ini berarti aplikasi Anda dapat melanjutkan kembali proses penulisan ke simpul primer Anda lebih cepat daripada ketika Multi-AZ tidak diaktifkan.

Untuk informasi selengkapnya, lihat Meminimalkan waktu henti ElastiCache dengan menggunakan Multi-AZ dengan Valkey dan Redis OSS.

Selama langkah 1 sampai 4 proses ini, aplikasi Anda tidak dapat menulis ke simpul primer. Namun, aplikasi Anda dapat terus membaca dari simpul replika Anda.

Untuk perlindungan tambahan, sebaiknya Anda meluncurkan node di grup replikasi Anda di Availability Zones (AZs) yang berbeda. Jika Anda melakukan ini, kegagalan AZ hanya akan berdampak pada simpul di AZ tersebut dan bukan yang lain.

Untuk informasi selengkapnya, lihat Ketersediaan tinggi menggunakan grup replikasi.

Mitigasi Kegagalan Zona Ketersediaan

Cache nirserver secara otomatis memitigasi kegagalan simpul dengan arsitektur Multi-AZ yang direplikasi sehingga kegagalan AZ terlihat jelas untuk aplikasi Anda.

Untuk mengurangi dampak kegagalan Zona Ketersediaan di klaster yang dirancang sendiri, tempatkan simpul untuk setiap serpihan di sebanyak mungkin Zona Ketersediaan.

Sebanyak apa pun simpul yang Anda miliki di sebuah serpihan, jika semua simpul terletak di Zona Ketersediaan yang sama, kegagalan fatal pada AZ tersebut akan membuat semua data serpihan Anda hilang. Namun, jika Anda menemukan node Anda dalam beberapa AZs, kegagalan AZ apa pun mengakibatkan Anda hanya kehilangan node di AZ tersebut.

Setiap kali kehilangan simpul, Anda dapat mengalami penurunan performa karena operasi baca menjadi terbagi ke simpul yang lebih sedikit. Penurunan performa ini akan berlanjut hingga simpul tersebut diganti.

Untuk informasi tentang menentukan Availability Zones untuk Valkey atau Redis OSS node, lihat. Membuat cluster Valkey (mode cluster dinonaktifkan) (Konsol)

Untuk informasi selengkapnya tentang wilayah dan Zona Ketersediaan, lihat Memilih wilayah dan zona ketersediaan untuk ElastiCache.

Rekomendasi

Sebaiknya buat cache nirserver, bukan klaster yang dirancang sendiri, karena Anda secara otomatis mendapatkan toleransi kesalahan yang lebih baik tanpa konfigurasi tambahan. Saat membuat klaster yang dirancang sendiri, ada dua jenis kegagalan yang perlu direncanakan: kegagalan simpul individual dan kegagalan Zona Ketersediaan yang luas. Rencana mitigasi kegagalan terbaik akan mengatasi kedua jenis kegagalan tersebut.

Meminimalkan Dampak Kegagalan Simpul

Untuk meminimalkan dampak kegagalan node saat menggunakan Valkey atau Redis OSS, sebaiknya implementasi Anda menggunakan beberapa node di setiap shard dan mendistribusikan node di beberapa Availability Zone. Ini dilakukan secara otomatis untuk cache nirserver.

Untuk cluster yang dirancang sendiri di Valkey atau Redis OSS, kami menyarankan Anda mengaktifkan Multi-AZ pada grup replikasi Anda sehingga secara otomatis ElastiCache akan gagal ke replika jika node utama gagal.

Saat menjalankan Memcached dan membuat partisi data Anda di seluruh simpul, semakin banyak simpul yang Anda gunakan maka semakin kecil data yang hilang jika ada satu simpul yang gagal.

Meminimalkan Dampak Kegagalan Zona Ketersediaan

Untuk meminimalkan dampak kegagalan Zona Ketersediaan, sebaiknya Anda meluncurkan simpul Anda di sebanyak mungkin Zona Ketersediaan yang tersedia. Menyebarkan node Anda secara merata AZs akan meminimalkan dampak jika terjadi kegagalan AZ. Ini dilakukan secara otomatis untuk cache nirserver.

Tindakan pencegahan lain

Jika Anda menjalankan Valkey atau Redis OSS, maka selain hal di atas, kami sarankan Anda menjadwalkan pencadangan reguler cluster Anda. Cadangan (snapshot) membuat file .rdb yang dapat Anda gunakan untuk memulihkan cache Anda jika terjadi kegagalan atau kerusakan. Untuk informasi selengkapnya, lihat Melakukan snapshot dan pemulihan.