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

Memecahkan masalah pemetaan sumber peristiwa di Lambda

Masalah di Lambda yang berhubungan dengan pemetaan sumber peristiwa bisa lebih kompleks karena melibatkan debugging di beberapa layanan. Selain itu, perilaku sumber peristiwa dapat berbeda berdasarkan sumber peristiwa yang tepat yang digunakan. Bagian ini mencantumkan masalah umum yang melibatkan pemetaan sumber peristiwa, dan memberikan panduan tentang cara mengidentifikasi dan memecahkan masalah tersebut.

Mengidentifikasi dan mengelola pelambatan

Di Lambda, throttling terjadi ketika Anda mencapai batas konkurensi fungsi atau akun Anda. Pertimbangkan contoh berikut, di mana ada fungsi Lambda yang membaca pesan dari antrian Amazon SQS. Fungsi Lambda ini mensimulasikan pemanggilan 30 detik, dan memiliki ukuran batch 1. Ini berarti bahwa fungsi hanya memproses 1 pesan setiap 30 detik:

const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms))

exports.handler = async (event) => {
    await doWork(30000)

}

Dengan waktu pemanggilan yang begitu lama, pesan mulai masuk dalam antrian lebih cepat daripada yang diproses. Jika konkurensi tanpa syarat akun Anda adalah 100, Lambda akan menskalakan hingga 100 eksekusi bersamaan, lalu pelambatan terjadi. Anda dapat melihat pola ini di CloudWatch metrik untuk fungsi:

CloudWatch metrik untuk fungsi tidak menunjukkan kesalahan, tetapi grafik eksekusi bersamaan menunjukkan bahwa konkurensi maksimum 100 tercapai. Akibatnya, grafik Throttles menunjukkan pelambatan di tempatnya.

Anda dapat mendeteksi pelambatan dengan CloudWatch alarm, dan mengatur alarm kapan saja metrik pelambatan untuk suatu fungsi lebih besar dari 0. Setelah Anda mengidentifikasi masalah pelambatan, Anda memiliki beberapa opsi untuk penyelesaian:

Kesalahan dalam fungsi pemrosesan

Jika fungsi pemrosesan melempar kesalahan, Lambda mengembalikan pesan ke antrian SQS. Lambda mencegah fungsi Anda dari penskalaan untuk mencegah kesalahan dalam skala. Metrik SQS berikut CloudWatch menunjukkan masalah dengan pemrosesan antrian:

Secara khusus, usia pesan tertua dan jumlah pesan yang terlihat meningkat, sementara tidak ada pesan yang dihapus. Antrian terus bertambah tetapi pesan tidak diproses. Met CloudWatch rik untuk pemrosesan fungsi Lambda juga menunjukkan bahwa ada masalah:

Metrik jumlah kesalahan tidak nol dan terus bertambah, sementara eksekusi bersamaan telah berkurang dan pelambatan telah berhenti. Ini menunjukkan bahwa Lambda telah berhenti meningkatkan fungsi Anda karena kesalahan. CloudWatch Log untuk fungsi memberikan rincian jenis kesalahan.

Anda dapat mengatasi masalah ini dengan mengidentifikasi fungsi yang menyebabkan kesalahan, kemudian menemukan dan menyelesaikan kesalahan. Setelah Anda memperbaiki kesalahan dan menerapkan kode fungsi baru, CloudWatch metrik akan menunjukkan pemulihan pemrosesan:

Di sini, metrik jumlah kesalahan turun ke nol dan metrik tingkat keberhasilan kembali ke 100%. Lambda mulai meningkatkan fungsi lagi, seperti yang ditunjukkan pada grafik eksekusi bersamaan.

Mengidentifikasi dan menangani tekanan balik

Jika produsen acara secara konsisten menghasilkan pesan untuk antrian SQS lebih cepat daripada fungsi Lambda dapat memprosesnya, tekanan balik terjadi. Dalam hal ini, pemantauan SQS harus menunjukkan usia pesan tertua yang tumbuh secara linier, bersama dengan perkiraan jumlah pesan yang terlihat. Anda dapat mendeteksi tekanan balik dalam antrian menggunakan CloudWatch alarm.

Langkah-langkah untuk mengatasi tekanan balik tergantung pada beban kerja Anda. Jika tujuan utamanya adalah untuk meningkatkan kemampuan pemrosesan dan throughput oleh fungsi Lambda, Anda memiliki beberapa opsi: