Mengukur kluster Anda DAX - Amazon DynamoDB

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

Mengukur kluster Anda DAX

Total kapasitas dan ketersediaan DAX cluster tergantung pada jenis dan jumlah node. Lebih banyak node di cluster meningkatkan kapasitas bacanya, tetapi bukan kapasitas tulis. Jenis node yang lebih besar (hingga r5.8xlarge) dapat menangani lebih banyak penulisan, tetapi terlalu sedikit node dapat memengaruhi ketersediaan ketika kegagalan node terjadi. Untuk informasi selengkapnya tentang ukuran DAX cluster Anda, lihat. Panduan pengukuran klaster DAX

Bagian berikut membahas berbagai aspek ukuran yang harus Anda pertimbangkan untuk menyeimbangkan jenis node dan hitungan untuk membuat cluster yang dapat diskalakan dan hemat biaya.

Ketersediaan perencanaan

Saat mengukur DAX cluster, Anda harus terlebih dahulu fokus pada ketersediaan yang ditargetkan. Ketersediaan layanan berkerumun, sepertiDAX, adalah dimensi dari jumlah total node dalam cluster. Karena cluster node tunggal tidak memiliki toleransi untuk kegagalan, ketersediaannya sama dengan satu node. Dalam cluster 10-node, hilangnya satu node memiliki dampak minimal terhadap kapasitas keseluruhan cluster. Kerugian ini tidak berdampak langsung pada ketersediaan karena node yang tersisa masih dapat memenuhi permintaan baca. Untuk melanjutkan penulisan, DAX dengan cepat menominasikan simpul utama baru.

DAXVPCberbasis. Ini menggunakan grup subnet untuk menentukan Zona Ketersediaan mana yang dapat menjalankan node dan alamat IP mana yang akan digunakan dari subnet. Untuk beban kerja produksi, kami sangat menyarankan Anda menggunakan DAX setidaknya tiga node di Availability Zone yang berbeda. Ini memastikan bahwa cluster memiliki lebih dari satu node tersisa untuk menangani permintaan bahkan jika satu node atau Availability Zone gagal. Sebuah cluster dapat memiliki hingga 11 node, di mana satu adalah node utama dan 10 adalah replika baca.

Perencanaan throughput tulis

Semua DAX cluster memiliki node utama untuk permintaan write-through. Ukuran tipe node untuk cluster menentukan kapasitas penulisannya. Menambahkan replika baca tambahan tidak meningkatkan kapasitas tulis cluster. Oleh karena itu, Anda harus mempertimbangkan kapasitas tulis selama pembuatan cluster karena Anda tidak dapat mengubah jenis node nanti.

Jika aplikasi Anda perlu menulis DAX untuk memperbarui cache item, pertimbangkan peningkatan penggunaan sumber daya klaster untuk memfasilitasi penulisan. Menulis terhadap DAX konsumsi sumber daya sekitar 25 kali lebih banyak daripada pembacaan cache-hit. Ini mungkin memerlukan tipe node yang lebih besar daripada cluster read-only.

Untuk panduan tambahan tentang menentukan apakah write-through atau write-around akan bekerja paling baik untuk aplikasi Anda, lihat. Strategi untuk penulisan

Merencanakan throughput baca

Kapasitas baca DAX klaster bergantung pada rasio hit cache dari beban kerja Anda. Karena DAX membaca data dari DynamoDB ketika cache miss terjadi, ia mengkonsumsi sekitar 10 kali lebih banyak sumber daya cluster daripada cache-hit. Untuk meningkatkan klik cache, tingkatkan TTLpengaturan cache untuk menentukan periode penyimpanan item dalam cache. TTLDurasi yang lebih tinggi, bagaimanapun, meningkatkan kemungkinan membaca versi item yang lebih lama kecuali pembaruan ditulisDAX.

Untuk memastikan bahwa cluster memiliki kapasitas baca yang cukup, skala cluster secara horizontal seperti yang disebutkan dalamMenskalakan cluster secara horizontal. Menambahkan lebih banyak node menambahkan replika baca ke kumpulan sumber daya, sementara menghapus node mengurangi kapasitas baca. Saat Anda memilih jumlah node dan ukurannya untuk sebuah cluster, pertimbangkan jumlah minimum dan maksimum kapasitas baca yang diperlukan. Jika Anda tidak dapat menskalakan cluster secara horizontal dengan tipe node yang lebih kecil untuk memenuhi persyaratan baca Anda, gunakan tipe node yang lebih besar.

Merencanakan ukuran dataset

