Infrastructure

Amazon SQS

Jinlib 2022. 6. 9. 20:04

What is the AWS SQS?

SQS. Simple Queue Service의 약자로 사용되는 AWS 서비스이다.

SQS는 애플리케이션을 구성하는 다양한 컴포넌트가 서로에게 메시지를 전송할 수 있도록 돕는

고가용성, 고탄력성 관리형 메시지 서비스이다. 수십만 건의 메시지를 불과 수초만에 처리할 수 있다.

  • 큐를 모아놨다가 Pooling처리를 실행하는 서비스
  • 256K까지 가벼운 데이터만 이용 가능, 60초에서 14일간만 메시지를 저장할 수 있다
  • Request큐와 Response큐를 사용해 송수신 큐잉을 구현
  • 여러개의 서버, 데이터센터에 큐를 저장하는 고가용성 서비스
  • 여러 사용자가 쓸 수 있는 유연함
  • 메세징이 증가해도 높은 Throughput을 유지함

큐의 종류

  1. 표준큐 : 순서대로 처리 + 반드시 한번은 실시함.
  1. FIFO : 큐에 들어온 순서대로 처리

SQS의 특성

  • 메세지 사이즈
    • 최대 메시지 사이즈는 256KB.
    • Extended Client Library 이용시 2GB까지의 메시지 송수신 가능
  • 메세지 보존기간
    • 삭제되지 않은 메시지는 기본값으로 4일간 보존
    • 유지 기간은 60초에서 14일 사이에 변경 가능
  • In Flight메세지
    • 큐당 최대 120,000 In Flight (받은 메시지 & Visibility Timeout내) 메시지

SQS의 추가 옵션

  • 짧은 폴링(Short Polling) : 큐가 빈 경우에도 즉시 리턴 (ReceiveMessageWaitTimeSeconds 속성이 0)
  • 긴 폴링(Long Polling) : 큐가 빈 경우에 타임아웃까지 기다림 (ReceiveMessageWaitTimeSeconds 속성이 0 보다 큰 값)
  • 데드 레터 큐 : 계속 남은 메시지를 별도 큐로 이동하여 정상적으로 처리하지 못한 메시지를 격리가능
  • Visibility timeout : 새 메시지를 지정된 시간 동안 보이지 않게 한다.
    • Visibility timeout을 설정함으로써 우선 처리하고 싶은 수신 인스턴스 지정 가능.

디커플링 아키텍처

정의 : 컴포넌트간의 상호의존을 줄인 구성으로 각각의 컴포넌트 변경이나 장애의 영향을 줄인다.

1 서버리스

  • 서버리스 설계로 디커플링 아키텍쳐가 사용되며 마이크로서비스화된 애플리케이션을 구축
  • 과거 SOA 방식에서 보다 작은 프로세스 단위의 서비스를 API로 연계한 마이크로 서비스로 설계할수 있음
  • SOA 방식
    • 한 가지 기능을 갖춘 큰 서비스 단위로 컴포넌트를 분할하는 설계 방식
  • 마이크로 서비스
    • SOA보다 더 작은 기능 단위의 프로세스로 서비스화한 구성
    • 각 프로세스에서는 1개의 작은 태스크를 서비스로 제공하고 프로세스 간 통신은 API를 이용한다.

Amazon SQS 대기열 지표를 기반 최적화

Problem

대상 추적용 ApproximateNumberOfMessagesVisible과 같이 CloudWatch Amazon SQS 지표를 사용할 때의 문제는 대기열의 메시지 수가 대기열에서 메시지를 처리하는 Auto Scaling 그룹의 크기에 비례하여 변경되지 않을 수 있다는 것

해결 방법은 인스턴스당 백로그 지표와 목표값을 사용하여 인스턴스당 허용 백로그를 유지하는 것입니다. 이 값은 다음과 같이 계산할 수 있습니다.

  • 인스턴스당 백로그: 인스턴스당 백로그를 계산하려면 ApproximateNumberOfMessages 대기열 속성을 사용하여 SQS 대기열의 길이(대기열에서 검색할 수 있는 메시지 수)를 확인합니다. 이 값을 플릿의 실행 용량(Auto Scaling 그룹에서 상태가 InService인 인스턴스 수)으로 나눠서 인스턴스당 백로그를 산출합니다.
  • 인스턴스당 허용되는 백로그: 목표값을 계산하려면 먼저 애플리케이션에서 허용할 수 있는 지연 시간을 확인하세요. 그런 다음 이 허용 지연 시간 값을, EC2 인스턴스가 메시지를 처리하기 위해 소요하는 평균 시간으로 나눕니다.

예제로 설명하기 위해 현재 ApproximateNumberOfMessages가 1,500개이고 플릿의 실행 용량이 10이라고 가정해 보겠습니다. 각 메시지의 평균 처리 시간 0.1초이고 가장 긴 허용 지연 시간이 10초인 경우, 인스턴스당 허용 가능한 백로그는 10/0.1인 100입니다. 즉, 목표 추적 정책의 목표값은 100입니다. 인스턴스당 백로그가 현재 150(1500/10)인 경우 플릿이 확장되고 5개의 인스턴스를 추가하여 목표값 비율을 유지합니다.

다음 절차에서는 사용자 지정 지표를 게시하고 이러한 계산에 따라 Auto Scaling 그룹을 조정하도록 구성하는 대상 추적 조정 정책을 생성하는 방법을 보여줍니다.

이러한 구성을 위해 세 가지 방법을 사용할 수 있습니다.

  • SQS 대기열의 메시지를 처리하기 위해 EC2 인스턴스를 관리하는 Auto Scaling 그룹.
  • Auto Scaling 그룹의 EC2 인스턴스당 대기열의 메시지 수를 측정하여 Amazon CloudWatch로 전송되는 사용자 지정 지표.
  • 사용자 지정 지표와 설정된 목표값에 따라 크기를 조정하도록 Auto Scaling 그룹을 구성하는 대상 추적 정책. CloudWatch 경보는 조정 정책을 호출합니다.

다음 다이어그램은 이 구성의 아키텍처를 보여 줍니다.

'Infrastructure' 카테고리의 다른 글

Amazon RDS  (0) 2022.06.09
Amazon LB  (0) 2022.06.09
Amazon EC2 Overview  (0) 2022.06.09
Amazon ELB overview  (0) 2022.06.09
Amazon EC2 EBS  (0) 2022.06.09