AWS SAA : Decoupling Application : SQS, SNS, Kinesis, Active MQ

Application Communication

• Synchronous communication
  • Service와 Service 사이가 직접적으로 연결되어있음
  • spike / overwhelmed 되면, 제대로된 서비스를 하지 못함
• Asynchronous / Event based communication
  • Service와 Service 사이에 Queue가 존재하여 간접적으로 연결되어있음

SQS

• SQS의 핵심은 Queue.
• Producer : Queue의 메세지를 보내는 주체
  • 1개 이상의 Producer가 있을 수 있음
• Queue : 메세지가 담김
  • 메세지를 처리해 Consumer로 메세지를 보냄
  • Producer와 Consumer를 분리하는 버퍼 역할을 함
• Consumer : Queue로부터 정보를 얻는 주체
  • 메세지를 polling하여 Queue로부터 정보를 얻음
  • 정보를 처리하고 Queue에서 메세지를 삭제
  • 1개 이상의 Consumer가 있을 수 있음

SQS - Standard Queue

Queue

• 가장 오래된 서비스
• decouple applications!
• 무제한 처리량을 얻을 수 있음
  • 큐에 무제한 메세지를 보낼 수 있음
  • 큐에 속해있는 메세지의 수도 제한되어 있지 않음
  • 처리량 문제를 해결하기 위해, 무한히 확장 가능한 SQS Queue를 활용함
• 메세지의 유지 기간은 짧음 (4일 ~ 14일)
• 지연시간이 짧음
• 메세지는 256KB 미만이어야 함
• Consumer가 여러개이므로, 중복 메세지가 있을 수 있음.
• Consumer가 여러개이므로, 이미 한 Consumer가 처리한 것에 대해서는 다른 Consumer에서는 처리를 못하므로 최선의 오더 (Best Effort Ordering) → 품절 메세지 보낼 수 있음

Producer

• 최대 256KB의 메세지를 생산
• SDK를 이용해, SendMessage API를 통해 SQS에 메세지를 보냄

Consumer

• AWS service (EC2 instance, on-premise server, Lambda..) 에서 메세지를 수신하고 읽을 수 있음
• Queue에 Polling하여 메세지를 받아오고, 그를 처리함

SQS with Auto Scaling Group

1. Auto Scaling Group으로 EC2 instance를 감싼다.
2. EC2 instance는 Consumer로, SQS Queue로부터 메세지를 풀링한다.
3. SQS Queue에 CloudWatch Metric을 설정하고, ApproximateNumberOfMessages (대기열 크기) 변수를 모니터링한다.
4. 만약 해당 변수가 특정 threshold를 넘어갈 경우, CloudWatch Alarm이 발생하며, AutoScalingGroup에서 Scale Out을 진행한다.

SQS to decouple between application tiers

1. User가 Front-End Web app에 요청을 보낸다
2. Front-End Web app은 받은 요청을 SQS Queue로 보낸다
3. Back-End processing app은 SQS Queue로부터 메세지를 풀링하고, 비디오를 처리하는 요청을 수행한 뒤 S3 bucket에 삽입한다.

→ Front-End 와 Back-End가 독립적으로 Scaling된다

SQS Security

Encryption

• In-flight encryption using HTTPS API
• KMS key를 사용한 Encryption
• Client측 Encryption → Client가 자체적으로 암호화/복호화

Access Control

• SQS API 접근을 위한 IAM 정책 설계

SQS Access Policies

• Cross-account 접근이 필요할 때
• 다른 서비스의 접근이 필요할 때

SQS Message Visibility Timeout

• Consumer 하나가, message를 폴링하면 Visibility timeout이 발생함
• timeout은 기본적으로 30초로 설정되어있음
  • 너무 길게 설정하면, re-processing하는데 너무 오랜 시간이 걸림
  • 너무 짧게 설정하면, 처리 중복이 너무 많아짐
• timeout 동안 다른 consumer들은 해당 메세지에 접근할 수 없음
• 하지만 timeout 시간동안 기존의 Consumer가 메세지를 처리한 뒤 삭제하지 못했다면 (=메세지를 처리하지 못했다면), timeout 시간 이후 메세지는 다시 Queue로 돌아가고 다른 Consumer에서 같은 메세지를 가져감 (처리 중복)
• 따라서, 만약 timeout 시간동안 기존의 Consumer가 메세지를 처리하지 못할 것을 알고 있다면 ChangeMessageVisibility API를 활용해서 처리할 시간을 더 길게 가져갈 수 있음

SQS Long Polling

Consumer가 Queue에 메세지를 요청하는데, Queue에 아무것도 없으면 기다림

목적

• 지연시간을 줄임
• SQS로 보내는 API 호출 횟수를 줄임

방법

• Queue Level에서 구성하여 Long Pooling 활성화
• Consumer Level에서 WaitTimeSeconds를 늘려 구성