Setiap jenis node yang tersedia memiliki ukuran memori yang ditetapkan DAX untuk menyimpan data cache. Jika tipe node terlalu kecil, kumpulan data kerja yang diminta aplikasi tidak akan muat dalam memori dan mengakibatkan cache hilang. Karena node yang lebih besar mendukung cache yang lebih besar, gunakan tipe node yang lebih besar dari perkiraan kumpulan data yang perlu Anda cache. Cache yang lebih besar juga meningkatkan rasio hit cache.

Anda mungkin mendapatkan pengembalian yang semakin berkurang untuk item caching dengan beberapa pembacaan berulang. Hitung ukuran memori untuk item yang sering diakses dan pastikan cache cukup besar untuk menyimpan kumpulan data tersebut.

Menghitung perkiraan persyaratan kapasitas cluster

Anda dapat memperkirakan total kebutuhan kapasitas beban kerja Anda untuk membantu Anda memilih ukuran dan jumlah node cluster yang sesuai. Untuk melakukan estimasi ini, hitung variabel permintaan dinormalisasi per detik (NormalisasiRPS). Variabel ini mewakili total unit kerja yang dibutuhkan oleh DAX klaster untuk didukung oleh aplikasi Anda, termasuk cache hits, cache misses, dan write. Untuk menghitung NormalisasiRPS, gunakan input berikut:

  • ReadRPS_CacheHit— Menentukan jumlah pembacaan per detik yang menghasilkan hit cache.

  • ReadRPS_CacheMiss— Menentukan jumlah pembacaan per detik yang mengakibatkan kehilangan cache.

  • WriteRPS— Menentukan jumlah penulisan per detik yang akan melaluiDAX.

  • DaxNodeCount— Menentukan jumlah node di DAX cluster.

  • Size— Menentukan ukuran item yang ditulis atau dibaca dalam KB dibulatkan ke KB terdekat.

  • 10x_ReadMissFactor- Merupakan nilai 10. Ketika cache miss terjadi, DAX menggunakan sekitar 10 kali lebih banyak sumber daya daripada cache hits.

  • 25x_WriteFactor— Merupakan nilai 25 karena DAX write-through menggunakan sekitar 25 kali lebih banyak sumber daya daripada klik cache.

Dengan menggunakan rumus berikut, Anda dapat menghitung Normalisasi. RPS

Normalized RPS = (ReadRPS_CacheHit * Size) + (ReadRPS_CacheMiss * Size * 10x_ReadMissFactor) + (WriteRequestRate * 25x_WriteFactor * Size * DaxNodeCount)

Misalnya, pertimbangkan nilai masukan berikut:

  • ReadRPS_CacheHit= 50.000

  • ReadRPS_CacheMiss= 1.000

  • ReadMissFactor= 1

  • Size= 2 KB

  • WriteRPS= 100

  • WriteFactor= 1

  • DaxNodeCount= 3

Dengan mengganti nilai-nilai ini dalam rumus, Anda dapat menghitung Normalisasi RPS sebagai berikut.

Normalized RPS = (50,000 Cache Hits/Sec * 2KB) + (1,000 Cache Misses/Sec * 2KB * 10) + (100 Writes/Sec * 25 * 2KB * 3)

Dalam contoh ini, nilai yang dihitung dari Normalisasi RPS adalah 135.000. Namun, RPS nilai Normalisasi ini tidak memperhitungkan penggunaan cluster di bawah 100% atau kehilangan node. Kami menyarankan Anda memperhitungkan kapasitas tambahan. Untuk melakukan ini, tentukan yang lebih besar dari dua faktor pengali: pemanfaatan target atau toleransi kehilangan simpul. Kemudian, kalikan Normalisasi RPS dengan faktor yang lebih besar untuk mendapatkan permintaan target per detik (TargetRPS).

  • Target pemanfaatan

    Karena dampak kinerja meningkatkan kesalahan cache, kami tidak menyarankan menjalankan DAX cluster pada pemanfaatan 100%. Idealnya, Anda harus menjaga pemanfaatan cluster pada atau di bawah 70%. Untuk mencapai ini, kalikan Normalisasi RPS dengan 1,43.

  • Toleransi kehilangan simpul

    Jika sebuah node gagal, aplikasi Anda harus dapat mendistribusikan permintaannya di antara node yang tersisa. Untuk memastikan node tetap di bawah pemanfaatan 100%, pilih jenis node yang cukup besar untuk menyerap lalu lintas ekstra sampai node yang gagal kembali online. Untuk cluster dengan node lebih sedikit, setiap node harus mentolerir peningkatan lalu lintas yang lebih besar ketika satu node gagal.

    Jika node primer gagal, DAX secara otomatis gagal ke replika baca dan menetapkannya sebagai primer baru. Jika replika node gagal, node lain dalam DAX cluster masih dapat melayani permintaan sampai node gagal dipulihkan.

    Misalnya, DAX cluster 3-node dengan kegagalan node membutuhkan tambahan kapasitas 50% pada dua node yang tersisa. Ini membutuhkan faktor pengalikan 1,5. Sebaliknya, cluster 11-node dengan node gagal membutuhkan tambahan kapasitas 10% pada node yang tersisa atau faktor perkalian 1,1.

