Lambda의 비동기 재시도 횟수는 모든 재실행을 막는 전역 스위치가 아닙니다. 먼저 비동기 호출인지 확인하고, 함수가 실행된 뒤 실패했는지 아니면 용량 부족으로 실행을 기다렸는지 나누세요.
적용 환경: AWS Lambda의 비동기 호출; 동기 호출과 SQS 이벤트 소스 매핑은 별도 경로. 자료 확인일: 2026-10-25. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.
1. 원인: 서로 다른 실패를 같은 횟수로 셉니다
함수 오류에는 코드 오류와 타임아웃 등이 포함됩니다. 공식 기본 동작은 함수 오류 후 추가 두 번의 시도입니다. 반면 스로틀링과 시스템 오류는 비동기 큐에서 재시도하며, 기본적으로 최대 6시간까지 이어질 수 있습니다. 실제 설정을 확인하지 않고 기본값을 운영값으로 단정하지 마세요.
함수 로그가 없다는 이유만으로 성공이라고 판단하지 않습니다. 호출 요청, 큐 대기, 함수 실행, 외부 결과 반영을 따로 확인해야 합니다.
2. 해결: 호출 경로와 적용 범위를 먼저 확인
| 확인 대상 | 점검 내용 |
| 호출 방식 | 비동기 호출인가, 이벤트 소스 매핑인가? |
| 함수 오류 | 실행 로그와 타임아웃이 있는가? |
| 처리 용량 | 스로틀링과 대기 증가가 있는가? |
| 설정 대상 | 함수·버전·별칭 중 어디에 적용했는가? |
MaximumRetryAttempts는 함수가 오류를 반환할 때의 재시도 설정입니다. MaximumEventAgeInSeconds는 이벤트를 큐에 보관하는 최대 나이입니다. 둘을 같은 제한으로 이해하면 오래 기다린 이벤트가 폐기되는 이유를 놓칠 수 있습니다.
3. 확인: 재실행과 결과 중복을 따로 측정
시험용 함수와 가상 이벤트에서 오류 반환 사례와 처리 용량 부족 사례를 분리해 기록합니다. 이벤트 식별자, 각 시도 시각, 결과 저장 여부를 비교하세요. 설정이 어느 별칭에 적용됐는지도 함께 남깁니다.
오류 없이도 동일 이벤트가 여러 번 전달될 가능성이 있으므로 외부 쓰기는 멱등성을 고려해야 합니다. 예를 들어 알림 발송 여부를 확인하지 않고 재시도하면 사용자가 같은 알림을 반복해서 받을 수 있습니다.
4. 주의와 FAQ
재시도 횟수를 0으로 하면 정확히 한 번인가요? 아닙니다. 호출자의 재전송과 이벤트 중복도 구분해야 합니다.
실패한 이벤트는 어디에서 찾나요? 폐기 이벤트를 보존할 DLQ 또는 실패 대상 설정을 검토하고 실제 도착 여부를 시험하세요. 단순 설정 화면만으로 수신 성공을 확정하지 않습니다.
운영 동시성이나 오류 처리 정책을 바꾸기 전 기존 값을 보존하고, 알림·결제 같은 부수 효과를 차단한 시험 범위에서 검증하세요. 이 글은 명령 실행 결과가 아닌 문서 기반 안내입니다.
공식 출처와 관련 글
invocation-async-error-handling.html
'소프트웨어개발' 카테고리의 다른 글
| SQS 작업이 두 번 실행될 때: 수신·처리·삭제 시각과 visibility timeout 점검 (0) | 2026.10.26 |
|---|---|
| journalctl -b -1 로그가 없을 때: 이전 부팅 기록과 저장 방식 점검 (0) | 2026.10.24 |
| git stash 후 새 파일이 남을 때: 미추적 파일과 무시 파일 구분 (0) | 2026.10.24 |
