sqs에 이벤트를 쌓아 spring boot 워커 애플리케이션에서 처리하고있다.
최근에 개발서버에서 워커애플리케이션 수정 중 sqs의 이벤트가 소실되는 문제가 있었다.
다행히 운영서버에 문제가 발생하지는 않았지만 섬칫한 경험이었기에, 이벤트 소실에대한 대비를 하려고한다.
상황
- API 서버에서 SNS로 이벤트를 발행한다.
- 해당 주제를 구독하고있는 여러 SQS의 큐로 메시지가 전파된다.
- 워커가 각 큐에대한 비즈니스를 처리한다. (성공시에만 ack 처리)
여기서 3번의 경우 별도의 DLQ를 설정하지 않았을때 이벤트처리에 실패하면 redrive policy 만큼 재시도를 하고, 재시도 횟수만큼 반복해도 성공하지 못하면 메시지가 소실될 수 있다고한다.
위 상황에서 메시지가 소실된것으로 보인다.
목표는 다음과같이 설정했다.
- 운영(production), 개발(staging)환경에 대한 DLQ 설정
- DLQ의 redrive 테스트(수동)
- DLQ에 메시지가 있으면 slack에 메시지 푸시
DLQ redrive는 자동으로 처리되게 구성할 수 있지만 당분간 직접 문제를 확인하고 분석하기위해 수동으로 진행한다.
DLQ 설정 및 리드라이브
SQS에 표준, FIFO 유형의 DLQ를 각각 생성한다.
SQS에는 리드라이브 허용 정책, 배달 못한 편지 대기열 이라는 속성이 있다. 각 속성에 대해 알아보자.
리드라이브 허용 정책
DLQ로 사용할 큐일경우 활성화한다. SourceQ 로 부터 이벤트를 받을 수 있게하는 속성이다.
SourceQ 화이트리스트로 생각하면 된다.
- 모두 허용 : 모든 SourceQ 허용
- 대기열 기준 : SourceQ 지정
- 모두 거부 : 모든 SourceQ 거부 (DLQ가 아닌게 아닌가?)
그리고 SourceQ 상세에서 배달 못한 편지 대기열 을 지정한다.
배달 못한 편지 대기열 를 활성화하고 DLQ를 지정한다.
위와같이 설정 후 워커에서 에러를 발생시키면 재시도 반복 후 DLQ로 메시지가 이동되는것을 확인할 수 있다.
DLQ 상세에서 리드라이브를 실행시킬 수 있다.
DLQ Slack 알림 푸시
DLQ에 메시지가 있으면 Slack으로 메시지를 푸시해 모니터링 하려고한다.
Cloud Watch -> SNS -> Lamda -> Slack
지표 설정
클라우드워치 경보 메뉴에서 어떤 지표를 기준으로 경보를 발생시킬지 지표를 선택한다.
DLQ에 대기중인 메시지가 있는경우 를 기준으로 하기위해
위 지표를 사용했다.
SNS 주제 선택
경보 발생 시 이벤트를 전달할 SNS 주제를 선택한다.
(선택) 이메일 연동
SNS 주제에 이메일 구독을 함께했다면 구독을 확정해야 정상적으로 이메일을 수신할 수 있다.
Confirm subscription 을 누르면 된다.
만약 이메일 구독이 필요하지 않다면, 위 주제에 대한 이메일 구독을 삭제하면 된다.
Lamda 함수 연결
SNS 주제를 구독하고 Slack으로 알림을 푸시하는 Lamda 함수를 정의한다.
블루프린트에 정의된 코드를 사용하면 더 손쉽게 구성이 가능하다.
SLACK_CHANNEL 등 필수적이지 않은 변수는 제거해도된다.
Slack WebhookUrl을 복사해서 환경변수에 입력하고, kms에서 생성한 키로 암호화한다.
Lamda 함수를 정의했으니 Cloud Watch 에서 연동한다.
경보 이름등을 설정하고나면 끝이다.
정의한 임계치는 1이다. 연결된 DLQ에 1개 이상의 대기중인 메시지가 있으면 Slack으로 알람을 푸시한다.
실시간은 아니고 약 1~2분 정도의 텀이있다.
검증
DLQ 로 메시지를 이동시키기 위해 에러를 발생시킨다.
임계치에 도달하면
정상적으로 알람이 전송된다.
그리고, DLQ 에서 리드라이브를 하며 이벤트를 정상완료 처리하면 경보 상태 에서 정상 으로 수정된다.
