[SAA] Amazon SQS - 표준 Queues 개요

Amazon SQS What’s a queue?

• SQL의 핵심은 대기열이며, SQS는 간단한 대기 서비스를 뜻하고 SQS 대기열에는 메시지가 포함됨
• 메시지를 담기 위해서는 무언가 SQS 대기열에 메시지를 전송해야 하는데 이를 생산자라고 하고
  생산자는 한 개일 수도 있고, 그 이상일 수도 있음
• 메시지는 무엇이든 상관없으며 생성한 모든 메시지는 대기열에 들어가게 되고 다음 대기열에서 메시지를 처리
• 수신해야 하는 대상은 소비자라고 하며 소비자는 대기열에서 소비자 앞으로 온 메시지가 있는지 물어보기 위해 메시지를 폴링
  만약 대기열에 메시지가 있으면 소비자는 이 메시지를 폴링해서 정보를 얻고 그 메시지가 처리되면 대기열에서 메시지를 삭제
• 여러 소비자가 SQS 대기열에서 메시지를 소비할 수 있도록 할 수 있음
• 즉, 대기열 서비스는 생산자와 소비자 사이를 분리하는 버퍼 역할을 하는 것

  

Amazon SQS – Standard Queue

• SQS는 복잡한 서비스이며 가장 먼저 제공되는 것이 표준 대기열용 Amazon SQS
• SQS는 AWS에서 제공하는 가장 오래된 서비스로 첫 번째 서비스 중 하나였음
• 완전 관리형 서비스이며 애플리케이션을 분리하는데 사용
• 무제한 처리량을 얻을 수 있으므로 초 당 원하는 만큼 메시지를 보낼 수 있고 대기열에도 원하는 만큼 메시지를 포함시킬 수 있음
  즉, 처리량에 제한이 없고 대기열에 있는 메시지 수에도 제한이 없음
• 메시지는 수명이 짧으므로 기본값으로 4일 동안 대기열에 남아 있고 대기열에 있을 수 있는 최대 시간은 14일
  즉, 대기열에 메시지를 보내자마자 소비자가 읽고 해당 보존 기간 내에 처리한 후 대기열에서 삭제해야 함
  그렇지 않는다면 소실되게 됨
• 지연 시간이 짧아서 SQS는 메시지를 보내거나 SQS에서 메시지를 읽을 때마다 10ms초 미내로 매우 빠르게 응답을 받게 됨
• SQS의 메시지는 크기가 작아야 하므로 전송된 메시지당 256KB 미만이어야 함
• SQS는 대기열 서비스이므로 높은 처리량, 높은 볼륨 등이 있어서 중복 메시지가 있을 수 있음
  그러므로 메시지가 두 번 전송되는 경우가 있으므로 적어도 한 번의 전송(at least once delivery, occasionally)이라고 함
• 최선의 오더(best effort ordering)라는 뜻으로 품절 메시지를 보낼 수 있으며 그 제한을 처리하는 SQS 유형 제품이 존재

SQS – Producing Messages

• 최대 256KB의 메시지가 생산자에 의해 SQS로 전송됨
  
  

  

• 생산자는 SDK 소프트웨어 개발 키트를 사용해 SQS에 메시지를 보내며, SQS에 메시지를 보내는 API를 SendMessage라고 함
• 메시지가 작성되면 소비자가 해당 메시지를 읽고 삭제할 때까지(처리될 때까지) SQS 대기열에 유지
• 메시지 생성 예)
  패킷과 같은 오더를 처리한 다음 센터로 전송할 때 원하는 시간에 이 작업을 수행하여
  오더 ID, 고객 ID, 원하는 속성(주소 등) 등의 일부 정보가 포함된 메시지를 SQS 대기열로 전송하게 되면
  애플리케이션 권한이 있는 소비자는 해당 메시지 자체를 처리

SQS – Consuming Messages

• 소비자는 일부 코드로 작성해야하는 애플리케이션이며 이 애플리케이션은 EC2 인스턴스(가상 서버)에서 실행될 수 있으며
  원하는 경우 자체 온프레미스 서버에서 실행할 수 있고 람다 함수(서버가 없는 컴퓨터 유형의 서비스)에서도 실행 가능
