[SAA] SQS

SQS – Message Visibility Timeout

• 소비자가 메시지를 폴링하면 그 메시지는 다른 소비자에게 보이지 않음
• 예) 왼쪽에서 오른쪽으로 가는 시간이 있을 때
  소비자가 ReceiveMessag 요청을 한 후 대기열에 메시지가 반환됨
  이제 가시성 시간 초과가 시작되며 기본값으로 메시지 가시성 시간 초과는 30초이므로 30초 동안 메시지가 처리되어야 함
  이 때 동일한 혹은 다른 소비자가 메시지 요청 API를 호출하거나 또 다른 요청이 들어와도 메시지가 반환되지 않음
  만약 가시성 시간 초과가 경과되고 메시지가 삭제되지 않았다면 메시지를 다시 대기열에 넣은 후
  다른 소비자나 동일한 소비자가 eceiveMessag 요청을 하면 이전의 그 메시지를 또 받게됨
  
  
  

  

  가시성 시간 초과 기간 내에 메시지를 처리하지 않으면 메시지가 두 번 처리될 수 있음

• 소비자가 메시지를 적극적으로 처리하고 있지만 메시지를 처리하는데 시간이 더 필요하다면
  메시지를 처리하지 않아 가시성 시간 초과 기간을 벗어날 때를 위해 ChangeMessageVisibility API 호출하여 SQS에 알려
  그 메시지를 보이지 않게 한 후 메시지를 처리할 시간을 조금 더 얻게 되어 처리할 수 있음
• 기본값을 매우 높은 값으로 설정하면 소비자가 충돌했을 때 메시지가 다시 SQS 대기열에 보이기까지 몇 시간이 걸리며,
  반면 매우 낮은 값으로 설정하면 소비자가 해당 메시지를 처리할 시간이 충분하지 않으므로
  다른 소비자가 메시지를 여러 번 읽게 되어 중복 처리될 수 있으므로 합당한 시간으로 결정한 후
  필요에 따라 ChangeMessageVisibility API를 호출하도록 프로그래밍해야 함

<SQS - 메시지 가시성 시간 초과 실습>

• 메시지 가시성 시간 초과 작동
  작동을 보기 위해 메시지 보내기와 메시지 받기를 위한 창을 두 개 연 후 메시지를 대기열로 보냄
  대기열의 기본 제한 시간은 30초이며 소비자가 두 명일 때
  첫 번째 소비자가 Poll for messages로 메시지를 수신하고 두 번째 소비자가 Poll for messages를 하면 메시지가 뜨지 않음
  그 이유는 메시지가 가시성 시간 초과 기간 내에 있기 때문이며
  이 메시지는 30초동안 첫 번째 소비자가 처리하려고 하고 있어 두 번째 소비자는 볼 수 없음
  이제 30초가 지나 메시지가 시간 초과가 되면 메시지가 대기열에 올라오게 되어 두 번째 소비자에게 수신되게 됨
  
  하지만 만약 첫 번째 소비자가 메시지까지 삭제하여 메시지를 완전히 삭제한 경우에는 두 번째 소비자는 볼 수 없음
  
  이 가시성 시간은 0초에서 12시간까지 설정할 수 있으며 만약 소비자가 메시지를 처리하는데 더 많은 시간이 필요하다면
  ChangeMessageVisibility API를 호출하여 메시지의 가시성을 편집하여 값을 늘릴 수 있음

첫 번째 소비자

두 번째 소비자

Amazon SQS – Dead Letter Queue

• 예) 소비자가 가시성 시간 초과 내에 메시지를 처리하지 못하는 경우
  오류가 있거나 충분한 시간이 없게 되어 메시지가 자동으로 대기열로 돌아가게 되어 메시지를 다시 읽게 될 때
  메시지에 문제가 있게 된다면 소비자가 메시지를 이해하지 못했거나 처리하지 못해 다시 대기열로 돌아가는 과정을 반복
• 이 때 몇 번 반복할지 최대 수신 임계값을 설정할 수 있으며 해당 임계값을 초과하면 SQS가 메시지가 이상함을 감지할 수 있으며
  많은 처리 시도가 있었지만 성공하지 못했기 때문에 메시지를 데드 레터 대기열로 보내게 되고
  데드 레터 대기열에는 나중에 처리할 수 있도록 그 메시지가 포함되고, SQS 대기열에서 제거됨
  
  

  

