Memilih ukuran simpul Anda - Amazon ElastiCache
Ukuran simpul (Valkey dan Redis OSS)Ukuran node (Memcached)

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

Memilih ukuran simpul Anda

Ukuran node yang Anda pilih untuk ElastiCache klaster memengaruhi biaya, kinerja, dan toleransi kesalahan.

Ukuran simpul (Valkey dan Redis OSS)

Untuk informasi tentang manfaat prosesor Graviton, lihat Prosesor AWS Graviton.

Menjawab pertanyaan-pertanyaan berikut dapat membantu Anda menentukan jenis node minimum yang Anda butuhkan untuk implementasi Valkey atau Redis OSS Anda:

  • Apakah Anda mengharapkan beban kerja terikat throughput dengan beberapa koneksi klien?

    Jika ini masalahnya dan Anda menjalankan Redis OSS versi 5.0.6 atau lebih tinggi, Anda bisa mendapatkan throughput dan latensi yang lebih baik dengan fitur I/O kami yang disempurnakan, jika CPUs tersedia digunakan untuk membongkar koneksi klien, atas nama mesin Redis OSS. Jika Anda menjalankan Redis OSS versi 7.0.4 atau lebih tinggi, di atas I/O yang disempurnakan, Anda akan mendapatkan akselerasi tambahan dengan multiplexing I/O yang disempurnakan, di mana setiap jaringan pipa thread IO khusus memerintahkan dari beberapa klien ke mesin Redis OSS, memanfaatkan kemampuan Redis OSS untuk memproses perintah secara efisien dalam batch. ElastiCache Untuk Redis OSS v7.1 dan di atasnya, kami memperluas fungsionalitas utas I/O yang disempurnakan untuk juga menangani logika lapisan presentasi. Dengan lapisan presentasi, yang kami maksud adalah bahwa utas I/O yang Ditingkatkan sekarang tidak hanya membaca input klien, tetapi juga mengurai input ke dalam format perintah biner Redis OSS, yang kemudian diteruskan ke utas utama untuk dieksekusi, memberikan peningkatan kinerja. Lihat postingan blog dan halaman versi yang didukung untuk detail tambahan.

  • Apakah Anda memiliki beban kerja yang mengakses sebagian kecil dari datanya secara berkala?

    Jika ini masalahnya dan Anda menjalankan mesin Redis OSS versi 6.2 atau yang lebih baru, Anda dapat memanfaatkan tiering data dengan memilih tipe node r6gd. Dengan tingkatan data, data yang sudah lama tidak digunakan akan disimpan di SSD. Ketika data ini diambil, ada sedikit latensi, tetapi diimbangi dengan penghematan biaya. Untuk informasi selengkapnya, lihat Tingkatan data di ElastiCache.

    Untuk informasi selengkapnya, lihat Jenis simpul yang didukung.

  • Berapa banyak memori total yang dibutuhkan untuk data Anda?

    Untuk mendapatkan estimasi umum, cari tahu ukuran item yang ingin Anda simpan dalam cache. Kalikan ukuran ini dengan jumlah item yang ingin Anda simpan dalam cache pada waktu yang sama. Untuk mendapatkan estimasi yang wajar dari ukuran item, pertama-tama serialisasikan item cache Anda, kemudian hitung karakternya. Kemudian bagi jumlah karakter dengan jumlah serpihan dalam klaster Anda.

    Untuk informasi selengkapnya, lihat Jenis simpul yang didukung.

  • Versi Redis OSS apa yang Anda jalankan?

    Versi Redis OSS sebelum 2.8.22 mengharuskan Anda untuk menyimpan lebih banyak memori untuk failover, snapshot, sinkronisasi, dan mempromosikan replika ke operasi utama. Persyaratan ini muncul karena Anda harus memiliki cukup memori tersedia untuk semua penulisan yang terjadi selama proses.

    Redis OSS versi 2.8.22 dan yang lebih baru menggunakan proses penyimpanan tanpa garpu yang membutuhkan lebih sedikit memori yang tersedia daripada proses sebelumnya.

    Untuk informasi selengkapnya, lihat berikut ini:

  • Seberapa berat operasi tulis aplikasi Anda?

    Aplikasi dengan operasi tulis berat dapat membutuhkan ketersediaan memori yang jauh lebih banyak, memori yang tidak digunakan oleh data, saat mengambil snapshot atau failover. Setiap kali proses BGSAVE dilakukan, Anda harus memiliki cukup memori yang tidak digunakan oleh data untuk mengakomodasi semua operasi tulis yang berlangsung selama proses BGSAVE. Contohnya adalah ketika mengambil snapshot, ketika menyinkronkan klaster primer dengan replika dalam klaster, dan ketika mengaktifkan fitur append-only file (AOF). Contoh lainnya adalah saat mempromosikan replika ke primer (jika Anda memiliki Multi-AZ yang aktif). Kemungkinan terburuknya adalah ketika semua data Anda ditulis ulang selama proses berlangsung. Dalam hal ini, Anda memerlukan ukuran instans simpul dengan memori dua kali lebih banyak dari yang diperlukan untuk data saja.

    Untuk informasi selengkapnya, lihat Memastikan Anda memiliki cukup memori untuk membuat snapshot Valkey atau Redis OSS.

  • Apakah implementasi Anda akan menjadi cluster Valkey atau Redis OSS (mode cluster dinonaktifkan) mandiri, atau cluster Valkey atau Redis OSS (mode cluster enabled) dengan beberapa pecahan?

    Valkey atau Redis OSS (mode cluster dinonaktifkan) cluster

    Jika Anda menerapkan cluster Valkey atau Redis OSS (mode cluster disabled), tipe node Anda harus dapat mengakomodasi semua data Anda ditambah overhead yang diperlukan seperti yang dijelaskan dalam bullet sebelumnya.

    Sebagai contoh, misalnya Anda memperkirakan bahwa total ukuran semua item Anda adalah 12 GB. Dalam kasus ini, Anda dapat menggunakan simpul cache.m3.xlarge dengan memori 13,3 GB atau simpul cache.r3.large dengan memori 13,5 GB. Namun, Anda mungkin memerlukan lebih banyak memori untuk operasi BGSAVE. Jika aplikasi Anda memiliki operasi tulis berat, gandakan persyaratan memori ke setidaknya 24 GB. Dengan demikian, gunakan cache.m3.2xlarge dengan memori 27,9 GB atau cache.r3.xlarge dengan memori 30,5 GB.

    Valkey atau Redis OSS (mode cluster diaktifkan) dengan beberapa pecahan

    Jika Anda menerapkan cluster Valkey atau Redis OSS (mode cluster enabled) dengan beberapa pecahan, maka tipe node harus dapat mengakomodasi bytes-for-data-and-overhead / number-of-shards byte data.

    Sebagai contoh, misalnya Anda memperkirakan bahwa total ukuran semua item Anda adalah 12 GB dan Anda memiliki dua serpihan. Dalam kasus ini, Anda dapat menggunakan simpul cache.m3.large dengan memori 6,05 GB (12 GB / 2). Namun, Anda mungkin memerlukan lebih banyak memori untuk operasi BGSAVE. Jika aplikasi Anda memiliki operasi tulis berat, gandakan persyaratan memori ke setidaknya 12 GB per serpihan. Dengan demikian, gunakan cache.m3.xlarge dengan memori 13,3 GB atau cache.r3.large dengan memori 13,5 GB.

  • Apakah Anda menggunakan Zona Lokal?

    Local Zones memungkinkan Anda menempatkan sumber daya seperti ElastiCache klaster di beberapa lokasi yang dekat dengan pengguna Anda. Namun, ketika Anda memilih ukuran simpul Anda, perhatikan bahwa ukuran simpul yang tersedia saat ini terbatas seperti yang tertera berikut ini, terlepas dari persyaratan kapasitas:

    • Generasi saat ini:

      Jenis simpul M5: cache.m5.large, cache.m5.xlarge, cache.m5.2xlarge, cache.m5.4xlarge, cache.m5.12xlarge, cache.m5.24xlarge

      Jenis simpul R5: cache.r5.large, cache.r5.xlarge, cache.r5.2xlarge, cache.r5.4xlarge, cache.r5.12xlarge, cache.r5.24xlarge

      Jenis simpul T3: cache.t3.micro, cache.t3.small, cache.t3.medium

