Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Panduan ini memberikan saran untuk memilih ukuran klaster Amazon DynamoDB Accelerator DAX () dan tipe node yang sesuai untuk aplikasi Anda. Petunjuk ini memandu Anda melalui langkah-langkah memperkirakan DAX lalu lintas aplikasi Anda, memilih konfigurasi klaster, dan mengujinya.
Jika Anda memiliki DAX cluster yang ada dan ingin mengevaluasi apakah ia memiliki jumlah dan ukuran node yang sesuai, silakan merujuk keMenskalakan klaster DAX.
Gambaran Umum
Penting untuk menskalakan DAX klaster Anda dengan tepat untuk beban kerja Anda, baik Anda membuat klaster baru atau memelihara klaster yang sudah ada. Seiring berjalannya waktu dan perubahan beban kerja aplikasi, Anda harus meninjau kembali keputusan penskalaan secara berkala untuk memastikan bahwa semuanya masih tepat.
Biasanya, proses mengikuti langkah-langkah berikut:
-
Memperkirakan lalu lintas. Pada langkah ini, Anda membuat prediksi tentang volume lalu lintas yang akan dikirim aplikasi AndaDAX, sifat lalu lintas (operasi baca vs. tulis), dan tingkat hit cache yang diharapkan.
-
Pengujian beban. Pada langkah ini, Anda membuat klaster dan mengirim lalu lintas yang mencerminkan estimasi Anda dari langkah sebelumnya ke klaster tersebut. Ulangi langkah ini hingga Anda menemukan konfigurasi klaster yang sesuai.
-
Pemantauan produksi. Saat aplikasi Anda digunakan DAX dalam produksi, Anda harus memantau klaster untuk terus memvalidasi bahwa klaster masih diskalakan dengan benar karena beban kerja Anda berubah seiring waktu.
Memperkirakan lalu lintas
Ada tiga faktor utama yang menjadi ciri beban DAX kerja yang khas:
-
Laju hit cache
-
Baca unit kapasitas (RCUs) per detik
-
Tulis unit kapasitas (WCUs) per detik
Memperkirakan laju hit cache
Jika Anda sudah memiliki DAX cluster, Anda dapat menggunakan CloudWatch metrik ItemCacheHits dan ItemCacheMisses Amazon untuk menentukan tingkat hit cache. laju hit cache sama dengan ItemCacheHits / (ItemCacheHits + ItemCacheMisses). Jika beban kerja Anda mencakup Query atau Scan, Anda juga harus melihat metrik QueryCacheHits, QueryCacheMisses, ScanCacheHits, dan ScanCacheMisses. Tingkat hit cache bervariasi dari satu aplikasi ke aplikasi lainnya dan sangat dipengaruhi oleh pengaturan Time to Live (TTL) cluster. Tingkat hit khas untuk aplikasi yang menggunakan DAX adalah 85-95 persen.
Memperkirakan unit kapasitas baca dan tulis
Jika Anda sudah memiliki tabel DynamoDB untuk aplikasi Anda, lihat ConsumedReadCapacityUnits dan metrik. ConsumedWriteCapacityUnits CloudWatch Gunakan statistik Sum dan bagi dengan jumlah detik dalam periode tersebut.
Jika Anda juga sudah memiliki DAX cluster, ingat bahwa metrik ConsumedReadCapacityUnits DynamoDB hanya memperhitungkan kesalahan cache. Jadi, untuk mendapatkan gambaran tentang unit kapasitas baca per detik yang ditangani oleh DAX cluster Anda, bagilah nomor dengan tingkat kehilangan cache Anda (yaitu, 1 - cache hit rate).
Jika Anda belum memiliki tabel DynamoDB, lihat dokumentasi tentang unit kapasitas baca dan tulis untuk memperkirakan lalu lintas Anda berdasarkan perkiraan tingkat permintaan aplikasi Anda, item yang diakses per permintaan, dan ukuran item.
Ketika membuat estimasi lalu lintas, rencanakan pertumbuhan di waktu mendatang dan untuk puncak yang diharapkan dan tidak terduga untuk memastikan bahwa klaster Anda memiliki ruang kosong yang cukup untuk meningkatkan lalu lintas.
Pengujian beban
Langkah berikutnya setelah memperkirakan lalu lintas adalah menguji konfigurasi klaster dengan beban.
-
Untuk pengujian beban awal, sebaiknya Anda memulai dengan jenis simpul
dax.r4.large, biaya performa tetap paling murah, jenis simpul dengan memori yang dioptimalkan. -
Klaster yang toleran terhadap kesalahan memerlukan setidaknya tiga simpul yang tersebar di tiga Zona Ketersediaan. Dalam kasus ini, jika Zona Ketersediaan menjadi tidak tersedia, jumlah Zona Ketersediaan efektif berkurang sepertiga. Untuk pengujian beban awal, sebaiknya Anda mulai dengan klaster dua simpul, yang menyimulasikan kegagalan satu Zona Ketersediaan di klaster tiga simpul.
-
Dorong lalu lintas berkelanjutan (seperti yang diperkirakan di langkah sebelumnya) ke klaster pengujian selama pengujian beban.
-
Pantau performa klaster selama pengujian beban.
Idealnya, profil lalu lintas yang Anda dorong selama pengujian beban harus semirip mungkin dengan lalu lintas aplikasi Anda yang sebenarnya. Hal ini termasuk distribusi operasi (misalnya, 70 persen GetItem, 25 persen Query, dan 5 persen PutItem), tingkat permintaan untuk setiap operasi, jumlah item yang diakses per permintaan, dan distribusi ukuran item. Untuk mencapai laju hit cache yang mirip dengan laju hit cache yang diharapkan aplikasi Anda, perhatikan distribusi kunci di lalu lintas pengujian Anda.
catatan
Hati-hati saat memuat pengujian jenis simpul T2 (dax.t2.small dan dax.t2.medium). Tipe node T2 memberikan CPUkinerja burstable yang bervariasi dari waktu ke waktu tergantung pada saldo CPU kredit node. Sebuah DAX cluster yang berjalan pada node T2 mungkin tampak beroperasi secara normal, tetapi jika ada node yang meledak di atas kinerja dasar instancenya, node tersebut menghabiskan saldo kredit yang masih harus dibayar. CPU Ketika saldo kredit hampir habis, performa akan menurun secara bertahap ke tingkat performa acuan.
Pantau DAX klaster Anda selama uji beban untuk menentukan apakah tipe node yang Anda gunakan untuk uji beban adalah tipe node yang tepat untuk Anda. Selain itu, selama pengujian beban, Anda harus memantau tingkat permintaan dan laju hit cache untuk memastikan bahwa infrastruktur pengujian Anda benar-benar mendorong jumlah lalu lintas yang diinginkan.
Anda harus memperhatikan konsumsi byte jaringan dari jenis instans klaster yang dipilih. Melebihi bandwidth dasar yang tersedia untuk EC2 instans Amazon menunjukkan bahwa klaster Anda mungkin tidak menopang beban kerja aplikasi Anda, dan perlu diskalakan.
Jika pengujian beban menunjukkan bahwa konfigurasi klaster yang dipilih tidak dapat mempertahankan beban kerja aplikasi Anda, Anda harus beralih ke tipe node yang lebih besar, terutama jika Anda melihat CPU pemanfaatan tinggi pada node utama di cluster, tingkat penggusuran tinggi, atau pemanfaatan memori cache yang tinggi. Jika laju hit konsisten tinggi dan rasio lalu lintas baca terhadap lalu lintas tulis tinggi, Anda dapat mempertimbangkan untuk menambahkan lebih banyak simpul ke klaster Anda. Lihat Menskalakan klaster DAX untuk mendapatkan panduan tambahan tentang waktu yang tepat untuk menggunakan jenis simpul yang lebih besar (penskalaan vertikal) atau menambahkan lebih banyak simpul (penskalaan horizontal).
Anda harus mengulangi pengujian beban setelah membuat perubahan pada konfigurasi klaster.
