[AWS SQS 들이파기] SQS 만들어보기

1. AWS console에서 SQS를 검색해 들어갑니다.

2. 대기열 생성을 눌러줍니다.

Amazon SQS > 대기열이라고 있는데, Queue를 대기열로 번역했네요. 뭔가 어색합니다 ㅋㅋㅋㅋ

3. 대기열 세부정보 설정

가장 먼저 나오는 것은 대기열 유형을 표준으로 고를지, FIFO로 고를지에 관한 것입니다.

둘의 가장 큰 차이점으로는 크게 4가지가 있습니다.

• 순서 : 표준 Queue는 순서를 가능한 보장하려 하나 항상 보장되는 것은 아니지만, FIFO Queue는 순서를 무조건 보장합니다.
• 특정 메시지 전송 횟수 : 표준 Queue는 메시지큐에 쌓여있는 메시지를 최소 1회 전송하지만, 가끔 한 개 이상의 메시지 사본이 배달될 수 있습니다. 때문에 메시지를 Application에서 idempotent을 유지해야 합니다. 하지만 FIFO는 정확히 1회만 전송합니다.
• 속도 : 표준 Queue는 무제한, FIFO는 300~3000msg/s 제한이 있습니다.
• 리젼 : 표준 Queue는 모든 region에 존재하고, FIFO는 지원되는 region이 정해져 있습니다.

우선 표준으로 만들 선택하고 진행해보겠습니다.

이름에는 sqs-study 라고 적었습니다 ㅋㅋ

 

4. 구성 설정

산넘어 산이네요... 각각의 의미를 알아보겠습니다.

• 표시 제한 시간 : 한 메시지 소비자가 대기열에서 수신한 메시지가 다른 메시지 소비자에게 보이지 않게 되는 시간. 그러니까 Queue가 하나 있고 해당 Queue에서 메시지를 받는 서버가 2대 있으면, 한 서버에게 메시지가 가고 나서 정해둔 시간만큼은 다른 서버에게 그 메시지를 보내지 않는다로 이해할 수 있습니다.
• 메시지 보존 기간 : SQS가 삭제되지 않은 메시지를 보관하는 시간. 서버가 메시지를 받아서 무언가 처리하고 큐에서 그 메시지를 삭제하라는 요청을 해야 하는데, 그 삭제 요청이 오지 않은 경우 큐 입장에서는 메시지가 처리되었는지 처리되지 않았는지 모르므로 일단 삭제를 하지 않습니다. 그리고 여기서 설정한 특정 시간이 지나면 자동으로 해당 메시지를 삭제하게 됩니다. (서버가 아예 메시지를 가져가지 않았을 수도 있고요..)
• 전송 지연 : 대기열에 추가된 각 메시지의 첫 번째 전송에 대한 지연시간. 일부러 첫 번째 전송을 늦추고 싶은 경우 전송 지연을 설정할 수 있습니다. 표준 큐는 소급적용되지 않고 FIFO 큐는 소급적용 됩니다.
• 최대 메시지 크기 : 전송하려는 메시지의 최대 크기를 설정할 수 있으며, 만약 256kb가 넘는 경우에는 Amazon SQS Extended Client Library를 사용해 S3와 함께 사용할 수 있다고 합니다.
• 메시지 수신 대기 시간 : 폴링이 메시지를 사용할 수 있을 때까지 기다리는 최대 시간.

오호 어떤 뜻인지 이해했습니다. 권장되는 default 값이 설정되어 있으니 필요한 경우에 추가 설정을 진행하면 될 것 같습니다 ^^

5. 엑세스 정책 설정

말 그대로 Queue에 접근할 수 있는 Access Policy 인데 대기열 소유자로 체크하고 넘어가려고 합니다.
AWS의 접근권한 관련해서는 IAM 쪽에서 다뤄볼 예정입니다.

6. 암호화, 배달 못한 편지 대기열

서버측 암호화(SSE, Service Side Encryption)를 활성화하면 SQS는 Queue에 들어오는 메시지들을 모두 암호화하게 됩니다. 권한 있는 소비자에게 전송되는 경우에만 메시지가 해독됩니다. 들어오는 메시지의 본문은 암호화하지만, 1) Queue의 메타데이터 2) 메시지의 메타데이터 3) Queue의 지표 들은 암호화되지 않습니다.

SSE를 활성화하면 AWS KMS(Key Management Service)를 이용하여 대기열 메시지 내용을 보호하게 됩니다. (앗 봐야할게 하나 늘었다 ^^,,,)

배달 못한 편지 Queue(DLQ)는 메시지를 소비할 수 없는 경우 사용됩니다. 배달 못한 편지 Queue를 사용하게 되면 문제가 있는 메시지를 격리하여 실패 원인을 확인할 수 있습니다. (디버깅시 유용) FIFO Queue의 DLQ는 FIFO Queue여야하고 표준 Queue의 DLQ는 표준 Queue여야 합니다.

DLQ가 설정되어 있는 경우의 동작 방식은 이렇습니다. Queue의 메시지를 메시지 소비자가 가져가서 처리하지 못하는 경우 그 횟수(receive_count)가 누적되는데 횟수가 최대치(max_receive_count)를 초과하는 경우 해당 메시지는 DLQ로 이동합니다. 메시지의 타임스탬프가 변경되지는 않으며, 때문에 DLQ의 보존 기간은 source Queue의 보존 기간보다 길어야 합니다.

우선은 둘 다 비활성화 해두고, 생산자, 소비자 애플리케이션까지 만들어서 동작을 확인한 다음에 활성화되었을때 어떤 변화가 있는지 확인해볼 예정입니다.

7. Queue 생성!

생성 완료!

 

전체 시리즈 보러가기 : lannstark.tistory.com/88

AWS SQS 들이파기