Saat cluster Anda berjalan, Anda dapat memantau penggunaan memori, pemanfaatan prosesor, klik cache, dan metrik cache misses yang dipublikasikan. CloudWatch Anda mungkin memperhatikan bahwa klaster Anda tidak memiliki laju hit yang Anda inginkan atau bahwa kunci terlalu sering dikosongkan. Dalam kasus ini, Anda dapat memilih ukuran simpul yang berbeda dengan spesifikasi CPU dan memori yang lebih besar.

Saat memantau penggunaan CPU, ingat Valkey dan Redis OSS adalah single-threaded. Dengan demikian, kalikan penggunaan CPU yang dilaporkan dengan jumlah inti CPU untuk mengetahui penggunaan yang sebenarnya. Misalnya, CPU empat inti yang melaporkan tingkat penggunaan 20 persen sebenarnya adalah satu inti Redis OSS berjalan pada pemanfaatan 80 persen.

Ukuran node (Memcached)

Klaster Memcached berisi satu atau beberapa simpul dengan data klaster yang dipartisi di seluruh simpul. Oleh karena itu, kebutuhan memori klaster dan memori simpul berkaitan, tetapi tidak sama. Anda dapat mencapai kapasitas memori klaster yang Anda butuhkan dengan memiliki simpul yang berjumlah sedikit namun berukuran besar atau beberapa simpul yang lebih kecil. Seiring waktu, ketika kebutuhan Anda berubah, Anda dapat menambahkan simpul ke atau menghapus simpul dari klaster dan dengan demikian membayar hanya untuk apa yang Anda butuhkan.

