Memecahkan Masalah Instans Terkelola Lambda - AWS Lambda
Masalah pelambatan dan penskalaanMasalah konkurensiMasalah kinerjaMasalah penyedia kapasitasMasalah pemantauan dan observabilitasMendapatkan bantuan tambahanLangkah selanjutnya

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

Memecahkan Masalah Instans Terkelola Lambda

Masalah pelambatan dan penskalaan

Tingkat kesalahan tinggi selama peningkatan skala

Masalah: Anda mengalami kesalahan pelambatan (HTTP 429) ketika lalu lintas meningkat dengan cepat.

Penyebab: Instans Terkelola Lambda menskalakan secara asinkron berdasarkan pemanfaatan sumber daya CPU dan saturasi multi-konkurensi. Jika lalu lintas Anda lebih dari dua kali lipat dalam 5 menit, Anda mungkin melihat pembatasan saat Lambda meningkatkan instance dan lingkungan eksekusi untuk memenuhi permintaan.

Solusi:

  • Sesuaikan pemanfaatan sumber daya target: Jika beban kerja Anda memiliki pola lalu lintas yang dapat diprediksi, tetapkan pemanfaatan sumber daya target yang lebih rendah untuk mempertahankan ruang kepala tambahan untuk ledakan lalu lintas.

  • Kapasitas pra-hangat: Untuk peningkatan lalu lintas yang direncanakan, secara bertahap tingkatkan lalu lintas selama periode yang lebih lama untuk memungkinkan penskalaan mengimbangi.

  • Metrik penskalaan monitor: Lacak metrik kesalahan throttle untuk memahami alasan masalah throttle dan penskalaan kapasitas.

  • Tinjau konfigurasi fungsi: Pastikan memori fungsi dan pengaturan vCPU Anda mendukung eksekusi multi-bersamaan. Meningkatkan memori fungsi atau alokasi vCPU jika diperlukan.

Penskalaan lambat

Masalah: Contoh membutuhkan waktu lama untuk menurunkan skala setelah lalu lintas menurun.

Penyebab: Instans Terkelola Lambda menurunkan skala secara bertahap untuk menjaga ketersediaan dan menghindari perubahan kapasitas cepat yang dapat memengaruhi kinerja.

Solusi:

Ini adalah perilaku yang diharapkan. Lambda menurunkan instance secara konservatif untuk memastikan stabilitas. Pantau CloudWatch metrik Anda untuk melacak jumlah instans yang sedang berjalan.

Masalah konkurensi

Lingkungan eksekusi dengan throttle pengalaman konkurensi rendah

Masalah: Fungsi Anda mengalami pelambatan meskipun memiliki kapasitas yang tersedia.

Penyebab: Lingkungan eksekusi dengan konkurensi maksimum yang sangat rendah mungkin mengalami kesulitan penskalaan secara efektif. Instans Terkelola Lambda dirancang untuk aplikasi multi-konkuren.

Solusi:

  • Tingkatkan konkurensi maksimum: Jika pemanggilan fungsi Anda menggunakan CPU yang sangat sedikit, tingkatkan pengaturan konkurensi maksimum hingga 64 per vCPU.

  • Optimalkan kode fungsi: Tinjau kode fungsi Anda untuk mengurangi konsumsi CPU per pemanggilan, memungkinkan konkurensi yang lebih tinggi.

  • Sesuaikan memori fungsi dan vCPU: Pastikan fungsi Anda memiliki sumber daya yang cukup untuk menangani beberapa pemanggilan bersamaan.

Masalah keamanan utas (runtime Java)

Masalah: Fungsi Java Anda menghasilkan hasil yang salah atau mengalami kondisi balapan yang sedang dimuat.

Penyebab: Beberapa utas mengeksekusi metode handler secara bersamaan, dan status bersama tidak aman untuk utas.

Solusi:

  • Gunakan AtomicInteger atau AtomicLong untuk penghitung alih-alih tipe primitif

  • Ganti HashMap dengan ConcurrentHashMap

  • Gunakan Collections.synchronizedList() untuk membungkus ArrayList

  • Gunakan ThreadLocal untuk status permintaan khusus

  • Akses jejak IDs dari objek Konteks Lambda, bukan variabel lingkungan

Untuk panduan terperinci, lihat dokumentasi Java runtime untuk Lambda Managed Instances.

Masalah isolasi status (runtime Node.js)

Masalah: Fungsi Node.js Anda mengembalikan data dari permintaan yang berbeda atau mengalami kerusakan data.

Penyebab: Variabel global dibagikan di seluruh pemanggilan bersamaan pada utas pekerja yang sama. Ketika operasi async menghasilkan kontrol, pemanggilan lain dapat mengubah status bersama.

Solusi:

  • Instal dan gunakan @aws/lambda-invoke-store untuk semua status khusus permintaan

  • Ganti variabel global dengan InvokeStore.set() dan InvokeStore.get()

  • Gunakan nama file unik /tmp dengan permintaan IDs

  • Akses jejak IDs menggunakan InvokeStore.getXRayTraceId() alih-alih variabel lingkungan