SQS FIFO Queue

• First In First Out → Standard Queue 보다 순서를 확실히 보장
• Standard Queue와 다르게 처리량이 제한적임
• 중복을 제거하여 정확히 한 번만 보냄
• 메세지가 소비자에 의해 순서대로 처리됨
• Group ID
  • Group ID가 없으면, 소비자는 1개만 존재할 수 있음
  • Group ID가 있으면, 소비자를 여러개로 늘릴 수 있음

SNS

Amazon Simple Notification Service : 하나의 메세지를 여러 사용자에게 전달

• Direct Integration : 하나의 서비스에서 다른 서비스들로 메세지 직접 전달
• Pub/Sub : 하나의 서비스에서 SNS Topic에 메세지를 업로드 (Publish)하면, 각 Topic을 구독하는 (Subscribe) 다른 서비스들이 메세지를 받아 저장
• Event Producer : 하나의 SNS Topic에만 메세지를 보낼 수 있음
• Event Receiver (Subscription) : SNS Topic 알림을 설정하고, 설정한 Topic에 대한 모든 메세지를 전달받음, 필터링도 가능함
  • Filtering : JSON 규칙으로, 모든 메세지가 아닌 필요한 메세지만 받음
• Event Producer (AWS Services) → SNS Topic : CloudWatch Alarm, ASG Notification, CloudFormation, … 등 알림 전달
• SNS Topic → Subscribers : Email, SMS, Mobile Notification, HTTP(S) Endpoint, SQS, Lambda, Kinesis Data Firehose
• SNS Topic 별로, 최대 1,200만 Subscriptions 가능
• 계정당 가질 수 있는 Topic은 10만개정도.
• Topic Publish (using SDK)
  1. Topic 생성
  2. Subscription(s) 생성
  3. Topic Publish
• Direct Publish (for mobile apps SDK)
  1. Platform Application 생성
  2. Platform Endpoint 생성
  3. Platform Endpoint에 Publish
  • Google GCM, Apple APNS, Amazon ADM에서 알림 수신 가능

SNS Security

Encryption

• In-flight encryption using HTTPS API
• KMS key를 사용한 Encryption
• Client측 Encryption → Client가 자체적으로 암호화/복호화

Access Control

• SNS API 접근을 위한 IAM 정책 설계

SNS Access Policies

• Cross-account 접근이 필요할 때
• 다른 서비스의 접근이 필요할 때

SNS, SQS : Fan Out

SQS 대기열이 여러개일 때, 각각의 대기열에 하나씩 보내면 문제 발생

→ Fan Out 사용

1. SNS topic으로 1번 메세지를 전송
2. 원하는만큼 SQS Queue를 SNS topic에 구독시켜 메세지를 받게 함

• Fully Decoupled
• No data loss
• SQS로 데이터 지속성, 지연처리, 작업 재시도 등의 효과 얻음
• SQS queue 정책에 SNS의 쓰기 기능을 허용해야 함
• Cross-Region Delivery : 한 리전의 SNS topic이 다른 리전의 SQS queue에 메세지를 보낼 수 있음

Amazon Kinesis

실시간 스트리밍 데이터를 손쉽게 수집하고 처리할 수 있음

• 애플리케이션 로그, 메트릭, 웹사이트 클릭 스트림, IoT 원격 측정 데이터 등…

Kinesis Data Streams

데이터 스트림 수집, 처리, 저장

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

보존 기간 : 1일 ~ 365일

데이터를 다시 처리하거나 확인 재생 (replay) 가능

데이터가 스트림에 들어오면, 삭제될 수 없음

실시간 Real-time

용량 유형

• Provisioned mode
  • 프로비저닝할 샤드 수를 미리 정하고 API를 활용하거나 수동으로 조절함
  • 각 샤드는 1MB/sec (in) 2MB/sec (out)
  • 시간당 비용 부과됨
• On-demand mode
  • 프로비저닝을 하거나 용량 관리할 필요 X → 시간에 따라 언제든 용량 조절
  • 각 샤드는 기본적으로 4MB/sec 로 처리되지만, 최근 30일동안의 처리량에 기반하여 scaling을 진행하고 이에 따라 비용이 부과됨

보안

• IAM 정책을 사용해 샤드를 생성하거나 접근 권한을 제어
• HTTPS로 전송 중 데이터 암호화, KMS로 미사용 데이터 암호화
• 클라이언트 측 데이터 암호화/복호화도 가능
• VPC Endpoint 사용하여 접근 가능
• 모든 API 요청은 CloudTrail로 모니터링

1~N번까지 번호가 부여된 여러 개의 샤드(Shard)로 구성, 미리 프로비저닝

• Shard는 데이터 수집률, 소비율 측면에서 스트림의 용량 결정

Producer : Kinesis Data Stream 에 데이터를 Record 형태로 전달

• Application
• Client
• SDK, KPL
• Kinesis Agent

