Mencoba lagi untuk fungsi tahan lama Lambda - AWS Lambda

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

Mencoba lagi untuk fungsi tahan lama Lambda

Fungsi tahan lama memberikan 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 mencoba lagi

Ketika pengecualian yang tidak tertangkap terjadi dalam satu langkah, SDK secara otomatis mencoba ulang langkah berdasarkan strategi coba lagi yang dikonfigurasi. Langkah percobaan ulang adalah operasi checkpoint yang memungkinkan SDK untuk menangguhkan eksekusi dan melanjutkan nanti tanpa kehilangan kemajuan.

Langkah coba lagi perilaku

Tabel berikut menjelaskan cara SDK menangani pengecualian dalam langkah-langkah:

Skenario Apa yang terjadi Dampak pengukuran
Pengecualian sejalan dengan upaya coba lagi yang tersisa SDK membuat pos pemeriksaan untuk coba lagi dan menangguhkan fungsi. Pada pemanggilan berikutnya, langkah mencoba lagi dengan penundaan backoff yang dikonfigurasi. 1 operasi+ukuran muatan kesalahan
Pengecualian dalam langkah tanpa upaya coba lagi yang tersisa Langkah gagal dan melempar pengecualian. Jika kode handler Anda tidak menangkap pengecualian ini, seluruh eksekusi gagal. 1 operasi+ukuran muatan kesalahan

Ketika sebuah 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 menerapkan penundaan backoff tanpa menghabiskan sumber daya komputasi. Fungsi dilanjutkan secara otomatis setelah periode backoff.

Mengkonfigurasi strategi coba lagi langkah

Konfigurasikan strategi coba lagi untuk mengontrol cara langkah-langkah menangani kegagalan. Anda dapat menentukan upaya maksimum, interval backoff, dan kondisi untuk mencoba kembali.

Backoff eksponensial dengan upaya maksimal:

