-
[ AWS ] SQS란?AWS 2023. 8. 13. 19:06
section 17 디커플링 애플리케이션 : SQS , SNS , Kinesis , Active MQ 섹션의 강의를 기반으로 작성했습니다.
해당 챕터는 미들웨어로 다른 서비스간 합동 작업을 하는 방법을 다루는 챕터입니다.
애플리케이션을 여러 개 배포하려고 할 때 여러분의 서비스는 정보와 데이터를 공유해야 하기 때문에, 반드시 커뮤니케이션을 할 수 밖에 없습니다.애플리케이션 커뮤니케이션은 동기 커뮤니케이션과 비동기 커뮤니케이션 패턴으로 나뉘어집니다
1) Synchronous communications (동기 커뮤니케이션)
이 커뮤니케이션은 어플리케이션이 직접적으로 다른 어플리케이션에 연결되는 것입니다.
아래 그림에서 확인할 수 있듯이 구매 서비스와 배송서비스는 직접적으로 연결되어 있기 때문에 동기 커뮤니케이션이 발생하고 있습니다.
어플리케이션 간의 동기화는 때때로 문제가 될 수 있습니다. 구매가 갑자기 증가했다거나 한 서비스가 다른 서비스를 압도하는 경우 갑자기 급증하거나 아무것도 예측할 수 없을 때 일반적으로 애플리케이션을 분리(decouple)하고 분리 계층(decouple layer)을 확장하는 것이 좋습니다.
2) Asynchronous / Event based communications (다른 유형의 통합은 비동기 혹은 이벤트 기반 유형)
아래 보시는 것과 같이 구매 서비스와 배송 서비스는 직접 연결되어 있지않고 그 사이에 대기열이 있습니다.
서로 직접적으로 소통하지 않기 때문에 비동기적이라고 하는 것입니다.
middleware (대기열) 등으로 불리는 미들웨어가 애플리케이션을 연결하는 구조입니다.
이 구조에서는 누군가 구매를 하고, 이를 대기열에 포함시키겠다고 말하면 끝입니다.
그러면 배송서비스가 대기열에게 최근 구매 내역이 있는지를 물어봅니다. 그러면 대기열이 해당 요소를 반환하면 배송 서비스는 자기가 원하는 것을 무엇이든지 할 수 있습니다.
대기열 모델에는 SQS를 사용합니다. 또한 pub/sub 모델에는 SNS를 사용하고, 실시간 스트리밍 모델을 통해 대용량 데이터를 다루게 된다면 Kinesis를 사용해 분리를 할 수 있습니다. 우리는 이 세 모델을 이용하여 독립적으로 서비스를 확장할 수 있습니다.
Decouple 모델
SQS : 대기열 모델
SNS : pub/sub 모델
Kinesis : 실시간 스트리밍 및 대용량 데이터
Amazon SQS
SQS의 핵심은 대기열 입니다.
- Amazon Simple Queue Service(SQS)는 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 위한 완전관리형 메시지 대기열입니다.
- 표준(Standard) 대기열 가장 오래됐고, 거의 10년이 넘어가는 기술이라 안정됨.
- 애플리케이션 분리하는데 사용되는 완전 관리형 서비스입니다. ( 시험에서 애플리케이션 "분리" 라는 단어가 보이면 SQS!!! )
SQS 대기열에는 메세지를 포함하고 있다. 메세지를 담기 위해서는 무언가 SQS 대기열 안에 메세지를 전송해야 되는데,
SQS 대기열에 메세지를 보내는 주체를 생산자라고 합니다.
생산자는 단일일 수 있고, 여러 생산자가 여러개의 메세지를 SQS 대기열에 보내게 할 수도 있습니다.
보낸 메세지들은 Queue(대기열)로 가게되고 대기열에서 메세지를 처리하고 수신해야하는 대상을 소비자라고 합니다.
이 과정은 소비자가 대기열에게 소비자 앞으로 온 메세지가 있는지를 물어보는 과정입니다.
만일 대기열에 메세지가 있다면 소비자는 이 메세지를 폴링해서 정보를 얻게 됩니다.
메세지 수신자는 받은 메세지로 일을 처리하고 대기열에서 그 메세지를 삭제하게 됩니다.
위의 그림에서 확인할 수 있듯이 대기열 서비스는 생산자와 소비자 사이를 분리하는 버퍼 역할을 합니다.
SQS 특징
- 무제한 처리량
- 즉 초당 원하는 만큼 메시지를 보낼 수 있고 대기열에도 원하는 만큼 메시지를 포함시킬 수 있습니다.
- 처리량에 제한이 없고 대기열에 있는 메세지 수에도 제한이 없다!!!!
- 메시지는 수명이 짧습니다.
- 기본값 4일, 최대 14일
- 대기열에 메세지를 보내자마자 소비자가 읽고 보존 기간 내에 처리한 후 삭제를 해야함! 안그럼 소실됨.
- 지연 시간이 짧습니다.
- SQS는 메시지를 보내거나 SQS에서 메시지를 읽을 때마다 게시 및 수신 시 10밀리초 이내로 매우 빠르게 응답을 받게 됩니다.
- SQS의 메시지는 작아야 합니다.
- 전송된 메시지당 크기 최대 256KB
- 중복 메시지가 있을 수 있습니다. (메세지가 두번 전송이 될 수 있기 때문에 적어도 한번의 전송이라고 함)
- 최선의 오더라는 뜻으로 품절 메시지를 보낼 수도 있습니다.
SQS - 메시지 생산자
- 생산자는 SDK 소프트웨어 개발 키트를 사용하여 SQS에 메시지를 보낼 겁니다.
- SQS에 메세지를 보내는 API인 SendMessage API 사용합니다.
- 소비자가 해당 메시지를 읽고 삭제할 때까지 SQS 대기열에 유지됩니다.
- 메세지가 삭제가 되었다는 말은 메세지가 처리가 되었다는 뜻임.
- 표준 SQS는 무제한 처리량을 자랑합니다.
예를들어 패킷과 같은 오더를 처리한 다음 센터로 배송하려고 할때, 생성자는 원하는 시간에 이 작업을 수행하여 일부 정보가 포함된 메세지를 SQS 대기열로 보냅니다.
- 오더 Id
- 고객 Id
SQS - 메시지 소비자
- 소비자는 일부 코드로 작성해야 하는 애플리케이션이고 이러한 애플리케이션은 EC2 인스턴스나 온프레미스 서버 혹은 Lambda의 람다함수(람다에서 메세지를 바로 읽을 수도 있다는 것을 의미함.)에서 실행될 수 있습니다.
- 대기열에는 소비자가가 있고 소비자는 SQS 메시지를 폴링합니다.
- 소비자는 한 번에 최대 10개의 메세지를 받을 겁니다.
- 소비자는 이 메시지들을 폴링하고 처리할 책임이 있습니다.
예를들어 RDS 데이터베이스에 오더를 입력하는 경우를 생각해보면, 각 오더들을 RDS 데이터베이스에 삽입하면 이 메세지들이 수신되어서 처리됐기 때문에 소비자가 이 메세지들을 DeleteMessage API로 대기열에서 삭제하게 됩니다.
그럼 다른 소비자들이 이 메세지를 볼 수 없게되고 그러면 메세지 처리가 완료됩니다.
다중 EC2 인스턴스 소비자
- SQS 대기열은 메세지를 동시에 수신하고 각각 다른 메세지세트를 처리할 소비자를 여러 개 가질 수 있습니다.
- 만일 메세지가 소비자에 의해서 빠르게 처리되지 않으면 해당 메세지를 다른 소비자가 수신하게 됩니다. 그래서 적어도 한번은 전송이 된다고 말할 수 있는 것입니다. (한번이 될 수 있고 그 이상이 될 수 있기 때문에)
- SQS 대기열에서 더 많은 메시지가 있어서 처리량을 늘려야 하면 소비자를 추가하고 수평 확장(Auto Scaling Group)을 수행해서 처리량을 개선할 수 있습니다.
SQS - ASG (Auto Scaling Group)
- 소비자가 ASG 내부에서 인스턴스를 실행하고, 대기열에서 메세지를 폴링하는 구조입니다.
ASG는 특정 지표에 따라 스케일이 변화하는데 이때 사용할 수 있는 지표는 대기열의 길이입니다.
이는 Queue lenth라고도 하고 Approximate Number Of Messages 라고 합니다.
이는 모든 SQS 대기열에서 쓸 수 있는 CloudWatch 지표입니다.
- 우리는 알람도 설치할 수 있는데 대기열의 길이가 특정 수준을 넘어가면 오토스케일링 그룹의 용량을 증가시키게 돕고, 이를 통해 더 많은 메세지들을 더 높은 처리량으로 처리할 수 있게 됩니다.
SQS - 애플리케이션 계층 간에 분리
- 파일 처리 요청과 실제 파일 처리가 서로 다른 애플리케이션에서 발생할 수 있도록 분리.
https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/learn/lecture/29389078#overview - 프론트엔드가 파일 처리 요청을 받을 때마다 SQS 대기열로 메세지를 전송하고, 처리 요청을 진행할때 그 파일은 SQS 대기열에 있게 됩니다. 그 이후 자체 오토스케일링 그룹에 속할 백엔드에서 두 번째 처리 계층을 생성할 수 있게 됩니다. 백앤드 애플리케이션이 메세지를 수신하고 비디오를 처리하고 이를 버킷에 삽입하는 식으로 일이 처리될 수 있습니다.
- 이런 아키텍처에서 프론트앤드와 백앤드는 서로 독립적으로 확장할 수 있다는 장점을 가집니다.
SQS 생성
FIFO 대기열을 생성하려면 반드시 이름에 "이름.fifo" 처럼 .fifo를 붙여줘야 함. (아니면 FIFO 대기열 못만듬)
구성 ( Configuration )
- 표시 제한 시간 / Visibility timeout (디폴트 : 30초)
- 전송 지연 / Delivery delay
- 메세지 수신 대기 시간 / Receive message wait time
- 메세지 보존 기간 / Message retention period
- 최대 메세지 크기 / Maximum message size
대기열 암호화
- HTTPS API를 사용하여 전송 중 암호화를 합니다.
- KMS 키를 사용하여 미사용 암호화를 얻습니다.
- 클라이언트가 자체적으로 암호화 및 암호 해독을 수행하는 클라이언트 측 암호화를 합니다.
액세스 제어
- SQS API에 대한 액세스를 규제할 수 있습니다.
SQS 대기열 액세스 정책
- 드롭다운을 통해 대기열에 누가 액세스 할 수 있는지를 정의할 수 있음.
- S3 버킷 정책과 유사합니다.
- SQS 대기열에 대한 교차 계정 액세스를 수행하려는 경우
- SNS 혹은 Amazon S3 같은 다른 서비스가 SQS 대기열에 S3 이벤트 같은 것을 쓸 수 있도록 허용
SQS - 메시지 가시성 시간 초과
( ChangeMessageVisibility API 호출을 사용하여 가시성 시간 초과를 늘립니다. )
- 소비자가 메시지를 폴링하면 그 메세지는 다른 소비자들에게 보이지 않게 됩니다.
- 기본값으로 메시지 가시성 시간 초과는 30초입니다.
- 가시성 시간 초과 기간 (Visibility timeout) 내에서는 그 메시지는 다른 소비자들에게 보이지 않습니다.
- 가시성 시간 초과가 되고 메시지가 삭제되지 않았다면 메시지는 대기열에 다시 들어갑니다. (큐에 재삽입)
- 이렇게 대기열에 들어간 메세지를 다른 소비자가 RecieveMessage API 호출을 하게되면 이전에 그 메세지를 또 받게 된다.
즉 가시성 시간 초과 기간 내에 메시지를 처리하지 않으면 두명의 다른 소비자가 해당 메세지를 수신하거나,
동일한 소비자가 같은 메세지를 두번 수신하게 되면서 메시지가 중복 처리될 수도 있습니다.
- 메시지를 처리하는 데 시간이 더 필요하다는 것을 알고 있는 소비자는 해당 메시지를 두 번 처리하지 않기 위해 ChangeMessageVisibility API를 호출하여 "이 메세지를 처리하는데 조금 더 시간이 필요하다고" SQS에 알려야 합니다.
- ChangeMessageVisibility
메시지를 처리하지 않아 가시성 시간 초과 기간을 벗어날 때 사용합니다.
- ChangeMessageVisibility
- 몇 초와 같이 매우 낮은 값으로 설정하면 소비자가 어떤 이유로든 해당 메시지를 처리할 시간이 충분하지 않으면 다른 소비자가 메시지를 여러 번 읽을 것이며 중복 처리될 수 있습니다.
Amazon SQS - Long Polling
Long Polling은 메시지를 폴링(조회)하는 방식 중 하나로, 기본적인 폴링 방식과는 다르게 더 효율적인 방식을 제공합니다.
기본 폴링 방식은 다음과 같은 방식으로 메시지를 확인합니다
1. 기본 폴링: 애플리케이션은 '일정한 주기'로 SQS에 "메시지가 도착했니?"라고 물어봅니다. 2. 빈 응답: 만약 메시지가 없으면 SQS는 "아직 메시지가 없어요"라는 빈 응답을 보냅니다. 3. 계속 폴링: 애플리케이션은 '메시지가 도착할 때까지 계속해서 주기적으로' 물어봅니다.
그런데 이 방식은 애플리케이션과 SQS에 불필요한 요청과 응답이 계속해서 오고가며, 시스템 부하를 유발할 수 있습니다.
SQS Long Polling은 기존 폴링 방식의 문제를 개선하는 방법입니다.SQS Long Polling을 사용하면,
1. 대기 시간 설정: 애플리케이션은 SQS에 메시지가 도착할 때까지 '기다리는 시간을 설정'할 수 있습니다. 2. 응답이 없는 동안 대기: 만약 메시지가 없으면 SQS는 바로 응답을 주지 않고, '메시지가 도착할 때까지 기다립니다.' 3. 효율적인 폴링: 이 방식을 사용하면 빈 응답이 줄어들어 시스템 부하가 줄어듭니다.SQS Long Polling은 메시지 수신 효율성을 높이기 위해 사용되며, 특히 메시지 트래픽이 높거나, 빠른 메시지 수신이 중요한 상황에서 유용합니다.
롱 폴링 방식에는 두가지의 이점이 있습니다.
1. 지연 시간을 줄일 수 있습니다. 2. SQS로 보내는 API 호출 숫자를 줄일 수 있습니다.
- 롱 폴링은 애플리케이션의 효율성과 대기 시간을 증가시키면서 SQS로의 API 호출 수를 감소시킵니다.
- 1초부터 20초 사이로 구성이 가능합니다.
∴ 시험에서 SQS대기열에 대한 API 호출 수를 최적화하고 지연 시간을 줄이는 법을 물어보면? 롱폴링
SQS FIFO (first in first out) 옵션
- First-In First-Out
- 표준 대기열 보다 더 확실히 순서가 보장되는 것입니다. = 선입 선출
- 소비자가 SQS FIFO 대기열로부터 메시지를 불러올 때 정확히 동일한 순서로 메시지를 받게 해 줍니다.
- 초당 제한된 처리량
- 묶음이 아닐 경우(= API)에는 초당 300개의 메시지
- 배치 함수인 (= 메시지를 묶음으로 보낼 경우) 처리량은 초당 3000개
- SQS FIFO 대기열의 기능으로 인해 중복을 제거하여 정확히 한번만 보낼 수 있게 해 줍니다.
- 분리가 발생하거나 메시지의 순서를 유지할 필요가 있을 때 FIFO 대기열을 확인해야 합니다.
- FIFO 전송을 하려면 <편집>에서 콘텐츠 기반 중복 제거 토굴을 활성화 해야함
SQS with Auto Scaling Group
SQS 대기열과 오토 스케일링 그룹이 있을 때 ASG 내의 EC2 인스턴스에 메시지를 SQS 대기열에서 폴링합니다. 이는 오토 스케일링 그룹을 자동으로 대기열 크기에 따라 확장시키기 위함으로 CloudWatch 지표인 대기열 길이를 보고 스케일링을 결정할 수 있습니다.
ApproximateNumberOfMessages 라고 하는 이 지표는 대기열에 몇 개의 메시지가 남아 있는지를 표시합니다.
만약 이 지표가 1000을 넘는 경우, 1000개의 메세지가 대기열에서 처리에 지연되고 있다는 것으로 파악할 수 있습니다.
따라서 이 경우에는 경보를 발생해서 메세지를 처리할 인스턴스를 확장하는 트리거를 발동 시킬 수 있습니다.
이를 통해 오토스케일링 그룹에 더 많은 EC2 인스턴스가 추가되며 확장이 이루어져 메세지가 더 빨리 처리되게 됩니다.
SQS와 ASG의 패턴 사용 예시
ex) 세일 행사를 진행한다는 가정하에, 많은 고객이 주문을 하게 되고 해당 주문은 DB에 저장이 될 것입니다.
이때 우리는 SQS를 버퍼로 사용할 수 있게 됩니다. 처리량 문제가 발생되지 않도록 무제한으로 확장 가능한 SQS 대기열을 어플리케이션 사이에 두고 트랜잭션을 처리하게 하면 됩니다. 이를 통해 처리량 문제와 데이터 유실을 해결할 수 있습니다.
이 패턴은 클라이언트에게 따로 데이터베이스에 쓰였다는 확인을 전송할 필요가 없을 때만 사용 가능합니다 하지만 SQS 대기열에 쓰기 작업이 일어났다는 것만으로도 어느 정도 작업 완료에 대한 체크가 가능합니다.
"분리나 급격히 증가한 로드, 시간초과 문제에서 신속한 스케일링이 필요한 경우 SQS 대기열을 기억하기!"
'AWS' 카테고리의 다른 글
GSLB란? (0) 2023.09.20 [ AWS ] aws 에서 엔드포인트란? (0) 2023.09.12 [ AWS ] Secrets Manager (0) 2023.08.12 [ AWS ] IVS란? (0) 2023.07.30 AWS route53에 한글 도메인 등록하기 (0) 2023.07.30