Evaluasi penggunaan aliran DynamoDB Anda

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

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

Bagian ini memberikan gambaran umum tentang cara mengevaluasi penggunaan DynamoDB Streams. Ada pola penggunaan tertentu yang tidak optimal untuk DynamoDB, dan pola tersebut memberikan ruang untuk pengoptimalan baik dari sudut pandang performa maupun biaya.

Anda memiliki dua integrasi streaming asli untuk kasus penggunaan berdasarkan peristiwa dan streaming:

Halaman ini hanya akan fokus pada strategi pengoptimalan biaya untuk opsi ini. Jika Anda ingin mengetahui cara memilih di antara kedua opsi tersebut, lihat Opsi streaming untuk tangkapan data perubahan.

Mengoptimalkan biaya untuk DynamoDB Streams

Seperti yang disebutkan di halaman harga untuk DynamoDB Streams, terlepas dari mode kapasitas throughput tabel, DynamoDB membebankan biaya pada jumlah permintaan baca yang dibuat terhadap DynamoDB Stream tabel. Permintaan baca yang dibuat terhadap DynamoDB Stream berbeda dari permintaan baca yang dibuat terhadap tabel DynamoDB.

Setiap permintaan baca dalam aliran berbentuk panggilan API GetRecords yang dapat mengembalikan hingga 1000 catatan atau catatan senilai 1 MB sebagai respons, mana saja yang dicapai terlebih dahulu. Tak satu pun dari DynamoDB APIs Stream lainnya yang dibebankan dan DynamoDB Streams tidak dikenakan biaya karena idle. Dengan kata lain, jika tidak ada permintaan baca yang dibuat ke DynamoDB Stream, mengaktifkan DynamoDB Stream pada tabel tidak akan dikenakan biaya.

Berikut adalah beberapa aplikasi konsumen untuk DynamoDB Streams:

Permintaan baca yang dibuat oleh konsumen DynamoDB Streams AWS berbasis Lambda gratis, sedangkan panggilan yang dilakukan oleh konsumen jenis lain dikenakan biaya. Setiap bulan, 2.500.000 permintaan baca pertama yang dibuat oleh konsumen non-Lambda juga tidak dikenakan biaya. Ini berlaku untuk semua permintaan baca yang dibuat ke DynamoDB Streams apa pun di AWS Akun untuk setiap Wilayah. AWS

Memantau penggunaan DynamoDB Streams

Biaya DynamoDB Streams pada konsol penagihan dikelompokkan bersama untuk semua DynamoDB Streams di seluruh Wilayah dalam Akun. AWS AWS Saat ini, penandaan DynamoDB Streams tidak didukung, sehingga tanda alokasi biaya tidak dapat digunakan untuk mengidentifikasi biaya mendetail untuk DynamoDB Streams. Volume panggilan GetRecords dapat diperoleh di tingkat DynamoDB Stream untuk menghitung biaya per aliran. Volume diwakili oleh SuccessfulRequestLatency metrik DynamoDB Stream dan CloudWatch statistiknya. SampleCount Metrik ini juga akan mencakup GetRecords panggilan yang dibuat oleh tabel global untuk melakukan replikasi yang sedang berlangsung serta panggilan yang dilakukan oleh konsumen AWS Lambda, yang keduanya tidak dikenakan biaya. Untuk informasi tentang CloudWatch metrik lain yang diterbitkan oleh DynamoDB Streams, lihat. Dimensi dan Metrik DynamoDB

Menggunakan AWS Lambda sebagai konsumen

Mengevaluasi jika menggunakan fungsi AWS Lambda sebagai konsumen untuk DynamoDB Streams layak karena dapat menghilangkan biaya yang terkait dengan pembacaan dari DynamoDB Stream. Di sisi lain, aplikasi konsumen berbasis SDK atau Adaptor DynamoDB Streams Kinesis akan dikenakan biaya pada jumlah panggilan GetRecords yang dilakukan terhadap DynamoDB Stream.

Invokasi fungsi Lambda akan dikenakan biaya berdasarkan harga Lambda standar, tetapi DynamoDB Streams tidak membebankan biaya apa pun. Lambda akan melakukan polling pada pecahan di DynamoDB Stream Anda untuk catatan dengan tingkat dasar sebanyak 4 kali per detik. Setelah catatan tersedia, Lambda menginvokasi fungsi Anda dan menunggu hasilnya. Jika pemrosesan berhasil, Lambda melanjutkan polling sampai menerima lebih banyak catatan.

Menyetel aplikasi konsumen berbasis Adaptor DynamoDB Streams Kinesis

Karena permintaan baca yang dibuat oleh konsumen berbasis non-Lambda dikenakan biaya untuk DynamoDB Streams, penting untuk menemukan keseimbangan antara persyaratan mendekati waktu nyata dan frekuensi aplikasi konsumen harus melakukan polling terhadap DynamoDB Stream.

Frekuensi polling pada DynamoDB Streams menggunakan aplikasi berbasis Adaptor DynamoDB Streams Kinesis ditentukan oleh konfigurasi nilai idleTimeBetweenReadsInMillis. Parameter ini menentukan waktu tunggu konsumen dalam milidetik sebelum memproses pecahan jika panggilan GetRecords sebelumnya yang dilakukan ke pecahan yang sama tidak menghasilkan catatan apa pun. Secara default, nilai untuk parameter ini adalah 1000 ms. Jika pemrosesan mendekati waktu nyata tidak diperlukan, parameter ini dapat ditingkatkan agar aplikasi konsumen melakukan lebih sedikit panggilan GetRecords dan mengoptimalkan panggilan DynamoDB Streams.

Mengoptimalkan biaya untuk Kinesis Data Streams

Jika Kinesis Data Stream ditetapkan sebagai tujuan untuk mengirimkan peristiwa pengambilan data perubahan untuk tabel DynamoDB, Kinesis Data Stream mungkin memerlukan manajemen ukuran terpisah yang akan memengaruhi biaya keseluruhan. DynamoDB mengenakan biaya dalam hal Change Data capture Units CDUs () di mana setiap unit terdiri dari ukuran item DynamoDB 1 KB yang dicoba oleh layanan DynamoDB ke Kinesis Data Stream tujuan.

Selain biaya oleh layanan DynamoDB, biaya Kinesis Data Stream standar akan dikenakan. Seperti yang disebutkan di halaman harga, harga layanan berbeda berdasarkan mode kapasitas - disediakan dan sesuai permintaan, yang berbeda dari mode kapasitas tabel DynamoDB dan ditentukan pengguna. Pada tingkat tinggi, Kinesis Data Streams membebankan tarif per jam berdasarkan mode kapasitas, serta data yang diserap ke dalam aliran oleh layanan DynamoDB. Mungkin ada biaya tambahan seperti pengambilan data (untuk mode sesuai permintaan), retensi data yang diperpanjang (melebihi default 24 jam), dan peningkatan pengambilan konsumen fan-out tergantung pada konfigurasi pengguna untuk Kinesis Data Stream.

Memantau penggunaan Kinesis Data Streams

Kinesis Data Streams untuk DynamoDB menerbitkan metrik dari DynamoDB selain Metrik Aliran Data Kinesis standar. CloudWatch Ada kemungkinan bahwa Put upaya oleh layanan DynamoDB dibatasi oleh layanan Kinesis karena kapasitas Kinesis Data Streams tidak mencukupi, atau oleh komponen dependen seperti layanan yang dapat dikonfigurasi untuk mengenkripsi data Kinesis Data Stream saat AWS KMS istirahat.

Untuk mempelajari lebih lanjut tentang CloudWatch metrik yang diterbitkan oleh layanan DynamoDB untuk Kinesis Data Stream, lihat. Memantau pengambilan data perubahan dengan Kinesis Data Streams Untuk menghindari biaya tambahan percobaan ulang layanan karena throttling, penting untuk menentukan ukuran Kinesis Data Stream yang tepat dalam Mode yang Disediakan.

Memilih mode kapasitas yang tepat untuk Kinesis Data Streams

Kinesis Data Streams didukung dalam dua mode kapasitas — mode disediakan dan mode sesuai permintaan.

Praktik terbaik untuk mengoptimalkan biaya adalah dengan mengevaluasi apakah tabel DynamoDB yang terkait dengan Kinesis Data Stream memiliki pola lalu lintas yang dapat diprediksi yang dapat memanfaatkan mode yang disediakan untuk Kinesis Data Streams. Jika beban kerja baru, Anda dapat menggunakan mode sesuai permintaan untuk Kinesis Data Streams selama beberapa minggu awal, meninjau CloudWatch metrik untuk memahami pola lalu lintas, lalu mengalihkan Stream yang sama ke mode yang disediakan berdasarkan sifat beban kerja. Dalam kasus mode yang disediakan, estimasi jumlah pecahan dapat dilakukan dengan mengikuti pertimbangan manajemen pecahan untuk Kinesis Data Streams.

Evaluasi aplikasi konsumen Anda menggunakan Kinesis Data Streams untuk DynamoDB

Karena Kinesis Data Streams tidak membebankan biaya pada jumlah panggilan GetRecords seperti DynamoDB Streams, aplikasi konsumen dapat membuat panggilan sebanyak mungkin, selama frekuensinya berada di bawah batas throttling untuk GetRecords. Terkait mode sesuai permintaan untuk Kinesis Data Streams, pembacaan data dikenakan biaya per GB. Untuk mode yang disediakan pada Kinesis Data Streams, pembacaan tidak dikenakan biaya jika data berumur kurang dari 7 hari. Dalam kasus fungsi Lambda sebagai konsumen Kinesis Data Streams, Lambda melakukan polling pada setiap pecahan di Kinesis Stream Anda untuk catatan dengan tingkat dasar sebanyak sekali per detik.

Strategi pengoptimalan biaya untuk kedua jenis penggunaan Streams

Pemfilteran acara untuk konsumen AWS Lambda

Pemfilteran peristiwa Lambda memungkinkan Anda untuk membuang peristiwa berdasarkan kriteria filter agar tidak tersedia dalam batch invokasi fungsi Lambda. Ini mengoptimalkan biaya Lambda untuk memproses atau membuang catatan aliran yang tidak diinginkan dalam logika fungsi konsumen. Untuk mempelajari selengkapnya tentang mengonfigurasi pemfilteran peristiwa dan menulis kriteria pemfilteran Anda, lihat Pemfilteran peristiwa Lambda.

Tuning AWS Lambda konsumen

Biaya dapat lebih dioptimalkan dengan menyetel parameter konfigurasi Lambda seperti meningkatkan BatchSize untuk memproses lebih banyak per invokasi, mengaktifkan BisectBatchOnFunctionError untuk mencegah pemrosesan duplikat (yang menimbulkan biaya tambahan), dan mengatur MaximumRetryAttempts agar tidak mengalami terlalu banyak percobaan ulang. Secara default, invokasi Lambda konsumen yang gagal akan dicoba ulang tanpa batas waktu hingga catatan kedaluwarsa dari aliran, yaitu sekitar 24 jam untuk DynamoDB Streams dan dapat dikonfigurasi mulai dari 24 jam hingga 1 tahun untuk Kinesis Data Streams. Opsi konfigurasi Lambda tambahan yang tersedia termasuk yang disebutkan di atas untuk konsumen DynamoDB Stream dapat dilihat di panduan developer AWS Lambda.