Dengan menggunakan rumus berikut, Anda dapat menghitung TargetRPS.

Target RPS = Normalized RPS * CEILING(TargetUtilization, NodeLossTolerance)

Misalnya, untuk menghitung TargetRPS, pertimbangkan nilai-nilai berikut:

  • Normalized RPS= 135.000

  • TargetUtilization= 1.43

    Karena kami bertujuan untuk pemanfaatan cluster maksimum 70%, kami menetapkan TargetUtilization ke 1,43.

  • NodeLossTolerance= 1.5

    Katakanlah kami menggunakan cluster 3-node, oleh karena itu, kami mengatur NodeLossTolerance ke kapasitas 50%.

Dengan mengganti nilai-nilai ini dalam rumus, Anda dapat menghitung Target RPS sebagai berikut.

Target RPS = 135,000 * CEILING(1.43, 1.5)

Dalam contoh ini, karena nilai NodeLossTolerance lebih besar dariTargetUtilization, kami menghitung nilai Target RPS denganNodeLossTolerance. Ini memberi kami Target RPS 202.500, yang merupakan jumlah total kapasitas yang harus didukung DAX cluster. Untuk menentukan jumlah node yang Anda perlukan dalam sebuah cluster, petakan Target RPS ke kolom yang sesuai dalam tabel berikut. Untuk contoh Target RPS 202,500 ini, Anda memerlukan tipe node dax.r5.large dengan tiga node.

Memperkirakan kapasitas throughput cluster menurut tipe node

Dengan menggunakanTarget RPS formula, Anda dapat memperkirakan kapasitas cluster untuk berbagai jenis node. Tabel berikut menunjukkan perkiraan kapasitas untuk cluster dengan tipe node 1, 3, 5, dan 11. Kapasitas ini tidak menggantikan kebutuhan untuk melakukan pengujian beban DAX dengan data dan pola permintaan Anda sendiri. Selain itu, kapasitas ini tidak termasuk instance tipe-t karena kurangnya kapasitas tetapnya. CPU Unit untuk semua nilai dalam tabel berikut adalah Normalisasi. RPS

Jenis simpul (memori) 1 simpul 3 simpul 5 node 11 simpul
dax.r5.24xlarge (768GB) 1M 3M 5M 11M
dax.r5.16xlarge (512GB) 1M 3M 5M 11M
dax.r5.12xlarge (384GB) 1M 3M 5M 11M
dax.r5.8xlarge (256GB) 1M 3M 5M 11M
dax.r5.4xlarge (128GB) 600k 1,8 M 3M 6,6 M
dax.r5.2xlarge (64GB) 300k 900k 1,5 M 3.3M
dax.r5.xlarge (32GB) 150k 450k 750k 1,65M
dax.r5.large (16GB) 75k 225k 375k 825k

Karena batas maksimum 1 juta NPS (operasi jaringan per detik) untuk setiap node, node tipe dax.r5.8xlarge atau lebih besar tidak memberikan kontribusi kapasitas cluster tambahan. Jenis node yang lebih besar dari 8xlarge mungkin tidak berkontribusi pada total kapasitas throughput cluster. Namun, jenis node tersebut dapat membantu untuk menyimpan kumpulan data kerja yang lebih besar dalam memori.

Menskalakan kapasitas tulis dalam cluster DAX

Setiap penulisan untuk DAX mengkonsumsi 25 permintaan yang dinormalisasi pada setiap node. Karena ada RPS batas 1 juta untuk setiap node, sebuah DAX cluster dibatasi hingga 40.000 penulisan per detik, tidak memperhitungkan penggunaan baca.

Jika kasus penggunaan Anda membutuhkan lebih dari 40.000 penulisan per detik dalam cache, Anda harus menggunakan DAX cluster terpisah dan menghancurkan penulisan di antara mereka. Mirip dengan DynamoDB, Anda dapat hash kunci partisi untuk data yang Anda tulis ke cache. Kemudian, gunakan modulus untuk menentukan pecahan mana untuk menulis data.

Contoh berikut menghitung hash dari string input. Kemudian menghitung modulus nilai hash dengan 10.

def hash_modulo(input_string): # Compute the hash of the input string hash_value = hash(input_string) # Compute the modulus of the hash value with 10 bucket_number = hash_value % 10 return bucket_number #Example usage if _name_ == "_main_": input_string = input("Enter a string: ") result = hash_modulo(input_string) print(f"The hash modulo 10 of '{input_string}' is: {result}.")