이번 포스팅에서는 실제로 Amazon SQS를 만들어보는 시간을 가져보도록 하겠습니다.
먼저 AWS 공식 홈페이지로 가서 AWS console에 Simple Queue Service를 검색해보겠습니다.
AWS console 검색
대기열 생성
Simple Queue Service에 들어가셔서 대기열 생성을 버튼을 클릭해줍시다!
대기열 버튼을 누르시면 대기열 생성 메뉴얼이 뜨는 것을 확인하실 수 있습니다. 여기서 대기열 세부 정보들을 설정하시면 됩니다.
대기열 세부 정보 설정
먼저 대기열 유형을 고르셔야 합니다. 종류는 표준형, FIFO형이 있습니다.
표준형과 FIFO형의 차이를 알고 싶으신 분은 아래 링크로 들어가셔서 확인하실 수 있습니다.
저희 프로젝트에서는 메시지의 순서가 중요한 사안이 아니기 때문에 속도나 비용적인 측면에서 유리한 표준형을 사용하기로 하였습니다.
SQS 이름은 프로젝트 이름을 따서 evertripqueue로 작성하였습니다.
구성 설정
다음 구성 설정에서 선택할 수 있는 옵션에 대해 알아보도록 하겠습니다.
1. 표시 제한 시간
한 메시지 소비자가 대기열에서 수신한 메시지를 다른 메시지 소비자가 볼 수 없도록 설정해둔 시간입니다.
예를 들어, Queue가 하나 있고 해당 Queue에서 메시지를 받는 서버가 2대가 있을 경우, 한 서버에게 메시지를 수신하고 나서 정해둔 시간(표시 제한 시간)만큼 다른 서버에서 해당 메시지를 볼 수 없다는 걸(수신할 수 없다)로 이해할 수 있습니다.
표시 제한 시간 = visibility timeout
2. 메시지 보존 기간
SQS가 삭제되지 않은 메시지를 보관하는 시간을 의미합니다.
서버가 메시지를 수신하여 로직을 처리하고 큐에게 그 메시지를 삭제하라는 요청을 보내야 하는데, 해당 삭제 요청이 오지 않은 경우 큐 입장에서는 메시지를 삭제하지 않습니다.
여기서 설정한 시간(메시지 보존 기간)이 지날 시 자동으로 해당 메시지를 삭제하게 됩니다.
3. 전송 지연
메시지가 큐에 추가되고 나서 실제로 메시지가 수신 가능해지기까지의 지연 시간을 설정하는 것입니다. 이 옵션을 사용하면, 메시지를 큐에 보낸 직후 바로 메시지를 받을 수 없게 하고, 지정한 지연 시간이 지난 후에만 메시지를 수신할 수 있게 됩니다.
표준 큐: 설정한 전송 지연은 큐에 새로 추가되는 모든 메시지에 적용됩니다. 즉, 각 메시지는 지연 시간만큼 큐에서 대기하게 됩니다.
FIFO 큐: FIFO 큐에서는 전송 지연이 그룹 단위로 적용되어, 같은 그룹 내의 메시지들이 지연 시간 후에 차례대로 처리됩니다.
4. 최대 메시지 크기
전송하려는 메시지의 최대 크기를 설정할 수 있으며, 만약 256kb가 넘는 경우에 Amazon SQS Extended Client Library를 사용하여 S3와 함께 사용할 수 있다고 합니다.
5. 메시지 수신 대기 시간
메시지 폴링이 메시지를 사용할 수 있을 때까지 대기하는 최대 시간을 의미합니다.
SQS가 메시지를 수신하려고 요청할 때, 설정한 시간 동안 새 메시지가 도착할 때까지 대기하도록 합니다.
저는 메시지 크기가 그렇게 크지 않기 때문에 20KB로 적당히 설정하였고 나머지 값들도 너무 크지 않는 값으로 설정하였습니다.
암호화 설정
서버 측 암호화(SSE, Service Side Encryption)를 활성화하면 SQS는 Queue에 들어오는 메시지들을 모두 암호화하게 됩니다. 권한이 있는 소비자(Consumer)에게 전송되는 경우에만 메시지가 해독됩니다.
들어오는 메시지의 본문은 암호화하지만, 1) Queue의 메타 데이터 2) 메시지의 메타 데이터 3) Queue의 지표들을 암호화되지 않습니다.
액세스 정책
액세스 정책은 Queue에 접근할 수 있는 정책을 의미하며 대기열 소유자로 체크하고 AWS 접근 권한을 추가해주는 방식으로 진행하였습니다.
리드라이브 허용, 배달되지 못한 편지 설정
리드라이브 허용 정책을 설정할 때는 몇 번의 시도 후에 메시지를 배달 못한 편지 대기열로 보낼지 설정할 수 있습니다.
배달 못한 편지 Queue(DLQ - Dead Letter Queue)는 메시지를 소비할 수 없는 경우 사용됩니다. 배달 못한 편지 Queue를 사용하게 되면 문제가 있는 메시지를 격리하여 실패 원인을 확인할 수 있습니다.
FIFO Queue의 DLQ는 FIFO Queue여야하고 표준 Queue의 DLQ는 표준 Queue여야 합니다.
DLQ가 설정되어 있는 경우의 동작 방식은
-
Queue의 메시지를 메시지 소비자가 큐에서 메시지를 가져가 처리를 시도합니다. 만약 처리에 실패하면, 그 메시지는 다시 큐로 돌아가고
receive_count라는 횟수가 하나씩 누적됩니다.receive_count는 메시지가 소비자에 의해 몇 번이나 시도되었는지를 나타냅니다. -
receive_count횟수가 최대치(max_receive_count)를 초과하는 경우 해당 메시지를 일반 큐에서 DLQ로 이동시킵니다.
메시지가 일반 큐에서 DLQ로 이동할 때, 그 메시지의 생성 시간 타임스탬프는 변경되지 않습니다. 즉, 메시지가 최초 생성된 시간이 유지된다는 의미입니다.
따라서, DLQ에서 메시지를 보관하는 시간(보존 기간)은 원래 큐의 보존 기간보다 길게 설정해야 할 수 있습니다. 왜냐하면 메시지가 처음 생성된 후 많은 시간이 흘렀을 수도 있기 때문입니다.
우선 둘 다 비활성화 해두었고 나중에 생산자, 소비자, 애플리케이션까지 만든 다음 동작을 확인하면서 해당 설정들을 활성화하여 어떤 변화가 있는지에 대해서도 확인해보겠습니다.
Queue 생성 클릭
생성하기를 클릭하시면 아래와 같이 정상적으로 SQS가 생성되었음을 확인하실 수 있습니다.
권한 추가
저는 이미 사용자와 권한을 만들어두었기 때문에 거기에 SQS Access에 대한 권한만 추가해주면 되었습니다.
IAM 사용자의 권한으로 가셔서 직접 정책 연결을 선택하신 후 AmazonSQSFullAccess 정책을 추가해주시면 끝입니다!
참고 자료
lannstark님 블로그