Kapasitas memori total klaster Anda dihitung dengan mengalikan jumlah simpul dalam klaster dengan kapasitas RAM setiap simpul setelah dikurangi sistem overhead. Kapasitas setiap simpul bergantung pada jenis simpul.

cluster_capacity = number_of_nodes * (node_capacity - system_overhead)

Jumlah simpul dalam klaster merupakan faktor utama dalam ketersediaan klaster Anda yang menjalankan Memcached. Kegagalan dari satu simpul dapat berdampak pada ketersediaan aplikasi Anda dan beban pada basis data backend Anda. Dalam kasus seperti itu, ElastiCache menyediakan pengganti untuk simpul yang gagal dan akan direpopulasi. Untuk mengurangi dampak ketersediaan ini, sebarkan memori dan kapasitas komputasi Anda pada lebih banyak simpul dengan kapasitas yang lebih kecil, daripada menggunakan simpul berkapasitas tinggi yang lebih sedikit.

Dalam skenario di mana Anda ingin memiliki 35 GB memori cache, Anda dapat mengatur salah satu konfigurasi berikut:

  • 11 simpul cache.t2.medium dengan memori 3,22 GB dengan masing-masing 2 thread = 35,42 GB dan 22 thread.

  • 6 simpul cache.m4.large dengan memori 6,42 GB dengan masing-masing 2 thread = 38,52 GB dan 12 thread.

  • 3 simpul cache.r4.large dengan memori 12,3 GB dengan masing-masing 2 thread = 36,90 GB dan 6 thread.

  • 3 simpul cache.m4.xlarge dengan memori 14,28 GB dengan masing-masing 4 thread = 42,84 GB dan 12 thread.

Membandingkan opsi simpul
Jenis simpul Memori (dalam GiB) Inti Biaya per jam* Simpul yang diperlukan Total memori (dalam GiB) Total inti Biaya bulanan 
cache.t2.medium 3.22 2 $0.068 11 35,42 22 $538.56
cache.m4.large 6.42 2 $0.156 6 38.52 12 $673,92
cache.m4.xlarge 14.28 4 $0.311 3 42,84 12 $671.76
cache.m5.xlarge 12.93 4 $0.311 3 38.81 12 $671.76
cache.m6g.large 6,85 2 $0.147 6 41.1 12 $635
cache.r4.large 12.3 2 $0.228 3 36,9 6 $492.48
cache.r5.large 13.07 2 $0.216 3 39,22 6 $466.56
cache.r6g.large 13.07 2 $0.205 3 42.12 6 $442
* Biaya per jam per simpul mulai 8 Oktober 2020.
Biaya bulanan 100% penggunaan selama 30 hari (720 jam).

Opsi ini masing-masing menyediakan kapasitas memori yang sama namun kapasitas komputasi dan biaya yang berbeda. Untuk membandingkan biaya opsi spesifik Anda, lihat ElastiCache Harga Amazon.

Untuk klaster yang menjalankan Memcached, beberapa memori yang tersedia pada setiap simpul digunakan untuk overhead koneksi. Untuk informasi selengkapnya, lihat Overhead koneksi Memcached

Menggunakan beberapa simpul membutuhkan penyebaran kunci di seluruh simpul. Setiap simpul memiliki titik akhir sendiri. Untuk manajemen endpoint yang mudah, Anda dapat menggunakan fitur Auto Discovery, yang memungkinkan program klien untuk secara otomatis mengidentifikasi semua node dalam sebuah cluster. ElastiCache Untuk informasi selengkapnya, lihat Secara otomatis mengidentifikasi node di cluster Anda (Memcached).

Dalam beberapa kasus, Anda mungkin tidak yakin berapa banyak kapasitas yang Anda butuhkan. Jika demikian, untuk pengujian sebaiknya mulai dengan satu simpul cache.m5.large. Kemudian pantau penggunaan memori, pemanfaatan CPU, dan laju hit cache dengan ElastiCache metrik yang dipublikasikan ke Amazon. CloudWatch Untuk informasi selengkapnya tentang CloudWatch metrik ElastiCache, lihatPemantauan penggunaan dengan CloudWatch Metrik. Untuk produksi dan beban kerja yang lebih besar, simpul R5 memberikan performa dan nilai biaya RAM yang terbaik.

Jika klaster Anda tidak memiliki laju hit yang Anda inginkan, Anda dapat dengan mudah menambahkan lebih banyak simpul untuk meningkatkan total memori yang tersedia di klaster Anda.

Jika klaster Anda terikat oleh CPU tetapi memiliki laju hit yang mencukupi, atur klaster yang baru dengan jenis simpul yang memiliki daya komputasi lebih besar.