• 데드 레터 대기열은 디버깅에 유용하며 일부 메시지를 처리하지 못하여 데드 레터 대기열(DLQ)로 보낼 수 없으면
  애플리케이션을 통해 이 메시지를 분석하거나 다른 이가 메시지를 분석하여
  애플리케이션이 멈춘 이유나 메시지가 제대로 처리되지 못한 이유를 파악할 수 있음
• 데드 레터 대기열도 SQS 대기열이므로 메시지 보관 기간에 제한이 있어 일정 시점에 만료되므로 높은 보존 기간 설정 필요
  예) 메시지를 읽고 처리하고 처리 실패로 인해 발생한 일을 이해할 수 있는 시간으로 14일 정도를 확보

<SQS - 배달 못한 편지 Queues 실습>

• 데드 레터 대기열 생성
  DemoQueueDLQ라는 이름으로 Standard를 선택하고 메시지는 메시지 보존 기간 동안 오랫동안 유지되어야 하기 때문에
  메시지를 분석하고 잃어버리지 않도록 최댓값인 14일로 변경해 생성
• 대기열 구성
  방금 생성한 대기열을 데드 레터 대기열로 지정하기 위해 이전에 만들어뒀던 DemoQueue 대기열의 설정을 편집
  가시성 시간 초과를 5초 정도로 설정해서 매우 빠르게 돌아가도록 설정하고
  데드 레터 대기열 구성을 활성화한 후 방금 생성한 DemoQueueDLQ를 선택한 후
  DLQ에 최대 몇 개의 메시지가 보내질 수 있는지 설정하기 위해 1에서 1000까지의 숫자로 고름
  만약 메시지를 10번까지 재처리하고 싶다면 10을 넣으면 되지만 이번 실습에서는 빨리 돌아가기 위해 최대 세 번으로 설정
  즉, 메시지를 세 번 받고 다시 SQS 대기열에 올려놓는다면 DLQ로 보내 나중에 문제해결을 하도록 하는 것

• 데드 레터 대기열 작동 확인
  메시지를 작성해 보낸 후 메시지가 3번까지는 수신받지만 계속해서 처리되지 않으면 네 번째에는 수신되지 못함
  그러므로 최대 수신 횟수 임계값을 초과하게 되어 DLQ로 메시지가 보내지고
  DLQ에서 이 메시지를 보고 이 메시지가 애플리케이션을 충돌시키는 이유를 이해해볼 수 있음

Amazon SQS – Delay Queue

• 대기열 지연은 소비자들이 적극적으로 보지 못하도록 메시지를 지연시키는 것으로 15분까지 지연시킬 수 있으며 기본값은 0초
• 원래는 SQS 대기열로 메시지를 보낸 직후부터 메시지를 읽을 수 있지만
  모든 메시지를 몇 초만큼 지연시킬 것인지 대기열 레벨에서 기본값을 지정하거나
  또는 매번 메시지를 보낼 때마다 DelaySeconds 파라미터를 사용하여 메시지별 지연 시간을 지정할 수 있음
• 예) 메시지 지연 시간이 30초라고 할 때
  30초 후에 소비자가 메시지를 불러오면 메시지를 성공적으로 수신하게 됨
  
  

  

<SQS - Queues 지연 실습>

• 지연 대기열 생성
  DelayQueue라는 이름으로 대기열을 생성하며 Delivery delay라는 설정을 기본값 0초, 최댓값 15분에서 10초로 설정
  10초로 설정해두었기 때문에 메시지는 10초를 기다린 후에 소비자가 읽을 수 있도록 전달될 것임
• 지연 대기열 작동 확인
  메시지 발신 후 10초를 기다리게 되면 소비자에 도착하며 메시지 발신 시점과 실제 도착 시점 자이에 지연이 존재함을 알 수 있음

Amazon SQS - Long Polling

