Memahami siklus hidup lingkungan eksekusi Lambda

Lambda melakukan invokasi fungsi dalam lingkungan eksekusi, yang menyediakan lingkungan waktu pengoperasian yang aman dan terisolasi. Lingkungan eksekusi mengelola sumber daya yang diperlukan untuk menjalankan fungsi Anda. Lingkungan eksekusi juga menyediakan dukungan siklus hidup untuk waktu pengoperasian fungsi dan ekstensi eksternal terkait fungsi Anda.

Waktu pengoperasian fungsi tersebut berkomunikasi dengan Lambda menggunakan API Waktu Pengoperasian. Ekstensi berkomunikasi dengan Lambda menggunakan API Ekstensi. Ekstensi juga dapat menerima pesan log dan telemetri lain dari fungsi dengan menggunakan API Telemetri.

Saat membuat fungsi Lambda, Anda menentukan informasi konfigurasi, seperti jumlah memori yang tersedia dan waktu eksekusi maksimal yang diizinkan untuk fungsi Anda. Lambda menggunakan informasi ini untuk menyiapkan lingkungan eksekusi.

Waktu pengoperasian fungsi dan setiap ekstensi eksternal adalah proses yang berjalan di dalam lingkungan eksekusi. Izin, sumber daya, kredensial, dan variabel lingkungan dibagikan di antara fungsi dan ekstensi.

Siklus hidup lingkungan eksekusi Lambda

Setiap fase dimulai dengan kejadian yang dikirimkan Lambda ke waktu pengoperasian dan ke semua ekstensi terdaftar. Waktu pengoperasian dan setiap ekstensi menunjukkan penyelesaian dengan mengirimkan permintaan API Next. Lambda membekukan lingkungan eksekusi saat waktu pengoperasian dan setiap ekstensi telah selesai dan tidak ada kejadian yang tertunda.

Topik

• Fase inisialisasi

• Kegagalan selama fase Init

• Fase pemulihan (hanya Lambda SnapStart )

• Fase invokasi

• Kegagalan selama fase pemanggilan

• Fase pematian

Fase inisialisasi

Di fase Init, Lambda melakukan tiga tugas:

• Memulai semua ekstensi (Extension init)

• Melakukan bootstrap waktu pengoperasian (Runtime init)

• Menjalankan kode statis fungsi (Function init)

• Jalankan kait runtime sebelum pos pemeriksaan (hanya Lambda) SnapStart

Fase Init berakhir ketika waktu pengoperasian dan semua ekstensi menandakan bahwa ekstensi siap dengan mengirim permintaan API Next. Fase Init dibatasi 10 detik. Jika ketiga tugas tidak selesai dalam 10 detik, Lambda mencoba kembali Init fase pada saat pemanggilan fungsi pertama dengan batas waktu fungsi yang dikonfigurasi.

Ketika Lambda SnapStart diaktifkan, Init fase terjadi ketika Anda mempublikasikan versi fungsi. Lambda menyimpan snapshot memori dan status disk dari lingkungan eksekusi yang diinisialisasi, mempertahankan snapshot terenkripsi, dan menyimpannya dalam cache untuk akses latensi rendah. Jika Anda memiliki hook runtime sebelum-checkpoint, maka kode berjalan di akhir fase. Init

catatan

Batas waktu 10 detik tidak berlaku untuk fungsi yang menggunakan konkurensi yang disediakan atau. SnapStart Untuk konkurensi dan SnapStart fungsi yang disediakan, kode inisialisasi Anda dapat berjalan hingga 15 menit. Batas waktu adalah 130 detik atau batas waktu fungsi yang dikonfigurasi (maksimum 900 detik), mana yang lebih tinggi.

Saat Anda menggunakan konkurensi yang disediakan, Lambda menginisialisasi lingkungan eksekusi saat Anda mengonfigurasi pengaturan PC untuk suatu fungsi. Lambda juga memastikan bahwa lingkungan eksekusi yang diinisialisasi selalu tersedia sebelum pemanggilan. Anda mungkin melihat kesenjangan antara fase pemanggilan dan inisialisasi fungsi Anda. Bergantung pada runtime dan konfigurasi memori fungsi Anda, Anda juga dapat melihat latensi variabel pada pemanggilan pertama pada lingkungan eksekusi yang diinisialisasi.

