Memecahkan masalah konfigurasi di Lambda

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.

Pengaturan konfigurasi fungsi Anda dapat berdampak pada kinerja dan perilaku fungsi Lambda secara keseluruhan. Ini mungkin tidak menyebabkan kesalahan fungsi yang sebenarnya, tetapi dapat menyebabkan batas waktu dan hasil yang tidak terduga.

Topik berikut memberikan saran pemecahan masalah untuk masalah umum yang mungkin Anda temui terkait dengan pengaturan konfigurasi fungsi Lambda.

Konfigurasi memori

Anda dapat mengonfigurasi fungsi Lambda untuk menggunakan antara 128 MB dan 10.240 MB memori. Secara default, fungsi apa pun yang dibuat di konsol diberi jumlah memori terkecil. Banyak fungsi Lambda berkinerja pada pengaturan terendah ini. Namun, jika Anda mengimpor pustaka kode besar atau menyelesaikan tugas intensif memori, 128 MB tidak cukup.

Jika fungsi Anda berjalan jauh lebih lambat dari yang diharapkan, langkah pertama adalah meningkatkan pengaturan memori. Untuk fungsi terikat memori, ini akan menyelesaikan kemacetan dan dapat meningkatkan kinerja fungsi Anda.

Konfigurasi terikat CPU

Untuk operasi komputasi intensif, jika fungsi Anda mengalami slower-than-expected kinerja, ini mungkin karena fungsi Anda terikat CPU. Dalam hal ini, kapasitas komputasi fungsi tidak dapat mengimbangi pekerjaan.

Meskipun Lambda tidak memungkinkan Anda untuk memodifikasi konfigurasi CPU secara langsung, CPU secara tidak langsung dikontrol melalui pengaturan memori. Layanan Lambda secara proporsional mengalokasikan lebih banyak CPU virtual saat Anda mengalokasikan lebih banyak memori. Pada memori 1, 8 GB, fungsi Lambda memiliki seluruh vCPU yang dialokasikan, dan di atas level ini ia memiliki akses ke lebih dari satu inti vCPU. Pada 10.240 MB, ia memiliki 6 v yang tersedia. CPUs Dengan kata lain, Anda dapat meningkatkan kinerja dengan meningkatkan alokasi memori, bahkan jika fungsi tersebut tidak menggunakan semua memori.

Timeout

Timeout untuk fungsi Lambda dapat diatur antara 1 dan 900 detik (15 menit). Secara default, konsol Lambda menyetel ini menjadi 3 detik. Nilai batas waktu adalah katup pengaman yang memastikan fungsi tidak berjalan tanpa batas waktu. Setelah nilai batas waktu tercapai, Lambda menghentikan pemanggilan fungsi.

Jika nilai batas waktu ditetapkan mendekati durasi rata-rata suatu fungsi, ini meningkatkan risiko bahwa fungsi tersebut akan habis secara tak terduga. Durasi suatu fungsi dapat bervariasi berdasarkan jumlah transfer dan pemrosesan data, dan latensi layanan apa pun yang berinteraksi dengan fungsi tersebut. Penyebab umum batas waktu meliputi:

Saat menguji aplikasi Anda, pastikan pengujian Anda secara akurat mencerminkan ukuran dan kuantitas data, serta nilai parameter yang realistis. Yang penting, gunakan kumpulan data di batas atas dari apa yang diharapkan secara wajar untuk beban kerja Anda.

Selain itu, terapkan batas batas atas dalam beban kerja Anda di mana pun praktis. Dalam contoh ini, aplikasi dapat menggunakan batas ukuran maksimum untuk setiap jenis file. Anda kemudian dapat menguji kinerja aplikasi Anda untuk berbagai ukuran file yang diharapkan, hingga dan termasuk batas maksimum.

Kebocoran memori di antara pemanggilan

Variabel global dan objek yang disimpan dalam fase INIT dari pemanggilan Lambda mempertahankan statusnya di antara pemanggilan hangat. Mereka sepenuhnya diatur ulang hanya ketika lingkungan eksekusi dijalankan untuk pertama kalinya (juga dikenal sebagai “start dingin”). Setiap variabel yang disimpan dalam handler dihancurkan ketika handler keluar. Praktik terbaik adalah menggunakan fase INIT untuk mengatur koneksi database, memuat pustaka, membuat cache, dan memuat aset yang tidak dapat diubah.

Saat Anda menggunakan pustaka pihak ketiga di beberapa pemanggilan di lingkungan eksekusi yang sama, periksa dokumentasi mereka untuk penggunaan di lingkungan komputasi tanpa server. Beberapa koneksi database dan pustaka logging dapat menyimpan hasil pemanggilan menengah dan data lainnya. Hal ini menyebabkan penggunaan memori perpustakaan ini tumbuh dengan pemanggilan hangat berikutnya. Jika ini masalahnya, Anda mungkin menemukan fungsi Lambda kehabisan memori, bahkan jika kode kustom Anda membuang variabel dengan benar.

Masalah ini memengaruhi pemanggilan yang terjadi di lingkungan eksekusi yang hangat. Misalnya, kode berikut membuat kebocoran memori antara pemanggilan. Fungsi Lambda mengkonsumsi memori tambahan dengan setiap pemanggilan dengan meningkatkan ukuran array global:

let a = []

exports.handler = async (event) => {
    a.push(Array(100000).fill(1))
}

Dikonfigurasi dengan memori 128 MB, setelah menjalankan fungsi ini 1000 kali, tab Pemantauan fungsi Lambda menunjukkan perubahan khas dalam pemanggilan, durasi, dan jumlah kesalahan saat kebocoran memori terjadi:

Setelah kesalahan, Lambda memulai ulang lingkungan eksekusi, yang menjelaskan mengapa ketiga grafik menunjukkan pengembalian ke keadaan semula. Memperluas CloudWatch metrik untuk durasi memberikan detail lebih lanjut untuk statistik durasi minimum, maksimum, dan rata-rata:

Untuk menemukan kesalahan yang dihasilkan di 1000 pemanggilan, Anda dapat menggunakan bahasa kueri CloudWatch Insights. Kueri berikut mengecualikan log informasi untuk melaporkan hanya kesalahan:

fields @timestamp, @message
| sort @timestamp desc
| filter @message not like 'EXTENSION'
| filter @message not like 'Lambda Insights'
| filter @message not like 'INFO' 
| filter @message not like 'REPORT'
| filter @message not like 'END'
| filter @message not like 'START'

Ketika dijalankan terhadap grup log untuk fungsi ini, ini menunjukkan bahwa batas waktu bertanggung jawab atas kesalahan periodik:

Hasil asinkron dikembalikan ke pemanggilan selanjutnya

Untuk kode fungsi yang menggunakan pola asinkron, hasil callback dari satu pemanggilan dapat dikembalikan dalam pemanggilan future. Contoh ini menggunakan Node.js, tetapi logika yang sama dapat diterapkan ke runtime lain menggunakan pola asinkron. Fungsi ini menggunakan sintaks callback tradisional di. JavaScript Ini memanggil fungsi asinkron dengan penghitung tambahan yang melacak jumlah pemanggilan:

let seqId = 0

exports.handler = async (event, context) => {
    console.log(`Starting: sequence Id=${++seqId}`)
    doWork(seqId, function(id) {
        console.log(`Work done: sequence Id=${id}`)
    })
}

function doWork(id, callback) {
    setTimeout(() => callback(id), 3000)
}

Ketika dipanggil beberapa kali berturut-turut, hasil callback terjadi dalam pemanggilan berikutnya:

Dalam JavaScript, panggilan balik asinkron ditangani dengan loop peristiwa. Runtime lain menggunakan mekanisme yang berbeda untuk menangani konkurensi. Ketika lingkungan eksekusi fungsi berakhir, Lambda membekukan lingkungan hingga pemanggilan berikutnya. Setelah dilanjutkan, JavaScript lanjutkan pemrosesan loop peristiwa, yang dalam hal ini menyertakan panggilan balik asinkron dari pemanggilan sebelumnya. Tanpa konteks ini, dapat muncul bahwa fungsi menjalankan kode tanpa alasan, dan mengembalikan data arbitrer. Faktanya, ini benar-benar artefak tentang bagaimana konkurensi runtime dan lingkungan eksekusi berinteraksi.

Ini menciptakan potensi data pribadi dari pemanggilan sebelumnya untuk muncul dalam pemanggilan berikutnya. Ada dua cara untuk mencegah atau mendeteksi perilaku ini. Pertama, JavaScript sediakan kata kunci async dan await untuk menyederhanakan pengembangan asinkron dan juga memaksa eksekusi kode untuk menunggu panggilan asinkron selesai. Fungsi di atas dapat ditulis ulang menggunakan pendekatan ini sebagai berikut:

let seqId = 0
exports.handler = async (event) => {
    console.log(`Starting: sequence Id=${++seqId}`)
    const result = await doWork(seqId)
    console.log(`Work done: sequence Id=${result}`)
}

function doWork(id) {
  return new Promise(resolve => {
    setTimeout(() => resolve(id), 4000)
  })
}

Menggunakan sintaks ini mencegah handler keluar sebelum fungsi asinkron selesai. Dalam kasus ini, jika callback membutuhkan waktu lebih lama dari batas waktu fungsi Lambda, fungsi akan memunculkan kesalahan, alih-alih mengembalikan hasil callback dalam pemanggilan selanjutnya:

Umumnya, Anda harus memastikan setiap proses latar belakang atau callback dalam kode selesai sebelum kode keluar. Jika hal ini tidak memungkinkan dalam kasus penggunaan Anda, Anda dapat menggunakan pengenal untuk memastikan bahwa callback milik pemanggilan saat ini. Untuk melakukan ini, Anda dapat menggunakan yang awsRequestIddisediakan oleh objek konteks. Dengan meneruskan nilai ini ke callback asinkron, Anda dapat membandingkan nilai yang diteruskan dengan nilai saat ini untuk mendeteksi apakah panggilan balik berasal dari pemanggilan lain:

let currentContext

exports.handler = async (event, context) => {
    console.log(`Starting: request id=$\{context.awsRequestId}`)
    currentContext = context

    doWork(context.awsRequestId, function(id) {
        if (id != currentContext.awsRequestId) {
            console.info(`This callback is from another invocation.`)
        }
    })

}

function doWork(id, callback) {
    setTimeout(() => callback(id), 3000)

}