• 소비자가 대기열에 메시지를 요청하는데 대기열에 아무도 없다면 메시지 도착을 기다리면 되는 것이 롱 폴링 
• 지연 시간을 줄이고 SQS로 보내는 API 효출 숫자를 줄여 최적화하기 위해 사용
• SQS 대기열이 있고 소비자가 대기열에 폴링을 최대 20초 동안 하게 되면 만약 대기열이 비어 있다면 그냥 기다린 후
  메시지가 대기열에 막 도착할 때 소비자가 여전히 롱 폴링 중이라면 자동적으로 그 메시지가 소비자에게 전송되어 빨리 받게 됨
• 롱 폴링은 SQS로의 API 호출 숫자를 줄이며 애플리케이션의 효율성과 대기 시간을 증가시킴
• 1초부터 20초 사이로 구성이 가능하며 더 길어질수록 좋음
• 롱 폴링을 구성하는 방법에는 두 가지가 존재
  1) 롱 폴링을 활성화하는 방법
  2) WaitTimeSeconds를 지정함으로 소비자가 스스로 롱 폴링을 하도록 설정

SQS – Request-Response Systems

• SQS를 통해 요청-응답 시스템을 시행하는 방법
• 요청자인 여러 생산자들은 모든 요청을 요청 대기열로 보내어 요청자와 응답을 분리하고
  중간에서 SQS를 이용해 요청 및 응답의 양을 스케일링할 수 있고, 응답자가 있는 곳은 오토 스케일링 그룹이라 함
  [Requesters - Producer] - [Request Queue] - [Responders - Auto Scaling Group]
• 생산자에게 응답할 때는 또다른 대기열에 응답을 넣는 방법을 사용하며 생산자가 메시지를 SQS 대기열에 보낼 때
  상호 관련 ID를 함께 보내며, 그 ID는 요청 번호와 요청의 내용 및 응답할 대기열을 나타냄
  예) 이 메시지를 받으면 응답 대기열1로 응답하세요라는 요청의 내용
  [Requesters - Producer1] - Send request(Correlation ID) -> [Request Queue] -> [Responders - Auto Scaling Group]
• 그후 응답자는 요청 대기열을 읽고 해당 요청을 처리해서 응답을 생성하며,
  그 대기열이 존재하지 않으면 응답 대기열1을 생성한 후 이전의 상호 관련 ID를 함께 전송하여
  생산자는 각각 어떤 응답이 어떤 요청에 대응하는지 알 수 있어 응답 페이로드를 이해할 수 있게 됨
  [Responders - Auto Scaling Group] - Send response(Correlation ID) -> [Response Queue1]
• 그런 후 생산자는 응답 대기열 1을 읽고 해당 응답을 수신하게 됨
  [Response Queue1] - Response -> [Requester]
• 중간에 확장 가능한 백엔드가 있어 수많은 다양한 요청과 다양한 응답을 전송할 수 있어 대상 시스템에 과부화를 주지 않음
• 두 번째 생산자가 여전히 같은 요청 대기열을 통해서 요청을 생산하게 되더라도 응답은 응답 대기열2로 달라지게 되고
  응답자는 응답 대기열2로 응답하여 생산자2는 필요한 응답을 얻기 위해 해당 대기열을 읽게됨
• SQS를 사용해서 시행할 수 있는 유형이며 요청-응답 시스템 아키텍처라고 함
  
• 요청-응답 시스템은 SQS Temporary Queue Client으로 SQS 임시 대기열 클라이언트라고도 불리는 것을 사용해 시행하며,
  실제 SQS 대기열을 만들고 없애는 대신 가상의 대기열을 활용하므로 비용 면에서도 효율적
  
  

  

Amazon SQS – FIFO Queue

• SQS에서 사용 가능한 다른 종류의 대기열로, FIFO는 선입선출이라는 뜻이므로
  대기열에 첫 번째로 도착한 메시지가 대기열을 떠날 때도 첫 번째가 되돌고 대기열 내의 순서가 정렬된다는 의미
  그러므로 표준 대기열보다 더 확실히 순서가 보장됨
• 생산자가 SQS 대기열로 메시지를 보낼 때,
  SQS FIFO 대기열은 소비자가 SQS 대기열로부터 메시지를 불러올 때 정확히 동일한 순서로 메시지를 받게 해 줌
  
  

  