Untuk fungsi yang menggunakan konkurensi sesuai permintaan, Lambda terkadang dapat menginisialisasi lingkungan eksekusi sebelum permintaan pemanggilan. Ketika ini terjadi, Anda juga dapat mengamati kesenjangan waktu antara fase inisialisasi dan pemanggilan fungsi Anda. Kami menyarankan Anda untuk tidak mengambil ketergantungan pada perilaku ini.

Kegagalan selama fase Init

Jika fungsi macet atau habis waktu selama Init fase, Lambda memancarkan informasi kesalahan di log. INIT_REPORT

contoh — Log INIT_REPORT untuk batas waktu

INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout

contoh — Log INIT_REPORT untuk kegagalan ekstensi

INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type: Extension.Crash

Jika Init fase berhasil, Lambda tidak memancarkan INIT_REPORT log kecuali SnapStartatau konkurensi yang disediakan diaktifkan. SnapStart dan fungsi konkurensi yang disediakan selalu memancarkan. INIT_REPORT Untuk informasi selengkapnya, lihat Pemantauan untuk Lambda SnapStart.

Fase pemulihan (hanya Lambda SnapStart )

Saat Anda pertama kali memanggil SnapStartfungsi dan saat fungsi ditingkatkan, Lambda melanjutkan lingkungan eksekusi baru dari snapshot yang bertahan alih-alih menginisialisasi fungsi dari awal. Jika Anda memiliki hook runtime after-restore, kode berjalan di akhir fase. Restore Anda dikenakan biaya untuk durasi kait runtime setelah pemulihan. Runtime harus dimuat dan kait runtime setelah pemulihan harus selesai dalam batas waktu tunggu (10 detik). Jika tidak, Anda akan mendapatkan SnapStartTimeoutException. Ketika Restore fase selesai, Lambda memanggil fungsi handler (the). Fase invokasi

Kegagalan selama fase Restore

Jika Restore fase gagal, Lambda memancarkan informasi kesalahan di log. RESTORE_REPORT

contoh — RESTORE_REPORT log untuk batas waktu

RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout

contoh — RESTORE_REPORT log untuk kegagalan hook runtime

RESTORE_REPORT Restore Duration: 1236.04 ms Status: error Error Type: Runtime.ExitError

Untuk informasi lebih lanjut tentang RESTORE_REPORT log, lihatPemantauan untuk Lambda SnapStart.

Fase invokasi

Saat fungsi Lambda diinvokasi untuk menanggapi permintaan API Next, Lambda mengirim kejadian Invoke ke waktu pengoperasian dan untuk setiap perpanjangan.

Pengaturan waktu habis fungsi membatasi durasi seluruh fase Invoke. Misalnya, jika Anda mengatur waktu fungsi habis sebagai 360 detik, fungsi dan semua ekstensi harus selesai dalam 360 detik. Perhatikan bahwa tidak ada fase pasca-invokasi yang independen. Durasi adalah jumlah semua waktu invokasi (waktu pengoperasian + ekstensi) dan tidak dihitung hingga fungsi dan semua ekstensi selesai dijalankan.

Fase invokasi berakhir ketika waktu pengoperasian dan semua ekstensi menandakan bahwa ekstensi selesai dengan mengirim permintaan API Next.

Kegagalan selama fase pemanggilan

Jika fungsi Lambda mengalami crash atau waktu habis selama fase Invoke, Lambda mengatur ulang lingkungan eksekusi. Diagram berikut menggambarkan perilaku lingkungan eksekusi Lambda ketika ada kegagalan pemanggilan:

Pada diagram sebelumnya:

• Fase pertama adalah fase INIT, yang berjalan tanpa kesalahan.

• Fase kedua adalah fase INVOKE, yang berjalan tanpa kesalahan.

