DLQ(Dead Letter Queue)란 무엇인가요?
DLQ(Dead Letter Queue)는 소프트웨어 시스템에서 오류로 인해 처리할 수 없는 메시지를 임시로 저장하는 특수한 유형의 메시지 대기열입니다. 메시지 대기열은 분산 시스템에서 비동기 통신을 지원하는 소프트웨어 구성 요소입니다. 어떤 볼륨에서든 소프트웨어 서비스 간에 메시지를 보낼 수 있게 해주며 메시지 수신자가 항상 사용 가능하지 않아도 됩니다. 특별히 DLQ(Dead Letter Queue)는 대상이 없거나 의도한 수신자가 처리할 수 없는 잘못된 메시지를 저장합니다.
DLQ(Dead Letter Queue)는 왜 중요한가요?
DLQ(Dead Letter Queue)는 일반 메시지 대기열과 함께 존재합니다. DLQ는 잘못된 메시지 및 실패한 메시지의 임시 저장소 역할을 합니다. DLQ는 소스 대기열에 처리되지 않은 메시지가 넘치지 않도록 합니다.
일반 메시지 대기열과 DLQ가 있는 소프트웨어를 예로 들어 보겠습니다. 소프트웨어는 일반 대기열을 사용하여 대상으로 전송하려는 메시지를 보관합니다. 수신자가 전송된 메시지에 응답하지 않거나 해당 메시지를 처리하지 못하면 소프트웨어가 메시지를 DLQ(Dead Letter Queue)로 이동합니다.
메시지가 DLQ 파이프라인으로 이동하는 경우 잘못된 메시지 콘텐츠 및 수신자 시스템에서의 변경 사항과 같은 두 가지 이유 때문일 수 있습니다.
잘못된 메시지 콘텐츠
전송된 메시지가 잘못된 경우 메시지는 DLQ로 이동합니다. 하드웨어, 소프트웨어 및 네트워크 상태로 인해 전송된 데이터가 손상될 수 있습니다. 예를 들어, 하드웨어 간섭으로 인해 전송 중에 일부 정보가 약간 변경됩니다. 예상치 못하게 데이터가 손상되면 수신자가 메시지를 거부하거나 무시할 수 있습니다.
수신자 시스템에서 변경 사항
수신 소프트웨어에서 발신자가 인식하지 못하는 변경 사항이 발생한 경우에도 메시지가 DLQ로 이동될 수 있습니다. 예를 들어, CUST_ID_005에 대한 메시지를 전송하여 고객 정보를 업데이트하려고 시도할 수 있습니다. 하지만 시스템 데이터베이스에서 고객이 제거되었으므로 수신자가 수신 메시지를 처리하지 못할 수 있습니다.
DLQ(Dead Letter Queue)의 장점은 무엇인가요?
다음으로, DLQ(Dead Letter Queue)의 장점에 대해 살펴보겠습니다.
통신 비용 절감
일반 또는 표준 메시지 대기열은 보존 기간이 만료될 때까지 메시지를 계속 처리합니다. 이러한 방식을 통해 지속적인 메시지 처리를 보장하고 대기열이 차단될 가능성을 최소화할 수 있습니다.
그러나 시스템에서 수천 개의 메시지를 처리하는 경우 오류 메시지가 많으면 통신 오버헤드 비용이 증가하고 통신 시스템에 부담이 됩니다. 실패한 메시지가 만료될 때까지 해당 메시지 처리를 시도하는 대신, 몇 번의 처리 시도 후에 해당 메시지를 DLQ(Dead Letter Queue)로 이동하는 것이 좋습니다.
문제 해결 개선
잘못된 메시지를 DLQ로 이동하면 개발자가 오류의 원인을 식별하는 데 집중할 수 있습니다. 수신자가 메시지를 처리할 수 없는 이유를 조사하고, 수정 사항을 적용한 후, 메시지를 전송하는 새로운 시도를 수행할 수 있습니다.
예를 들어, 뱅킹 소프트웨어는 승인을 위해 매일 수천 건의 신용카드 신청 요청을 백엔드 시스템으로 전송할 수 있습니다. 여기서 백엔드 시스템은 신청 요청을 수신하지만 불완전한 정보로 인해 모든 요청을 처리할 수 없습니다. 소프트웨어는 무한으로 시도하는 대신, IT 팀이 문제를 해결할 때까지 메시지를 DLQ로 이동합니다. 이렇게 하면 시스템에서 성능 문제 없이 나머지 메시지를 처리하고 전송할 수 있습니다.
DLQ(Dead Letter Queue)를 사용해야 할 때는 언제인가요?
시스템에 다음과 같은 문제가 있는 경우 DLQ(Dead Letter Queue)를 사용할 수 있습니다.
정렬되지 않은 대기열
애플리케이션이 순서에 의존하지 않는 경우 DLQ를 활용할 수 있습니다. DLQ는 잘못된 메시지 전송 작업의 문제를 해결하는 데 도움이 되지만, 대기열을 계속 모니터링하고 실패한 메시지를 다시 전송해야 합니다.
FIFO 대기열
메시지 순서는 선입선출(FIFO) 대기열에서 중요합니다. 다음 메시지를 전송하기 전에 모든 메시지를 처리해야 합니다. DLQ(Dead Letter Queue)를 FIFO 대기열과 함께 사용할 수 있지만 DLQ도 FIFO로 구현되어야 합니다.
DLQ(Dead Letter Queue)를 사용하지 말아야 할 때는 언제인가요?
메시지 전송을 무한으로 재시도하려는 경우 정렬되지 않은 대기열과 함께 DLQ(Dead Letter Queue)를 사용해서는 안 됩니다. 예를 들어, 프로그램이 종속 프로세스가 활성화되거나 사용 가능해질 때까지 기다려야 하는 경우에는 DLQ(Dead Letter Queue)를 사용하지 않습니다.
마찬가지로, 메시지 또는 작업의 정확한 순서를 그대로 유지하려면 선입선출(FIFO) 대기열과 함께 DLQ(Dead Letter Queue)를 사용해서는 안 됩니다. 예를 들어, 비디오 편집 제품군의 경우 편집 결정 목록(EDL)의 지침과 함께 DLQ(Dead Letter Queue)를 사용하지 않습니다. 이 경우 사용자가 편집 순서를 변경하여 후속 편집의 컨텍스트를 변경할 수 있습니다.
DLQ(Dead Letter Queue)는 어떻게 작동하나요?
대부분의 경우 DLQ(Dead Letter Queue)는 일반 메시지 대기열처럼 작동합니다. 이 대기열은 오류 원인을 조사하기 위해 잘못된 메시지를 처리할 때까지 해당 메시지를 저장합니다.
다음으로, DLQ의 리드라이브 정책과 메시지가 DLQ에 들어오고 나가는 방식을 살펴보겠습니다.
리드라이브 정책 생성
소프트웨어는 리드라이브 정책을 참조하여 메시지를 DLQ(Dead Letter Queue)로 이동합니다. 리드라이브 정책은 소프트웨어가 메시지를 DLQ(Dead Letter Queue)로 이동해야 하는 시기를 결정하는 규칙으로 구성됩니다. 리드라이브 정책은 주로 최대 재시도 횟수를 정의하여 소스 대기열과 DLQ(Dead Letter Queue)가 서로 상호 작용하는 방식을 규제합니다.
예를 들어, 개발자가 최대 재시도 횟수를 1로 설정하면 시스템은 한 번 시도한 후에 실패한 모든 전송을 DLQ로 이동합니다. 일시적인 네트워크 과부하 또는 소프트웨어 문제로 인해 일부 전송에 실패할 수도 있습니다. 이 경우 전송되지 않은 많은 메시지가 DLQ로 전송됩니다. 적절한 균형을 유지하기 위해 개발자는 메시지를 DLQ로 이동하기 전에 소프트웨어가 충분한 재시도를 수행하도록 최대 재시도 횟수를 최적화합니다.
메시지를 DLQ(Dead Letter Queue)에 넣기
발신자와 수신자 간 전송 시도는 다음과 같은 여러 가지 이유로 실패할 수 있습니다.
- 메시지가 존재하지 않기 때문에 수신자가 메시지를 수신하지 못합니다.
- 메시지에 오류가 있습니다.
- 메시지가 대기열 또는 메시지 길이 제한을 초과합니다. 예를 들어, 일부 수신자는 특정 크기를 초과하는 메시지를 처리할 수 없습니다.
- 메시지의 TTL(Time To Live)이 만료되었습니다. TTL은 네트워크에서 특정 데이터 패킷의 유효 기간을 나타내는 값입니다.
메시지를 DLQ(Dead Letter Queue)에서 꺼내기
메시지가 DLQ(Dead Letter Queue)로 이동하면 개발자는 잘못된 메시지를 검사하여 원인을 파악합니다. DLQ의 메시지에는 향후 유사한 문제가 재발하지 않도록 하는 유용한 정보가 포함될 수 있습니다. 개발자가 문제를 분석하고 해결하면 시스템은 해당 메시지를 DLQ에서 소스 대기열로 이동합니다. 이렇게 하면 발신자가 메시지를 계속 처리할 수 있습니다.
AWS는 DLQ(Dead Letter Queue) 요구 사항을 어떻게 지원할 수 있나요?
Amazon Simple Queue Service(Amazon SQS)는 분산 시스템 사이에서 메시지를 대규모로 교환할 수 있는 확장 가능한 접근 방식을 제공합니다. 개발자는 Amazon SQS를 통해 완전관리형 표준 대기열과 선입선출(FIFO) 대기열을 사용하여 안정적인 웹 애플리케이션을 구축할 수 있습니다.
Amazon SQS의 다른 이점은 다음과 같습니다.
- Amazon SQS를 사용하면 시스템에서 메시지 대기열을 무제한으로 생성할 수 있음
- 개발자는 메시지를 배치 단위로 전송하여 비용 효율성을 높일 수 있음
- Amazon SQS는 메시지 잠금을 지원하여 여러 컴퓨터에서 동일한 메시지를 동시에 처리하지 않도록 방지
지금 AWS 계정을 생성하여 Amazon Web Services(AWS)를 시작하세요.