• 순서에 대한 강제적 보장이 존재하기 때문에 SQS 대기열은 제한된 처리량을 가지므로 많은 메시지를 보내지 않도록 해야하며
  묶음이 아닐 경우에는 초당 300개의 메시지를 처리하고 메시지를 묶음으로 보낼 경우 초당 3000개를 처리
• 중복을 제거하도록 해주는 SQS FIFO 대기열의 기능으로인해 정확히 한 번만 보낼 수 있게 해 줌
• 메시지는 소비자에 의해 순서대로 처리되므로 분리가 발생하거나 메시지의 순서를 유지할 필요가 있을 때 FIFO 대기열을 사용

<SQS - FIFO Queues 실습>

• FIFO 대기열 생성
  DemoQueue.fifo로 설정하며 fifo의 경우 이름이 .fifo로 끝나야 대기열을 만들 수 잇음
  구성은 이전과 매우 비슷하지만 Content-based deduplication이라는 설정이 추가되었음
  이는 5분 이내의 짧은 시간 동안 동일한 메시지가 두 번 발송됐을 경우 중복을 방지하기 위한 설정임
• FIFO 대기열 작동 확인
  메시지를 작동한 후 Message group ID, Message deduplication ID를 설정할 수 있음
  실습 전반에 걸쳐 같은 메시지 그룹 ID를 사용하도록 설정하며 첫 번째 메시지이므로 Message diduplication ID를 1로 설정 
  그 이후 다시 두 번째 메시지를 보낼 때는 중복 방지를 위해 Message diduplication ID를 2로 설정 
  이 후 세 번째 메시지와 네 번째 메시즐 보낼 때는 3와 4로 설정
  
  이제 네 개의 메시지를 전송했으므로 네 개의 메시지를 수신 가능한 상태가 되므로 메세지를 불러오면 볼 수 있음
  불러온 메시지의 순서와 정보를 보게 되면 Hello World 1 2 3 4이므로 순서를 보장함을 알 수 있음

SQS with Auto Scaling Group (ASG)

• SQS를 오토 스케일링 그룹과 통합할 수 있음
• 오토 스케일링 그룹이 있고 EC2 인스턴스가 있으며 인스턴스는 SQS 대기열에서 메시지를 폴링하고 있을 때
  EC2 인스턴스의 숫자를 대기열의 메시지 양에 따라 스케일링할 수 있음
  대기열에 더 많은 부하가 걸려있다면 EC2 인스턴스에 더 많은 용량을 할당할 것이며
  부하가 적으면 오토스케일링 그룹을 통해 EC2 인스턴스의 일부를 종료
• 작동 원리상 지표를 사용해서 알람에 따라 오토 스케일링 그룹을 스케일링하므로
  EC2 인스턴스는 CloudWatch 사용자 지정 지표인 대기열의 길이를 푸시
  대기열의 길이 = 처리를 기다리는 메시지의 수 / 오토 스케일링 그룹의 인스턴스 개수
  
• 메시지가 너무 많거나 인스턴스가 부족한 것과 같이 지표가 특정 임계값을 위반되는 경우를 위해 CloudWatch 경보를 생성하면
  CloudWatch 경보가 자동으로 오토 스케일링 그룹의 스케일링 정책에 할당되고 그에 따라 적절하게 스케일링 
• 예) 지표의 특정 임계값을 넘을 경우의 경보와 임계값 아래로 내려갈 경우의 경보
  
  

  

  
  

SQS to decouple between applicaion tiers

• SQS를 오토 스케일링 그룹과 통합하는 것은 애플리케이션 티어에서 분리를 위해 자주 쓰이는 기능
  
• EC2 인스턴스에 다량의 요청이 들어오면 요토 스케일링 그룹이 관리하게 되며
  파일을 처리하라는 요청을 받을 경우 이 요청들을 SQS 대기열에 넣게 되며 대기열은 무한대로 스케일링됨
• EC2 인스턴스는 또 다른 오토 스케일링 그룹이 관리하게 되어 대기열 뒤에서 대기열로부터 폴링을 하게 됨
• 위를 통해 매우 큰 확장성을 가지고 완전히 분리된 아키텍처를 얻을 수 있음