[AWS SAA] 49. SQS

SQS

SQS는 관리 부담 없이 최소한의 구성으로 바로 사용할 수 있는 완전 관리형 서비스입니다. 이 서비스는 방대한 규모로 작동하느므로 하루에 수십억 건의 메시지를 처리할 수 있습니다. SQS는 여러 이중화 가용 영역을 사용하여 가용성이 높은 단일 AWS 리전에 모든 메시지 대기열과 메시지를 저장합니다. 그러므로 단일 컴 퓨터, 네트워크 또는 가용 영역 장애로 인해 메시지에 액세스하지 못하는 경우가 없습니다. 메시지는 동시에 보내고 읽을 수 있습니다.

 

개발자는 SQS 대기열을 익명으로 또는 특정 AWS 계정과 안전하게 공유할 수 있습니다. 특정 IP 주소와 특정 시간으로 대기열 공유를 제한할 수도 있습니다. 스트리밍 SIMD(Single Instruction  Multiple Data) 확장 (SSE)은 AWS KMS에서 관리되는 키를 사용하여 SQS 대기열에 있는 메시지의 콘텐츠를 보호합니다. SIMD 확장은 SQS가 메시지를 수신하는 즉시 이를 암호화합니다. 이 메시지는 암호화된 형태로 저장되며 SQS는 권한이 있는 사용자에게 전송할 메시지만 복호화합니다.

 

SQS 대기열

위 예시에서는 생산자 애플리케이션이 고객 주문을 생성한 후 SQS 대기열로 전송합니다. 소비자 애플리케이션 티어가 생산자 애플리케이션 티어의 주문을 처리합니다. 이 애플리케이션은 대기열을 폴링하고 메시지를 수신합니다. 그런 다음 RDS DB에 기록하고 처리된 메시지를 SQS 대기열에서 삭제합니다. SQS는 처리할 수 없는 메시지를 나중에 처리할 수 있는 DLQ(Dead Letter Queue)로 전송합니다. 이 대기열에서 해당 메시지를 나중에 처리할 수 있습니다.

 

SQS 대기열을 사용하면 다음과 같은 이점이 있습니다.

• 느슨한 결합
  SQS를 사용하면 전처리 단계를 컴퓨팅 단계 및 후처리 단계와 분리할 수 있습니다. 비동기식 처리가 사용되므로 생산자 로직이 소비자 로직과는 별도의 자체 구성 요소에 격리됩니다.
• 내결함성
  애플리케이션 예외나 트랜잭션 장애가 발생하는 경우 주문 처리를 재시도할 수 있습니다. 최대 재시도 횟수에 도달하면 SQS는 SQS DLQ로 메시지를 리디렉션할 수 있습니다. 그러므로 나중에 이 대기열에서 메시지를 다시 처리하거나 디버그할 수 있습니다. 느슨하게 결합된 워크로드에서 한 노드 또는 작업이 손실되어도 일반적으로 전체 계산이 지연되지 않습니다.
• 급증하는 트래픽 처리
  SQS 대기열 사용 시에는 시스템의 복원력이 향상됩니다. 대기열은 급증하는 트래픽 처리를 위한 버퍼로 사용됩니다. 그러므로 애플리케이션이 확장 작업을 완료할 수 있는 추가 시간이 제공됩니다. 그리고 급증하는 트래픽 처리를 위한 유휴 컴퓨팅 리소스를 프로비저닝할 필요가 없으므로 비용 효율성도 높아집니다.

 

SQS는 다음과 같은 사례에서 사용을 검토할 수 있습니다.

• 작업 대기열
  동일한 양의 작업을 동시에 처리하지 못할 수 있는 분산 애플리케이션의 구성 요소를 분리합니다. 애플리케이션의 요구 사항에 따라 표준 대기열 또는 FIFO(선입선출) 대기열을 선출할 수 있습니다.
• 버퍼링 및 배치 작업
  아키텍처에 확장성과 안정성을 더하고, 메시지를 손실하거나 지연시간을 늘리지 않고 일시적인 볼륨 스파이크를 원활하게 처리합니다.
• 요청 오프로딩
  요청을 대기열에 전송하여 대화식 요청 경로에서 속도가 느린 작업을 이동합니다.
• 인스턴스 자동 크기 조정
  SQS 대기열을 사용하여 애플리케이션의 로드를 확인할 수 있습니다. 자동 크기 조정과 함께 사용하면 트래픽 볼륨에 따라 EC2 인스턴스 수를 늘리거나 줄일 수 있습니다.

 

대기열 종류

