SQS, SNS, Kinesis

매 초 10개의 요청만 처리할 수 있는 옵션의 인스턴스 구성에
1000개의 요청이 들어온 경우 연결되어 있는 모든 애플리케이션은
연쇄적 과부하가 발생할 수 있음

위 문제는 애플리케이션을 분리하고 분리 계층을 확장할 수 있는 모델 필요

SQS

• 대기열 서비스
  • SQS 의 주 역할
  • 생산자와 소비자를 분리하는 버퍼 역할
• 생산자(Producer)
  • SQS 대기열에 메시지를 보내는 주체
  • 다수의 생산자 생성 가능
• 소비자(Consumer)
  • 대기열 메시지를 수신/처리/삭제하는 대상, 폴링 상태로 있음
    • 폴링: 대기열에서 소비자 앞으로 온 메시지가 있는지 확인
  • 다수의 소비자 생성 가능

Standard Queue

무제한 처리량
초당 원하는 만큼의 메시지 전송
메시지 수 제한 없음
메시지 크기 256KB 미만
메시지 보존 기간 4일(최소), 14일(최대)

Security

HTTPS API 사용으로 메시지 생성/전달 단계에서 암호화
KMS 키 사용으로 일반적인 암호화 미사용 가능
IAM 정책을 사용하여 SQS API 에 대한 액세스 규제 가능

SQS 액세스 정책

SQS 대기열의 교차 계정 액세스, SNS, S3 에서 접근해야할 때 유용

SQS with ASG

SQS Queue 메시지를 처리하기 위해 백엔드 서버(EC2, Lambda)에서 폴링 상태
그러나 대기열이 많거나 적은 경우 백엔드 서버(소비자)도 늘어나거나 줄어야함
스케일 대상인 지표(대기열 길이)가 필요하며 지표 서비스를 연결하여
SQS Queue 상태를 확인 가능
그러나 단순히 지표값 만으로 스케일인/아웃을 구분할 수 없음
알람 서비스를 연결하여 대기열 수 에 대한 스케일 인/아웃 의 설정값 세팅 가능
이 후 운영중인 서비스의 상태는 알람을 통해 ASG 가 인스턴스를 자동으로 스케일 진행

지표 서비스 ApproximateNumberOfMessages(Queue Lengh)
모든 SQS 대기열에 사용할 수 있는 CloudWatch 지표로 대기열 길이 확인용

알람 서비스 CloudWatch Alarm
대기열의 길이가 특정 수준을 넘은 경우에 사용할 수 있음

SQS 실습

1.SQS Dashboard -> Create Queue
2.Queue 타입, 이름, 구성, 암호화 등 설정 후 Create
3.생성한 Queue -> Send and receive message
4.메시지가 정상적으로 들어가는 테스트 -> 값 설정 -> Send message
5.하단에 Receive messages 우측 Poll for messages 클릭
6.Messages 에 생성한 메시지가 대기열에 있는지 확인
7.메시지 확인 후 삭제하면 정상적으로 메시지를 처리했다고 판단

Message visibility timeout

SQS Queue, 생성된 1개 메시지, 폴링 중인 A, B 소비자
A 소비자가 메시지를 받으면 B 소비자는 visibility timeout 에 설정한 시간 동안
메시지를 확인 불가
그러나 visibility timeout 시간 동안 작업이 정상적으로 처리되지 않게 되면
폴링 중인 B 소비자는 다시 대기열에 들어온 메시지를 전달받게 됨
A 소비자가 visibility timeout 시간 안에 처리하지 못했지만 이 후 해당 메시지가
정상적으로 처리되었다면 B 소비자에서 동일한 요청을 한번 더 처리하게 됨

소비자가 메시지를 처리하는 작업 시간이 visibility timeout 보다
늦어질 걸 예상할 수 있다면 SQS Queue 서비스에 ChangeMessageVisibility API 를
호출하여 메시지가 SQS Queue 에 재생성되는 시간을 늦출수 있고
위 예시와 같은 문제를 해결할 수 있음

Long polling

Consumer 가 대기열의 메시지를 대기하는 시간을 최대한 길게 적용 하여
SQS API 호출, 지연시간을 줄이는 방법
시간 설정은 1 ~ 20초로 설정 가능하며 일반적으로 긴 시간을 선호

FIFO

Standard Type 보다 더 정확한 선입선출
초당 메시지 처리량 300/3000(메시지 묶음) 개
중복을 제거하여 정확히 한번만 보내도록 하는 옵션 제공
SQS 로 보내는 메시지 처리량 제한 설정 가능\
Queue 이름에 접미어로 .fifo 를 반드시 붙여서 생성해야 FIFO 적용 가능

FIFO 타입을 클릭하면 Standard 타입과 구성이 거의 동일하며
content-based deduplication(중복 제거 옵션) 체크 박스만 하나 추가됨

SNS

