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

Praktik terbaik untuk Instans Terkelola Lambda

Konfigurasi penyedia kapasitas

Pisahkan penyedia kapasitas berdasarkan tingkat kepercayaan. Buat penyedia kapasitas yang berbeda untuk beban kerja dengan persyaratan keamanan yang berbeda. Semua Fungsi Acara Lambda yang ditetapkan untuk penyedia kapasitas yang sama harus saling dipercaya, karena penyedia kapasitas berfungsi sebagai batas keamanan.

Gunakan nama deskriptif. Sebutkan penyedia kapasitas untuk secara jelas menunjukkan tujuan penggunaan dan tingkat kepercayaan mereka (misalnya,production-trusted,dev-sandbox). Ini membantu tim memahami tujuan dan postur keamanan masing-masing penyedia kapasitas.

Gunakan beberapa Availability Zone. Tentukan subnet di beberapa Availability Zone saat membuat penyedia kapasitas. Lambda meluncurkan tiga instans secara default untuk ketahanan AZ, memastikan ketersediaan tinggi untuk fungsi Anda.

Pemilihan tipe instans

Biarkan Lambda memilih jenis instance. Secara default, Lambda memilih jenis instans terbaik untuk beban kerja Anda. Sebaiknya izinkan Instans Terkelola Lambda memilih jenis instans untuk Anda, karena membatasi jumlah kemungkinan jenis instans dapat mengakibatkan ketersediaan lebih rendah.

Tentukan jenis instance untuk persyaratan tertentu. Jika Anda memiliki persyaratan perangkat keras tertentu, setel jenis instans yang diizinkan ke daftar instance yang kompatibel. Contoh:

Konfigurasi fungsi

Pilih pengaturan memori dan vCPU yang sesuai. Pilih konfigurasi memori dan vCPU yang mendukung eksekusi multi-konkuren fungsi Anda. Ukuran fungsi minimum yang didukung adalah 2GB dan 1 vCPU.

Konfigurasikan konkurensi maksimum dengan tepat. Lambda memilih default yang masuk akal untuk konkurensi maksimum yang menyeimbangkan konsumsi sumber daya dan throughput. Sesuaikan pengaturan ini berdasarkan penggunaan sumber daya fungsi Anda:

Perhatikan bahwa lingkungan eksekusi dengan konkurensi yang sangat rendah mungkin mengalami throttle dan kesulitan penskalaan.

Long-running fungsi

Fungsi pada Instans AWS Lambda Terkelola dapat berjalan hingga 90 menit (5.400 detik) per pemanggilan untuk pemanggilan asinkron dan untuk pemanggilan pemetaan sumber peristiwa, kecuali pemetaan sumber peristiwa Amazon MQ dan Amazon DocumentDB, yang tetap dibatasi hingga 15 menit. Pemanggilan sinkron dan fase inisialisasi fungsi juga tetap terbatas hingga 15 menit. Untuk informasi selengkapnya tentang menyetel batas waktu, lihat Mengonfigurasi batas waktu fungsi Lambda. Karena fungsi Anda dapat berjalan lebih lama, tinjau pertimbangan berikut untuk komponen yang bersifat fana, seperti koneksi jaringan dan kredensil.

Mengakomodasi batas waktu koneksi idle. Pastikan batas waktu koneksi idle pada layanan hilir seperti Amazon RDS, ElastiCache Amazon, dan API eksternal mengakomodasi durasi fungsi penuh. Jika fungsi Anda merutekan lalu lintas melalui gateway NAT, kirim paket keep-alive untuk mencegah koneksi idle terputus setelah batas waktu idle gateway NAT 350 detik.

Hormati nilai DNS TTL. Hormati nilai TTL DNS saat Anda menyelesaikan nama host eksternal. AWS SDK menangani ini secara otomatis, tetapi klien HTTP khusus mungkin menyimpan resolusi DNS di luar TTL mereka.

Segarkan kredensi sementara. Jika fungsi Anda memperoleh kredensi atau token sementara, verifikasi bahwa token tersebut tetap valid selama durasi eksekusi penuh, atau segarkan kembali di latar belakang.

Desain untuk idempotensi. Lambda tidak menjamin pemrosesan yang tepat sekali. Saat fungsi berjalan lebih lama, jendela untuk percobaan ulang dan pengiriman duplikat meningkat. Gunakan Powertools untuk AWS Lambda untuk mengimplementasikan idempotensi untuk operasi seperti pembayaran atau penulisan database, sehingga mereka menghasilkan hasil yang sama bahkan jika mereka berjalan lebih dari sekali. Jika Anda menggunakan fungsi tahan lama Lambda, langkah-langkah memiliki semantik eksekusi paling sedikit sekali: SDK eksekusi yang tahan lama melewatkan langkah-langkah yang telah selesai selama pemutaran ulang, tetapi langkah-langkah yang gagal sebelum checkpointing dapat berjalan lagi. Anda dapat menggunakan nama eksekusi sebagai kunci idempotensi.

