Evaluasi kapasitas yang disediakan untuk penyediaan ukuran yang tepat - Amazon DynamoDB

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

Evaluasi kapasitas yang disediakan untuk penyediaan ukuran yang tepat

Bagian ini memberikan gambaran umum tentang cara mengevaluasi apakah Anda memiliki ukuran penyediaan yang tepat pada tabel DynamoDB Anda. Seiring berkembangnya beban kerja Anda, Anda harus memodifikasi prosedur operasional dengan tepat, terutama ketika tabel DynamoDB Anda dikonfigurasi dalam mode yang disediakan dan Anda memiliki risiko untuk menyediakan tabel secara berlebihan atau kurang.

Prosedur yang dijelaskan di bawah memerlukan informasi statistik yang harus diambil dari tabel DynamoDB yang mendukung aplikasi produksi Anda. Untuk memahami perilaku aplikasi Anda, Anda harus menentukan periode waktu yang cukup signifikan untuk mengambil data musiman dari 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, tabel DynamoDB dapat mengonfigurasi Unit Kapasitas Baca (RCU) dan Unit Kapasitas Tulis (WCU) secara terpisah. Jika tabel Anda memiliki Indeks Sekunder Global (GSI) yang dikonfigurasi, Anda perlu menentukan throughput yang akan digunakannya, yang juga tidak bergantung pada RCU dan WCU dari tabel dasar.

catatan

Indeks Sekunder Lokal (LSI) menggunakan kapasitas dari tabel dasar.

Cara mengambil metrik penggunaan pada tabel DynamoDB Anda

Untuk mengevaluasi tabel dan kapasitas GSI, pantau CloudWatch metrik berikut dan pilih dimensi yang sesuai untuk mengambil informasi tabel atau GSI:

Unit Kapasitas Baca Unit Kapasitas Tulis

ConsumedReadCapacityUnits

ConsumedWriteCapacityUnits

ProvisionedReadCapacityUnits

ProvisionedWriteCapacityUnits

ReadThrottleEvents

WriteThrottleEvents

Anda dapat melakukan ini baik melalui AWS CLI atau AWS Management Console.

AWS CLI

Sebelum kita mengambil metrik konsumsi tabel, kita harus mulai dengan menangkap beberapa titik data historis menggunakan API. CloudWatch

Mulailah dengan membuat dua file: write-calc.json dan read-calc.json. File-file ini akan mewakili penghitungan untuk tabel atau GSI. Anda harus memperbarui beberapa bidang, seperti yang ditunjukkan pada tabel di bawah ini, agar sesuai dengan lingkungan Anda.

Nama Bidang Definisi Contoh
<table-name> Nama tabel yang akan dianalisis SampleTable
<period> Jangka waktu yang akan Anda gunakan untuk mengevaluasi pemanfaatan target, berdasarkan detik Untuk periode 1 jam, Anda harus menentukan: 3600
<start-time> Awal interval evaluasi Anda, ditentukan dalam format ISO8601 2022-02-21T23:00:00
<end-time> Akhir interval evaluasi Anda, ditentukan dalam format ISO8601 2022-02-22T06:00:00

File penghitungan tulis akan mengambil jumlah WCU yang disediakan dan terpakai dalam rentang tanggal tertentu. Ini juga akan menghasilkan persentase penggunaan yang akan digunakan untuk analisis. Konten lengkap file write-calc.json akan seperti berikut:

{ "MetricDataQueries": [ { "Id": "provisionedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/DynamoDB", "MetricName": "ProvisionedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "<table-name>" } ] }, "Period": <period>, "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/DynamoDB", "MetricName": "ConsumedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "<table-name>"" } ] }, "Period": <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": "<start-time>", "EndTime": "<ent-time>", "ScanBy": "TimestampDescending", "MaxDatapoints": 24 }

File penghitungan baca menggunakan file serupa. File ini akan mengambil berapa banyak RCU yang disediakan dan terpakai selama jangka waktu untuk rentang tanggal tertentu. Konten file read-calc.json akan seperti berikut:

{ "MetricDataQueries": [ { "Id": "provisionedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/DynamoDB", "MetricName": "ProvisionedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "<table-name>" } ] }, "Period": <period>, "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/DynamoDB", "MetricName": "ConsumedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "<table-name>" } ] }, "Period": <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": "<start-time>", "EndTime": "<end-time>", "ScanBy": "TimestampDescending", "MaxDatapoints": 24 }

Setelah membuat file, Anda dapat mulai mengambil data penggunaan.

  1. Untuk mengambil data penggunaan tulis, keluarkan perintah berikut:

    aws cloudwatch get-metric-data --cli-input-json file://write-calc.json
  2. Untuk mengambil data penggunaan baca, keluarkan perintah berikut:

    aws cloudwatch get-metric-data --cli-input-json file://read-calc.json

Hasil untuk kedua kueri akan menjadi serangkaian titik data dalam format JSON yang akan digunakan untuk analisis. Hasil Anda akan tergantung pada jumlah titik data yang Anda tentukan, periode, dan data beban kerja spesifik Anda sendiri. Hasilnya akan seperti 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 menentukan jangka waktu pendek dan rentang waktu yang lama, Anda mungkin perlu memodifikasi MaxDatapoints yang secara default ditetapkan ke 24 dalam skrip. Ini mewakili satu titik data per jam dan 24 per hari.

AWS Management Console
  1. Masuk ke AWS Management Console dan arahkan ke halaman CloudWatch layanan. Pilih yang sesuai Wilayah AWS jika perlu.

  2. Temukan bagian Metrik di bilah navigasi kiri dan pilih Semua metrik.

  3. Ini akan membuka dasbor dengan dua panel. Panel atas akan menampilkan grafik, dan panel bawah akan menampilkan metrik yang ingin Anda grafik. Pilih DynamoDB.

  4. Pilih Metrik Tabel. Ini akan menampilkan tabel di Wilayah Anda saat ini.

  5. Gunakan kotak Pencarian untuk mencari nama tabel Anda dan 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.

  6. Pilih tab Graphed metrics (2) untuk memodifikasi rumus. Secara default, CloudWatch memilih fungsi statistik Rata-rata untuk grafik.

    Metrik grafik yang dipilih dan Rata-rata sebagai fungsi statistik default.
  7. 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 kali memilih fungsi Persentase:

  8. Pada titik ini, Anda memiliki empat metrik di menu bawah. Mari kita kerjakan penghitungan ConsumedWriteCapacityUnits. Agar konsisten, kita perlu mencocokkan nama untuk yang kita gunakan di AWS CLI bagian ini. Klik m1 ID dan ubah nilai ini menjadi consumedWCU.

  9. Ubah statistik dari Average menjadi Sum. Tindakan ini secara otomatis akan membuat metrik lain yang disebut ANOMALY_DETECTION_BAND. Untuk cakupan prosedur ini, kita dapat mengabaikannya dengan menghapus centang pada ad1 metric yang baru dibuat.

  10. Ulangi langkah 8 untuk mengganti nama m2 ID menjadi ProvisionedWCU. Biarkan statistik diatur ke Average.

  11. Pilih label Expression1 lalu perbarui nilainya menjadi m1 dan labelnya menjadi Consumed WCU.

    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_DETECTION_BAND, tetapi kita dapat mengabaikannya untuk cakupan prosedur ini.

  12. Anda sekarang memiliki dua grafik: satu yang menunjukkan WCU yang sediakan pada tabel dan satu lagi yang menunjukkan WCU yang digunakan. Bentuk grafiknya mungkin berbeda dengan gambar di bawah ini, tetapi Anda dapat menggunakannya sebagai referensi:

  13. Perbarui rumus persentase dengan memilih grafik Expression2 (e2). Ganti nama label dan ID menjadi utilizationPercentage. Ganti nama rumus agar sesuai dengan 100*(m1/provisionedWCU).

  14. Hapus centang dari semua metrik kecuali utilizationPercentage untuk memvisualisasikan pola penggunaan Anda. Interval default diatur ke 1 menit, tetapi Anda dapat mengubahnya sesuai kebutuhan.

Berikut adalah tampilan periode waktu yang lebih lama serta periode yang lebih dari 1 jam. Anda dapat melihat ada beberapa interval yang penggunaannya lebih tinggi dari 100%, tetapi beban kerja khusus ini memiliki interval yang lebih panjang dengan penggunaan nol.

Pada titik ini, Anda mungkin mendapatkan hasil yang berbeda dari gambar dalam contoh ini. Itu semua tergantung pada data dari beban kerja Anda. Interval dengan penggunaan lebih dari 100% rentan terhadap peristiwa throttling. DynamoDB menawarkan kapasitas lonjakan, tetapi segera setelah kapasitas lonjakan dilakukan, apa pun di atas 100% akan dibatasi.

Cara mengidentifikasi tabel DynamoDB yang kurang tersedia

Untuk sebagian besar beban kerja, tabel dianggap kurang tersedia jika terus-menerus menggunakan lebih dari 80% kapasitas yang disediakan.

Kapasitas lonjakan adalah fitur DynamoDB yang memungkinkan pelanggan menggunakan lebih banyak RCU/WCU daripada yang disediakan sebelumnya (lebih dari throughput yang disediakan per detik yang ditentukan dalam tabel) untuk sementara waktu. Kapasitas lonjakan diciptakan untuk menyerap peningkatan lalu lintas tiba-tiba karena peristiwa khusus atau lonjakan penggunaan. Kapasitas lonjakan ini tidak bertahan selamanya. Segera setelah RCU dan WCU yang tidak terpakai habis, Anda akan mengalami throttling jika mencoba menggunakan lebih banyak kapasitas daripada yang disediakan. Ketika lalu lintas aplikasi Anda mendekati tingkat penggunaan 80%, risiko throttling Anda jauh 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 ~90% 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, datanya miring ketika dianalisis setiap hari atau setiap minggu. 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 dengan menjadwalkan penskalaan otomatis di mana Anda menentukan jam dalam sehari (dan hari dalam seminggu) untuk meningkatkan kapasitas yang disediakan dan kapan harus menguranginya. Alih-alih bertujuan untuk kapasitas yang lebih tinggi sehingga Anda dapat menutupi jam sibuk, Anda juga dapat memanfaatkan konfigurasi penskalaan otomatis tabel DynamoDB jika musim Anda kurang terasa.

catatan

Saat membuat konfigurasi penskalaan otomatis DynamoDB untuk tabel dasar Anda, jangan lupa menyertakan konfigurasi lain untuk GSI yang terkait dengan tabel tersebut.

Cara mengidentifikasi tabel DynamoDB 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 menentukan lebih lanjut apakah Anda perlu mengurangi jumlah WCU dan RCU, Anda harus meninjau kembali pembacaan lain dalam interval tersebut.

Ketika tabel Anda berisi beberapa interval penggunaan rendah, Anda benar-benar dapat mengambil manfaat dari menggunakan kebijakan penskalaan otomatis, baik dengan menjadwalkan penskalaan otomatis atau hanya mengonfigurasi kebijakan penskalaan otomatis 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 banyak selama beberapa hari (atau jam), tetapi secara umum lalu lintas secara konsisten rendah. Dalam skenario ini, mungkin bermanfaat untuk menggunakan penskalaan otomatis terjadwal.