AWS SQS, SNS, kinesis, activeMQ

구매서비스가 있고, 배송 서비스가 있다고 가정하자.

먼저 구매서비스가 일어나면 배송서비스가 실행되어야하는데

synchronous communication인 경우 직접 둘이 연결되어있어서

구매서비스가 배송서비스에게 요청을 할 것이다. (app to app)

 

asynchronous / event based인 경우 직접 둘이 연결되는 것이 아니라

중간에 queue라는 것이 있어서 구매서비스는 구매서비스가 일어나면 이 큐에 정보를 담고

배송서비스는 큐에 뭔가 들어있으면 실행한다.  이러한 구조는 구매서비스와 배송서비스가 직접 연결되어있지 않기에

비동기로라고 불린다.

(app to que to app )

 

동기화는 때때로 문제가 될 수 있다ㅣ.

갑자기 트래픽이 몰려버리면 문제가 생길 수 있기에 둘을 구분 시켜 놓는 것이 좋다.

SQS는 queue모델을 사용하고 SNS는 pub/sub모델 kinesis는 실시간 스티리밍 모델을사용한ㄷㅏ.

 

SQS

SQS는 큐이며, 간단한 대기서비스이다.

SQS대기열에는 메시지를 포함하는데  메시지를 담기 위해서는 무언가 sqs대기열에 메시지를 전송해야한다.

이 전송하는 주체를 프로듀서라고한다. 프로듀서는 여러개 일 수 있고 여러개를 보낼 수 있다.

그리고 이 메시지를 받아야 하는 대상은 컨슈머라고 한다. 대기엘에서 메시지를 풀링한다.

메시지가 있으면 이 메시즐ㄹ 폴링해서 받고 처리한 뒤 메시지를 삭제한다.컨슈머가 어려개일 수도 있다.

sqs는 프로듀서와 컨슈머 사이를 분리하는 버퍼 역할을 한다.

시험문제에서 분리 ( decoupling)에 대한 문제가 보이면 SQS라고 생각해라.

 

SQS 특징

1. 무제한 처리량을 얻을 수 있다. 메시지를 받고 전달하는데 개수 제한이 없음

하지만 메시지는 기본값으로 4일동안 대기열에 남아있다. 맥시멈은 14일

2. 전송된 메시지당 256kb미만이어야 한다.

3.지연시간이 매우 적다. 

4. 중복 메시지가 있을 수 있다. ( 두번 정송되는 경우 )

 

 

프로듀서

256kb의 메시지가 프로듀서에 의해서 sqs로 전달된다. 어떻게 보낼까?

SDK소프트 웨어 개발 키트를 사용하여 sqs로 보낸다. 

 

소비자

ec2, 자체 온프로미스, aws lamda와 같은 것들이 소비자가 될 수 있다.

한번에 10개까지 메시지를 받을 수 있다. 

받은 메시지를 처리해야한다. RDS로 받은 오더 메시지를 인서트 한다고 생각해보자.

이 후 메시지를 대기열에서 삭제하면 된다.

 

수신하고 처리할 소비자를 여러개 가질 수 있다.

ec2가 3개 있다고 가정하고 ( 소비자로써 )

이들이 각각 다른 메시지세트를 풀링한다.

 

만일 메시지가 소비자에 의해 충분히 빠르게 처리되지 않으면

다른 소비자가 수신하게 된다. 

 

sqs에 많은 메시지가 쌓여 처리할 ec2가 부족할 수 있다. 이 때 ASG을 사용하면 수평확장을 알아서 해주기에 편리하게 이용할 수 있다.

asg는 일종의 지표에 따라 확장되어야 하는데, 대기열의 길이를 지표로 삼을 수있다.

이건 cloudwatch metric - queue length이걸 확인하면 된다. ( approximatenumber of messages )

 

이는 모든 sqs대기열에서 쓸 수 있는 cloudwatch지표이다. 일정 대기열의 길이가 되면 알람을 설정할 수 있다.

그럼 이 설치한 cloudwatch alarm이 asg에게 그룹의 용량을 늘리라고 알려줄 것이다, 

 

예를들어 프론트에서 어떤 비디오를 받아서 처리해준다고 할 때 이걸 프론트에서 처리하면 오래걸릴 것이다. 따라서 sqs름 만든 뒤 파일이 들어오면 백엔드로 이 파일을 처리해 달라는 메시지를 보낸다, 이 후 백엔드가 이 파일을 s3로 업로드 한 뒤 메시지를 지운다.

 

sqs security

https로 전송할 수 있고

kms로 암호화 할 수 있다.

 

SQS 대기열 지연은 Amazon SQS가 소비자들에게 새로운 SQS 메시지가 보이지 않도록 유지하는 기간입니다. SQS 대기열 지연은 대기열로 처음 추가된 메시지를 감춤 처리합니다.(기본: 0분, 최대: 15분)

 

delay seconds 파라미터를 늘리면된다.

 

 

SQS 데드 레터 대기열은 다른 SQS 대기열(소스 대기열)들이 처리(소비)될 수 없는 메시지를 보낼 수 있는 곳입니다. 이를 통해 문제가 되는 메시지들을 분리하여 처리가 실패한 이유를 디버깅할 수 있으므로, 디버깅에 유용합니다.

 

sqs message visibility timeout (가시성 시간 초과)

소비자가 메시지를 풀링하면 메시지는 다른 소비자에게는 보이지 않게 된다.

그 때 부터 visibility time이 시작된다. 기본적으로는 30초이다. 그 말은 30초동안 이 메시지가 처리되어야 한다는 뜻이다.

이 때에는 다른 소비자가 메시지를 달라고해도 이 메시지가 반환되지 않는다. 이미 다른 소비자가 처리를 하고 잇는 시간이니까

하지만 그 시간이 초과되고 메시지가 삭제되지 않았다면 메시지는 대기열에 다시 넣는다. 그리고 나서 다른 소비자 혹인 동일한 소비자가 다시 메시지를 불러들일 수 있게 된다.

 

이 기간내에 메시지가 처리되지 않으면 두번 처리될 수도 있다는 것이다.

만약 소비자가 그 메시지를 처리하는데 30초 보다( 기본값 ) 더 걸릴거 같다면 그 시간을 change할 수있다.

소비자는 changeMessageVisibility API를 호출하여 sqs에 알릴 수 있다.

 

소비자들이 한 번에 10개의 메시지를 폴링하고 1분 내로 이에 대한 처리를 완료하는 SQS 대기열이 있습니다. 잠시 후, 여러분은 동일한 SQS 메시지를 다른 소비자들도 수신하여 메시지가 한 번 이상 처리되었음을 알게 되었습니다. 이 문제를 해결하기 위해서는 어떻게 해야 할까요? -> 가시성 시간 초과 늘리기

 

 

 가시성 시간초과를 증가시키면 소비자들이 더 오랜 시간 동안 메시지를 처리할 수 있게 해주며, 메시지의 중복 읽기를 방지합니다.(기본: 30초, 최소: 0초, 최대: 12시간)

sqs long poling 

소비자가 대기열에 있는 메시지를 요청하는데 메시지가 없다면 롱 폴링 상태가된다. 

이렇게 하는 이유는 2가지가 있다, api호출 숫자를 줄이기 위해서, 지연시간을 줄이기위해서

1초~20초 설정가능,

시험에 나올 수 있다.,메시지를 요청하는 api호출 줄이고, 지연시간 줄이기 위해 사용!

 

SQS FIFO queue

선입선출로 표준 대기열 보다 순서가 더 확실히 보장 되는 것이다.

프로듀서가 sqs로 메시지를 4개 보내면, 소비자가 fifo 대기열로부터 불러올 때 정확히 같은 순서대로 불러온다.

이렇게 정확히 하기에 sqs대기열 처리량에는 제한이 있따 ( 스탠다드이면 없었음 )

 메시지는 한 번만 전송되며, 소비자가 해당 메시지를 처리하고 삭제할 때까지 사용할 수 있습니다.

 

두 번째, 복제된 메시지는 대기열에 들어오지 않습니다.

SQS with ASG

sqs대기열과 오토스케일링 그룹이 있을 때 

ASG내의 EC2 인스턴스에 메시지를 SQS대기열에서 폴링합니다.

이는 오토스케일링 그룹을 자동으로 대기열 크기에따라 확장시키기 위함이다.

 

sqs에 cloudwatch metric를 달아놓을 수 있다. 이 것이 sqs queue를 지켜보면서 처리 대기중인 메시지가 1000개 이상인 경우에

cloudwatch alarm을 울리도록 해두었고 이 것과 asg를 묶어서 알람이 울리면 인스턴스를 늘리도록 할 수 있다, 이렇게 되면 인스턴스가 추가되어 소비자 역할을 함으로 대기중 메시지 수가 줄어들고, 점점 줄어들면 축소과정또한 할 수 있다. 

 

SQS as a buffer to database writes

우리가 직접적으로 트랜잭션을 통해서 rds를 사용한다면, 모종의 오류가 발생하면, ux가 안좋을 것이다. 따라서 sqs를 버퍼로 사용하여 이와 같은 일을 해결할 수 있다.

 

