Pilar Keandalan Lensa ElastiCache Well-Architected Amazon - Amazon ElastiCache
REL1: Bagaimana Anda mendukung penerapan arsitektur ketersediaan tinggi (HA)?REL2: Bagaimana Anda memenuhi Tujuan Titik Pemulihan Anda (RPOs) denganElastiCache?REL3: Bagaimana Anda mendukung persyaratan pemulihan bencana (DR)? REL4: Bagaimana Anda secara efektif merencanakan kegagalan?REL5: Apakah ElastiCache komponen Anda dirancang untuk skala?

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

Pilar Keandalan Lensa ElastiCache Well-Architected Amazon

Pilar keandalan berfokus pada beban kerja yang menjalankan fungsi yang dimaksudkan dan bagaimana memulihkan dengan cepat dari kegagalan untuk memenuhi tuntutan. Topik utama meliputi desain sistem terdistribusi, perencanaan pemulihan, dan beradaptasi dengan perubahan persyaratan.

REL1: Bagaimana Anda mendukung penerapan arsitektur ketersediaan tinggi (HA)?

Pengenalan tingkat pertanyaan: Memahami arsitektur ketersediaan tinggi Amazon ElastiCache akan memungkinkan Anda beroperasi dalam keadaan tangguh selama acara ketersediaan.

Manfaat tingkat pertanyaan: Merancang ElastiCache cluster Anda agar tahan terhadap kegagalan memastikan ketersediaan yang lebih tinggi untuk penerapan Anda. ElastiCache

  • [Wajib] Tentukan tingkat keandalan yang Anda butuhkan untuk ElastiCache klaster Anda. Beban kerja yang berbeda memiliki standar ketahanan yang berbeda, dari beban kerja yang sepenuhnya sementara hingga beban kerja krusial. Tentukan kebutuhan untuk setiap jenis lingkungan yang Anda operasikan seperti dev, test, dan production.

    Mesin caching: ElastiCache (Memcached) vs ElastiCache (Redis) OSS

    1. ElastiCache (Memcached) tidak menyediakan mekanisme replikasi apa pun dan digunakan terutama untuk beban kerja sementara.

    2. ElastiCache (RedisOSS) menawarkan fitur HA yang dibahas di bawah ini

  • [Terbaik] Untuk beban kerja yang membutuhkan HA, gunakan ElastiCache (RedisOSS) dalam mode cluster dengan minimal dua replika per pecahan, bahkan untuk beban kerja persyaratan throughput kecil yang hanya membutuhkan satu pecahan.

    1. Untuk mode klaster diaktifkan, Multi-AZ diaktifkan secara otomatis.

      Multi-AZ meminimalkan waktu henti dengan melakukan failover otomatis dari simpul primer ke replika, jika terjadi pemeliharaan yang direncanakan atau tidak direncanakan serta mengurangi kegagalan AZ.

    2. Untuk beban kerja sharded, minimal tiga pecahan memberikan pemulihan yang lebih cepat selama peristiwa failover karena Protokol OSS Cluster Valkey atau Redis mengharuskan mayoritas node primer tersedia untuk mencapai kuorum.

    3. Siapkan dua replika atau lebih di seluruh Zona Ketersediaan.

      Memiliki dua replika memberikan peningkatan skalabilitas baca dan juga ketersediaan baca dalam skenario di mana satu replika sedang menjalani pemeliharaan.

    4. Gunakan jenis simpul berbasis Graviton2 (simpul default di sebagian besar wilayah).

      ElastiCache (RedisOSS) telah menambahkan kinerja yang dioptimalkan pada node ini. Hasilnya, Anda mendapatkan performa replikasi dan sinkronisasi yang lebih baik, sehingga meningkatkan ketersediaan secara keseluruhan.

    5. Monitor dan ukuran yang tepat untuk menangani puncak lalu lintas yang diantisipasi: di bawah beban berat, mesin ElastiCache (RedisOSS) mungkin menjadi tidak responsif, yang memengaruhi ketersediaan. BytesUsedForCachedan DatabaseMemoryUsagePercentage merupakan indikator yang baik dari penggunaan memori Anda, sedangkan ReplicationLag merupakan indikator kesehatan replikasi Anda berdasarkan tingkat tulis Anda. Anda dapat menggunakan metrik ini untuk memicu penskalaan klaster.

    6. Pastikan ketahanan sisi klien dengan menguji dengan Failover APIsebelum peristiwa failover produksi.

    [Sumber Daya]:

REL2: Bagaimana Anda memenuhi Tujuan Titik Pemulihan Anda (RPOs) denganElastiCache?

Pengenalan tingkat pertanyaan: Memahami beban kerja RPO untuk menginformasikan keputusan tentang strategi ElastiCache pencadangan dan pemulihan.

