Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Coba ulang untuk fungsi tahan lama Lambda
Fungsi tahan lama menyediakan kemampuan coba ulang otomatis yang membuat aplikasi Anda tahan terhadap kegagalan sementara. SDK menangani percobaan ulang pada dua tingkat: percobaan ulang langkah untuk kegagalan logika bisnis dan percobaan ulang backend untuk kegagalan infrastruktur.
Langkah percobaan ulang
Ketika pengecualian yang tidak tertangkap terjadi dalam satu langkah, SDK secara otomatis mencoba ulang langkah tersebut berdasarkan strategi coba ulang yang dikonfigurasi. Langkah percobaan ulang adalah operasi yang diperiksa yang memungkinkan SDK menangguhkan eksekusi dan melanjutkan nanti tanpa kehilangan kemajuan.
Perilaku coba lagi langkah
Tabel berikut menjelaskan cara SDK menangani pengecualian dalam langkah-langkah:
| Skenario | Apa yang terjadi | Dampak pengukuran |
|---|---|---|
| Pengecualian selangkah dengan upaya coba ulang yang tersisa | SDK membuat pos pemeriksaan untuk percobaan ulang dan menangguhkan fungsi. Pada pemanggilan berikutnya, langkah tersebut mencoba lagi dengan penundaan backoff yang dikonfigurasi. | 1 operasi+kesalahan ukuran muatan |
| Pengecualian dalam langkah tanpa upaya percobaan ulang yang tersisa | Langkah gagal dan melempar pengecualian. Jika kode handler Anda tidak menangkap pengecualian ini, seluruh eksekusi gagal. | 1 operasi+kesalahan ukuran muatan |
Ketika suatu langkah perlu dicoba lagi, SDK memeriksa status coba lagi dan keluar dari pemanggilan Lambda jika tidak ada pekerjaan lain yang berjalan. Hal ini memungkinkan SDK untuk mengimplementasikan penundaan mundur tanpa menghabiskan sumber daya komputasi. Fungsi dilanjutkan secara otomatis setelah periode backoff.
Mengkonfigurasi strategi coba ulang langkah
Konfigurasikan strategi coba ulang untuk mengontrol cara langkah-langkah menangani kegagalan. Anda dapat menentukan upaya maksimum, interval mundur, dan kondisi untuk mencoba lagi. Untuk referensi lengkap bantuan strategi coba ulang, preset, dan strategi khusus, lihat Percobaan ulang di dokumentasi SDK Eksekusi Tahan Lama.
Pengecualian di luar langkah
Ketika pengecualian yang tidak tertangkap terjadi dalam kode handler Anda tetapi di luar langkah apa pun, SDK menandai eksekusi sebagai gagal. Ini memastikan kesalahan dalam logika aplikasi Anda ditangkap dan dilaporkan dengan benar.
| Skenario | Apa yang terjadi | Dampak pengukuran |
|---|---|---|
| Pengecualian dalam kode handler di luar langkah apa pun | SDK menandai eksekusi sebagai GAGAL dan mengembalikan kesalahan. Pengecualian tidak dicoba ulang secara otomatis. | Kesalahan ukuran muatan |
Untuk mengaktifkan coba ulang otomatis untuk kode rawan kesalahan, bungkus dalam satu langkah dengan strategi coba lagi. Langkah-langkah menyediakan percobaan ulang otomatis dengan backoff yang dapat dikonfigurasi, sementara kode di luar langkah segera gagal.
Percobaan ulang pemanggilan
Percobaan ulang tingkat pemanggilan ditangani secara berbeda tergantung pada bagaimana fungsi tahan lama Lambda dicoba untuk dipanggil. Tabel berikut menjelaskan bagaimana jenis pemanggilan yang berbeda dapat mempengaruhi percobaan ulang tingkat pemanggilan.
| Jenis pemanggilan | Apa yang terjadi |
|---|---|
| Invokasi sinkron | Lambda tidak secara otomatis mencoba lagi pemanggilan pada kesalahan selama eksekusi fungsi yang tahan lama. Percobaan ulang pada kegagalan pemanggilan bergantung pada sumber pemanggilan sinkron. Misalnya, menggunakan AWS SDK, InternalFailure dan secara default ThrottlingException dicoba ulang secara otomatis. |
| Invokasi asinkron | Jika eksekusi fungsi tahan lama gagal (misalnya, ia memasuki status FAILED, STOPPED, atau TIMED_OUT), Lambda tidak mencoba lagi eksekusi. Ini berbeda dari fungsi Lambda standar, di mana Lambda mencoba ulang fungsi pada kegagalan pemanggilan asinkron. Peng MaximumRetryAttempts aturan untuk pemanggilan asinkron tidak berlaku untuk eksekusi tahan lama. Jika Anda mengonfigurasi antrean huruf mati (DLQ) untuk fungsi tersebut, Lambda mengirimkan peristiwa pemicu ke DLQ. |
| ESM (Pemetaan Sumber Peristiwa) | Lambda secara default mencoba ulang seluruh batch sampai berhasil. Untuk sumber aliran (DynamoDB dan Kinesis), Anda dapat mengonfigurasi jumlah maksimum Lambda mencoba lagi ketika fungsi Anda mengembalikan kesalahan. Lihat batching pemetaan sumber peristiwa. Untuk Amazon SQS ESM, Anda dapat mengonfigurasi percobaan ulang maksimal melalui DLQ pada antrian Amazon SQS asli. Lihat mengkonfigurasi Amazon SQS ES M. Sebagai praktik terbaik, Anda mungkin mempertimbangkan DLQ di tingkat fungsi dan Lambda mengirimkan peristiwa pemicu gagal ke DLQ. Lihat fungsi DLQ. |
| Pemicu Langsung | Ini tergantung pada “Pemicu”. Misalnya, Lambda memproses fungsi yang dipicu oleh notifikasi peristiwa Amazon S3 secara asinkron. Lihat Mem proses notifikasi peristiwa Amazon SQS dengan Lambda. Lambda memproses fungsi yang dipicu oleh notifikasi peristiwa Amazon SNS, secara asinkron. Lihat Mem anggil fungsi Lambda dengan notifikasi Amazon SNS. Perilaku coba ulang pemanggilan asinkron ada di atas dalam entri tabel “Pemanggilan asinkron”. Jika Amazon SNS tidak dapat mencapai Lambda atau pesan ditolak, Amazon SNS melakukan percobaan ulang dengan interval yang diperpanjang selama beberapa jam. Untuk perinciannya, lihat Reliabilitas |
Coba ulang backend
Percobaan ulang backend terjadi saat Lambda mengalami kegagalan infrastruktur, kesalahan runtime, atau ketika SDK tidak dapat berkomunikasi dengan layanan eksekusi tahan lama. Lambda secara otomatis mencoba ulang kegagalan ini untuk membantu fungsi tahan lama Anda pulih dari masalah infrastruktur sementara.
Skenario coba ulang backend
Lambda secara otomatis mencoba ulang fungsi Anda ketika menemukan skenario berikut:
-
Kesalahan layanan internal - Ketika Lambda atau layanan eksekusi tahan lama mengembalikan kesalahan 5xx, menunjukkan masalah layanan sementara.
-
Throttling - Saat fungsi Anda dibatasi karena batas konkurensi atau kuota layanan.
-
Batas waktu - Ketika SDK tidak dapat mencapai layanan eksekusi tahan lama dalam periode batas waktu.
-
Kegagalan inisialisasi kotak pasir - Ketika Lambda tidak dapat menginisialisasi lingkungan eksekusi.
-
Kesalahan runtime - Ketika runtime Lambda menemukan kesalahan di luar kode fungsi Anda, seperti kesalahan kehabisan memori atau proses crash.
-
Kesalahan token pos pemeriksaan tidak valid - Ketika token pos pemeriksaan tidak lagi valid, biasanya karena perubahan status sisi layanan.
Tabel berikut menjelaskan cara SDK menangani skenario ini:
| Skenario | Apa yang terjadi | Dampak pengukuran |
|---|---|---|
| Kesalahan runtime di luar handler tahan lama (OOM, batas waktu, crash) | Lambda secara otomatis mencoba kembali pemanggilan. SDK diputar ulang dari pos pemeriksaan terakhir, melewati langkah-langkah yang telah selesai. | Ukuran payload gala+1 operasi per percobaan ulang |
Kesalahan layanan (5xx) atau batas waktu saat memanggil/API CheckpointDurableExecution GetDurableExecutionState |
Lambda secara otomatis mencoba kembali pemanggilan. SDK diputar ulang dari pos pemeriksaan terakhir. | Ukuran payload gala+1 operasi per percobaan ulang |
Throttling (429) atau token checkpoint tidak valid saat memanggil/API CheckpointDurableExecution GetDurableExecutionState |
Lambda secara otomatis mencoba kembali pemanggilan dengan backoff eksponensial. SDK diputar ulang dari pos pemeriksaan terakhir. | Ukuran payload gala+1 operasi per percobaan ulang |
Kesalahan klien (4xx, kecuali 429 dan token tidak valid) saatCheckpointDurableExecution/API GetDurableExecutionState |
SDK menandai eksekusi sebagai GAGAL. Tidak ada percobaan ulang otomatis yang terjadi karena kesalahan menunjukkan masalah permanen. | Kesalahan ukuran muatan |
Percobaan ulang backend menggunakan backoff eksponensial dan berlanjut sampai fungsi berhasil atau batas waktu eksekusi tercapai. Selama pemutaran ulang, SDK melewatkan pos pemeriksaan yang telah selesai dan melanjutkan eksekusi dari operasi terakhir yang berhasil, memastikan fungsi Anda tidak mengeksekusi ulang pekerjaan yang telah selesai.
Coba lagi praktik terbaik
Ikuti praktik terbaik berikut saat mengonfigurasi strategi coba lagi:
-
Konfigurasikan strategi coba ulang eksplisit - Jangan mengandalkan perilaku coba ulang default dalam produksi. Konfigurasikan strategi coba ulang eksplisit dengan upaya maksimal dan interval mundur yang sesuai untuk kasus penggunaan Anda.
-
Gunakan percobaan ulang bersyarat - Terapkan
shouldRetrylogika untuk mencoba lagi hanya kesalahan sementara (batas laju, batas waktu) dan gagal cepat pada kesalahan permanen (kegagalan validasi, tidak ditemukan). -
Tetapkan upaya maksimal yang sesuai - Keseimbangan antara ketahanan dan waktu eksekusi. Terlalu banyak percobaan ulang dapat menunda deteksi kegagalan, sementara terlalu sedikit dapat menyebabkan kegagalan yang tidak perlu.
-
Gunakan backoff eksponensial - Backoff eksponensial mengurangi beban pada layanan hilir dan meningkatkan kemungkinan pemulihan dari kegagalan sementara.
-
Bungkus kode rawan kesalahan dalam langkah-langkah - Kode di luar langkah tidak dapat dicoba ulang secara otomatis. Bungkus panggilan API eksternal, kueri database, dan operasi rawan kesalahan lainnya dalam langkah-langkah dengan strategi coba lagi.
-
Memantau metrik percobaan ulang - Lacak operasi percobaan ulang langkah dan kegagalan eksekusi di Amazon CloudWatch untuk mengidentifikasi pola dan mengoptimalkan strategi coba ulang.