Untuk panduan terperinci, lihat runtime Node.js untuk dokumentasi Instans Terkelola Lambda.

Konflik file (runtime Python)

Masalah: Fungsi Python Anda membaca data yang salah dari file di. /tmp

Penyebab: Beberapa proses berbagi /tmp direktori. Menulis bersamaan ke file yang sama dapat menyebabkan kerusakan data.

Solusi:

  • Gunakan nama file unik dengan permintaan IDs: /tmp/request_{context.request_id}.txt

  • Gunakan penguncian file fcntl.flock() untuk file bersama

  • Bersihkan file sementara dengan os.remove() setelah digunakan

Untuk panduan terperinci, lihat runtime Python untuk dokumentasi Instans Terkelola Lambda.

Masalah kinerja

Pemanfaatan memori tinggi

Masalah: Fungsi Anda mengalami pemanfaatan memori tinggi atau out-of-memory kesalahan.

Penyebab: Setiap permintaan bersamaan dalam Python berjalan dalam proses terpisah dengan ruang memorinya sendiri. Total penggunaan memori sama dengan memori per proses dikalikan dengan proses bersamaan.

Solusi:

  • Pantau MemoryUtilization metrik di CloudWatch

  • Kurangi MaxConcurrency pengaturan jika penggunaan memori mendekati batas memori fungsi

  • Meningkatkan alokasi memori fungsi untuk mendukung konkurensi yang lebih tinggi

  • Optimalkan penggunaan memori dengan memuat data sesuai permintaan alih-alih selama inisialisasi

Kinerja yang tidak konsisten

Masalah: Kinerja fungsi bervariasi secara signifikan antara pemanggilan.

Penyebab: Lambda dapat memilih jenis instans yang berbeda berdasarkan ketersediaan, atau fungsi mungkin berjalan pada instance dengan ketersediaan sumber daya yang bervariasi.

Solusi:

  • Tentukan jenis instans yang diizinkan: Jika Anda memiliki persyaratan kinerja tertentu, konfigurasikan jenis instans yang diizinkan di penyedia kapasitas untuk membatasi jenis instans yang dapat dipilih Lambda.

  • Memantau metrik tingkat instans: Lacak CPUUtilization dan MemoryUtilization pada tingkat penyedia kapasitas untuk mengidentifikasi kendala sumber daya.

  • Tinjau metrik kapasitas: Periksa vCPUAvailable dan MemoryAvailable untuk memastikan sumber daya yang cukup tersedia di instans Anda.

Masalah penyedia kapasitas

Versi fungsi gagal menjadi AKTIF

Masalah: Versi fungsi Anda tetap dalam status tertunda setelah dipublikasikan.

Penyebab: Lambda meluncurkan Instans Terkelola dan memulai lingkungan eksekusi. Proses ini membutuhkan waktu, terutama untuk versi fungsi pertama pada penyedia kapasitas baru.

Solusi:

Tunggu Lambda menyelesaikan proses inisialisasi. Lambda meluncurkan tiga instance secara default untuk ketahanan AZ dan memulai tiga lingkungan eksekusi sebelum menandai versi fungsi Anda ACTIVE. Ini biasanya memerlukan waktu beberapa menit.

Tidak dapat menghapus penyedia kapasitas

Masalah: Anda menerima kesalahan saat mencoba menghapus penyedia kapasitas.

Penyebab: Anda tidak dapat menghapus penyedia kapasitas yang memiliki versi fungsi yang melekat padanya.

Solusi:

  1. Identifikasi semua versi fungsi menggunakan penyedia kapasitas dengan ListFunctionVersionsByCapacityProvider API.

  2. Hapus atau perbarui versi fungsi tersebut untuk menghapus asosiasi penyedia kapasitas.

  3. Coba lagi menghapus penyedia kapasitas.

Pesan kesalahan umum selama penerbitan fungsi

Masalah: Anda menemukan pesan kesalahan umum seperti “Kesalahan internal terjadi selama penerbitan” saat menerbitkan fungsi.

Solusi:

  • Periksa izin IAM: Pastikan Anda memiliki lambda:PassCapacityProvider izin untuk penyedia kapasitas yang Anda coba gunakan.

  • Verifikasi konfigurasi penyedia kapasitas: Konfirmasikan bahwa penyedia kapasitas Anda dalam status AKTIF menggunakan GetCapacityProvider API.

  • Tinjau konfigurasi VPC: Pastikan subnet dan grup keamanan yang ditentukan dalam penyedia kapasitas Anda dikonfigurasi dan diakses dengan benar.

  • Periksa AWS CloudTrail log: Tinjau CloudTrail log untuk informasi kesalahan terperinci tentang operasi yang gagal.

Masalah pemantauan dan observabilitas

