Today I Learned
날짜
2025년 2월 5일 수요일
내용
SQS 메시지의 수명과 전송지연
어제 저녁부터 들어온 웹훅 메시지들을 아침에 확인해봤다. 메시지 수명이 뭔가 꺼림칙하다.
저 60초선에 닿으면 뭔일이라도 나는 것마냥 구는 저 그래프가 참으로 거슬린다. 혹시 저 시간이 지난 메시지들이 삭제되는 것이 아닌지 확인할 필요가 있다는 팀장님의 제보를 받고 확인해보았는데 데이터는 잘 들어오고 있다.
어제 오후 7시부터 SQS에 들어온 메시지의 갯수 그래프다. 38만 개 정도 된다. 7시부터인 이유는 어제 오후 7시에 Redis 를 한번 초기화해버렸으니까..
현재 Redis에 저장된 38만개! 놓치지 않고 잘들어오고있다.
그럼 첫 그래프가 저렇게 생겨먹은 이유는 뭘까? 그것은 전송지연.
SQS에는 전송지연이라는 기능이 있는데, 메시지가 들어오면 실제로 큐에 넣기까지 대기시간을 두는것이다. 카페24에서 웹훅이 발생하고나서 실제 데이터가 변경되기 까지 60초의 시간이 걸리기 떄문에 웹훅이 들어오더라도 60초 후에 처리해야 한다. 따라서 큐에 60초 전송지연이 있는데 이 시간이 메시지 수명에 포함되었다. 따라서 60초동안은 큐에 들어오지 않아 처리되지 않는다. 60초가 지나는 순간 트리거가 발생하면서 처리된다. 바꿔 말하면, 모든 메시지는 최소 수명이 전송지연만큼은 보장된다는 의미다.
테스트서버에서 전송지연을 7초로 설정하고 메시지를 아주 천천히 보내봤더니 이렇게 뜬다. 생명주기가 7초에서 더 늘어나지 않는다. 전송지연 시간이 지내자마자 처리되어 사라졌으니까. 그런데 저 7초 후에 나타나는 5라는 값은 무엇인가? 모든 메시지의 생명주기는 7초가 보장되어야 하는거 아닌가? 모든 메시지가 최소한 전송지연만큼은 수명을 가진다면 그 이하 값이 존재할 수 없는 것 아닌가?
저 그래프는 ‘가장 오래된 메시지’의 수명이다. 메시지 A가 들어오고 20초 후에 메시지 B가 들어왔다. 60초후에야 A가 처리된다. 따라서 60초 시점에 ‘가장 오래된 메시지’는 A고 이것의 수명은 60초다. 1초 후, 메시지 A는 처리되어 큐에서 사라진다. 그럼 B는 전송지연이 41초 진행된 상태가 된다. 이떄 가장 오래된 메시지는 B고, 이 메시지의 수명은 41초다. 그러니 전송 지연 시간보다 낮은 값이 떴다.
저 경우에도 2초에 한번 메시지를 보냈다. 그러니 첫번째 메시지가 소비되고 두번쨰 메시지가 전송지연이 5초 만큼 진행된 상태의 값이 반영된 것이다.
회고
안되는 줄 알고 깜짝 놀랐다.
