Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Panduan pengukuran klaster DAX
Panduan ini memberikan saran untuk memilih ukuran klaster dan jenis simpul Amazon DynamoDB Accelerator (DAX) yang sesuai untuk aplikasi Anda. Petunjuk ini memandu Anda melakukan langkah-langkah untuk memperkirakan lalu lintas DAX aplikasi, memilih konfigurasi klaster, dan mengujinya.
Jika Anda memiliki klaster DAX yang sudah ada dan ingin mengevaluasi apakah klaster memiliki jumlah dan ukuran simpul yang sesuai, lihat Menskalakan klaster DAX.
Gambaran Umum
Penting menskalakan klaster DAX untuk beban kerja secara tepat, baik ketika membuat klaster baru atau mempertahankan 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. Dalam langkah ini, Anda membuat prediksi tentang volume lalu lintas yang akan dikirimkan oleh aplikasi ke DAX, sifat lalu lintas (operasi baca vs. tulis), dan laju 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 menggunakan DAX dalam produksi, Anda harus memantau klaster untuk terus memvalidasi bahwa klaster masih melakukan penskalaan dengan benar sebagai perubahan beban kerja Anda dari waktu ke waktu.
Memperkirakan lalu lintas
Ada tiga faktor utama yang menjadi ciri beban kerja DAX umum:
-
Laju hit cache
-
Unit kapasitas baca (RCU) per detik
-
Unit kapasitas tulis (WCU) per detik
Memperkirakan laju hit cache
Jika Anda sudah memiliki cluster DAX, 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. Laju hit cache bervariasi antara satu aplikasi dengan aplikasi yang lain dan sangat dipengaruhi oleh pengaturan Time to Live (TTL) klaster. Laju hit umum 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 klaster DAX, ingat bahwa metrik ConsumedReadCapacityUnits DynamoDB hanya memperhitungkan cache miss. Jadi, untuk mengetahui unit kapasitas baca per detik yang ditangani oleh klaster DAX Anda, bagi angka dengan laju cache miss Anda (yaitu, 1 - laju hit cache).
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). Jenis simpul T2 menyediakan performa CPU yang dapat melonjak yang bervariasi dari waktu ke waktu tergantung saldo kredit CPU simpul. Klaster DAX yang berjalan pada simpul T2 mungkin tampak beroperasi secara normal, tetapi jika ada simpul yang mengalami lonjakan di atas performa acuan instansnya, simpul akan menggunakan saldo kredit CPU yang diakumulasikan. Ketika saldo kredit hampir habis, performa akan menurun secara bertahap ke tingkat performa acuan.
Pantau klaster DAX Anda selama pengujian beban untuk menentukan apakah jenis simpul yang Anda gunakan untuk pengujian beban adalah jenis simpul 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. Kelebihan bandwidth acuan yang tersedia untuk instans Amazon EC2 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 harus beralih ke jenis simpul yang lebih besar, terutama jika melihat pemanfaatan CPU yang tinggi pada simpul primer di klaster, tingkat pengosongan 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.
