AWS SQS(Simple Queue Service)

SQS(Simple Queue Service)는 fully managed service로 서로 다른 시스템을 이벤트 방식으로 처리하기 위해 사용한다. 메시지를 생성하는 producer, 데이터를 연결하는 queue, 메시지를 가져가는 consumer로 구성된다.

 

구성

producer는 최대 256kb의 메시지를 만들어 SQS에 보낸다. 

consumer는 long polling 방식으로 SQS로부터 메시지를 받아온다. 대기하고 있는 메시지가 많아도 최대 10개까지만 받아온다.

 

메시지를 받아온 후 모든 처리를 했으면 받아온 메시지를 id를 삭제하기 위해 메시지 id를 SQS로 전달한다.

polling 후 삭제하기 전까지 다른 consumer가 같은 메시지를 가져가지 못하게 하기 위해 해당 메시지는 SQS에서 invisible 상태가 된다. 처리를 완료한 후 consumer에서 삭제 요청을 보내면 비로소 처리가 완료된다.

주의해야 할 점은 삭제 요청이 오지 않아도 visibility timeout이 지나면 visible 상태로 바뀐다. consumer에서 메시지를 처리하는 작업에 따라 적절한 visibility timeout을 설정해야 한다.

 

이렇게 consumer에서 처리에 실패해서 다시 visible 상태로 바뀌면 다시 consumer가 가져갈 수 있다. 하지만 실패 원인이 메시지에 있으면 어떤 consumer가 가져가도 실패할 것이고 visible -> invisible -> visible -> invisible 상태가 반복될 것이다.

실패가 RedrivePolicy.maxReceiveCount 만큼 반복되면 메시지는 Dead-Letter Queue로 옮겨진다. 이 경우는 DLQ에서 메시지를 확인해서 원인을 파악해야 한다.

 

delay 기능을 추가해서 producer가 보낸 메시지를 최대 15분까지 보관했다가 consumer에게 전달하게 할 수 있다.

 

SQS는 성능과 기능에 따라 구현된 다른 queue type이 있다.

 

Standard Queue

producer 쪽에서 storage 걱정 없이 메시지를 보내도 된다. consumer는 10ms 내의 빠른 속도로 메시지를 받아간다. 

 

만능처럼 보이지만 이렇기 때문에 발생하는 요소들이 있다.

아주 가끔씩 메시지가 중복될 수 있다. producer가 메시지 하나를 보내도 consumer 쪽에서 두 번 가져갈 수 있기 때문에 retry에 치명적인 메시지라면 별도로 중복 검사를 하거나 다른 디자인을 생각해 봐야 한다. 또한 producer가 보낸 순서대로 consumer가 가져간다는 보장이 없다.

이런 문제점들은 SQS를 설계하며 생기는 어쩔 수 없는 단점이다.

 

 

FIFO Queue

Standard Queue의 단점을 보완해준다.

producer가 메시지를 보내면 한 번만 consumer에게 전달하고, 메시지의 순서도 보장된다. 이런 디자인에 따라 처리량은 standard queue에 비해 떨어진다.

 

ContentBasedDeduplication 속성으로 producer가 전달한 메시지와 같은 메시지가 이미 queue 안에 있을 경우 중복을 막아주는 옵션이 있다.