Memilih ukuran simpul Anda - Amazon ElastiCache
Ukuran simpul (Valkey dan Redis) OSSUkuran 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 OSS Redis 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 OSS mesin Redis, memanfaatkan kemampuan Redis untuk memproses perintah secara efisien dalam batch. OSS Di ElastiCache (RedisOSS) 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 OSS biner Redis, 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 OSS mesin Redis versi 6.2 atau yang lebih baru, Anda dapat memanfaatkan tiering data dengan memilih tipe node r6gd. Dengan tiering data, data yang paling jarang digunakan 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 apa OSS yang Anda jalankan?

    OSSVersi Redis 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 saat mengambil snapshot, saat menyinkronkan cluster utama dengan replika di cluster, dan saat 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 diaktifkan) dengan beberapa pecahan?

    Valkey atau Redis OSS (mode cluster dinonaktifkan) cluster

    Jika Anda menerapkan cluster Valkey atau Redis OSS (mode cluster dinonaktifkan), 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 node yang berbeda dengan spesifikasi memori CPU yang lebih besar.

Saat memantau CPU penggunaan, ingat Valkey dan Redis berulir tunggalOSS. Jadi, kalikan CPU penggunaan yang dilaporkan dengan jumlah CPU core untuk mendapatkan penggunaan aktual itu. Misalnya, empat inti yang CPU melaporkan tingkat penggunaan 20 persen sebenarnya adalah satu-satunya inti Redis berjalan pada OSS 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.

Total kapasitas memori cluster Anda dihitung dengan mengalikan jumlah node dalam cluster dengan RAM kapasitas setiap node setelah dikurangi overhead sistem. 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 memberikan pengganti untuk node yang gagal dan itu akan diisi kembali. Untuk mengurangi dampak ketersediaan ini, sebarkan kapasitas memori dan komputasi Anda ke lebih banyak simpul dengan kapasitas yang lebih kecil, daripada menggunakan sedikit simpul yang berkapasitas tinggi.

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, CPU pemanfaatan, dan tingkat 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, node R5 memberikan kinerja dan nilai RAM biaya 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 hit rate yang cukup, siapkan cluster baru dengan tipe node yang memberikan lebih banyak daya komputasi.