프론트엔드 애플리케이션이 있고 데이터베이스가 있다고 가정하면 db에 바로 요청을 보내는 것이 아니라, 트랜잭션을 일명 무한히 확장 가능한 sqs대기열에 먼저 트랜잭션을 모두 쓰는 방법이 있다,. 이렇게 하면 처리량 문제가 발생하지 않는다. ( sqs는 기본적으로 무한히 메시지를 받을 수 있기 때문 ) 앞서 말했듯이 엄청난 수의 트랜잭션이 바로 rds로 가버리면 오류가 발생할 수 있지만 이 방법으로는 절대 그럴일이 없음

그리고 이제 이 메시지를 처리할 목적으로 인스턴스(백엔드)를 만들어 줘야 하는데 (asg로 관리) 이것들이 메시지를 읽어 들이고 (풀링) 처리하여 데이터베이스로 보내는 것이다.

 

SNS

메세지 하나를 여러 수신자에게 보낸다고 가정해보자

구매 서비스가 발생하면 이 서비스가 sqs 메시지, 이메일 보내기, 사기 방지 참지 등 여러 메시지를 직접 보냈다.

하지만 sns를 사용하면 구매서비스가 sns 하나에만 메시지를 보내고, sns를 구독한 서비스가 있다면 그 서비스에게 메시지가 전달 되는 구조이다

 

sns에서 퍼블리쉬 하면 구독자들이 이메일을 보낼 수도있고, sms & mobile notifications 모바일 알림을 보낼 수 있다. http통신으로 직접 데이터를 보낼 수도 있다. 또 sqs서비스에도 메시지를 보낼 수 있다. 람다, kinsis등에도 보낼 수 있다.

 

sns는 다양한 aws 서비스에서 데이터를 수신할 수 있다.

 

cloud watch aaram, lammda, rds, s3, asg , kinesis data firehose....  

 

kinesis data streams는 구독 할 수 없다.

SNS + SQS : fan out

메시지를 여러 sqs 대기열로 보내고 싶은데 모든 sqs 대기열에 개별적으로 메시지를 보내면 문제가 발생할 수 있다.

sqs가 sns 주제를 구독하게 하는 것이다. 이 대기열들은 구독자로서 sns로 들어오는 모든 메시지를 받게 된다.

, 단 하나의 메시지를 SNS 주제로 전송한 뒤, 다수의 SQS 대기열로 ‘팬 아웃’합니다.

구매서비스 -> sns -> sqs1 ,

sqs2 , ->

sqs1 -> fraud service,  

sqs2 -> shipping service

 

SNS FIFO 

SQS와 마찬가지로 선입선출을 보장할 수 있다. 이 때 sqs도 선입선출 대기열이여야한다.

 

SNS message filtering

sns주제를 구독할 때 전송되는 메시지를 필터링하는데 사용되는 Json정책이다.

여기서 설정한대로 sqs는 필터링 된 메시지만 받을 수 있다.

json으로 상태가 202인 값만 sqs1이 구독하고,

205인 값만 sqs2가 구독하고

모든 메시지가 다 가는 것을 sqs3가 구독할 수도 있다.

 

Kinesis

실시간 스트리밍 데이터를 손쉽게 수집하고 분석 할 수 있다. 

웹사이트 클릭스트림, IoT원격 측정, 애플리케이션 로그등이 될 수 있다. 데이터가 빠르게 실시간으로 생성된다면 real-time data라고 볼 수 있다.

 

4가지로 구성됨

1.kinesis data streams : data streams를 수집, 가공, 저장

2.kinesis data firehose : aws내부나 외부의 데이터 저장소로 데이터스트림을 읽어들인다.

3.kinesis data analytics : analyze daya streams with sql or apache flink sql언어나 apache flink를 활용하여 데이터 스트림을 분석한다.

4.kinesis video stream : 비디오 스트림을 수집하고 처리 저장

  

kinesis data streams

큰 규모의 데이터 흐름을 다루는 서비스이다. 여러개의 샤드로 구성

몇개의 샤드로 시작할건지 정해야한다, 데이터ㅡㄴ 모든 샤드에 분배된다. 샤드는 데이터 수집률이란 소비율 측면에서 스트림의 용량을 결정한다, 생산자가 데이터를 kinesis data stream으로 보낸다고 해보자, 생산자는 다양하다. 애플리키에셔느 클라이언트, sdk ...일 수 있다. 생산자들은 kinesis data stream에 레코드를전달한다. 레코드는 2가지로 구성된다.

파티션키와 최대 1mb크기의 데이터블롭이다. 여기서 초당 1mb 아니면 초당 1000개의 메시지를 샤드당 보낸다.

샤드가 6개면 초당 6mb/ 6000개의 메시지를 전송할 수 있다,. 그럼 이 데이터는 소비자한테 간다.

소비자 역시 다양하다. 인스턴스에 있는 sdk라던지, 람다, firehose , analytics등이있다. 여기에 레코드를 보내는데