메시지 한 개를 여러 수신자에게 전달하려 할 때 Direct Integretion(직접 통합) 사용
직접 통합을 사용하여 메시지를 각 주제 별로 수신하도록 설정할 수 있음
수신은 AWS 의 다양한 서비스들이 수신 가능

• event producer(이벤트 생산자)
  • 하나의 SNS 주제(Topic)에만 메시지를 보냄
• event consumer(이벤트 소비자/구독자)
  • 특정 주제의 SNS 알람을 받으려는 경우

Fan Out

SNS + SQS 팬 아웃 패턴
애플리케이션에서 SNS Topic 에 메시지를 전송한 후 SQS 대기열들이 SNS 주제를 구독
SQS 대기열들은 SNS 의 구독자로 원하는 Topic 의 메시지를 모두 받을 수 있음

주제별 분리, 데이터 무손실, SQS 재작업, 데이터 지속성, 지연 처리 수행 등 수행 가능
SQS 액세스 정책에서 SNS 주제가 SQS 대기열에 쓰기 작업 허용 필요
A 리전의 SNS 주제를 B 리전의 SQS 대기열에 쓰기 가능

FIFO

SQS FIFO 와 기능이 같으며 필요한 이유는 SQS FIFO 를 유지하기 위해 사용

Message Filtering

JSON 정책으로 구독자에게 메시지를 전달할 때 전송되는 메시지를 필터링하는 기술
예시로 구매 서비스라는 애플리케이션이 있고 SNS Topic 에 보내는 메시지와 주제가
발주, 취소가 있다면 SQS 대기열을 2개를 만들어 하나는 발주 주제의 메시지들
다른 하나의 대기열은 취소 주제의 메시지들만 받아서 처리하도록 필터링할 수 있음

SNS 실습

1.SNS Dashboard -> SNS Topic 명 설정 & Next step
2.타입, 이름, 설정 -> create topic
3.하단에 Create subscription 클릭
4.프로토콜, 필터, 정책 설정 -> create subscription 클릭
5.publish message 클릭하여 메시지 생성
6.적용한 프로토콜에 생성한 메시지 전달되는지 확인

Kinesis

실시간 스트리밍 데이터를 손쉽게 수집/처리/분석 가능

Kinesis Data Streams

여러개의 샤드로 구성, 1 ~ N 개, 사용시 프로비저닝 필요
데이터는 프로비저닝한 수 만큼의 샤드에 분배

• Shard
  • 기본 처리량 단위 역할
  • 쓰기는 1MB/초, 초당 1,000개의 레코드, 읽기는 2MB/초 지원
  • 생산자는 6개의 shard 있을 경우 초당 6MB 또는 6000개의 레코드를 얻을 수 있음
  • 소비자는 6개의 shard 초당 12MB 읽기가 가능함
• Record
  • KDS 에 저장되는 데이터 단위
  • Partition Key, 1MB 크기의 데이터 블롭으로 구성
  • Partition Key
    • 레코드가 이용할 샤드를 결정하는데 사용

Producers

Applications, Client(PC, Mobile), SDK, KPL, Kinesis Agent ...

Consumers

Apps(SDK, KCL), Lambda, Kinesis Data Firehose or Analytics ...

Capacity Modes

• Provisioned mode
  • 샤드 수 설정하거나 API 활용하여 수동으로 조정
  • 샤드 사양은 위 설명과 동일
  • 소비 유형, 효율성을 높인 팬아웃 방식으로 적용되며 시간당으로 비용 부과됨
• on-demand mode
  • 기본적으로 초당 4MB, 4000개의 레코드 처리
  • 지난 30일 동안을 관측한 최대 처리량에 기반하여 자동으로 설정
  • 시간당, 스트림당, 송수신 데이터양(GB 단위)에 따라 비용 부과

사용량을 예측하기 어려울 때 on-demand 모드 사용 권장

Security

접근 제어, IAM 정책을 사용한 승인(권한 부여)
HTTPS endpoints 에 전송중인 데이터 암호화
미사용 데이터는 KMS 로 암호화 가능
클라이언트에서 데이터를 암호화/복호화 가능
VPC 를 사용하여 인터넷을 거치지 않고 프라이빗 서브넷의 인스턴스에 접근 가능
모든 API 요청은 CloudTrail 사용하여 감시 가능

Kinesis Data Stream 실습

1.Kinesis Dashboard -> KDS 클릭 -> Create data stream
2.name, capacity mode 설정
3.capacity mode -> provisioned 인 경우 shard 수 설정
4.CLI 명령어 put-record, get-records 데이터 입력/출력 확인

Kinesis Data Firehose

생산자에서 데이터를 가져올 수 있는 서비스
자동으로 용량의 크기가 조정되고 서버리스로 관리할 서버가 없음
KDF 를 통하는 데이터에 대해서만 비용을 지불

• 세 개의 주 수신처
  • Amazon S3
  • Amazon Redshift(데이터 웨어하우스)
    • 이 곳에 데이터를 쓸 때 먼저 S3 에 데이터를 쓰고 복사 명령어를 내보냄
    • 위 명령어가 S3 데이터를 레드시프트로 복사하는 방식
  • Amazon ElasticSearch