• Pada titik tertentu, misalkan fungsi Anda mengalami kegagalan pemanggilan (seperti batas waktu fungsi atau kesalahan runtime). Fase ketiga, berlabel INVOKE WITH ERROR, menggambarkan skenario ini. Ketika ini terjadi, layanan Lambda melakukan reset. Reset berperilaku seperti kejadian Shutdown. Pertama, Lambda mematikan runtime, lalu mengirimkan Shutdown acara ke setiap ekstensi eksternal terdaftar. Kejadian ini mencakup alasan untuk pematian. Jika lingkungan ini digunakan untuk pemanggilan baru, Lambda menginisialisasi ulang ekstensi dan runtime bersama dengan pemanggilan berikutnya.

  Perhatikan bahwa reset Lambda tidak menghapus konten /tmp direktori sebelum fase init berikutnya. Perilaku ini konsisten dengan fase shutdown reguler.

  catatan

  AWS saat ini menerapkan perubahan pada layanan Lambda. Karena perubahan ini, Anda mungkin melihat perbedaan kecil antara struktur dan konten pesan log sistem dan segmen pelacakan yang dipancarkan oleh fungsi Lambda yang berbeda di Anda. Akun AWS

  Jika konfigurasi log sistem fungsi Anda disetel ke teks biasa, perubahan ini memengaruhi pesan log yang ditangkap di CloudWatch Log saat fungsi Anda mengalami kegagalan pemanggilan. Contoh berikut menunjukkan output log dalam format lama dan baru.

  Perubahan ini akan diterapkan selama beberapa minggu mendatang, dan semua fungsi di semua Wilayah AWS kecuali China GovCloud dan wilayah akan bertransisi untuk menggunakan pesan log format baru dan segmen pelacakan.

  contoh CloudWatch Keluaran log log (runtime atau ekstensi crash) - gaya lama

  START RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Version: $LATEST
  RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Error: Runtime exited without providing a reason
  Runtime.ExitError
  END RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1
  REPORT RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Duration: 933.59 ms Billed Duration: 934 ms Memory Size: 128 MB Max Memory Used: 9 MB

  contoh CloudWatch Keluaran log log (batas waktu fungsi) - gaya lama

  START RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Version: $LATEST
  2024-03-04T17:22:38.033Z b70435cc-261c-4438-b9b6-efe4c8f04b21 Task timed out after 3.00 seconds
  END RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21
  REPORT RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Duration: 3004.92 ms Billed Duration: 3000 ms Memory Size: 128 MB Max Memory Used: 33 MB Init Duration: 111.23 ms

  Format baru untuk CloudWatch log mencakup status bidang tambahan di REPORT baris. Dalam kasus runtime atau ekstensi crash, REPORT baris juga menyertakan bidangErrorType.

  contoh CloudWatch Keluaran log log (runtime atau ekstensi crash) - gaya baru

  START RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Version: $LATEST
  END RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd
  REPORT RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Duration: 133.61 ms Billed Duration: 133 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 80.00 ms Status: error Error Type: Runtime.ExitError

  contoh CloudWatch Keluaran log log (batas waktu fungsi) - gaya baru

  START RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Version: $LATEST
  END RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda
  REPORT RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Duration: 3016.78 ms Billed Duration: 3016 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 84.00 ms Status: timeout

• Fase keempat mewakili fase INVOKE segera setelah kegagalan pemanggilan. Di sini, Lambda menginisialisasi lingkungan lagi dengan menjalankan kembali fase INIT. Ini disebut init yang ditekan. Ketika input yang ditekan terjadi, Lambda tidak secara eksplisit melaporkan fase INIT tambahan di Log. CloudWatch Sebagai gantinya, Anda mungkin memperhatikan bahwa durasi di baris LAPORAN menyertakan durasi INIT tambahan+durasi INVOKE. Misalnya, Anda melihat log berikut CloudWatch:

  2022-12-20T01:00:00.000-08:00 START RequestId: XXX Version: $LATEST 
  2022-12-20T01:00:02.500-08:00 END RequestId: XXX 
  2022-12-20T01:00:02.500-08:00 REPORT RequestId: XXX Duration: 3022.91 ms 
  Billed Duration: 3000 ms Memory Size: 512 MB Max Memory Used: 157 MB

  Dalam contoh ini, perbedaan antara stempel waktu REPORT dan START adalah 2,5 detik. Ini tidak cocok dengan durasi yang dilaporkan 3022,91 milldetik, karena tidak memperhitungkan INIT ekstra (init yang ditekan) yang dilakukan Lambda. Dalam contoh ini, Anda dapat menyimpulkan bahwa fase INVOKE yang sebenarnya membutuhkan waktu 2,5 detik.

  Untuk wawasan lebih lanjut tentang perilaku ini, Anda dapat menggunakanMengakses data telemetri real-time untuk ekstensi menggunakan API Telemetri. API Telemetri memancarkanINIT_START,INIT_RUNTIME_DONE, dan INIT_REPORT peristiwa dengan input yang ditekan phase=invoke setiap kali terjadi di antara fase pemanggilan.