파티션키, 시퀀스넘버, 데이터 블롭을 보낸다. 

 

 

Kinesis Data streams vs Kinesis Data Firehose

 

Kinesis Data streams 

Streaming service for ingest at scale

write custom code ( producer / comsumer )

real time 

manage scaling 

data storage for 1 to 365 days

supports replay capability ( 여러 소비자가 같은 스트림에서 읽어올 수 있고 반복 기능도 지원 )

 

Kinesis Data Firehose

load streaming data into s3 , redshift, elastic search, 3rd party/ custom http

fully managed

near real time

automatic scaling 

no data storage 

doesn't support replay capability

 

ordering data into kinesis

트럭이 100대 있고 각 트럭당 아이디가 하나씩 있다고 가정하자.

GPS 위치를 주기적으로 AWS에 보낼 것이다.

이제 각 트럭의 순서대로 데이터를 소비해서, 그 경로를 순서대로 확인하려고 한다.

하지만 100대의 트럭이 동시에 데이터를 보내기에 어떤 트럭의 정보인지 구별하기 힘들다. 

이 때 파티션키로 트럭 id를 특정하면 된다.

같은 파티션 키를 지정하면 해당 키가 언제나 동일한 샤드로 전달된다.

 

트럭이 5대 존재하고 샤드가 3개 존재한다면 파티션키를 지정했을 경우

1번 2번 트럭이 1번샤드, 3번 4번트럭은 2번샤드, 5번 트럭은 3번 샤드로 데이터를 보낼 수 있다.

데이터가 언제가 같은 샤드로 이동한다. 

트럭이 100대이고, 샤드가 5개라면 샤드 하나당 평균 20대의 트럭의 데이터를 담당한다.

소비자는 샤드당 하나밖에 가질 수 없으므로 최대 5개의 소비자만 가질 수 있다.

 

ordering data into sqs

for sqs standard, there is no ordering 

그래서 sqs fifo라는 선입 선출 방식이 있다. 이 sql fifo의 그룹 Id를 사용하지 않으면 모든 메시지가 소비되는 방식은 보내진 순서에 따르며

소비자는 하나만 존재한다. 

 

그룹 id를 사용하면 fifo대기열은 내부에 두개의 그룹이 생기고, 정의한 그룹마다 각각 소비자를 가질 수 있게 된다.

 

let's assum 100trucks, 5 kinesis, 1 sqs fifo

Kinesis data stream : 

 on average you'll have 20 trucks per shard

 trucks will have their data ordered within each shard

 the maximum amount of comsumers in parallel we can have is 5

 can receive up to 5 mb/s of data

SQS FIFO

 you only have one sqs fifo queue

 you will have 100 group ID

 you can have up to 100 cumstomers ( due to the 100 group ID )

 you have to up to 300 messages per second ( of 3000 if using batching )

 

경우에 따라 적절한 모델은 달라지며 sqs fifo는 그룹 id숫자에 따른 동적 소비자 수를 원할때,

좋은 모델이고 kinesis는 10000대의 트럭이 많은 데이터를 송출하고 샤드당 데이터를 정렬할 때 좋다.

 

SQS, SNS, Kinesis 차이점

SQS에서는 소비자가 SQS대기열에서 메시지를 풀링해서 가져오는 식이다.

따라서 데이터를 처리한 후 소비자가 대기열에서 삭제해서 다른 소비자가 읽을 수 없도록 해야한다.

작업자나 소비자 수는 제한이 없다.

순서를 보장하려면 fifo대기열을 사용해야한다.

처리량에 제한이 없다 ( 스탠다드 기준 )

 

SNS는 pub/sub 모델이므로, 다수의 구독자에게 데이터를 푸시하면 메시지의 복사본을 받는다.

데이터가 한번 sns에 전송되면 지속되지 않는다. ( 제대로 전달되지 않으면 데이터를 읽을 수 있다는 뜻 )

처리량에 제한이 없다.

SQS와 결합할 수 있다. (fan out )

sns도 fifo를 사용할 수 있는데 그럼 sqs랑 엮을 때 sqs역시 fifo여야한다.

 

kinesis는 소비자가 데이터를 가져오는 표준모드는 2개가 있다.

스탠다드 : 읽어들이는 경우 초당 샤드당 2mb속도를 지원

enhanced-fan out : kinesis가 소비자에게 데이터를 푸시하며 샤드 하나에 소비자당 2mb의 속도가 나온다.

데이터를 다시 읽을 수 있기 때문에 실시간 빅데이터 분석 ETL등에 활용된다.

 

1~365일까지 데이터 보존 가능

샤드수를 미리 정다는 브로비저닝과, 온디맨드에서는 샤드가 자동으로 조정된다.