설명
Lambda 비동기 호출의 재시도나 이벤트 수명 제한이 끝난 뒤 실패 이벤트를 보관할 경로가 없으면 원인 분석과 재처리가 어려워집니다. DLQ는 한 가지 방법이며, 별도의 실패 대상 등 다른 처리 경로가 있다면 DLQ가 없다는 이유만으로 이벤트 손실을 단정할 수는 없습니다.
잠재적 영향
- 폐기되는 이벤트를 보관하지 못하면 처리 누락을 복구하기 어려울 수 있습니다.
- 실패 전달과 후속 처리를 감시하지 않으면 장애를 늦게 발견할 수 있습니다.
해결 방법
비동기 실패 처리 요구에 맞게 DLQ 또는 실패 대상을 구성하세요. dead_letter_config에는 Standard SQS 큐나 Standard SNS 토픽의 ARN을 사용하고 실행 역할에 전달 권한을 부여하세요. 전달 오류를 감시하고 보관 및 재처리를 시험하세요.
예시
비동기 실패 처리 설정의 발췌입니다. var.lambda_runtime에는 배포 파일에 맞는 지원 런타임을 지정하세요. 실행 역할, SNS 토픽과 구독 대상은 별도로 준비하세요. SQS 이벤트 소스의 DLQ는 큐 자체에 설정합니다.
변경 전
hcl
resource "aws_lambda_function" "example" {
function_name = "lambdaWithoutDLQ"
role = aws_iam_role.lambda_exec_role.arn
handler = "index.handler"
runtime = var.lambda_runtime
filename = "lambda.zip"
}
변경 후
hcl
resource "aws_lambda_function" "example" {
function_name = "lambdaWithoutDLQ"
role = aws_iam_role.lambda_exec_role.arn
handler = "index.handler"
runtime = var.lambda_runtime
filename = "lambda.zip"
dead_letter_config {
target_arn = "arn:aws:sns:us-east-1:123456789012:my-dlq-topic"
}
}
변경 후에는 같은 함수에 SNS DLQ를 연결합니다. SNS는 실패 이벤트를 구독 대상에 전달하므로 실제 수신과 보관 경로를 확인하세요. 권한 오류나 크기 제한으로 전달이 실패할 수 있어 설정만으로 보관이 보장되지는 않습니다.