Manfaat tingkat pertanyaan: Memiliki RPO strategi di tempat dapat meningkatkan kelangsungan bisnis jika terjadi skenario pemulihan bencana. Merancang kebijakan pencadangan dan pemulihan dapat membantu Anda memenuhi Tujuan Titik Pemulihan (RPO) untuk ElastiCache data Anda. ElastiCache (RedisOSS) menawarkan kemampuan snapshot yang disimpan di Amazon S3, bersama dengan kebijakan retensi yang dapat dikonfigurasi. Snapshot ini diambil selama periode pencadangan yang ditentukan dan ditangani oleh layanan secara otomatis. Jika beban kerja Anda memerlukan perincian pencadangan tambahan, Anda memiliki opsi untuk membuat hingga 20 pencadangan manual per hari. Pencadangan yang dibuat secara manual tidak memiliki kebijakan retensi layanan dan dapat disimpan tanpa batas waktu.

  • [Wajib] Memahami dan mendokumentasikan RPO ElastiCache penerapan Anda.

    • Perlu diketahui bahwa Memcached tidak menawarkan proses pencadangan apa pun.

    • Tinjau kemampuan fitur ElastiCache Backup dan Restore.

  • [Terbaik] Terapkan proses yang dikomunikasikan dengan baik untuk mencadangkan klaster Anda.

    • Mulai pencadangan manual sesuai kebutuhan.

    • Tinjau kebijakan retensi untuk pencadangan otomatis.

    • Perhatikan bahwa cadangan manual akan dipertahankan tanpa batas waktu.

    • Jadwalkan pencadangan otomatis Anda selama periode penggunaan rendah.

    • Lakukan operasi pencadangan terhadap replika baca untuk memastikan Anda meminimalkan dampak pada performa klaster.

  • [Bagus] Manfaatkan fitur pencadangan terjadwal ElastiCache untuk mencadangkan data Anda secara teratur selama jendela yang ditentukan.

    • Tes secara berkala pemulihan dari cadangan Anda.

  • [Sumber Daya]:

REL3: Bagaimana Anda mendukung persyaratan pemulihan bencana (DR)?

Pengenalan tingkat pertanyaan: Pemulihan bencana adalah aspek penting dari setiap perencanaan beban kerja. ElastiCache (RedisOSS) menawarkan beberapa opsi untuk menerapkan pemulihan bencana berdasarkan persyaratan ketahanan beban kerja. Dengan Amazon ElastiCache Global Datastore, Anda dapat menulis ke klaster ElastiCache (RedisOSS) Anda di satu wilayah dan memiliki data yang tersedia untuk dibaca dari dua cluster replika lintas wilayah lainnya, sehingga memungkinkan pembacaan latensi rendah dan pemulihan bencana di seluruh wilayah.

Manfaat tingkat pertanyaan: Memahami dan merencanakan berbagai skenario bencana dapat memastikan kelangsungan bisnis. Strategi DR harus seimbang dengan biaya, dampak performa, dan potensi kehilangan data.

  • [Wajib] Kembangkan dan dokumentasikan strategi DR untuk semua ElastiCache komponen Anda berdasarkan persyaratan beban kerja. ElastiCache unik karena beberapa kasus penggunaan sepenuhnya fana dan tidak memerlukan strategi DR apa pun, sedangkan yang lain berada di ujung spektrum yang berlawanan dan memerlukan strategi DR yang sangat kuat. Semua opsi harus ditimbang dalam kaitannya dengan Optimalisasi Biaya - ketahanan yang lebih kuat membutuhkan jumlah infrastruktur yang lebih besar.

    Memahami opsi DR yang tersedia di tingkat regional dan multi-wilayah.

    • Deployment Multi-AZ direkomendasikan untuk mencegah kegagalan AZ. Pastikan untuk menerapkan dengan Cluster-Mode diaktifkan dalam arsitektur Multi-AZ, dengan minimal 3 tersedia. AZs

    • Penyimpanan Data Global direkomendasikan untuk memberikan perlindungan terhadap kegagalan regional.

  • [Terbaik] Aktifkan Penyimpanan Data Global untuk beban kerja yang membutuhkan ketahanan tingkat wilayah.

    • Siapkan rencana untuk melakukan failover ke wilayah sekunder jika terjadi degradasi primer.

    • Uji proses failover multi-wilayah sebelum melakukan failover dalam lingkungan produksi.

    • Pantau metrik ReplicationLag untuk memahami potensi dampak kehilangan data selama peristiwa failover.

  • [Sumber Daya]:

REL4: Bagaimana Anda secara efektif merencanakan kegagalan?

