Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Mengoptimalkan biaya tabel Amazon Keyspaces Bagian ini mencakup praktik terbaik tentang cara mengoptimalkan biaya untuk tabel Amazon Keyspaces yang ada. Anda harus melihat strategi berikut untuk mengetahui strategi pengoptimalan biaya yang paling sesuai dengan kebutuhan Anda dan mendekatinya secara berulang. Setiap strategi memberikan gambaran umum tentang apa yang mungkin memengaruhi biaya Anda, cara mencari peluang untuk mengoptimalkan biaya, dan panduan preskriptif tentang cara menerapkan praktik terbaik ini untuk membantu Anda menghemat. **Topics** + [Evaluasi biaya Anda di tingkat tabel](CostOptimization_TableLevelCostAnalysis.md) + [Evaluasi mode kapasitas tabel Anda](CostOptimization_TableCapacityMode.md) + [Evaluasi pengaturan Application Auto Scaling tabel Anda](CostOptimization_AutoScalingSettings.md) + [Identifikasi sumber daya yang tidak digunakan untuk mengoptimalkan biaya di Amazon Keyspaces](CostOptimization_UnusedResources.md) + [Evaluasi pola penggunaan tabel Anda untuk mengoptimalkan kinerja dan biaya](CostOptimization_TableUsagePatterns.md) + [Evaluasi kapasitas yang disediakan untuk penyediaan ukuran yang tepat](CostOptimization_RightSizedProvisioning.md) # Evaluasi biaya Anda di tingkat tabel Alat Cost Explorer yang ditemukan di dalamnya Konsol Manajemen AWS memungkinkan Anda melihat biaya yang dipecah berdasarkan jenis, misalnya biaya baca, tulis, penyimpanan, dan cadangan. Anda juga dapat melihat biaya-biaya ini dirangkum berdasarkan periode seperti bulan atau hari. Salah satu tantangan umum dengan Cost Explorer adalah Anda tidak dapat meninjau biaya hanya satu tabel tertentu dengan mudah, karena Cost Explorer tidak memungkinkan Anda memfilter atau mengelompokkan berdasarkan biaya tabel tertentu. **Anda dapat melihat **ukuran tabel Billable metrik (Byte)** dari setiap tabel di konsol Amazon Keyspaces pada tab Monitor tabel.** Jika Anda memerlukan lebih banyak informasi terkait biaya per tabel, bagian ini menunjukkan cara menggunakan [penandaan](tagging-keyspaces.md) untuk melakukan analisis biaya tabel individual di Cost Explorer. **Topics** + [Cara melihat biaya satu tabel Amazon Keyspaces](#CostOptimization_TableLevelCostAnalysis_ViewInfo) + [Tampilan default Cost Explorer](#CostOptimization_TableLevelCostAnalysis_CostExplorer) + [Cara menggunakan dan menerapkan tanda tabel di Cost Explorer](#CostOptimization_TableLevelCostAnalysis_Tagging) ## Cara melihat biaya satu tabel Amazon Keyspaces Anda dapat melihat informasi dasar tentang tabel Amazon Keyspaces di konsol, termasuk skema kunci utama, ukuran tabel yang dapat ditagih, dan metrik terkait kapasitas. Anda dapat menggunakan ukuran tabel untuk menghitung biaya penyimpanan bulanan untuk tabel. Misalnya, \$10,25 per GB di AS Timur (Virginia N.). Wilayah AWS Jika tabel menggunakan mode kapasitas yang disediakan, pengaturan unit kapasitas baca saat ini (RCU) dan unit kapasitas tulis (WCU) dikembalikan juga. Anda dapat menggunakan informasi ini untuk menghitung biaya baca dan tulis saat ini untuk tabel. Perhatikan bahwa biaya ini dapat berubah, terutama jika Anda telah mengonfigurasi tabel dengan penskalaan otomatis Amazon Keyspaces. ## Tampilan default Cost Explorer Tampilan default di Cost Explorer menyediakan bagan yang menunjukkan biaya sumber daya yang dikonsumsi, misalnya throughput dan penyimpanan. Anda dapat memilih untuk mengelompokkan biaya ini berdasarkan periode, seperti total berdasarkan bulan atau hari. Biaya penyimpanan, membaca, menulis, dan kategori lainnya dapat dipecah dan dibandingkan juga. ![\[Gambar yang menunjukkan biaya sumber daya yang digunakan dalam tampilan Cost Explorer.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/CostOptimization/CostExplorerView.png) ## Cara menggunakan dan menerapkan tanda tabel di Cost Explorer Secara default, Cost Explorer tidak memberikan ringkasan biaya untuk satu tabel tertentu, karena menggabungkan biaya beberapa tabel menjadi total. Namun, Anda dapat menggunakan [penandaan sumber daya AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) untuk mengidentifikasi setiap tabel dengan tanda metadata. Tag adalah pasangan nilai kunci yang dapat Anda gunakan untuk berbagai tujuan, misalnya untuk mengidentifikasi semua sumber daya milik proyek atau departemen. Untuk informasi selengkapnya, lihat [Bekerja dengan tag dan label untuk sumber daya Amazon Keyspaces](tagging-keyspaces.md). Untuk contoh ini, kami menggunakan tabel dengan nama **MyTable**. 1. Tetapkan tag dengan kunci **table\$1name** dan nilai. **MyTable** 1. [Aktifkan tanda di dalam Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) lalu filter pada nilai tanda untuk mendapatkan lebih banyak visibilitas ke setiap biaya tabel. **catatan** Tanda mungkin akan mulai muncul di Cost Explorer setelah satu atau dua hari Anda dapat mengatur sendiri tag metadata di konsol, atau secara terprogram dengan CQL, the, atau SDK. AWS CLI AWS Pertimbangkan untuk mewajibkan tanda **table\$1name** ditetapkan sebagai bagian dari proses pembuatan tabel baru organisasi Anda. Untuk informasi selengkapnya, lihat [Membuat laporan alokasi biaya menggunakan tag untuk Amazon Keyspaces](CostAllocationReports.md). # Evaluasi mode kapasitas tabel Anda Bagian ini memberikan gambaran umum tentang cara memilih mode kapasitas yang sesuai untuk tabel Amazon Keyspaces Anda. Setiap mode disesuaikan untuk memenuhi kebutuhan beban kerja yang berbeda dalam hal respons terhadap perubahan throughput, serta cara penagihan penggunaan tersebut. Anda harus menyeimbangkan faktor-faktor ini saat membuat keputusan. **Topics** + [Mode kapasitas tabel yang tersedia](#CostOptimization_TableCapacityMode_Overview) + [Kapan harus memilih mode kapasitas sesuai permintaan](#CostOptimization_TableCapacityMode_OnDemand) + [Kapan harus mode kapasitas yang disediakan](#CostOptimization_TableCapacityMode_Provisioned) + [Faktor lain yang perlu dipertimbangkan saat memilih mode kapasitas tabel](#CostOptimization_TableCapacityMode_AdditionalFactors) ## Mode kapasitas tabel yang tersedia Saat membuat tabel Amazon Keyspaces, Anda harus memilih mode kapasitas sesuai permintaan atau yang disediakan. Untuk informasi selengkapnya, lihat [Konfigurasikan mode read/write kapasitas di Amazon Keyspaces](ReadWriteCapacityMode.md). **Mode kapasitas sesuai permintaan** Mode kapasitas sesuai permintaan dirancang untuk menghilangkan kebutuhan untuk merencanakan atau menyediakan kapasitas tabel Amazon Keyspaces Anda. Dalam mode ini, tabel Anda langsung mengakomodasi permintaan tanpa perlu menskalakan sumber daya apa pun ke atas atau ke bawah (hingga dua kali throughput puncak tabel sebelumnya). Tabel sesuai permintaan ditagih dengan menghitung jumlah permintaan aktual terhadap tabel, jadi Anda hanya membayar untuk apa yang Anda gunakan daripada apa yang telah disediakan. **Tabel kapasitas yang disediakan** Mode kapasitas yang disediakan adalah model yang lebih tradisional di mana Anda dapat menentukan berapa banyak kapasitas tabel yang tersedia untuk permintaan baik secara langsung atau dengan bantuan Application Auto Scaling. Karena kapasitas tertentu disediakan untuk tabel pada waktu tertentu, penagihan didasarkan pada kapasitas yang disediakan, bukan jumlah permintaan. Melebihi kapasitas yang dialokasikan juga dapat menyebabkan tabel menolak permintaan dan mengurangi pengalaman pengguna aplikasi Anda. Mode kapasitas yang disediakan memerlukan keseimbangan antara tidak penyediaan berlebihan atau di bawah penyediaan tabel untuk mencapai keduanya, rendahnya terjadinya kesalahan kapasitas throughput yang tidak mencukupi, dan biaya yang dioptimalkan. ## Kapan harus memilih mode kapasitas sesuai permintaan Saat mengoptimalkan biaya, mode sesuai permintaan adalah pilihan terbaik Anda ketika Anda memiliki beban kerja yang tidak terduga mirip dengan yang ditunjukkan pada grafik berikut. Faktor-faktor ini berkontribusi pada jenis beban kerja ini: + Waktu permintaan yang tidak dapat diprediksi (mengakibatkan lonjakan lalu lintas) + Volume permintaan variabel (dihasilkan dari beban kerja batch) + Turun ke nol atau di bawah 18% dari puncak selama satu jam tertentu (dihasilkan dari lingkungan pengembangan atau pengujian) ![\[Gambar yang menunjukkan lonjakan beban kerja dengan puncak lalu lintas yang acak.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeOnDemand.png) Untuk beban kerja dengan karakteristik di atas, menggunakan Application Auto Scaling untuk mempertahankan kapasitas yang cukup bagi tabel untuk merespons lonjakan lalu lintas dapat menyebabkan hasil yang tidak diinginkan. Entah tabel dapat disediakan secara berlebihan dan biaya lebih dari yang diperlukan, atau tabel dapat disediakan dan permintaan menyebabkan kesalahan throughput kapasitas rendah yang tidak perlu. Dalam kasus seperti ini, tabel berdasarkan permintaan adalah pilihan yang lebih baik. Karena tabel berdasarkan permintaan ditagih berdasarkan permintaan, tidak ada lagi yang perlu Anda lakukan di tingkat tabel untuk mengoptimalkan biaya. Anda harus secara teratur mengevaluasi tabel sesuai permintaan Anda untuk memverifikasi beban kerja masih memiliki karakteristik di atas. Jika beban kerja telah stabil, pertimbangkan untuk mengubah ke mode yang disediakan untuk mempertahankan optimalisasi biaya. ## Kapan harus mode kapasitas yang disediakan Beban kerja yang ideal untuk mode kapasitas yang disediakan adalah beban kerja dengan pola penggunaan yang lebih dapat diprediksi seperti yang ditunjukkan pada grafik di bawah ini. Faktor-faktor berikut berkontribusi pada beban kerja yang dapat diprediksi: + Lalu lintas yang dapat diprediksi/bersiklus untuk jam atau hari tertentu + Lonjakan lalu lintas jangka pendek terbatas ![\[Gambar yang menunjukkan beban kerja yang cukup dapat diprediksi dengan puncak lalu lintas terbatas.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeProvisioned.png) Karena volume lalu lintas dalam waktu atau hari tertentu lebih stabil, Anda dapat mengatur kapasitas yang disediakan relatif dekat dengan kapasitas konsumsi tabel yang sebenarnya. Pengoptimalan biaya tabel kapasitas yang disediakan pada akhirnya merupakan latihan untuk mendapatkan kapasitas yang disediakan (garis biru) sedekat mungkin dengan kapasitas yang dikonsumsi (garis oranye) tanpa meningkatkan `ThrottledRequests` peristiwa untuk tabel. Ruang antara kedua jalur adalah kapasitas yang terbuang serta asuransi terhadap pengalaman pengguna yang buruk karena kesalahan kapasitas throughput yang tidak mencukupi. Amazon Keyspaces menyediakan Application Auto Scaling untuk tabel kapasitas yang disediakan, yang secara otomatis menyeimbangkannya atas nama Anda. Anda dapat melacak kapasitas yang dikonsumsi sepanjang hari dan mengonfigurasi kapasitas tabel yang disediakan berdasarkan beberapa variabel. **Unit kapasitas minimum** Anda dapat mengatur kapasitas minimum tabel untuk membatasi terjadinya kesalahan kapasitas throughput yang tidak mencukupi, tetapi itu tidak mengurangi biaya tabel. Jika tabel Anda memiliki periode penggunaan rendah diikuti dengan ledakan penggunaan tinggi yang tiba-tiba, pengaturan minimum dapat mencegah Application Auto Scaling mengatur kapasitas tabel terlalu rendah. **Unit kapasitas maksimum** Anda dapat mengatur kapasitas tabel maksimum untuk membatasi penskalaan tabel yang lebih tinggi dari yang dimaksudkan. Pertimbangkan untuk menerapkan maksimum untuk tabel pengembangan atau pengujian, di mana pengujian beban skala besar tidak diinginkan. Anda dapat mengatur maksimum untuk tabel apa pun, tetapi pastikan untuk mengevaluasi pengaturan ini secara teratur terhadap baseline tabel saat menggunakannya dalam produksi, untuk mencegah kesalahan kapasitas throughput yang tidak disengaja. **Pemanfaatan target** Menetapkan pemanfaatan target pada tabel adalah cara utama pengoptimalan biaya untuk kapasitas tabel yang disediakan. Menetapkan nilai persen yang lebih rendah di sini meningkatkan berapa banyak tabel yang disediakan secara berlebihan, meningkatkan biaya, tetapi mengurangi risiko kesalahan kapasitas throughput yang tidak mencukupi. Menetapkan nilai persentase yang lebih tinggi berkurang dengan seberapa banyak tabel disediakan secara berlebihan, tetapi meningkatkan risiko kesalahan kapasitas throughput yang tidak mencukupi. ## Faktor lain yang perlu dipertimbangkan saat memilih mode kapasitas tabel Saat memutuskan antara dua mode kapasitas, ada beberapa faktor tambahan yang perlu dipertimbangkan. Saat memutuskan antara dua mode tabel, pertimbangkan seberapa besar diskon tambahan ini memengaruhi biaya tabel. Dalam banyak kasus, bahkan beban kerja yang relatif tidak dapat diprediksi dapat lebih hemat biaya untuk dijalankan pada tabel kapasitas yang disediakan secara berlebihan dengan kapasitas cadangan. **Meningkatkan prediktabilitas beban kerja Anda** Dalam beberapa situasi, beban kerja tampaknya memiliki keduanya, pola yang dapat diprediksi dan tidak dapat diprediksi. Meskipun ini dapat dengan mudah didukung dengan tabel sesuai permintaan, biaya kemungkinan akan lebih rendah jika pola beban kerja yang tidak terduga dapat ditingkatkan. Salah satu penyebab paling umum dari pola ini adalah impor batch. Jenis lalu lintas ini seringkali dapat melebihi kapasitas dasar tabel sedemikian rupa sehingga kesalahan kapasitas throughput yang tidak mencukupi akan terjadi jika dijalankan. Agar beban kerja seperti ini tetap berjalan pada kapasitas tabel yang disediakan, pertimbangkan opsi berikut: + Jika batch terjadi pada waktu yang dijadwalkan, Anda dapat menjadwalkan peningkatan kapasitas penskalaan otomatis aplikasi Anda sebelum dijalankan. + Jika batch terjadi secara acak, pertimbangkan untuk mencoba memperpanjang waktu yang diperlukan untuk menjalankan daripada mengeksekusi secepat mungkin. + Tambahkan periode ramp up ke impor, di mana kecepatan impor mulai kecil tetapi perlahan-lahan meningkat selama beberapa menit sampai Application Auto Scaling memiliki kesempatan untuk mulai menyesuaikan kapasitas tabel. # Evaluasi pengaturan Application Auto Scaling tabel Anda Bagian ini memberikan gambaran umum tentang cara mengevaluasi pengaturan Application Auto Scaling pada tabel Amazon Keyspaces Anda. [Amazon Keyspaces Application Auto](autoscaling.md) Scaling adalah fitur yang mengelola throughput tabel berdasarkan lalu lintas aplikasi dan metrik pemanfaatan target Anda. Ini memastikan tabel Anda memiliki kapasitas yang diperlukan untuk pola aplikasi Anda. Layanan Application Auto Scaling memantau pemanfaatan tabel Anda saat ini dan membandingkannya dengan nilai pemanfaatan target:. `TargetValue` Ini memberi tahu Anda jika sudah waktunya untuk menambah atau mengurangi kapasitas yang dialokasikan. **Topics** + [Memahami pengaturan Application Auto Scaling](#CostOptimization_AutoScalingSettings_UnderProvisionedTables) + [Cara mengidentifikasi tabel dengan pemanfaatan target rendah (<= 50%)](#CostOptimization_AutoScalingSettings_IdentifyLowUtilization) + [Cara mengatasi beban kerja dengan varian musiman](#CostOptimization_AutoScalingSettings_SeasonalVariance) + [Cara mengatasi lonjakan beban kerja dengan pola yang tidak diketahui](#CostOptimization_AutoScalingSettings_UnknownPatterns) + [Cara mengatasi beban kerja dengan aplikasi tertaut](#CostOptimization_AutoScalingSettings_BetweenRanges) ## Memahami pengaturan Application Auto Scaling Mendefinisikan nilai yang benar untuk pemanfaatan target, langkah awal, dan nilai akhir adalah aktivitas yang memerlukan keterlibatan dari tim operasi Anda. Ini memungkinkan Anda untuk menentukan nilai dengan benar berdasarkan penggunaan aplikasi historis, yang digunakan untuk memicu kebijakan Application Auto Scaling. Target pemanfaatan adalah persentase dari total kapasitas Anda yang perlu dipenuhi selama periode waktu tertentu sebelum aturan Application Auto Scaling berlaku. Ketika Anda menetapkan target **pemanfaatan yang tinggi (target sekitar 90%)** itu berarti lalu lintas Anda harus lebih tinggi dari 90% untuk jangka waktu tertentu sebelum Application Auto Scaling diaktifkan. Jangan menggunakan pemanfaatan target yang tinggi kecuali aplikasi Anda sangat konstan dan tidak menerima lonjakan lalu lintas. Ketika Anda menetapkan **pemanfaatan yang sangat rendah (target kurang dari 50%)** itu berarti aplikasi Anda harus mencapai 50% dari kapasitas yang disediakan sebelum memicu kebijakan Application Auto Scaling. Kecuali lalu lintas aplikasi Anda tumbuh pada tingkat yang sangat agresif, ini biasanya diterjemahkan ke dalam kapasitas yang tidak terpakai dan sumber daya yang terbuang. ## Cara mengidentifikasi tabel dengan pemanfaatan target rendah (<= 50%) Anda dapat menggunakan AWS CLI atau Konsol Manajemen AWS untuk memantau dan mengidentifikasi kebijakan Application Auto Scaling di resource Amazon Keyspaces Anda. `TargetValues` **catatan** Saat Anda menggunakan tabel Multi-wilayah dalam mode kapasitas yang disediakan dengan penskalaan otomatis Amazon Keyspaces, pastikan untuk menggunakan operasi Amazon Keyspaces API untuk mengonfigurasi penskalaan otomatis. Operasi Application Auto Scaling API yang mendasari yang dipanggil Amazon Keyspaces atas nama Anda tidak memiliki kemampuan Multi-region. Untuk informasi selengkapnya, lihat [Melihat setelan kapasitas dan penskalaan otomatis yang disediakan untuk tabel Multi-wilayah di Amazon Keyspaces](tables-mrr-view.md). ------ #### [ AWS CLI ] 1. Kembalikan seluruh daftar sumber daya dengan menjalankan perintah berikut: ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra ``` Perintah ini akan mengembalikan seluruh daftar kebijakan Application Auto Scaling yang dikeluarkan untuk sumber daya Amazon Keyspaces apa pun. Jika hanya ingin mengambil sumber daya dari tabel tertentu, Anda dapat menambahkan `–resource-id parameter`. Contoh: ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name” ``` 1. Kembalikan hanya kebijakan penskalaan otomatis untuk tabel tertentu dengan menjalankan perintah berikut ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name” ``` Nilai untuk kebijakan Application Auto Scaling disorot di bawah ini. Anda perlu memastikan bahwa nilai target lebih besar dari 50% untuk menghindari penyediaan berlebih. Anda akan mendapatkan hasil yang mirip dengan berikut ini: ``` { "ScalingPolicies": [ { "PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy::resource/keyspaces/table/table-name-scaling-policy", "PolicyName": $”, "ServiceNamespace": "cassandra", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:WriteCapacityUnits", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "KeyspacesWriteCapacityUtilization" } }, "Alarms": [ ... ], "CreationTime": "2022-03-04T16:23:48.641000+10:00" }, { "PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy::resource/keyspaces/table/table-name-scaling-policy", "PolicyName":$”, "ServiceNamespace": "cassandra", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:ReadCapacityUnits", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "KeyspacesReadCapacityUtilization" } }, "Alarms": [ ... ], "CreationTime": "2022-03-04T16:23:47.820000+10:00" } ] } ``` ------ #### [ Konsol Manajemen AWS ] 1. Masuk ke Konsol Manajemen AWS dan navigasikan ke halaman CloudWatch layanan di [Memulai dengan Konsol Manajemen AWS](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html). Pilih yang sesuai Wilayah AWS jika perlu. 1. Di bilah navigasi kiri, pilih **Tabel**. Di halaman **Tabel**, pilih **Nama** tabel. 1. Pada halaman **Detail Tabel** pada tab **Kapasitas**, tinjau pengaturan Application Auto Scaling tabel Anda. ------ Jika nilai pemanfaatan target Anda kurang dari atau sama dengan 50%, Anda harus mempelajari metrik pemanfaatan tabel Anda untuk mengetahui apakah nilai tersebut [kurang tersedia atau disediakan secara berlebihan](CostOptimization_RightSizedProvisioning.md). ## Cara mengatasi beban kerja dengan varian musiman Pertimbangkan skenario berikut: aplikasi Anda sering kali beroperasi di bawah nilai rata-rata minimum, tetapi pemanfaatan targetnya rendah sehingga aplikasi Anda dapat bereaksi dengan cepat terhadap peristiwa yang terjadi pada jam-jam tertentu dalam sehari dan Anda memiliki kapasitas yang memadai serta menghindari throttling. Skenario ini umum terjadi ketika Anda memiliki aplikasi yang sangat sibuk selama jam kantor normal (9 pagi hingga 5 sore) tetapi kemudian berfungsi pada tingkat dasar setelah jam kerja. Karena beberapa pengguna mulai terhubung sebelum jam 9 pagi, aplikasi menggunakan ambang batas rendah ini untuk meningkatkan dengan cepat untuk mencapai kapasitas yang *diperlukan* selama jam sibuk. Skenario ini akan seperti berikut: + Antara jam 5 sore dan 9 pagi `ConsumedWriteCapacityUnits` unit tetap berada di antara 90 dan 100 + Pengguna mulai terhubung ke aplikasi sebelum jam 9 pagi dan unit kapasitas meningkat pesat (nilai maksimum yang Anda lihat adalah 1500 WCU) + Rata-rata, penggunaan aplikasi Anda berkisar antara 800 hingga 1200 selama jam kerja Jika skenario sebelumnya berlaku untuk aplikasi Anda, pertimbangkan untuk menggunakan [penskalaan otomatis aplikasi terjadwal](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html), di mana tabel Anda masih dapat memiliki aturan Application Auto Scaling yang dikonfigurasi, tetapi dengan pemanfaatan target yang kurang agresif yang hanya menyediakan kapasitas ekstra pada interval tertentu yang Anda butuhkan. Anda dapat menggunakan AWS CLI untuk menjalankan langkah-langkah berikut untuk membuat aturan penskalaan otomatis terjadwal yang dijalankan berdasarkan waktu hari dan hari dalam seminggu. 1. Daftarkan tabel Amazon Keyspaces Anda sebagai target yang dapat diskalakan dengan. Application Auto Scaling Target yang dapat diskalakan adalah sumber daya yang skalanya dapat diperkecil atau diperbesar oleh Application Auto Scaling . ``` aws application-autoscaling register-scalable-target \ --service-namespace cassandra \ --scalable-dimension cassandra:table:WriteCapacityUnits \ --resource-id keyspace/keyspace-name/table/table-name \ --min-capacity 90 \ --max-capacity 1500 ``` 1. Siapkan tindakan terjadwal sesuai dengan kebutuhan Anda. Anda memerlukan dua aturan untuk menutupi skenario: satu untuk meningkatkan dan satu lagi untuk menurunkan skala. Aturan pertama untuk meningkatkan tindakan terjadwal ditampilkan dalam contoh berikut. ``` aws application-autoscaling put-scheduled-action \ --service-namespace cassandra \ --scalable-dimension cassandra:table:WriteCapacityUnits \ --resource-id keyspace/keyspace-name/table/table-name \ --scheduled-action-name my-8-5-scheduled-action \ --scalable-target-action MinCapacity=800,MaxCapacity=1500 \ --schedule "cron(45 8 ? * MON-FRI *)" \ --timezone "Australia/Brisbane" ``` Aturan kedua untuk mengurangi tindakan terjadwal ditunjukkan dalam contoh ini. ``` aws application-autoscaling put-scheduled-action \ --service-namespace cassandra \ --scalable-dimension cassandra:table:WriteCapacityUnits \ --resource-id keyspace/keyspace-name/table/table-name \ --scheduled-action-name my-5-8-scheduled-down-action \ --scalable-target-action MinCapacity=90,MaxCapacity=1500 \ --schedule "cron(15 17 ? * MON-FRI *)" \ --timezone "Australia/Brisbane" ``` 1. Jalankan perintah berikut untuk memvalidasi bahwa kedua aturan telah diaktifkan: ``` aws application-autoscaling describe-scheduled-actions --service-namespace cassandra ``` Anda akan mendapatkan hasil seperti ini: ``` { "ScheduledActions": [ { "ScheduledActionName": "my-5-8-scheduled-down-action", "ScheduledActionARN": "arn:aws:autoscaling:us-east-1:111122223333:scheduledAction::resource/keyspaces/table/table-name:scheduledActionName/my-5-8-scheduled-down-action", "ServiceNamespace": "cassandra", "Schedule": "cron(15 17 ? * MON-FRI *)", "Timezone": "Australia/Brisbane", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:WriteCapacityUnits", "ScalableTargetAction": { "MinCapacity": 90, "MaxCapacity": 1500 }, "CreationTime": "2022-03-15T17:30:25.100000+10:00" }, { "ScheduledActionName": "my-8-5-scheduled-action", "ScheduledActionARN": "arn:aws:autoscaling:us-east-1:111122223333:scheduledAction::resource/keyspaces/table/table-name:scheduledActionName/my-8-5-scheduled-action", "ServiceNamespace": "cassandra", "Schedule": "cron(45 8 ? * MON-FRI *)", "Timezone": "Australia/Brisbane", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:WriteCapacityUnits", "ScalableTargetAction": { "MinCapacity": 800, "MaxCapacity": 1500 }, "CreationTime": "2022-03-15T17:28:57.816000+10:00" } ] } ``` Gambar berikut menunjukkan beban kerja sampel yang selalu mempertahankan pemanfaatan target 70%. Perhatikan bagaimana aturan penskalaan otomatis masih berlaku dan throughputnya tidak berkurang. ![\[Grafik yang menunjukkan penggunaan tulis dalam satuan per detik membandingkan kapasitas yang disediakan dengan konsumsi selama periode satu hari.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings3.png) Jika diperbesar, kita dapat melihat adanya lonjakan dalam aplikasi yang memicu ambang penskalaan otomatis sebesar 70%, sehingga memaksa penskalaan otomatis untuk memulai dan menyediakan kapasitas tambahan yang diperlukan untuk tabel. Tindakan penskalaan otomatis terjadwal akan memengaruhi nilai maksimum dan minimum, dan Anda bertanggung jawab untuk mengaturnya. ![\[Tampilan grafik yang lebih rinci yang menunjukkan penggunaan tulis dalam satuan per detik membandingkan kapasitas yang disediakan dengan konsumsi, memperbesar waktu tertentu.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings4.png) ![\[Menampilkan tampilan rinci grafik yang menunjukkan penggunaan tulis dalam satuan per detik membandingkan kapasitas yang disediakan dengan konsumsi selama periode satu hari.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings5.png) ## Cara mengatasi lonjakan beban kerja dengan pola yang tidak diketahui Dalam skenario ini, aplikasi menggunakan target pemanfaatan yang sangat rendah, karena Anda belum mengetahui pola aplikasi, dan Anda ingin memastikan beban kerja Anda tidak mengalami kesalahan throughput kapasitas rendah. Sebaiknya gunakan [mode kapasitas sesuai permintaan](ReadWriteCapacityMode.OnDemand.md). Tabel sesuai permintaan sangat cocok untuk lonjakan beban kerja yang tidak Anda ketahui pola lalu lintasnya. Dengan mode kapasitas sesuai permintaan, Anda membayar per permintaan atas pembacaan dan penulisan data yang dilakukan aplikasi Anda pada tabel Anda. Anda tidak perlu menentukan berapa banyak throughput baca dan tulis yang Anda harapkan untuk dilakukan aplikasi Anda, karena Amazon Keyspaces langsung mengakomodasi beban kerja Anda saat naik atau turun. ## Cara mengatasi beban kerja dengan aplikasi tertaut Dalam skenario ini, aplikasi bergantung pada sistem lain, seperti skenario pemrosesan batch yang dapat menghasilkan lonjakan besar dalam lalu lintas sesuai dengan peristiwa dalam logika aplikasi. Pertimbangkan untuk mengembangkan logika auto-scaling aplikasi khusus yang bereaksi terhadap peristiwa di mana Anda dapat meningkatkan kapasitas tabel `TargetValues` dan tergantung pada kebutuhan spesifik Anda. Anda bisa mendapatkan keuntungan dari Amazon EventBridge dan menggunakan kombinasi AWS layanan seperti Λ dan Step Functions untuk menanggapi kebutuhan aplikasi spesifik Anda. # Identifikasi sumber daya yang tidak digunakan untuk mengoptimalkan biaya di Amazon Keyspaces Bagian ini memberikan gambaran umum tentang cara mengevaluasi sumber daya yang Anda tidak terpakai secara berkala. Saat persyaratan aplikasi Anda berkembang, Anda harus memastikan tidak ada sumber daya yang tidak digunakan dan berkontribusi pada biaya Amazon Keyspaces yang tidak perlu. Prosedur yang dijelaskan di bawah ini menggunakan CloudWatch metrik Amazon untuk mengidentifikasi sumber daya yang tidak digunakan dan mengambil tindakan untuk mengurangi biaya. Anda dapat memantau Amazon Keyspaces menggunakan CloudWatch, yang mengumpulkan dan memproses data mentah dari Amazon Keyspaces menjadi metrik hampir real-time yang dapat dibaca. Statistik ini disimpan selama jangka waktu tertentu, sehingga Anda dapat mengakses informasi historis untuk lebih memahami pemanfaatan Anda. Secara default, data metrik Amazon Keyspaces dikirim secara otomatis. CloudWatch Untuk informasi lebih lanjut, lihat [Apa itu Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) dan [Retensi metrik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#metrics-retention) di *Panduan CloudWatch Pengguna Amazon*. **Topics** + [Cara mengidentifikasi sumber daya yang tidak terpakai](#CostOptimization_UnusedResources_Identifying) + [Mengidentifikasi sumber daya tabel yang tidak terpakai](#CostOptimization_UnusedResources_Tables) + [Membersihkan sumber daya tabel yang tidak terpakai](#CostOptimization_UnusedResources_Tables_Cleanup) + [Membersihkan cadangan point-in-time pemulihan yang tidak terpakai (PITR)](#CostOptimization_UnusedResources_Backups) ## Cara mengidentifikasi sumber daya yang tidak terpakai Untuk mengidentifikasi tabel yang tidak digunakan, Anda dapat melihat CloudWatch metrik berikut selama 30 hari untuk memahami apakah ada pembacaan atau penulisan aktif pada tabel tertentu: **`ConsumedReadCapacityUnits`** Jumlah unit kapasitas baca yang terpakai selama jangka waktu tertentu, sehingga Anda dapat melacak jumlah kapasitas terpakai yang telah Anda gunakan. Anda dapat mengambil total kapasitas baca yang dikonsumsi untuk sebuah tabel. **`ConsumedWriteCapacityUnits`** Jumlah unit kapasitas tulis yang terpakai selama jangka waktu tertentu, sehingga Anda dapat melacak jumlah kapasitas terpakai yang telah Anda gunakan. Anda dapat mengambil total kapasitas tulis yang dikonsumsi untuk sebuah tabel. ## Mengidentifikasi sumber daya tabel yang tidak terpakai Amazon CloudWatch adalah layanan pemantauan dan observabilitas yang menyediakan metrik tabel Amazon Keyspaces yang dapat Anda gunakan untuk mengidentifikasi sumber daya yang tidak digunakan. CloudWatch metrik dapat dilihat melalui Konsol Manajemen AWS maupun melalui. AWS Command Line Interface ------ #### [ AWS Command Line Interface ] Untuk melihat metrik tabel Anda melalui AWS Command Line Interface, Anda dapat menggunakan perintah berikut. 1. Pertama, evaluasi pembacaan tabel Anda: **catatan** Jika nama tabel tidak unik dalam akun Anda, Anda juga harus menentukan nama ruang kunci. ``` aws cloudwatch get-metric-statistics --metric-name ConsumedReadCapacityUnits --start-time --end-time --period --namespace AWS/Cassandra --statistics Sum -- dimensions Name=TableName,Value= ``` Untuk menghindari kesalahan dalam mengidentifikasi tabel sebagai tidak terpakai, evaluasi metrik dalam jangka waktu yang lebih lama. **Pilih rentang waktu mulai dan akhir waktu yang sesuai, seperti **30 hari**, dan periode yang sesuai, seperti 86400.** Dalam data yang dikembalikan, setiap **Jumlah** di atas **0** menunjukkan bahwa tabel yang Anda evaluasi menerima lalu lintas baca selama periode tersebut. Hasil berikut menunjukkan tabel yang menerima lalu lintas baca pada periode yang dievaluasi: ``` { "Timestamp": "2022-08-25T19:40:00Z", "Sum": 36023355.0, "Unit": "Count" }, { "Timestamp": "2022-08-12T19:40:00Z", "Sum": 38025777.5, "Unit": "Count" }, ``` Hasil berikut menunjukkan tabel yang tidak menerima lalu lintas baca pada periode yang dievaluasi: ``` { "Timestamp": "2022-08-01T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-20T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, ``` 1. Selanjutnya, evaluasi penulisan tabel Anda: ``` aws cloudwatch get-metric-statistics --metric-name ConsumedWriteCapacityUnits --start-time --end-time --period --namespace AWS/Cassandra --statistics Sum -- dimensions Name=TableName,Value= ``` Untuk menghindari kesalahan dalam mengidentifikasi tabel sebagai tidak terpakai, sebaiknya Anda mengevaluasi metrik dalam jangka waktu yang lebih lama. Pilih rentang waktu mulai dan waktu berakhir yang sesuai, seperti **30 hari**, dan periode yang sesuai, seperti **86400**. Dalam data yang dikembalikan, setiap **Jumlah** di atas **0** menunjukkan bahwa tabel yang Anda evaluasi menerima lalu lintas baca selama periode tersebut. Hasil berikut menunjukkan tabel yang menerima lalu lintas tulis pada periode yang dievaluasi: ``` { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 41014457.0, "Unit": "Count" }, { "Timestamp": "2022-08-18T20:15:00Z", "Sum": 40048531.0, "Unit": "Count" }, ``` Hasil berikut menunjukkan tabel yang tidak menerima lalu lintas tulis pada periode yang dievaluasi: ``` { "Timestamp": "2022-07-31T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, ``` ------ #### [ Konsol Manajemen AWS ] Langkah-langkah berikut memungkinkan Anda untuk mengevaluasi pemanfaatan sumber daya Anda melalui. Konsol Manajemen AWS 1. Masuk ke Konsol Manajemen AWS dan navigasikan ke halaman CloudWatch layanan di [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). Pilih yang sesuai Wilayah AWS di kanan atas konsol, jika perlu. 1. Di bilah navigasi kiri, cari bagian **Metrik** dan pilih **Semua metrik**. 1. Tindakan di atas membuka dasbor dengan dua panel. Di panel atas, Anda dapat melihat metrik grafik saat ini. Di bagian bawah Anda dapat memilih metrik yang tersedia untuk grafik. Pilih Amazon Keyspaces di panel bawah. 1. Di panel pemilihan metrik Amazon Keyspaces, pilih kategori **Metrik Tabel untuk menampilkan metrik** tabel di wilayah saat ini. 1. Identifikasi nama tabel Anda dengan menggulir ke bawah menu, lalu pilih metrik `ConsumedReadCapacityUnits` dan `ConsumedWriteCapacityUnits` untuk tabel Anda. 1. **Pilih **Metrik grafik (2)** tab dan sesuaikan kolom **Statistik** ke Jumlah.** 1. Untuk menghindari kesalahan mengidentifikasi tabel sebagai tidak terpakai, evaluasi metrik tabel selama periode yang lebih lama. Di bagian atas panel grafik, pilih kerangka waktu yang sesuai, seperti 1 bulan, untuk mengevaluasi tabel Anda. Pilih **Kustom**, pilih **1 Bulan** di menu tarik-turun, dan pilih **Terapkan**. 1. Evaluasi metrik bergrafik untuk tabel Anda guna menentukan apakah tabel sedang digunakan. Metrik di atas **0** menunjukkan bahwa tabel telah digunakan selama jangka waktu evaluasi. Grafik datar pada **0** untuk membaca dan menulis menunjukkan bahwa tabel tidak digunakan. ------ ## Membersihkan sumber daya tabel yang tidak terpakai Jika Anda telah mengidentifikasi sumber daya tabel yang tidak terpakai, Anda dapat mengurangi biaya berkelanjutannya dengan cara berikut. **catatan** Jika Anda telah mengidentifikasi tabel yang tidak terpakai tetapi masih ingin tetap tersedia jika tabel tersebut perlu diakses di masa mendatang, pertimbangkan untuk mengalihkannya ke mode sesuai permintaan. Jika tidak, Anda dapat mempertimbangkan untuk menghapus tabel. **Mode kapasitas** Amazon Keyspaces mengenakan biaya untuk membaca, menulis, dan menyimpan data di tabel Amazon Keyspaces Anda. Amazon Keyspaces memiliki [dua mode kapasitas](ReadWriteCapacityMode.md), yang dilengkapi dengan opsi penagihan khusus untuk memproses pembacaan dan penulisan di tabel Anda: sesuai permintaan dan disediakan. Mode read/write kapasitas mengontrol bagaimana Anda dikenakan biaya untuk throughput baca dan tulis dan bagaimana Anda mengelola kapasitas. Untuk tabel mode sesuai permintaan, Anda tidak perlu menentukan jumlah throughput baca dan tulis yang Anda harapkan untuk dijalankan oleh aplikasi Anda. Amazon Keyspaces menagih Anda untuk membaca dan menulis bahwa aplikasi Anda bekerja pada tabel Anda dalam hal unit permintaan baca dan unit permintaan tulis. Jika tidak ada aktivitas di meja Anda, Anda tidak membayar untuk throughput tetapi Anda masih dikenakan biaya penyimpanan. **Menghapus tabel** Jika Anda telah menemukan tabel yang tidak digunakan dan ingin menghapusnya, pertimbangkan untuk membuat cadangan atau mengekspor data terlebih dahulu. Pencadangan yang dilakukan AWS Backup dapat memanfaatkan tiering cold storage, yang selanjutnya mengurangi biaya. Lihat dokumentasi [Mengelola rencana cadangan](https://docs.aws.amazon.com/aws-backup/latest/devguide/about-backup-plans) untuk informasi tentang cara menggunakan siklus hidup untuk memindahkan cadangan Anda ke penyimpanan dingin. Setelah tabel Anda telah dicadangkan, Anda dapat menghapusnya melalui Konsol Manajemen AWS atau AWS Command Line Interface. ## Membersihkan cadangan point-in-time pemulihan yang tidak terpakai (PITR) Amazon Keyspaces menawarkan Point-in-time pemulihan, yang menyediakan pencadangan berkelanjutan selama 35 hari untuk membantu Anda melindungi dari penulisan atau penghapusan yang tidak disengaja. Pencadangan PITR memiliki biaya yang terkait dengannya. Lihat dokumentasi di [Cadangkan dan pulihkan data dengan point-in-time pemulihan untuk Amazon Keyspaces](PointInTimeRecovery.md) untuk menentukan apakah tabel Anda memiliki cadangan diaktifkan yang mungkin tidak lagi diperlukan. # Evaluasi pola penggunaan tabel Anda untuk mengoptimalkan kinerja dan biaya Bagian ini memberikan ikhtisar tentang cara mengevaluasi jika Anda menggunakan tabel Amazon Keyspaces secara efisien. Ada pola penggunaan tertentu yang tidak optimal untuk Amazon Keyspaces, dan mereka memungkinkan ruang untuk pengoptimalan baik dari perspektif kinerja maupun biaya. **Topics** + [Lakukan lebih sedikit operasi bacaan sangat konsisten](#CostOptimization_TableUsagePatterns_StronglyConsistentReads) + [Aktifkan Waktu untuk Tayang (TTL)](#CostOptimization_TableUsagePatterns_TTL) ## Lakukan lebih sedikit operasi bacaan sangat konsisten Amazon Keyspaces memungkinkan Anda mengonfigurasi [konsistensi baca](consistency.md#ReadConsistency) berdasarkan per permintaan. Permintaan baca pada akhirnya konsisten secara default. Akhirnya pembacaan yang konsisten dibebankan pada 0,5 RCU hingga 4 KB data. Sebagian besar beban kerja terdistribusi bersifat fleksibel dan dapat menoleransi konsistensi akhir. Namun, mungkin ada pola akses yang membutuhkan bacaan sangat konsisten. Pembacaan yang sangat konsisten dibebankan pada 1 RCU hingga 4 KB data, yang pada dasarnya menggandakan biaya baca Anda. Amazon Keyspaces memberi Anda fleksibilitas untuk menggunakan kedua model konsistensi pada tabel yang sama. Anda dapat mengevaluasi beban kerja dan kode aplikasi untuk mengonfirmasi apakah bacaan sangat konsisten hanya digunakan jika diperlukan. ## Aktifkan Waktu untuk Tayang (TTL) [Time to Live (TTL)](TTL.md) membantu Anda menyederhanakan logika aplikasi Anda dan mengoptimalkan harga penyimpanan dengan kedaluwarsa data dari tabel secara otomatis. Data yang tidak lagi Anda perlukan akan dihapus secara otomatis dari tabel berdasarkan nilai Time to Live yang Anda tetapkan. # Evaluasi kapasitas yang disediakan untuk penyediaan ukuran yang tepat Bagian ini memberikan ikhtisar tentang cara mengevaluasi apakah Anda memiliki penyediaan ukuran yang tepat di tabel Amazon Keyspaces Anda. Seiring berkembangnya beban kerja, Anda harus mengubah prosedur operasional dengan tepat, terutama ketika tabel Amazon Keyspaces Anda dikonfigurasi dalam mode yang disediakan dan Anda berisiko untuk menyediakan tabel Anda secara berlebihan atau kurang menyediakan tabel Anda. Prosedur yang dijelaskan di bagian ini memerlukan informasi statistik yang harus diambil dari tabel Amazon Keyspaces yang mendukung aplikasi produksi Anda. Untuk memahami perilaku aplikasi Anda, Anda harus menentukan periode waktu yang cukup signifikan untuk menangkap data musiman aplikasi Anda. Misalnya, jika aplikasi Anda menunjukkan pola mingguan, menggunakan periode tiga minggu akan memberi Anda cukup ruang untuk menganalisis kebutuhan throughput aplikasi. Jika Anda tidak tahu harus mulai dari mana, gunakan penggunaan data setidaknya selama satu bulan untuk penghitungan di bawah ini. Saat mengevaluasi kapasitas, untuk tabel Amazon Keyspaces Anda dapat **mengonfigurasi Unit Kapasitas Baca RCUs () dan Unit Kapasitas Tulis (****WCU**) secara independen. **Topics** + [Cara mengambil metrik konsumsi dari tabel Amazon Keyspaces](#CostOptimization_RightSizedProvisioning_ConsumptionMetrics) + [Cara mengidentifikasi tabel Amazon Keyspaces yang kurang disediakan](#CostOptimization_RightSizedProvisioning_UnderProvisionedTables) + [Cara mengidentifikasi tabel Amazon Keyspaces yang disediakan secara berlebihan](#CostOptimization_RightSizedProvisioning_OverProvisionedTables) ## Cara mengambil metrik konsumsi dari tabel Amazon Keyspaces Untuk mengevaluasi kapasitas tabel, pantau CloudWatch metrik berikut dan pilih dimensi yang sesuai untuk mengambil informasi tabel: | Unit Kapasitas Baca | Unit Kapasitas Tulis | | --- | --- | | `ConsumedReadCapacityUnits` | `ConsumedWriteCapacityUnits` | | `ProvisionedReadCapacityUnits` | `ProvisionedWriteCapacityUnits` | | `ReadThrottleEvents` | `WriteThrottleEvents` | Anda dapat melakukan ini baik melalui AWS CLI atau Konsol Manajemen AWS. ------ #### [ AWS CLI ] Sebelum mengambil metrik konsumsi tabel, Anda harus memulai dengan menangkap beberapa titik data historis menggunakan API. CloudWatch Mulailah dengan membuat dua file: `write-calc.json` dan `read-calc.json`. File-file ini mewakili perhitungan untuk tabel. Anda perlu memperbarui beberapa bidang, seperti yang ditunjukkan pada tabel di bawah ini, agar sesuai dengan lingkungan Anda. **catatan** Jika nama tabel tidak unik dalam akun Anda, Anda juga harus menentukan nama ruang kunci. | Nama Bidang | Definisi | Contoh | | --- | --- | --- | | | Nama tabel yang Anda analisis | SampleTable | | | Jangka waktu yang Anda gunakan untuk mengevaluasi target pemanfaatan, berdasarkan detik | Untuk periode 1 jam, Anda harus menentukan: 3600 | | | Awal interval evaluasi Anda, ditentukan dalam ISO8601 format | 2022-02-21T23:00:00 | | | Akhir interval evaluasi Anda, ditentukan dalam ISO8601 format | 2022-02-22T06:00:00 | File perhitungan tulis mengambil jumlah WCU yang disediakan dan dikonsumsi dalam periode waktu untuk rentang tanggal yang ditentukan. Ini juga menghasilkan persentase pemanfaatan yang dapat digunakan untuk analisis. Isi lengkap `write-calc.json` file akan terlihat seperti pada contoh berikut. ``` { "MetricDataQueries": [ { "Id": "provisionedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ProvisionedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ConsumedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": """ } ] }, "Period": , "Stat": "Sum" }, "Label": "", "ReturnData": false }, { "Id": "m1", "Expression": "consumedWCU/PERIOD(consumedWCU)", "Label": "Consumed WCUs", "ReturnData": false }, { "Id": "utilizationPercentage", "Expression": "100*(m1/provisionedWCU)", "Label": "Utilization Percentage", "ReturnData": true } ], "StartTime": "", "EndTime": "", "ScanBy": "TimestampDescending", "MaxDatapoints": 24 } ``` File perhitungan baca menggunakan metrik serupa. File ini mengambil berapa banyak RCUs yang disediakan dan dikonsumsi selama periode waktu untuk rentang tanggal yang ditentukan. Isi `read-calc.json` file akan terlihat seperti dalam contoh ini. ``` { "MetricDataQueries": [ { "Id": "provisionedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ProvisionedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ConsumedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Sum" }, "Label": "", "ReturnData": false }, { "Id": "m1", "Expression": "consumedRCU/PERIOD(consumedRCU)", "Label": "Consumed RCUs", "ReturnData": false }, { "Id": "utilizationPercentage", "Expression": "100*(m1/provisionedRCU)", "Label": "Utilization Percentage", "ReturnData": true } ], "StartTime": "", "EndTime": "", "ScanBy": "TimestampDescending", "MaxDatapoints": 24 } ``` Setelah Anda membuat file, Anda dapat mulai mengambil data pemanfaatan. 1. Untuk mengambil data pemanfaatan tulis, keluarkan perintah berikut: ``` aws cloudwatch get-metric-data --cli-input-json file://write-calc.json ``` 1. Untuk mengambil data pemanfaatan baca, keluarkan perintah berikut: ``` aws cloudwatch get-metric-data --cli-input-json file://read-calc.json ``` Hasil untuk kedua kueri adalah serangkaian titik data dalam format JSON yang dapat digunakan untuk analisis. Hasil Anda bergantung pada jumlah titik data yang Anda tentukan, periode, dan data beban kerja spesifik Anda sendiri. Itu bisa terlihat seperti pada contoh berikut. ``` { "MetricDataResults": [ { "Id": "utilizationPercentage", "Label": "Utilization Percentage", "Timestamps": [ "2022-02-22T05:00:00+00:00", "2022-02-22T04:00:00+00:00", "2022-02-22T03:00:00+00:00", "2022-02-22T02:00:00+00:00", "2022-02-22T01:00:00+00:00", "2022-02-22T00:00:00+00:00", "2022-02-21T23:00:00+00:00" ], "Values": [ 91.55364583333333, 55.066631944444445, 2.6114930555555556, 24.9496875, 40.94725694444445, 25.61819444444444, 0.0 ], "StatusCode": "Complete" } ], "Messages": [] } ``` **catatan** Jika Anda menentukan periode pendek dan rentang waktu yang lama, Anda mungkin perlu memodifikasi `MaxDatapoints` nilainya, yang secara default disetel ke 24 dalam skrip. Ini mewakili satu titik data per jam dan 24 per hari. ------ #### [ Konsol Manajemen AWS ] 1. Masuk ke Konsol Manajemen AWS dan navigasikan ke halaman CloudWatch layanan di [Memulai dengan Konsol Manajemen AWS](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html). Pilih yang sesuai Wilayah AWS jika perlu. 1. Temukan bagian Metrik di bilah navigasi kiri dan pilih **Semua metrik**. 1. Ini membuka dasbor dengan dua panel. Panel atas menunjukkan grafik, dan panel bawah memiliki metrik yang ingin Anda grafik. Pilih panel Amazon Keyspaces. 1. Pilih kategori **Metrik Tabel** dari sub panel. Ini menunjukkan kepada Anda tabel di saat ini Wilayah AWS. 1. Identifikasi nama tabel Anda dengan menggulir menu ke bawah, lalu memilih metrik operasi tulis: `ConsumedWriteCapacityUnits` dan `ProvisionedWriteCapacityUnits` **catatan** Contoh ini membahas metrik operasi tulis, tetapi Anda juga dapat menggunakan langkah-langkah ini untuk membuat grafik metrik operasi baca. 1. Pilih tab **Metrik bergrafik (2)** untuk memodifikasi rumus. Secara default CloudWatch memilih fungsi statistik **Rata-rata** untuk grafik. 1. Saat memilih kedua metrik bergrafik (kotak centang di sebelah kiri) pilih menu **Tambahkan perhitungan**, diikuti oleh **Umum**, lalu pilih fungsi **Persentase**. Ulangi prosedur ini dua kali. Pertama kali memilih fungsi **Persentase**. Kedua kalinya memilih fungsi **Persentase**. 1. Pada titik ini, Anda memiliki empat metrik di menu bawah. Mari kita kerjakan penghitungan `ConsumedWriteCapacityUnits`. Agar konsisten, Anda harus mencocokkan nama dengan yang Anda gunakan di AWS CLI bagian ini. Klik **m1 ID** dan ubah nilai ini menjadi **consumedWCU**. 1. Ubah statistik dari **Average** menjadi **Sum**. Tindakan ini secara otomatis membuat metrik lain yang disebut **ANOMALY\$1DETECTION\$1BAND**. Untuk cakupan prosedur ini, Anda dapat mengabaikan ini dengan menghapus kotak centang pada metrik **ad1** yang baru dibuat. 1. Ulangi langkah 8 untuk mengganti nama **m2 ID** menjadi **ProvisionedWCU**. Biarkan statistik diatur ke **Average**. 1. **Pilih label **Expression1** dan perbarui nilainya ke **m1** dan label ke Consumed. WCUs** **catatan** Pastikan Anda hanya memilih **m1** (kotak centang di sebelah kiri) dan **ProvisionedWCU** untuk memvisualisasikan data dengan benar. Perbarui rumus dengan mengklik **Detail** dan mengubah rumus menjadi **consumedWCU/PERIOD(consumedWCU)**. Langkah ini mungkin juga menghasilkan metrik **ANOMALY\$1DETECTION\$1BAND** lain, tetapi untuk cakupan prosedur ini Anda dapat mengabaikannya. 1. Anda sekarang harus memiliki dua grafik: satu yang menunjukkan Anda disediakan WCUs di atas meja dan satu lagi yang menunjukkan yang dikonsumsi. WCUs 1. Perbarui rumus persentase dengan memilih grafik Expression2 (**e2**). Ganti nama label dan IDs **UtilizationPercentage**. Ganti nama rumus agar sesuai dengan **100\$1(m1/provisionedWCU)**. 1. Hapus kotak centang dari semua metrik kecuali **utilizationPercentage** untuk memvisualisasikan pola pemanfaatan Anda. Interval default diatur ke 1 menit, tetapi jangan ragu untuk memodifikasinya sesuai kebutuhan. Hasil yang Anda dapatkan tergantung pada data aktual dari beban kerja Anda. Interval dengan pemanfaatan lebih dari 100% rentan terhadap peristiwa kesalahan kapasitas throughput yang rendah. Amazon Keyspaces menawarkan [kapasitas burst](throughput-bursting.md), tetapi segera setelah kapasitas burst habis, apa pun di atas 100% mengalami peristiwa kesalahan kapasitas throughput yang rendah. ------ ## Cara mengidentifikasi tabel Amazon Keyspaces yang kurang disediakan Untuk sebagian besar beban kerja, tabel dianggap kurang disediakan ketika terus-menerus mengkonsumsi lebih dari 80% dari kapasitas yang disediakan. [Kapasitas burst](throughput-bursting.md) adalah fitur Amazon Keyspaces yang memungkinkan pelanggan untuk sementara mengkonsumsi lebih RCUs/WCUs dari yang disediakan semula (lebih dari throughput yang disediakan per detik yang ditentukan untuk tabel). Kapasitas lonjakan diciptakan untuk menyerap peningkatan lalu lintas tiba-tiba karena peristiwa khusus atau lonjakan penggunaan. Kapasitas ledakan ini terbatas, untuk informasi lebih lanjut, lihat[Gunakan kapasitas burst secara efektif di Amazon Keyspaces](throughput-bursting.md). Segera setelah tidak digunakan RCUs dan WCUs habis, Anda dapat mengalami peristiwa kesalahan throughput berkapasitas rendah jika Anda mencoba mengkonsumsi lebih banyak kapasitas daripada yang disediakan. Ketika lalu lintas aplikasi Anda mendekati tingkat pemanfaatan 80%, risiko Anda mengalami peristiwa kesalahan throughput kapasitas rendah secara signifikan lebih tinggi. Aturan tingkat penggunaan 80% bervariasi berdasarkan musim data dan pertumbuhan lalu lintas Anda. Pertimbangkan skenario berikut: + Jika lalu lintas Anda **stabil** pada tingkat penggunaan \$190% selama 12 bulan terakhir, tabel Anda memiliki kapasitas yang tepat + Jika lalu lintas aplikasi Anda **tumbuh** sebesar 8% setiap bulan dalam waktu kurang dari 3 bulan, Anda akan mencapai 100% + Jika lalu lintas aplikasi Anda **tumbuh** sebesar 5% dalam waktu lebih dari 4 bulan, Anda masih akan mencapai 100% Hasil dari kueri di atas memberikan gambaran tingkat penggunaan Anda. Gunakan hasil tersebut sebagai panduan untuk mengevaluasi lebih lanjut metrik lain yang dapat membantu Anda meningkatkan kapasitas tabel sesuai kebutuhan (misalnya: tingkat pertumbuhan bulanan atau mingguan). Bekerjalah dengan tim operasi Anda untuk menentukan persentase yang baik untuk beban kerja dan tabel Anda. Ada skenario khusus di mana data miring ketika Anda menganalisisnya setiap hari atau mingguan. Misalnya, dengan aplikasi musiman yang memiliki lonjakan penggunaan selama jam kerja (tetapi kemudian turun menjadi hampir nol di luar jam kerja), Anda bisa mendapatkan keuntungan dari [penjadwalan auto-scaling aplikasi](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html), di mana Anda menentukan jam dalam sehari (dan hari dalam seminggu) untuk meningkatkan kapasitas yang disediakan, serta kapan harus menguranginya. Alih-alih bertujuan untuk kapasitas yang lebih tinggi sehingga Anda dapat menutupi jam sibuk, Anda juga dapat memanfaatkan konfigurasi [auto-scaling tabel Amazon Keyspaces](autoscaling.md) jika musim Anda kurang terasa. ## Cara mengidentifikasi tabel Amazon Keyspaces yang disediakan secara berlebihan Hasil kueri yang diperoleh dari skrip di atas memberikan titik data yang diperlukan untuk melakukan beberapa analisis awal. Jika set data Anda menyajikan nilai penggunaan yang lebih rendah dari 20% untuk beberapa interval, tabel Anda mungkin disediakan secara berlebihan. Untuk lebih menentukan apakah Anda perlu mengurangi jumlah WCUs dan RCUS, Anda harus meninjau kembali bacaan lain dalam interval. Jika tabel berisi beberapa interval penggunaan rendah, Anda bisa mendapatkan keuntungan dari menggunakan kebijakan Application Auto Scaling, baik dengan menjadwalkan Application Auto Scaling atau hanya dengan mengonfigurasi kebijakan Application Auto Scaling default untuk tabel yang didasarkan pada pemanfaatan. Jika Anda memiliki beban kerja dengan pemanfaatan rendah terhadap rasio throttle tinggi (**Max (ThrottleEvents) /Min () dalam intervalThrottleEvents)**, ini bisa terjadi ketika Anda memiliki beban kerja yang sangat runcing di mana lalu lintas meningkat secara signifikan pada hari-hari tertentu (atau waktu dalam sehari), tetapi sebaliknya secara konsisten rendah. Dalam skenario ini, mungkin bermanfaat untuk menggunakan [Application Auto Scaling terjadwal](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html).