• Fase kelima mewakili fase SHUTDOWN, yang berjalan tanpa kesalahan.

Fase pematian

Ketika Lambda akan mematikan runtime, ia mengirimkan Shutdown acara ke setiap ekstensi eksternal yang terdaftar. Ekstensi dapat menggunakan waktu ini untuk tugas pembersihan akhir. Kejadian Shutdown adalah respons terhadap permintaan API Next.

Durasi: Keseluruhan fase Shutdown dibatasi hingga 2 detik. Jika waktu pengoperasian atau ekstensi tidak merespons, Lambda menghentikannya melalui sinyal (SIGKILL).

Setelah fungsi dan semua ekstensi selesai, Lambda mempertahankan lingkungan eksekusi selama beberapa waktu untuk mengantisipasi invokasi fungsi lain. Namun, Lambda menghentikan lingkungan eksekusi setiap beberapa jam untuk memungkinkan pembaruan dan pemeliharaan runtime — bahkan untuk fungsi yang dipanggil terus menerus. Anda tidak boleh berasumsi bahwa lingkungan eksekusi akan bertahan tanpa batas waktu. Untuk informasi selengkapnya, lihat Menerapkan tanpa kewarganegaraan dalam fungsi.

Saat fungsinya diinvokasi lagi, Lambda mencairkan lingkungan untuk digunakan kembali. Menggunakan kembali lingkungan eksekusi memiliki implikasi berikut:

• Objek yang dinyatakan di luar metode penangan fungsi tetap diinisialisasi, memberikan pengoptimalan tambahan ketika fungsi diinvokasi lagi. Misalnya, jika fungsi Lambda Anda menetapkan koneksi database, alih-alih menetapkan kembali koneksi, koneksi asli digunakan dalam invokasi berikutnya. Kami menyarankan Anda menambahkan logika dalam kode untuk memeriksa apakah ada koneksi sebelum membuat yang baru.

• Setiap lingkungan eksekusi menyediakan antara 512 MB dan 10.240 MB, dalam peningkatan 1-MB, ruang disk dalam direktori. /tmp Isi direktori tetap ada ketika lingkungan eksekusi dibekukan, menyediakan cache sementara yang dapat digunakan untuk beberapa invokasi. Anda dapat menambahkan kode tambahan untuk memeriksa apakah cache memiliki data yang Anda simpan. Untuk informasi lebih lanjut tentang batas ukuran deployment, lihat Kuota Lambda.

• Proses latar belakang atau panggilan balik yang diinisialisasi fungsi Lambda Anda dan tidak selesai ketika fungsi berakhir akan dilanjutkan jika Lambda menggunakan kembali lingkungan eksekusi. Pastikan setiap proses latar belakang atau panggilan balik dalam kode Anda selesai sebelum kode tersebut ditutup.

Mulai dingin dan latensi

Ketika Lambda menerima permintaan untuk menjalankan fungsi melalui API Lambda, layanan terlebih dahulu menyiapkan lingkungan eksekusi. Selama fase inisialisasi ini, layanan mengunduh kode Anda, memulai lingkungan, dan menjalankan kode inisialisasi apa pun di luar penangan utama. Akhirnya, Lambda menjalankan kode handler.

Dalam diagram ini, dua langkah pertama mengunduh kode dan mengatur lingkungan sering disebut sebagai “awal yang dingin”. Anda tidak dikenakan biaya untuk kali ini, tetapi itu menambah latensi ke durasi pemanggilan Anda secara keseluruhan.

Setelah pemanggilan selesai, lingkungan eksekusi dibekukan. Untuk meningkatkan manajemen dan kinerja sumber daya, Lambda mempertahankan lingkungan eksekusi untuk jangka waktu tertentu. Selama waktu ini, jika permintaan lain tiba untuk fungsi yang sama, Lambda dapat menggunakan kembali lingkungan. Permintaan kedua ini biasanya selesai lebih cepat, karena lingkungan eksekusi sudah sepenuhnya diatur. Ini disebut “awal yang hangat”.

