섹션 17 디 커플링 애플리케이션: SQS,SNS,Kinesis,Active MQ

SQS

SQS 대기열에 메시지를 보내는 주체를 생산자 (1 or many)

수신해야 하는 대상을 소비자

SQS - Standard Queue

완전 관리형 서비스이며 애플리케이션을 분리하는데 사용

무체한 처리량

메시지 대기열에 있을수 있는 시간은 기본 4일 최대 14일

지연시간 짧다

SQS 메시지는 작아야한다.

중복 메시지가 있을수 있다

SQS - Producing messages

• produced to SQS using the SDK
• 메시지는 소비자가 삭제할때까지 persised

SQS - Consuming Messages

• cunsumers ( running on EC2 instances , servers, or AWS lambda)

SQS with Auto Scaling Group ( ASG)

cloudWatch 를 통해서 queue 길이에 대한 알람을 받고

auto scaling 작동시켜서 SQS queue 처리량 증가

SQS message visibility timeout

메시지 가시성 시간 초과는 기본값 30초

30초 동안 메시자 처리되어야 함

가시성 시간 초과 기간동안 처리하지 않으면 해당 메시지가

다음 처리 할때 나타나니깐 메시지가 두번 처리될수 있음

메시지 처리 시간 변경하는 changeMessageVisibility 가 있음

Amazon SQS - Long Polling

소비자가 대기열에 메시지 요청 대기열에 아무것도 없으면 대기

1. 지연시간 줄이기 가능
2. 요청 횟수 감소

Amazon SQS - FIFO Queue

선입 선출

보낸 순서대로 받으니깐 순서에 보장이됨

중복을 제거해줌

처리량에 제한이 있다

queue 만들때 이름 뒤에 .fifo를 붙여야 생성가능

Amazon SNS

이벤트 생산자는 한 sns 주제에만 메시지를 보낸다.

구독자는 해당 주제에만 메시지를 받는다.

주제별로 최대 1,200 만 이상의 구독자 가능

계정당 가질수 있는 주제의 수는 100,000

kinesis data firehose는 지원하지만 kinesis data streams 는 지원안함

how to publish

• topic publish ( using the SDK )
  • create a topic
  • create a subscription
  • publish to the topic
• direct publish ( for mobile apps SDK)
  • create a platform application
  • create a platform endpoint
  • publish to the platform endpoint

SNS + SQS : Fan out

• push once in SNS , receive in all SQS queues that are subscribers
• fully decoupled, no data loss
• 메시지를 sns 주제로 전송한뒤 다수의 SQS 대기열로 팬 아웃 한다.

sns -message filtering

kinesis

• make it easy to collect , process ,and analyze streaming data in real-time

kinesis Data Streams : capture, process, and store data streams

kinesis data firehose : load data streams into AWS data stores

kinesis data analytics : analyze data streams with SQL or Apache Flink

Kinesis Data Streams

시스템에서 큰 규모의 데이터 흐름을 다루는 서비스

생산자가 kinesis data stream에 데이터를 전송하고 데이터는 거기에 잠시 머물면서

여러 소비자에게 얽힌다.

보존기간은 1~ 365 days

사용량이 예측 할수 없다면 on-demand mode

사용량이 예측가능하면 provisioned mode

용량 제한은 샤드의 수에 의해 결정

kinesis Data Firehose

• fully managed service , 관리 필요없고 ,자동 용량 조정

Kinesis Data Streams + kinesis Data firehose=실시간 데이터를 S3와 Redshift로 로딩하기 위한 완벽한 기법 조함

kinesis Data streams vs firehose

Kinesis Data Streams :

• 데이터를 대규모로 수집할때 쓰는 스트리밍 서비스
• 생산자와 소비자 커스텀 코드 사용
• supports replay capability

kinesis Data firehose

수집 서비스로 데이터를 아마존 s3나 레드시프트 , ES, 3rd party 로 스트리밍

near real-time

ordering data into kinesis

파티션 키를 해시해서 어느 샤드로 보낼지 결정

데이터가 골고루 분산

ordering data into SQS

SQS FIFO 대기열은 하나뿐이다.

그룹 ID를 생성

SQS ,SNS ,Kinesis 차이점

SQS :

소비자가 SQS 대기열에서 메시지를 요청해서 데이터를 가져오는 모델

데이터를 삭제해서 다른 소비자가 읽지 못하게 함

작업자나 소비자 수는 제한이 없다. 처리량을 프로비저닝할 필요 없다.

순서를 보장하려면 fifo queues

메시지 지연 기능 있음

SNS :

다수의 구독자에게 데이터를 푸시하면 메시지의 복사본을 받게 됨

데이터가 제대로 전달되지 않으면 데이터를 잃은 가능성 있음

게시 구독 모델

처리량 프로비저닝 할 필요 없다.

FAN OUT 아키텍처 패턴 이용할경우 SQS와 결합 가능

Kinesis:

standard : pull data

enhanced-fan out :push data

실시간 빅 데이터 분석 ,ETL 등에 활용

프로비전 모드 :원하는 사드양 미리 지정

온디멘드 모드 :샤드 수가 Kinesis 데이터 스트림에 따라 자동으로 조정

Amazon MQ

애플리케이션을 클라우드에 마이그레이션 하는 경우에는

애플리케이션을 다시 구축하고 싶지 않고 MQTT, AMQP 등과 같은 기존에 쓰던 프로토콜을 사용하고 싶을 때

RabbitMQ 와 ActiveMQ 두가지 기술을 위한 관리형 메시지 브로커 서비스

확장성이 크지 않고 서버 문제 있을수 있음

Queue 기능과 topice 주제 기능