AWS Lambda timeout과 재시도: 같은 작업이 두 번 실행될 수 있는 이유

Lambda 호출이 timeout됐다고 해서 함수가 아무 작업도 하지 않았다고 단정할 수 없다. 외부 API 호출이나 데이터 저장이 끝난 직후 응답만 못 보냈을 수도 있고, 이벤트 전달 방식에 따라 재시도가 이어질 수도 있다.

제한 시간은 실제 작업 경계에 맞춘다

timeout을 크게 늘리기 전에 어떤 단계가 오래 걸리는지 측정한다. 데이터베이스·외부 API의 자체 timeout은 Lambda보다 짧게 두어 함수가 끝나기 직전까지 무작정 기다리지 않게 한다. 오래 걸리는 작업은 큐·배치·다른 실행 모델로 분리하는 것이 더 적절할 수 있다.

예를 들어 비동기 이벤트 order-42가 저장에 성공한 직후 함수 제한 시간에 걸리면 호출자는 성공 여부를 모를 수 있다. 같은 이벤트가 다시 전달될 때 저장을 한 번 더 수행하지 않도록 이벤트 키와 저장 결과를 함께 확인해야 한다. 로그에서는 키별 시작·완료·시간 초과를 구분하되 요청 본문이나 비밀값은 남기지 않는다.

재시도를 전제로 멱등하게 만든다

같은 이벤트가 두 번 처리돼도 결제가 중복되거나 같은 레코드가 여러 번 생성되지 않도록 멱등 키와 상태 전이를 설계한다. 성공 여부가 불확실한 외부 호출은 단순 재시도보다 요청 식별자와 수신 측의 중복 방지 계약이 필요하다.

재시도 방식은 호출 경로마다 다르다. Lambda의 비동기 호출은 함수 오류·시간 초과에 재시도가 적용될 수 있지만, 동기 호출은 호출자가 재시도 여부를 정한다. 큐 이벤트라면 큐의 가시성 시간과 실패 처리 설정을 함께 봐야 한다. 모든 Lambda 실행이 같은 횟수로 자동 재시도된다고 가정하지 말자.

order-42를 받은 함수가 DB 기록을 마친 직후 응답 전에 시간 초과됐다면, 같은 이벤트의 재시도에서 함수 호출은 두 번이어도 주문 기록은 한 번만 남아야 한다.

단순히 함수 메모리에 처리 목록을 두면 다른 실행 환경에서는 목록이 비어 있을 수 있다. 데이터 저장소의 유일 키나 조건부 쓰기처럼 여러 호출에서 공유되는 원자적 경계를 사용한다. 디버깅할 때는 호출 성공 여부와 업무 데이터 반영 여부를 따로 확인한다.

핵심 요약

Lambda 시간 초과 뒤 재시도 여부는 호출 방식에 달려 있다. 함수·외부 호출의 시간 제한을 함께 설정하고, 재전달 가능한 이벤트는 멱등 키와 명시적 상태로 처리하자. timeout을 늘리기 전에 병목과 처리 모델을 구분하는 편이 안전하다.