Permulaan dingin biasanya terjadi di bawah 1% dari doa. Durasi awal dingin bervariasi dari di bawah 100 ms hingga lebih dari 1 detik. Secara umum, start dingin biasanya lebih umum dalam fungsi pengembangan dan pengujian daripada beban kerja produksi. Ini karena fungsi pengembangan dan pengujian biasanya lebih jarang dipanggil.

Mengurangi dingin dimulai dengan Provisioned Concurrency

Jika Anda membutuhkan waktu mulai fungsi yang dapat diprediksi untuk beban kerja Anda, konkurensi yang disediakan adalah solusi yang disarankan untuk memastikan latensi serendah mungkin. Fitur ini melakukan pra-inisialisasi lingkungan eksekusi, mengurangi start dingin.

Misalnya, fungsi dengan konkurensi 6 yang disediakan memiliki 6 lingkungan eksekusi yang telah dipanaskan sebelumnya.

Mengoptimalkan inisialisasi statis

Inisialisasi statis terjadi sebelum kode handler mulai berjalan dalam suatu fungsi. Ini adalah kode inisialisasi yang Anda berikan, yang berada di luar penangan utama. Kode ini sering digunakan untuk mengimpor pustaka dan dependensi, mengatur konfigurasi, dan menginisialisasi koneksi ke layanan lain.

Contoh Python berikut menunjukkan mengimpor, dan mengonfigurasi modul, dan membuat klien Amazon S3 selama fase inisialisasi, sebelum fungsi berjalan selama pemanggilan. lambda_handler

import os
import json
import cv2
import logging
import boto3

s3 = boto3.client('s3')
logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):

  # Handler logic...

Kontributor latensi terbesar sebelum eksekusi fungsi berasal dari kode inisialisasi. Kode ini berjalan ketika lingkungan eksekusi baru dibuat untuk pertama kalinya. Kode inisialisasi tidak dijalankan lagi jika pemanggilan menggunakan lingkungan eksekusi yang hangat. Faktor-faktor yang mempengaruhi latensi kode inisialisasi meliputi:

• Ukuran paket fungsi, dalam hal pustaka dan dependensi yang diimpor, dan lapisan Lambda.

• Jumlah kode dan inisialisasi bekerja.

• Kinerja perpustakaan dan layanan lainnya dalam menyiapkan koneksi dan sumber daya lainnya.

Ada sejumlah langkah yang dapat diambil pengembang untuk mengoptimalkan latensi inisialisasi statis. Jika suatu fungsi memiliki banyak objek dan koneksi, Anda mungkin dapat merancang ulang satu fungsi menjadi beberapa fungsi khusus. Ini secara individual lebih kecil dan masing-masing memiliki kode inisialisasi yang lebih sedikit.

Penting bahwa fungsi hanya mengimpor pustaka dan dependensi yang mereka butuhkan. Misalnya, jika Anda hanya menggunakan Amazon DynamoDB di AWS SDK, Anda dapat meminta layanan individual alih-alih seluruh SDK. Bandingkan tiga contoh berikut:

// Instead of const AWS = require('aws-sdk'), use:
const DynamoDB = require('aws-sdk/clients/dynamodb')

// Instead of const AWSXRay = require('aws-xray-sdk'), use:
const AWSXRay = require('aws-xray-sdk-core')

// Instead of const AWS = AWSXRay.captureAWS(require('aws-sdk')), use:
const dynamodb = new DynamoDB.DocumentClient()
AWSXRay.captureAWSClient(dynamodb.service)

Inisialisasi statis juga sering merupakan tempat terbaik untuk membuka koneksi database untuk memungkinkan fungsi menggunakan kembali koneksi melalui beberapa pemanggilan ke lingkungan eksekusi yang sama. Namun, Anda mungkin memiliki sejumlah besar objek yang hanya digunakan di jalur eksekusi tertentu dalam fungsi Anda. Dalam hal ini, Anda dapat dengan malas memuat variabel dalam lingkup global untuk mengurangi durasi inisialisasi statis.

Hindari variabel global untuk informasi spesifik konteks. Jika fungsi Anda memiliki variabel global yang digunakan hanya untuk masa pakai pemanggilan tunggal dan disetel ulang untuk pemanggilan berikutnya, gunakan cakupan variabel yang bersifat lokal ke handler. Ini tidak hanya mencegah kebocoran variabel global di seluruh pemanggilan, tetapi juga meningkatkan kinerja inisialisasi statis.