TypeScript
const result = await context.step('call-api', async () => { const response = await fetch('https://api.example.com/data'); if (!response.ok) throw new Error(`API error: ${response.status}`); return await response.json(); }, { retryStrategy: (error, attemptCount) => { if (attemptCount >= 5) { return { shouldRetry: false }; } // Exponential backoff: 2s, 4s, 8s, 16s, 32s (capped at 300s) const delay = Math.min(2 * Math.pow(2, attemptCount - 1), 300); return { shouldRetry: true, delay: { seconds: delay } }; } });
Python
def retry_strategy(error, attempt_count): if attempt_count >= 5: return {'should_retry': False} # Exponential backoff: 2s, 4s, 8s, 16s, 32s (capped at 300s) delay = min(2 * (2 ** (attempt_count - 1)), 300) return {'should_retry': True, 'delay': delay} result = context.step( lambda _: call_external_api(), name='call-api', config=StepConfig(retry_strategy=retry_strategy) )

Backoff interval tetap:

TypeScript
const orders = await context.step('query-orders', async () => { return await queryDatabase(event.userId); }, { retryStrategy: (error, attemptCount) => { if (attemptCount >= 3) { return { shouldRetry: false }; } return { shouldRetry: true, delay: { seconds: 5 } }; } });
Python
def retry_strategy(error, attempt_count): if attempt_count >= 3: return {'should_retry': False} return {'should_retry': True, 'delay': 5} orders = context.step( lambda _: query_database(event['userId']), name='query-orders', config=StepConfig(retry_strategy=retry_strategy) )

Coba lagi bersyarat (coba lagi hanya kesalahan tertentu):

TypeScript
const result = await context.step('call-rate-limited-api', async () => { const response = await fetch('https://api.example.com/data'); if (response.status === 429) throw new Error('RATE_LIMIT'); if (response.status === 504) throw new Error('TIMEOUT'); if (!response.ok) throw new Error(`API_ERROR_${response.status}`); return await response.json(); }, { retryStrategy: (error, attemptCount) => { // Only retry rate limits and timeouts const isRetryable = error.message === 'RATE_LIMIT' || error.message === 'TIMEOUT'; if (!isRetryable || attemptCount >= 3) { return { shouldRetry: false }; } // Exponential backoff: 1s, 2s, 4s (capped at 30s) const delay = Math.min(Math.pow(2, attemptCount - 1), 30); return { shouldRetry: true, delay: { seconds: delay } }; } });
Python
def retry_strategy(error, attempt_count): # Only retry rate limits and timeouts is_retryable = str(error) in ['RATE_LIMIT', 'TIMEOUT'] if not is_retryable or attempt_count >= 3: return {'should_retry': False} # Exponential backoff: 1s, 2s, 4s (capped at 30s) delay = min(2 ** (attempt_count - 1), 30) return {'should_retry': True, 'delay': delay} result = context.step( lambda _: call_rate_limited_api(), name='call-rate-limited-api', config=StepConfig(retry_strategy=retry_strategy) )

Nonaktifkan percobaan ulang:

TypeScript
const isDuplicate = await context.step('check-duplicate', async () => { return await checkIfOrderExists(event.orderId); }, { retryStrategy: () => ({ shouldRetry: false }) });
Python
is_duplicate = context.step( lambda _: check_if_order_exists(event['orderId']), name='check-duplicate', config=StepConfig( retry_strategy=lambda error, attempt: {'should_retry': False} ) )

Ketika strategi coba lagi kembalishouldRetry: false, langkah gagal segera tanpa mencoba lagi. Gunakan ini untuk operasi yang tidak boleh dicoba lagi, seperti pemeriksaan idempotensi atau operasi dengan efek samping yang tidak dapat diulang dengan aman.

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 payload

Untuk mengaktifkan percobaan ulang otomatis untuk kode rawan kesalahan, bungkus dalam satu langkah dengan strategi coba lagi. Langkah-langkah memberikan percobaan ulang otomatis dengan backoff yang dapat dikonfigurasi, sementara kode di luar langkah segera gagal.

Backend mencoba lagi

Percobaan ulang backend terjadi ketika Lambda mengalami kegagalan infrastruktur, kesalahan runtime, atau saat SDK tidak dapat berkomunikasi dengan layanan eksekusi tahan lama. Lambda secara otomatis mencoba kembali kegagalan ini untuk memastikan fungsi tahan lama Anda dapat pulih dari masalah infrastruktur sementara.

Skenario coba lagi 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 - Ketika fungsi Anda dibatasi karena batas konkurensi atau kuota layanan.

  • Timeout - 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, out-of-memory seperti kesalahan 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 ulang pemanggilan. SDK diputar ulang dari pos pemeriksaan terakhir, melewatkan langkah-langkah yang telah selesai. Kesalahan ukuran payload+1 operasi per coba lagi
Kesalahan layanan (5xx) atau batas waktu saat menelepon/CheckpointDurableExecutionGetDurableExecutionState APIs Lambda secara otomatis mencoba ulang pemanggilan. SDK diputar ulang dari pos pemeriksaan terakhir. Kesalahan ukuran payload+1 operasi per coba lagi
Throttling (429) atau token pos pemeriksaan tidak valid saat memanggil/CheckpointDurableExecutionGetDurableExecutionState APIs Lambda secara otomatis mencoba ulang pemanggilan dengan backoff eksponensial. SDK diputar ulang dari pos pemeriksaan terakhir. Kesalahan ukuran payload+1 operasi per coba lagi
Kesalahan klien (4xx, kecuali 429 dan token tidak valid) ketika/CheckpointDurableExecutionGetDurableExecutionState APIs SDK menandai eksekusi sebagai GAGAL. Tidak ada percobaan ulang otomatis yang terjadi karena kesalahan menunjukkan masalah permanen. Kesalahan ukuran payload

Backend mencoba menggunakan backoff eksponensial dan melanjutkan sampai fungsi berhasil atau batas waktu eksekusi tercapai. Selama pemutaran ulang, SDK melewati pos pemeriksaan yang telah selesai dan melanjutkan eksekusi dari operasi terakhir yang berhasil, memastikan fungsi Anda tidak menjalankan kembali pekerjaan yang telah selesai.

Coba lagi praktik terbaik

Ikuti praktik terbaik ini 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 backoff yang sesuai untuk kasus penggunaan Anda.

  • Gunakan percobaan ulang bersyarat - Terapkan shouldRetry logika untuk mencoba lagi hanya kesalahan sementara (batas tingkat, 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.

  • Pantau metrik coba lagi - Lacak operasi percobaan ulang langkah dan kegagalan eksekusi di Amazon CloudWatch untuk mengidentifikasi pola dan mengoptimalkan strategi coba lagi.