Record (Producer → Data Stream)

• Partition Key : 레코드가 이용할 샤드를 결정하는데 사용
• Data Blob : 1MB 이하, 값 자체

⇒ 1MB/sec or 1000 msg/sec per shard

Record (Data Stream → Consumer)

• Partition Key : 샤드 번호
• Sequence No : 샤드 내 위치 번호
• Data Blob : 값 자체

⇒ 2MB/sec (shared) per shard all consumers

2MB/sec (enhanced) per shard per consumer

Consumer

• Apps : KCL, SDK
• Lambda
• Kinesis Data Firehose
• Kinesis Data Analytics

Kinesis Data Firehose

데이터 스트림을 AWS 내부나 외부의 데이터 저장소로 읽어들임

완전 관리형 서비스

자동 스케일링, 서버리스

거의 실시간으로 작동함 (Near Real-time)

• Firehose → Destination 한번에 데이터 작성하기 때문
• 버퍼 간격과 크기를 잘 조절하여 실시간처럼 만들 수 있음

Firehose를 통과하는 데이터에 대해서만 비용 지불

데이터 재생 (replay) 불가능

Producer : Kinesis Data Firehose 에 데이터를 Record 형태로 전달

• Application
• Client
• SDK, KPL
• Kinesis Agent
• Kinesis Data Streams
• CloudWatch (Logs & Events)
• AWS IoT

Kinesis Data Firehose

• Producer로 부터 데이터 레코드 받음
• Lambda function 이용해 Data Transformation (선택 사항)
• Batch write : 일괄적으로 Destination에 작성
• S3 backup bucket에 데이터 작성 (전체 / 실패한 데이터)

Destination

• AWS Destination
  • S3
  • Redshift ← S3 복사
  • OpenSearch
• 3rd part partner Destination
  • DataDog
  • Splunk ..
• Custom Destination
  • HTTP Endpoint API

Kinesis Data Analytics

SQL 언어나 Apache Flink를 활용해 데이터 스트림 분석

Kinesis Video Stream

비디오 스트림을 캡쳐, 처리, 저장

Kinesis vs SQS FIFO Ordering

ex. 100개의 producer, 5개의 shards, 1개의 SQS FIFO

• Kinesis Data Stream
  • 1개의 shard에서는 20개의 producer를 평균적으로 가짐
  • 각 shard에서는 데이터가 정렬된 상태로 유지됨
  • consumer는 5개가 최대임 (← shard 개수)
• SQS FIFO Ordering
  • 각 producer ID에 상응하는 group ID를 생성해 100개 가짐
  • consumer는 100개가 최대임 (← group ID 개수)

SQS vs SNS vs Kinesis

• SQS
  • 소비자가 SQS 큐에 메세지를 폴링해서 데이터를 가져옴
  • 데이터 처리한 후 소비자가 큐에서 직접 삭제해 다른 소비자가 처리할 수 없도록 만들어야 함
  • 작업자나 소비자 수에 제한이 없음
  • 관리된 서비스이므로 프로비저닝이 필요 없음
  • 순서를 보장하기 위해서는 FIFO Queue 를 활성화
  • 각 메시지에 지연 기능이 있어, 일정 시간 뒤에 대기열에 나타날 수 있음
• SNS
  • pub/sub 모델로, 데이터를 푸시 (Publish) 하면 여러 구독자 (Subscriber)가 데이터를 받음
  • SNS topic별로 1200만명의 구독자 가능
  • 데이터가 한번 SNS에 전송되면 유지되지 않음 (데이터 유실 가능)
  • SNS topic은 최대 10만개까지 가능
  • 관리된 서비스이므로 프로비저닝이 필요 없음
  • Fan-out feature를 위해 SQS와 통합
• Kinesis
  • Standard : pull data → 소비자가 Kinesis로부터 데이터를 가져옴
  • Enhanced fan-out : push data → Kinesis가 소비자에게 데이터를 전송
  • 데이터 지속되기 때문에 다시 재생 가능
  • 실시간 빅데이터 분석, ETL에 활용
  • 샤드 레벨에서 정렬 가능
  • 데이터 보존 가능
  • 용량 모드 : Provisioned mode / On-demand mode

Amazon MQ

온프레미스의 전통 애플리케이션에서 MQTT, AMQP, STOMP, Openwire, WSS와 같은 프로토콜을 사용, 이를 클라우드로 migrate할 때, MQ를 사용

MQ : RabbitMQ와 ActiveMQ 를 위한 관리형 메세지 브로커 서비스

• 확장성이 크지는 않음 (SQS, SNS만큼은 아님)
• 서버에서 실행되므로 서버 이슈 발생 가능
  • 고가용성을 위해 장애 조치와 함께 다중 AZ 설정 가능
• SQS처럼 보이는 대기열 기능과 SNS처럼 보이는 topic 기능 제