• 대기열에는 소비자가 있고 소비자는 대기열에 자신의 앞으로 온 메시지가 있는지 묻기 위해 SQS 메시지를 폴링
  소비자는 한 번에 최댜 10개의 메시지를 받을 수 있고 SQS 대기열에 메시지가 있으면 유효한 응답을 받을 수 있음
• 코드인 소비자는 메시지들을 처리할 책임이 있으므로
  만약 RDS 데이터베이스에 오더를 입력하는 경우 오더들을 RDS 데이터베이스에 삽입하여 메시지를 수신 처리할 수 있으며
  소비자들은 이 후 이 메시지들을 DeleteMessage API로 대기열에서 삭제
  
  

  

SQS – Multiple EC2 Instances Consumers

• SQS 대기열은 메시지를 동시에 수신하고 처리할 소비자를 여러 개 동시에 가질 수 있음
• EC2 인스턴스가 세 가지 있고 각 소비자는 Poll 함수를 호출하여 다른 메시지 세트를 수신하게 되고
  만일 메시지가 소비자에 의해 충분히 빠르게 처리되지 않으면 다른 소비자가 수신하게 되므로 적어도 한 번은 전송이 된다고 함
  그러므로 이는 최선의 노력으로 메시지 순서 지정을 하는 이유 
  
  

  

• 소비자가 메시지를 처리하면 메시지를 삭제해야 다른 소비자가 메시지를 볼 수 없게 됨
• SQS 대기열에서 더 많은 메시지가 있어서 처리량을 늘려야 하면 소비자를 추가하고 수평 확장을 수행해서 처리량 개선 가능

SQS with Auto Scaling Group (ASG)

• 소비자가 ASG의 내부에서 EC2 인스턴스를 실행하고 SQS 대기열에서 메시지를 폴링할 수 있음
• ASG는 일종의 지표에 따라 확장되어야 하는데 이의 경우 지표로 대기열의 길이(ApproximateNumberOdMessages)를 사용
  이는 모든 SQS 대기열에서 쓸 수 있는 CloudWatch 지표
• 대기열의 길이가 특정 수준을 넘어가면 CloudWatch Alarm을 설정할 수 있음 
  예) 알람을 통해 ASG의 용량을 x만큼 증가시키기
  이렇게 증가시킬 경우 더 많은 메시지가 SQS 대기열에 있을 수 있게 됨
  예) 만일 웹사이트에 오더가 폭주했을 경우 ASG이 더 많은 EC2 인스턴스를 제공하여 메시지들을 더 높은 처리량으로 처리
  
  

  

SQS to decouple between application tiers

• SQS는 애플리케이션 계층 간에 분리를 위해 사용됨
• 비디오를 처리하는 애플리케이션이 있을 때
  프론트엔드라는 큰 애플리케이션이 요청을 받고 비디오가 처리되어야 할 때 프론트엔드가 처리를 한 후 S3 버킷에 삽입하게 되면
  처리 시간이 매우 오래 걸릴 수 있고 프론트엔드에서 이를 처리하면 웹사이트의 속도가 느려질 수 있음
  대신 애플리케이션을 분리하여 파일 처리 요청과 실제 파일 처리가 서로 다른 애플리케이션에서 발생할 수 있게 함
  이를 위해 파일 처리 요청을 받을 때마다 SQS 대기열로 메시지를 전송하고 처리 요청을 할 때 해당 파일은 SQS 대기열에 있게 됨
  그 후 자체 ASG에 속할 백엔드 처리 애플리케이션이라는 두 번째 처리 계층을 생성하고
  이들이 메시지를 수신하고 비디오를 처리해 S3 버킷에 삽입하도록 함
  이러한 아키텍처를 통해 독립적으로 프론트엔드를 확장할 수 있고 그에 따라 백엔드도 독립적으로 확장할 수 있음
  예) 프론트로 EC2 인스턴스 사용, 백엔드로 비디오 처리를 수행할 때 그래픽 처리 장치인 GPU가 있는 EC2 인스턴스 사용
  
  

  

Amazon SQS - Security

• HTTPS API를 사용해 메시지를 보내고 생성함으로써 전송 중 암호화
• KMS 키를 사용한 저장 데이터 암호화
• 클라이언트 측 암호화를 통해 클라이언트가 자체적으로 암호화 및 해독을 수행
• 액세스 제어를 위해 IAM 정책을 수행해 SQS API에 대한 액세스를 규제
• S3 버킷 정책과 유사한 SQS 액세스 정책을 통해
  SQS 대기열에 대한 교차 계정 액세스를 수행하려는 경우나 다른 서비스가 SQS 대기열에 S3 이벤트를 쓸 수 있도록 사용

<표준 Queuse 실습>

• SQS에서 대기열 생성
  대기열 생성 선택지로는 Standard와 FIFO 두 가지가 존재하는데 Standard를 선택해 대기열 이름을 DemoQueue로 생성
  
  대기열을 구성하기 위해서는 파라미터가 많음
  메시지 보존 기간 메시지가 대기열에서 자동으로 삭제되기 전에 처리되기를 기다리면서 대기열에 머무는 시간으로
  현재는 4일이지만 1분에서 14일 사이에서 지정할 수 있음
  메시지 크기 최댓값은 256KB이고 1KB에서 256KB 사이로 지정할 수 있음
  
  액세스 정책으로는 대기열에 누가 액세스할 수 있는지를 정하는 것이며
  기본값으로는 대기열 소유자만 메시지를 대기열로 보내고 대기열에서 메시지를 받을 수 있음
  이외에도 설정을 통해 다른 계정, 역할, 또는 대기열에 메시지를 보낼 수 있는 IAM 사용자를 설정할 수 있음
  이는 S3나 SNS와 통합할 때 매우 유용함
  또한 Advanced를 선택하면 JSON 정책을 인라인으로 직접 편집해서 SQS 대기열에 쓸 수 있는 사람을 지정할 수 있음
  이는 동일한 목적을 가지고 잇는 S3 버킷 정책과 매우 흡사하며 교차 계정이나 다른 역할 등을 작업할 경우 액세스 사용자를 정의
  
  대기열 암호화도 가능하며 기본값으로는 in-transit 암호화가 활성화되어 있지만 서버측 암호화를 활성화할 수 있음
  이를 위해 기본 CMK를 보장하거나 자체 키를 생성하여 별칭을 선택할 수 있음
  또한 데이터 키 재사용 기간을 제공하며 이는 데이터를 암호화하는데 동일한 데이터 키를 사용해야 하는 기간을 뜻함
  
  

• 대기열 생성 확인
  Send and receive message를 통해 메시지를 보낼 수 잇는 기능과 받을 수 있는 기능이 존재
  
  처음 대기열을 생성하면 수신 가능한 메시지가 없지만 메시지 본문을 입력하고 메시지가 전송되면 수신 가능한 메시지가 생성됨
  이를 보기 위해서는 Poll for message를 클릭하면 메시지를 수신할 수 있고 메시지 ID가 있음
  메시지를 클릭하면 많은 메타 데이터를 통해 메세지의 해시, 누가 보냈는지, 수신은 몇 번 되었는지 등을 알 수 있음
  
  만약 충분한 시간 내에 처리되지 않을 경우 메시지가 다시 대기열에 들어갔다가 똑같은 메시지를 다시 수신하게 됨
  이를 끝내기 위해선 해당 메시지를 처리했다는 의미로 메시지를 클릭한 후 대기열에서 메시지를 삭제해주어 성공적 처리를 알림
  이후로는 대기열에 수신 가능한 메시지가 없으며 동일한 메시지를 받지 않게 됨

• 대기열 추가 옵션
  대기열에서는 모든 대기열의 구성을 편집할 수 있고 Purge로 대기열을 제거할 수 있으며 제거시 대기열의 모든 메시지가 삭제됨
  
  옵션의 모니터링 부분에서는 대기열에 대략 몇 개의 메시지가 있는지, 가장 오래된 메시지의 대략적인 연령 등을 알 수 있음