위 아마존 서비스를 제외한 써드파티 파트너도 있고 계속 늘어나고 있으며
HTTP 엔드포인트가 있는 API 서버가 있으면 KDF 를 통해 수신처로 사용 가능

근 실시간

전체 배치가 아닌 경우 최소 60초의 지연시간 발생
데이터를 수신처에 보낼 때 한 번에 적어도 1MB의 데이터가 있을 때까지 대기 필요

Kinesis Data Streams vs Firehose

• Kinesis Data Streams
  • 데이터를 대규모로 수집할 때 쓰는 스트리밍 서버
  • 생산자, 소비자에 대해 커스텀 코드를 사용할 수 있음
  • 실시간으로 이루어짐
  • 70ms ~ 200ms 정도의 지연시간 발생
  • 용량을 직접 조정할 수 있어 샤드 분할, 병합으로 용량이나 처리량을 늘릴 수 있음
  • 제공한 용량 만큼의 비용 지불
  • 데이터 1 ~ 365일 저장으로 여러 소비자가 같은 스트림에 읽거나 반복 기능 가능
• Kinesis Data Firehose
  • 수집 서비스로 데이터를 S3, 레드시프트, ElasticSearch, 써드 파티 파트너에 전달
  • 완전 관리, 서버리스, 근 실시간
  • 자동으로 용량 조정과 KDF 를 통하는 데이터의 비용 지불
  • 데이터 스토리지가 없으므로 데이터 반복 기능은 지원하지 않음

Kinesis Data Firehose 실습

1.Kinesis Dashboard -> Delivery Streams -> Create delivery stream
2.source(생산자), destination(대상, 소비자?) 설정
3.생산자/소비자에 대한 상세 설정, 고급 설정 -> Create delivery stream
4.해당 테스트에서는 생산자: KDS, 소비자: S3
5.CloudShell 에서 커맨드를 입력하여 KDS 에 메시지를 전달
6.최종 목적지인 S3 에 데이터가 들어와 있는지 확인

Kinesis, SQS FIFO 데이터 정렬

Kinesis 는
5개의 Producer 있고 Kinesis 에 데이터를 스트리밍할 때 파티션 키를 이용
Kinesis 는 파티션 키를 hash 하여 얻은 값에 매칭되는 Shard 에 전송

SQS FIFO 는
그룹 ID 를 사용하지 않은 메시지 소비 방식은 보내진 순서에 따르며 소비자는 하나만 존재
소비자 숫자를 스케일링하고 연관된 메시지를 그룹화하고 싶은 경우 그룹 ID 사용
그룹 ID 사용시 추가한 수 만큼 FIFO 내부에 그룹이 추가 생성됨
A, B, C 그룹을 생성하면 1, 2, 3 의 소비자를 얻게되는 구조

사례에 따른 Use Case

SQS FIFO 는 Group id 숫자에 따라 동적 소비자 수를 원할 때
KDS 는 특정한 수의 생산자가 많은 데이터를 전송하고 샤드당 데이터를 정렬해야할 때

Amazon MQ

RabbitMQ, ActiveMQ 를 위한 관리형 메시지 브로커 서비스
온프레미스에서 기존 애플리케이션을 실행하는 경우
개방형 프로토콜 MQTT, AMQP, STOMP, WSS, Openwire 사용
애플리케이션을 클라우드에 마이그레이션하는 경우 애플리케이션을 다시 구축하지 않고
위 명시된 프로토콜을 사용하고 싶은 경우 amazon MQ 사용

확장성이 크지 않음
Amazon MQ 는 서버에서 실행되며 문제가 발생할 수 있음
이를 위한 조치로 고가용성을 위한 장애조치 다중 AZ 설정을 실행할 수 있음

• MQTT(Message Queueing Telemetry Transport)
  • ISO 표준 발행/구독 기반의 메시지 프로토콜
• AMQP(Advanced Message Queing Protocol)
  • 메시지 지향 미들웨어를 위한 개방형 표준 응용 계층 프로토콜
    • 메시지 지향 미들웨어란 응용 소프트웨어 간의 데이터 통신을 위한 소프트웨어
• STOMP(Simple Text Oriented Messaging Protocol)
  • 메시지 지향 미들웨어와 함께 작동하도록 설계된 단순 텍스트 메시지 프로토콜
• WSS
  • SSL 적용된 웹소켓

Amazon MQ High Avaliability

특정 리전안에 1a, 1b 가용 영역에 MQ broker 가 있고
각 broker 에 EFS(다중 가용 영역에 마운트 가능) 를 연결
위 설정은 하나의 브로커에 장애 조치가 발생해도 활성, 대기 상태의 대기열
모두 동일한 데이터를 가질 수 있고 장애 조치 발생에도 올바르게 작동 가능