1. 표준 대기열
   최소 1회 메시지 전송을 지우너하고 최선의 정렬로 제공합니다. 메시지는 일반적으로 수신된 순서와 동일한 순서로 전송됩니다. 하지만 고도로 분산된 아키텍처의 특성상 때로는 2개 이상의 메시지 사본이 순서가 맞지 않게 전송될 수 있습니다. 포준 대기열은 처리할 수 있는 초당 API 호출 수에 거의 제한이 없습니다. 한 번 이상 잘못된 순서로 도착하는 메시지를 애플리케이션에서 처리할 수 있는 경우, 포준 메시지 대기열을 사용할 수 있습니다.
2. FIFO 대기열
   작업 및 이벤트 순서가 중요하거나 중복 항목이 허용되지 않는 경우에 애플리케이션 간 메시징을 강화하도록 설계되었습니다. 또한 FIFO 대기열은 정확히 한 번 처리를 제공하지만 초당 API 호출수가 제한됩니다.

 

구성 최적화

SQS 대기열 애플리케이션을 생성할 때는 애플리케이션이 대기열과 상호 작용하는 방식을 고려해야 합니다. 이 정보는 대기열 구성을 최적화하여 비용을 제어하고 성능을 향상시크는 데 도움이 됩니다.

 

• 가시성 제한시간
  소비자가 수신한 SQS 메시지는 소비자가 삭제할 때까지 대기열에 유지됩니다. 해당 메시지가 일정 기간동안 다른 소비자에게는 표시되지 않도록 SQS 대기열의 가시성 제한 시간 설정을 구성할 수 있습니다. 그러면 다른 소비자가 같은 메시지를 처리하지 못하도록 설정할 수 있습니다. 가시성 제한 시간의 기본값은 30초 입니다. 소비자는 처리를 완료한 메시지를 삭제합니다. 가시성 제한 시간이 만료되기 전에 소비자가 메시지를 삭제하지 않을 경우, 다른 소비자가 메시지를 볼 수 있게 되며 해당 메시지는 다시 처리될 수 있습니다.
  
  일반적으로 가시성 제한 시간 설정 시 애플리케이션이 대기열에서 메시지를 처리하고 삭제하는 데 걸리는 최대 시간으로 설정해야 합니다. 시간 제한을 너무 짧게 설정하면 애플리케이션이 메시지를 두 번 처리할 가능성이 높아집니다. 반면 가시성 제한 시간을 너무 길게 설정하면 후속 메시지 처리 시도가 지연됩니다.
  
  
• 폴링 유형
  짧은 폴링이나 긴 폴링을 사용하도록 SQS 대기열을 구성할 수 있습니다.
  • 짧은 폴링을 사용하는 SQS 대기열의 특징을 다음과 같습니다.
    
    • 요청을 수신하는 즉시 소비자에게 응답을 전송하므로 응답이 더 빠르게 제공됩니다.
    • 응답 수가 늘어나므로 비용도 증가합니다.
  • 긴 폴링 시간을 사용하는 SQS 대기열의 특징은 다음과 같습니다.
    • 메시지가 하나 이상 도착하거나 폴링 시간이 초과될 때까지는 응답을 반환하지 않습니다.
    • 응답 빈도는 낮아지지만 비용 또한 감소합니다.

대기열에 메시지가 도착하는 빈도에 따라서는 짧은 폴링을 사용하는 대기열의 응답 중 대다수가 빈 대기열을 보고하게 될 수 있습니다. 애플리케이션이 폴링 요청의 응답을 즉시 받아야 하는 경우가 아니라면 긴 폴링 옵션을 사용하는 것이 좋습니다.

 

메시지 대기열을 사용해야 하는 이유

특정 기술이 사용 사레에 적합하지 않은 경우를 아는 것도 중요합니다. 메시징에는 일반적으로 보게 되는 고유한 안티 패턴이 있습니다. 특정 속성 집합과 일치하거나 심지어 일회성 논리적 쿼리와 일치하는 메시지를 대기열에서 선택적으로 검색하기를 원할 수 있습니다. 예를 들어 서비스는 특정 속성이 있는 메시지를 요청하는데, 서비스가 전송한 다른 메시지에 대한 응답이 포함되어 있기 때문입니다. 이로 인해 아무도 폴링하지 않고 결코 소비되지 않는 메시지가 대기열에 있는 시나리오가 발생할 수 있습니다.

 

대부분의 메시징 프로토콜과 구현은 메시지의 크가가 적절할 때(수십 또는 수백 킬로바이트) 가장 효과적입니다. 메시지 크기가 커진다면, S3와 같은 전용 스토리지 시스템을 사용하고 해당 스토어에 있는 객체에 대한 참조를 메시지 자체에 넣어 전달하는 것이 가장 좋습니다.