CloudWatch Metrik tidak ada

Masalah: Anda tidak melihat metrik yang diharapkan CloudWatch untuk penyedia kapasitas atau fungsi Anda.

Penyebab: Metrik diterbitkan pada interval 5 menit. Penyedia kapasitas atau fungsi baru mungkin tidak memiliki metrik yang tersedia segera.

Solusi:

Tunggu setidaknya 5-10 menit setelah menerbitkan versi fungsi sebelum mengharapkan metrik muncul. CloudWatch Pastikan Anda melihat namespace (AWS/Lambda) dan dimensi (CapacityProviderName,FunctionName, atauInstanceType) yang benar.

Tidak dapat menemukan CloudWatch log

Masalah: Fungsi Anda berhasil dijalankan, tetapi Anda tidak dapat menemukan log di CloudWatch Log.

Penyebab: Instans Terkelola Lambda berjalan di VPC Anda dan memerlukan konektivitas jaringan untuk mengirim log ke Log. CloudWatch Tanpa konfigurasi konektivitas VPC yang tepat, fungsi Anda tidak dapat mencapai titik akhir layanan CloudWatch Log.

Solusi:

Konfigurasikan konektivitas VPC untuk mengaktifkan fungsi Anda mengirim log ke CloudWatch Log. Anda memiliki tiga opsi:

Opsi 1: Titik akhir VPC untuk CloudWatch Log (direkomendasikan untuk produksi)

  1. Buka konsol VPC Amazon di console.aws.amazon.com/vpc/.

  2. Di panel navigasi, pilih Titik Akhir.

  3. Pilih Buat Titik Akhir.

  4. Untuk kategori Layanan, pilih AWS layanan.

  5. Untuk nama Layanan, pilih com.amazonaws.region.logs (ganti region dengan AWS Wilayah Anda).

  6. Untuk VPC, pilih VPC yang digunakan oleh penyedia kapasitas Anda.

  7. Untuk Subnet, pilih subnet tempat Anda ingin membuat antarmuka jaringan titik akhir. Untuk ketersediaan tinggi, pilih subnet di beberapa Availability Zone.

  8. Untuk grup Keamanan, pilih grup keamanan yang mengizinkan lalu lintas HTTPS masuk (port 443) dari grup keamanan fungsi Anda.

  9. Aktifkan DNS Pribadi untuk titik akhir.

  10. Pilih Buat titik akhir.

Opsi 2: Subnet publik dengan gateway internet

Jika penyedia kapasitas Anda menggunakan subnet publik, pastikan:

  1. Gateway internet terpasang ke VPC Anda

  2. Tabel rute merutekan 0.0.0.0/0 lalu lintas ke gateway internet

  3. Grup keamanan memungkinkan lalu lintas HTTPS keluar pada port 443

Opsi 3: Subnet pribadi dengan gateway NAT

Jika penyedia kapasitas Anda menggunakan subnet pribadi, pastikan:

  1. Gateway NAT ada di subnet publik

  2. Tabel rute subnet pribadi merutekan 0.0.0.0/0 lalu lintas ke gateway NAT

  3. Tabel rute subnet publik merutekan 0.0.0.0/0 lalu lintas ke gateway internet

  4. Grup keamanan memungkinkan lalu lintas HTTPS keluar pada port 443

Untuk panduan terperinci tentang opsi konektivitas VPC, lihat Konektivitas VPC untuk Instans Terkelola Lambda.

Kesulitan mengkorelasikan log dari permintaan bersamaan

Masalah: Log dari permintaan yang berbeda disisipkan, sehingga sulit untuk melacak permintaan individu.

Penyebab: Log interleaving diharapkan dan perilaku standar dalam sistem multi-konkuren.

Solusi:

  • Gunakan logging terstruktur dengan format JSON: Sertakan ID permintaan di semua pernyataan log

  • Java: Gunakan Log4j dengan ThreadContext untuk secara otomatis menyertakan ID permintaan

  • Node.js: Gunakan console.log() dengan format JSON dan sertakan InvokeStore.getRequestId()

  • Python: Gunakan modul logging standar dengan format JSON dan sertakan context.request_id

Untuk panduan terperinci, lihat halaman dokumentasi khusus runtime.

Mendapatkan bantuan tambahan

Jika Anda terus mengalami masalah setelah mencoba solusi ini:

  1. Tinjau CloudWatch metrik: Periksa penyedia kapasitas dan metrik lingkungan eksekusi untuk mengidentifikasi kendala sumber daya atau masalah penskalaan.

  2. Periksa AWS CloudTrail log: Tinjau CloudTrail log untuk informasi terperinci tentang panggilan dan kesalahan API.

  3. Hubungi AWS Support: Jika Anda tidak dapat menyelesaikan masalah, hubungi AWS Support dengan detail tentang konfigurasi penyedia kapasitas, konfigurasi fungsi, dan pesan galat spesifik yang Anda temui.

Langkah selanjutnya