Pengenalan tingkat pertanyaan: Mengaktifkan Multi-AZ dengan failover otomatis adalah praktik terbaik. ElastiCache Dalam kasus tertentu, ElastiCache (RedisOSS) menggantikan node primer sebagai bagian dari operasi layanan. Contohnya termasuk peristiwa pemeliharaan yang direncanakan dan kasus yang tidak diharapkan seperti kegagalan simpul atau masalah zona ketersediaan. Failover yang berhasil bergantung pada keduanya ElastiCache dan konfigurasi pustaka klien Anda.

Manfaat tingkat pertanyaan: Mengikuti praktik terbaik untuk ElastiCache failover bersama dengan pustaka klien spesifik ElastiCache (RedisOSS) membantu Anda meminimalkan potensi waktu henti selama peristiwa failover.

  • [Wajib] Untuk mode klaster dinonaktifkan, gunakan waktu tunggu sehingga klien dapat mendeteksi jika perlu memutuskan koneksi dari simpul primer lama dan terhubung kembali ke simpul primer baru, menggunakan alamat IP titik akhir primer yang diperbarui. Untuk mode klaster diaktifkan, pustaka klien bertanggung jawab untuk mendeteksi perubahan dalam topologi klaster yang mendasarinya. Ini paling sering dilakukan dengan pengaturan konfigurasi di pustaka klien ElastiCache (RedisOSS), yang juga memungkinkan Anda untuk mengkonfigurasi frekuensi dan metode penyegaran. Setiap pustaka klien menawarkan pengaturannya sendiri dan detail lebih lanjut tersedia dalam dokumentasi yang sesuai.

    [Sumber Daya]:

  • [Wajib] Failover yang berhasil bergantung pada lingkungan replikasi yang berkondisi baik antara simpul primer dan replika. Tinjau dan pahami sifat asinkron OSS replikasi Valkey dan Redis, serta CloudWatch metrik yang tersedia untuk melaporkan jeda replikasi antara node primer dan replika. Untuk kasus penggunaan yang membutuhkan keamanan data yang lebih besar, manfaatkan WAIT perintah untuk memaksa replika untuk mengakui penulisan sebelum menanggapi klien yang terhubung.

    [Sumber Daya]:

  • [Terbaik] Secara teratur memvalidasi respons aplikasi Anda selama failover menggunakan Test Failover. ElastiCache API

    [Sumber Daya]:

REL5: Apakah ElastiCache komponen Anda dirancang untuk skala?

Pengenalan tingkat pertanyaan: Dengan memahami kemampuan penskalaan dan topologi penerapan yang tersedia, ElastiCache komponen Anda dapat menyesuaikan dari waktu ke waktu untuk memenuhi persyaratan beban kerja yang berubah. ElastiCachemenawarkan penskalaan 4 arah: masuk/keluar (horizontal) serta atas/bawah (vertikal).

Manfaat tingkat pertanyaan: Mengikuti praktik terbaik untuk ElastiCache penerapan memberikan fleksibilitas penskalaan terbesar, serta memenuhi prinsip penskalaan yang dirancang dengan baik secara horizontal untuk meminimalkan dampak kegagalan.

  • [Wajib] Memahami perbedaan antara topologi Mode Klaster Diaktifkan dan Mode Klaster Dinonaktifkan. Dalam hampir semua kasus, sebaiknya lakukan deployment dengan mode Klaster diaktifkan karena memungkinkan skalabilitas yang lebih besar dari waktu ke waktu. Komponen mode klaster dinonaktifkan memiliki kemampuan terbatas untuk menskalakan secara horizontal dengan menambahkan replika baca.

  • [Wajib] Memahami kapan dan bagaimana melakukan penskalaan.

    • Untuk lebih lanjutREADIOPS: tambahkan replika

    • Untuk lebih lanjutWRITEOPS: tambahkan pecahan (skala keluar)

    • Untuk meningkatkan IO jaringan - gunakan instans yang dioptimalkan jaringan (menaikkan skala)

  • [Terbaik] Terapkan ElastiCache komponen Anda dengan mode Cluster diaktifkan, dengan bias terhadap lebih banyak node yang lebih kecil daripada lebih sedikit, node yang lebih besar. Opsi ini secara efektif membatasi radius ledakan kegagalan simpul.

  • [Terbaik] Sertakan replika di klaster Anda untuk meningkatkan respons selama peristiwa penskalaan

  • [Bagus] Untuk mode cluster dinonaktifkan, manfaatkan replika baca untuk meningkatkan kapasitas baca secara keseluruhan. ElastiCache memiliki dukungan hingga 5 replika baca dalam mode cluster dinonaktifkan, serta penskalaan vertikal.

  • [Sumber Daya]: