SQS ?
Simple Queue Service는 AWS에서 제공하는
완전 관리형 메시지 대기열 서비스 이다.
SQS는 서버리스 애플리케이션 간에 메시지를 안전하게 전송, 저장 및 수신을 할 수 있게 해준다.
주요 특징은 다음과 같다.
- 분산 컴포넌트간의 비동기 통신
- SQS를 사용하면, 서로 다른 시스템 및 애플리케이션 간에 메시지를 비동기적으로 교환할 수 있다.
이는 컴포넌트들이 서로 독립적으로 작동하면서도 효율적으로 통신할 수 있게 해준다.
- SQS를 사용하면, 서로 다른 시스템 및 애플리케이션 간에 메시지를 비동기적으로 교환할 수 있다.
- 탄력적이고 확장 가능
- SQS는 자동으로 확장되므로 메시지의 양이 많아지더라도 안정적으로 처리할 수 있다.
이는 높은 수준의 트래픽과 대량의 메시지를 처리하는 데 매우 유용하다.
- SQS는 자동으로 확장되므로 메시지의 양이 많아지더라도 안정적으로 처리할 수 있다.
- 두 가지 대기열 유형
- 표준 대기열 : 최대 처리량에 최적화된 대기열,
메시지가 최소 한 번 전달되며, 때때로 메시지의 순서가 바뀔 수 있다 - ++ 직접 경험해본 바로는, S3의 특정 폴더에 업로드 이벤트로 SQS를 선택할 때
SQS가 FIFO 형식이라면 선택이 불가능했다.
- 표준 대기열 : 최대 처리량에 최적화된 대기열,
- 유연한 메시지 관리
- 메시지의 가시성 타임아웃, 지연 시간 및 메시지 생명 주기를 설정할 수 있다.
- 서버리스 통합
- AWS Lambda와 같은 다른 AWS 서비스와 통합하여
서버리스 아키텍처에서 사용하는 중요한 역할을 수행한다.
SQS가 Lambda 함수의 트리거로 설정되는 것이 일반적이다.
- AWS Lambda와 같은 다른 AWS 서비스와 통합하여
어떨 때 사용?
SQS는 말 그대로 Queue 서비스이다.
람다함수와 연동되게 사용한다 가정하면
SQS(1) <-> Lambda(1)
SQS(2) <-> Lambda(2)
. . .
SQS(N) <-> Lambda(N)
이런식으로 SQS에 이벤트가 쌓일 때 마다 람다가 실행된다.
일련의 시나리오를 써보자.
- 사용자가 FTP를 이용해서 S3의 특정 버킷에 이미지를 업로드한다.
- 해당 폴더에 Created 이벤트가 걸려있었고, 해당 이미지의 정보를 SQS에 전송한다.
- SQS에는 이미지 정보가 들어있는 이벤트들이 전달되고,
SQS에 정보가 들어오자 이를 Trigger로 가지고 있는 Lambda 함수가 실행된다.
- SQS에는 이미지 정보가 들어있는 이벤트들이 전달되고,
즉, 사용자는 그저 폴더에 이미지를 마구잡이로 업로드해도 이는 SQS에 차곡차곡 쌓여
Lambda함수를 실행시키게 된다.
이쯤 되면 한가지 드는 의문이 있다.
SQS는 대량의 이벤트를 처리하는데 적합하다.
하지만 만약, 특정한 큐가 실패한다면 어떻게될까?
어떤 이벤트가 실패했는지 일일히 Cloud Watch를 뒤져보는 수밖에 없는,
굉장히 비 개발자적인 방법밖에 없다.
SQS는 이에 대비하여 한가지 대책을 내놓았는데,
그게 바로 배달 못한 편지 대기열, Dead Letter Queue 다.
DLQ라고 불리는 이 큐는 항상 SQS와 붙어다니는 큐로,
SQS의 정상 로직에서 벗어난 이벤트들이 넘어가는 큐라고 생각하면 된다.
DLQ의 역할은 무엇일까?
SQS에서 Lambda를 트리거로 사용할 수 있듯,
DLQ도 마찬가지로 SQS의 일부분이기 때문에 별도의 Lambda를 트리거로 가져서
실패한 이벤트에 대한 처리를 DLQ의 트리거에서 해결하거나
또는 DLQ에 쌓인 데이터를 보고 어느 부분에서 오류가 발생했는지 확인한 뒤
Lambda 함수를 수정하고 DLQ를 리드라이브시키면
실패한 이벤트들이 다시 정상적인 큐로 넘어가면서 수정된 람다를 재실행한다.
여기서 리드라이브란, 실패한 대기열인 DLQ에 쌓여있는 이벤트들을
다시 정상적인 SQS로 넘기는 작업을 의미한다.
가령, 중요한 이벤트를 담은 큐가 실패한 경우
해당 이벤트를 다시 실행할 수 없을 때 DLQ로 들어온 이벤트를 리드라이브 시킴으로써
다시 정상적인 SQS로 넘기는 작업을 수행한다.
내가 DLQ를 사용하는 방법은 다음과 같다.
Q. 개발자씨, 제가 올린 이미지 몇개가 서버에서 안보이는데 이유좀 알려주실래요?
해결방안) 해당 람다의 트리거로 걸려있는 SQS와 연관된 DLQ로 들어가서
폴링된(DLQ에 쌓인 이벤트) 메시지가 있나 확인,
폴링된 메시지가 있다면 해당 DLQ에 들어가서 메시지 수신으로 실패한 이벤트의 시간 및 이름을 확인.
Cloud Watch에서 실패한 이미지의 시간대를 포함해서 [Error] 로 검색.
검색된 Error의 이유를 분석, 보고 진행.
A. ~ 이유로 인해서 버그가 발생했습니다. 버그를 일으키는 로직을 수정하여 배포까지 완료했습니다.
Q. 고마워요.
올린 이미지가 너무 많아서 실패한 이미지를 따로 찾아서 올리기 힘든데, 큰일이네요.
A. 실패한 이미지들은 따로 저장(DLQ)하고 있습니다.
필요하시다면 이미지들을 그대로 다시 업로드 해드릴까요?
Q. 다행이네요. 부탁드릴게요.
해결방안) DLQ에서 리드라이브 진행,
Cloud Watch에 들어가서 DLQ에 있던 이벤트들이 제대로 등록되어 동작하는지 확인
이렇듯, SQS는 DLQ와 반드시 짝지어 만들어 주는것이 좋다.
+++
일반 SQS와 DLQ를 연동하는 방법은 간단하다.
SQS의 편집으로 들어가서
배달 못한 편지 대기열을 활성화하고 대기열에서 생성한 DLQ를 선택하면 된다.
최대 수신수는 SQS를 재실행할 횟수, 즉 람다가 3번 실패하면 DLQ로 넘어가라는 의미이다.