Tune pemetaan sumber acara untuk pemrosesan yang lebih lama. Untuk Amazon SQS, setel batas waktu visibilitas antrian setidaknya enam kali batas waktu fungsi, sehingga Lambda memiliki cukup waktu untuk mencoba kembali batch jika fungsi dibatasi. Lambda memvalidasi ini saat Anda membuat pemetaan sumber peristiwa, tetapi tidak mencegah perubahan selanjutnya pada antrian atau fungsi yang membuat ketidakcocokan. Untuk Amazon Kinesis Data Streams dan Amazon DynamoDB Streams, konfigurasikan jendela batching maksimum dan faktor paralelisasi untuk memperhitungkan waktu pemrosesan yang lebih lama per batch, dan aktifkan pelaporan kegagalan batch sebagian sehingga hanya catatan gagal yang dicoba ulang, bukan seluruh batch.

Konfigurasi penskalaan

Tetapkan pemanfaatan sumber daya target yang tepat. Secara default, Lambda mempertahankan ruang kepala yang cukup untuk lalu lintas Anda berlipat ganda dalam waktu 5 menit tanpa throttle. Sesuaikan ini berdasarkan karakteristik beban kerja Anda:

Rencanakan pertumbuhan lalu lintas. Jika lalu lintas Anda lebih dari dua kali lipat dalam 5 menit, Anda mungkin melihat throttle saat Lambda meningkatkan instance dan lingkungan eksekusi. Rancang aplikasi Anda untuk menangani potensi pelambatan selama periode peningkatan skala yang cepat.

Keamanan

Terapkan hak istimewa paling sedikit untuk PassCapacityProvider izin. Berikan lambda:PassCapacityProvider izin hanya untuk penyedia kapasitas yang diperlukan. Gunakan izin tingkat sumber daya untuk membatasi penyedia kapasitas mana yang dapat ditetapkan pengguna ke fungsi.

Pantau penggunaan penyedia kapasitas. Gunakan AWS CloudTrail untuk memantau tugas penyedia kapasitas dan pola akses. Ini membantu mengidentifikasi upaya akses yang tidak sah dan memastikan kepatuhan terhadap kebijakan keamanan.

Pisahkan beban kerja yang tidak tepercaya. Jangan mengandalkan kontainer untuk isolasi keamanan antara beban kerja yang tidak tepercaya. Gunakan penyedia kapasitas yang berbeda untuk memisahkan beban kerja yang tidak saling dipercaya.

Optimalisasi biaya

Gunakan opsi harga EC2. Manfaatkan EC2 Savings Plans dan Instans Cadangan untuk mengurangi biaya. Opsi harga ini berlaku untuk komputasi EC2 yang mendasarinya (biaya manajemen 15% tidak didiskon).

Optimalkan untuk beban kerja kondisi mapan. Instans Terkelola Lambda paling cocok untuk fungsi kondisi mapan dengan lalu lintas volume tinggi yang dapat diprediksi. Untuk pola lalu lintas yang meledak, Lambda (default) mungkin lebih hemat biaya.

Pantau pemanfaatan sumber daya. Lacak CloudWatch metrik untuk memahami pemanfaatan CPU dan memori. Sesuaikan alokasi memori fungsi dan pemilihan jenis instans berdasarkan pola penggunaan aktual untuk mengoptimalkan biaya.

Pemantauan dan observabilitas

Pantau metrik penyedia kapasitas. Melacak metrik tingkat penyedia kapasitas termasuk CPUUutilization,, VCPUAvailable MemoryUtilization, dan MemoryAvailable untuk memverifikasi sumber daya yang memadai tersedia untuk beban kerja Anda.

Pantau metrik lingkungan eksekusi. Lacak metrik tingkat lingkungan eksekusi termasuk ExecutionEnvironmentConcurrency dan ExecutionEnvironmentConcurrencyLimit untuk memahami perilaku penskalaan dan mengidentifikasi potensi pelambatan.

Mengatur CloudWatch alarm. Buat CloudWatch alarm untuk metrik utama untuk mengidentifikasi masalah secara proaktif:

Language-specific pertimbangan

Ikuti praktik terbaik khusus bahasa. Setiap bahasa pemrograman menangani multi-konkurensi secara berbeda. Tinjau panduan khusus bahasa untuk rekomendasi terperinci:

Uji keamanan benang dan masalah konkurensi. Sebelum menerapkan ke produksi, uji fungsi Anda secara menyeluruh untuk masalah keselamatan benang, kondisi balapan, dan isolasi status yang tepat di bawah beban bersamaan.

Langkah selanjutnya