기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon SQS Dead Letter Queue(DLQ) 및 DLQ 리드라이브 문제 해결
다음 주제에서는 Amazon SQS DLQ 및 DLQ 리드라이브 문제의 가장 일반적인 원인과 문제를 해결하는 방법을 다룹니다. 자세한 내용은 *AWS 지식 센터 가이드*의 [Amazon SQS DLQ 리드라이브 문제를 해결하려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/sqs-dead-letter-queue-redrive)를 참조하세요.
## DLQ 문제
일반적인 DLQ 문제와 이를 해결하는 방법에 대해 알아봅니다.
### 콘솔을 사용하여 메시지를 보면 메시지가 DLQ(Dead Letter Queue)로 이동할 수 있음
Amazon SQS는 콘솔에서 메시지를 보는 것을 해당 대기열의 리드라이브 정책을 위반하는 것으로 간주합니다. 따라서 콘솔에서 해당 대기열의 리드라이브 정책에 지정된 횟수로 메시지를 보는 경우 이 메시지는 해당 대기열의 DLQ(Dead Letter Queue)로 이동됩니다.
이 동작을 조정하려면 다음 중 하나를 수행할 수 있습니다.
+ 해당 대기열의 리드라이브 정책에 맞게 [**Maximum Receives**] 설정을 늘립니다.
+ 콘솔에서 해당 대기열의 메시지를 보는 것을 피합니다.
### 배달 못한 편지 대기열에 대한 `NumberOfMessagesSent` 및 `NumberOfMessagesReceived`가 일치하지 않음
메시지를 Dead Letter Queue(DLQ)에 수동으로 전송하는 경우, 이것은 [`NumberOfMessagesSent`](sqs-available-cloudwatch-metrics.md) 지표로 캡처됩니다. 그러나 처리 실패로 인해 메시지가 배달 못한 편지 대기열로 전송되는 경우에는 이 지표로 캡처되지 않습니다. 따라서 `NumberOfMessagesSent` 및 [`NumberOfMessagesReceived`](sqs-available-cloudwatch-metrics.md) 값이 다를 수 있습니다.
### 배달 못한 편지 대기열 리드라이브 생성 및 구성
Dead Letter Queue(DLQ) 리드라이브를 사용하려면 Amazon SQS가 Dead Letter Queue(DLQ)에서 메시지를 수신하고 대상 대기열로 메시지를 보낼 수 있도록 적절한 [권한](sqs-configure-dead-letter-queue-redrive.md#sqs-configure-dead-letter-queue-redrive-permissions)을 설정해야 합니다. 올바른 권한이 없는 경우 Dead Letter Queue(DLQ) 리드라이브 작업이 실패할 수 있습니다. 메시지 리드라이브 작업의 상태를 보고 문제를 해결하고 다시 시도할 수 있습니다.
### 표준 및 FIFO 대기열 메시지 실패 처리
[**표준 대기열**](standard-queues.md)은 [보존 기간](sqs-dead-letter-queues.md#understanding-message-retention-periods)이 만료될 때까지 메시지를 계속 처리합니다. 이 연속 처리는 사용하지 않는 메시지로 인해 대기열이 차단될 가능성을 최소화합니다. 소비자가 반복적으로 많은 수의 메시지 삭제에 실패하면 비용이 증가하고 하드웨어의 부하가 늘어날 수 있습니다. 비용을 줄이려면 실패한 메시지를 Dead Letter Queue(DLQ)로 이동합니다.
표준 대기열에도 처리 중 메시지가 많을 수 있습니다. 대부분의 메시지를 소비하지 않고 Dead Letter Queue(DLQ)로 보내지도 않는다면 메시지의 처리 속도가 느려질 수 있습니다. 대기열의 효율성을 유지하려면 애플리케이션이 메시지 처리를 올바르게 수행하는지 확인하세요.
[**FIFO 대기열**](sqs-fifo-queues.md)은 메시지 그룹의 메시지를 순서에 따라 소비함으로써 한 번만 처리되도록 합니다. 이렇게 하면 대기열을 가로막고 있는 메시지가 제대로 처리되거나 Dead Letter Queue(DLQ)로 이동될 때까지 첫 번째 메시지 그룹은 사용할 수 없는 상태가 되지만, 소비자는 다른 메시지 그룹으로부터 정렬된 메시지를 계속 가져올 수 있습니다.
또한 FIFO 대기열을 사용하면 처리 중 메시지의 수를 줄일 수 있습니다. 메시지로 인해 FIFO 대기열이 차단되는 것을 방지하려면 애플리케이션이 메시지 처리를 올바르게 수행하는지 확인하세요.
자세한 내용은 [Amazon SQS 메시지 할당량](quotas-messages.md) 및 [Amazon SQS 모범 사례](sqs-best-practices.md) 섹션을 참조하세요.
## DLQ 리드라이브 문제
일반적인 DLQ 리드라이브 문제와 이를 해결하는 방법에 대해 알아봅니다.
### AccessDenied 권한 문제
AWS Identity and Access Management (IAM) 엔터티에 필요한 권한이 없기 때문에 DLQ 리드라이브가 실패할 때 `AccessDenied` 오류가 발생합니다.
**오류 메시지 예:**
```
Failed to create redrive task. Error code: AccessDenied - Queue Permissions to Redrive.
```
DLQ 리드라이브 요청을 수행하려면 다음 API 권한이 필요합니다.
**메시지 리드라이브를 시작하려면:**
+ 배달 못한 편지 대기열 권한:
+ `sqs:StartMessageMoveTask`
+ `sqs:ReceiveMessage`
+ `sqs:DeleteMessage`
+ `sqs:GetQueueAttributes`
+ `kms:Decrypt` - 배달 못한 편지 대기열 또는 원본 소스 대기열이 암호화되는 경우.
+ 대상 대기열 권한:
+ `sqs:SendMessage`
+ `kms:GenerateDataKey` - 대상 대기열이 암호화되는 경우.
+ `kms:Decrypt` - 대상 대기열이 암호화되는 경우.
**진행 중인 메시지 리드라이브를 취소하려면:**
+ 배달 못한 편지 대기열 권한:
+ `sqs:CancelMessageMoveTask`
+ `sqs:ReceiveMessage`
+ `sqs:DeleteMessage`
+ `sqs:GetQueueAttributes`
+ `kms:Decrypt` - 배달 못한 편지 대기열 또는 원본 소스 대기열이 암호화되는 경우.
**메시지 이동 상태를 표시하려면:**
+ 배달 못한 편지 대기열 권한:
+ `sqs:ListMessageMoveTasks`
+ `sqs:GetQueueAttributes`
### `NonExistentQueue` 오류
`NonExistentQueue` 오류는 Amazon SQS 소스 대기열이 없거나 삭제되었을 때 발생합니다. 확인 후 현재 있는 Amazon SQS 대기열로 다시 이동합니다.
**오류 메시지 예:**
```
Failed: AWS.SimpleQueueService.NonExistentQueue
```
### CouldNotDetermineMessageSource 오류
다음 시나리오로 DLQ 리드라이브를 시작하려고 하면 `CouldNotDetermineMessageSource` 오류가 발생합니다.
+ [`SendMessage`](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) API를 사용하여 DLQ로 직접 전송되는 Amazon SQS 메시지입니다.
+ DLQ가 구성된 Amazon Simple Notification Service(Amazon SNS) 주제 또는 AWS Lambda 함수의 메시지입니다.
이 오류를 해결하려면 리드라이브를 시작할 때 **사용자 지정 대상으로 리드라이브**를 선택합니다. 그런 다음 Amazon SQS 대기열 ARN을 입력하여 모든 메시지를 DLQ에서 대상 대기열로 이동합니다.
**오류 메시지 예:**
```
Failed: CouldNotDetermineMessageSource
```