woongs dogfoot

Amazon SQS

• SQS Queue : Producer와 Consumer를 분리하는 buffer역할을 하는 메세지 저장소(?)

• Producer : SQS Queue에 메세지(ex. 명령 등)를 보내는 생산자

• Comsumer : SQS Queue에 있는 메세지를 수신하는 대상, polling 방식으로 Queue로부터 메세지를 가져옴 (Queue에게 수신자 대상의 메세지가 있는지 확인 후, 있으면 가져옴) -> 메세지 수신 후, Queue에서 해당 메세지 삭제
  
  
  

• Standard Queue

1. 가장 오래된 Queue
2. 완전 관리형 for decouple application
3. 무제한 처리량, 대기열 메세지 수도 제한 없음
4. 메세지는 수명이 짧음 -> 메세지는 기본적으로 Queue에 4일 동안 저장되고, 최대 14일까지도 유지됨 -> Consumer가 메세지 수명 기간안에 수신해야 함
5. 저지연 성능 -> 메세지 송신/수신 시간이 매우 짧음
6. 메세지 크기는 작아야 함 (< 256KB)
7. 동일 메세지가 여러번 송/수신 되는 경우가 있음 (중복 메세지 있을 수 있음)
8. can have out of order messages (best effort ordering) -> 메세지 수신 순서를 정할 수 있다는 말인 듯?
   
   
   

• Producing Messages

1. Producer(application)는 SQS로 메세지를 보내는 SDK를 통해 SQS Queue에 메세지를 보낼 수 있음
2. use case : 어떤 처리를 위한 오더 메세지를 보낼 수 있음 (처리에 필요한 값과 함께)

• Consuming Messages

1. Consumer는 application으로 EC2 인스턴스나 온프레미스, Lambda가 될 수 있음
2. polling방식으로 메세지 수신 -> consumer가 SQS Queue에 자신에게 온 메세지가 있는지 질의
3. 한번에 최대 10개까지의 메세지 수신
4. consumer가 메세지를 수신한 후, DB에 메세지의 값을 저장하는 등 처리를 완료하면 SQS Queue상의 해당 메세지를 삭제해야할 의무가 있음 (SQS SDK의 DeleteMessage API 활용)
5. Consumer를 여러개 가질 수 있음 -> 메세지를 먼저 수신한 Consumer가 메세지를 빠르게 처리하여 삭제하는 것이 아니라면 다수의 Consumer들이 메세지를 수신할 수 있음 -> 메세지 수신 순서를 정해야 함
6. Consumer를 늘리는 방식으로 처리량을 늘릴 수 있음

• SQS with Auto Scaling Group (ASG)
  : Queue의 길이(ApproximateNumberOfMessages, CloudWatch 지표 : Queue내 메세지 갯수)가 특정 기준을 넘으면 CloudWatch Alarm이 발생하도록 할 수 있음 -> 더 많은 양의 메세지 처리가 필요하기 때문에 ASG에 Alarm을 보내어 Scale-Out이 되도록 함 -> SQS의 메세지 처리량 증가 -> 축소도 가능

• SQS to decouple between application tiers
  : front에서 S3로 video처리를 바로 요청하여 받으면 느릴 수 있음 -> 아래 사진의 SQS + ASG 구조 적용, 더 좋은 성능의 Back 서버를 경유하게 하여 Video 처리 진행 -> 성능 개선
  
  
  

• SQS Security

1. HTTPS로 메세지를 보내고 수신함 -> 전송중 암호화 (SSE-SQS, SSE-KMS 두 가지 key 지원)
2. KMS키를 활용하여 전송중 암호화 가능
3. client에서 직접 암호화/복호화 가능 -> SQS에서 기본적으로 지원하는 기능은 아님
4. IAM 정책을 통해 SQS API로의 접근을 제어할 수 있음 (호출측? 제어)
5. S3 Bucket Policy와 같은 SQS Access Policy도 있음 -> 교차계정 접근이나 다른 서비스에서의 접근을 허용하는 데 유용함 (응답측? 제어)
   
   
   

Message Visibility Timeout

• Message Visibility Timeout : Consumer가 Queue의 Message받고 처리하기 시작했을 때부터 Visibility Timeout 시간동안 다른 Consumer가 Message를 수신할 수 없음 -> 다른 Consumer는 해당 시간동안 Message가 보이지 않음 (default : 30s)
• Visibility Timeout 시간이 지나고 Message가 삭제되지 않으면 다른 Consumer가 해당 Message를 수신하여 처리할 수 있게됨 -> 해당 시간 동안 처리되지 않으면 동일한 Consumer가 동일한 Message를 수신하거나, 다른 Consumer가 수신할 수 있게됨
• ChangeMessageVisibility API를 호출하여 더 많은 Visibility 시간을 확보할 수 있음

Long Polling

• Long Polling : Consumer가 Queue에 메세지를 요청했을 때, 메세지가 없을 경우 메세지가 Queue에 생성될 때까지 기다리는 것

• Long Polling시간은 1s~20s사이로 설정 가능
  
  
  

• 활용이유

1. 지연시간과 API호출을 줄이기 위해 활용
2. Long Polling중 메세지가 Queue에 수신되면, 해당 메세지를 Consumer가 저지연시간으로 빠르게 읽을 수 있음
   
   
   

• 활용방법

1. WaitTimeSeconds를 지정하여 Consumer가 스스로 Long Polling 진행
2. Queue레벨에서 Polling하는 아무 소비자가 Long Polling 진행할 수 있도록 설정함
   
   
   

FIFO Queue

• FIFO Queue : 선입선출 Queue로써, 기존 Queue보다 순서가 보장되는 Queue -> Consumer가 polling할 경우, 입력 순서대로 메세지를 수신함
• 순서를 보장하기 때문에 Queue처리량에 제한이 있음 (Batch성이 아닐 경우, 초당 300개 / Batch성일 경우, 초당 3,000개)
• 순서를 보장하여 정확히 한 번만 보내기 때문에 중복을 제거할 수 있음
• FIFO Queue의 이름은 뒤에 .fifo를 붙여줘야 함
• Content-based deduplication : 5분 이내의 짧은 시간동안 동일 메세지가 두 번 발송되었을 경우, 중복을 방지해주는 기능
• Message Deduplication ID : 같은 메세지 그룹 내 중복을 방지하기 위한 순서 key 값

SQS with Auto Scaling Group (ASG)

• SQS Scaling

• 사용 패턴
  : 광고 등의 이벤트 때문에 많은 양의 트래픽이 application에 몰리게 됨 -> 많은 처리량 때문에 DB로의 특정 트랜잭션에 에러가 발생되면 유실됨 -> 해결책으로 SQS를 사용할 수 있음 -> DB에 직접 붙는 것이 아닌 SQS에 메세지를 보내고, 다른 Consumer측 ASG가 이를 처리하게 하여 처리량 문제 해결 -> 많은 양의 트랜잭션을 처리할 수 있음 -> 트랜잭션 유실 우려 감소
• 조건 : client에 DB저장에 대한 결과를 응답하지 않아도 되는 경우에만 사용 가능 -> SQS Queue에 메세지를 전송했다는 것으로 대체할 수 있음

Amazon SNS (Simple Notification Service)

• Amazon SNS : 특정 서비스에서 여러 개의 타서비스로 연동이 필요할 때, 직접 붙는방식 대신 Pub/Sub 패턴을 이용하여 SNS Topic으로 메세지를 보내면, 해당 Topic을 구독하고있는 Consumer가 메세지를 수신하여 연동하게 하는 AWS 서비스 (SQS는 polling, SNS는 Topic 구독)

• 특징

1. event producer는 하나의 SNS Topic에만 메세지를 보냄
2. event receiver(subscriber)는 구독하고있는 Topic의 메세지를 수신함
3. Topic당 1,200만까지 구독자를 가질 수 있음
4. 계정당 가질 수 있는 Topic의 갯수는 최대 100,000개
   
   
   

• SNS에서 보낼 수 있는 Subscribers

• SNS로 알림을 보낼 수 있는 주체

• SNS 게시 방법 (SDK 활용)

1. topic 생성
2. 하나 이상의 구독자 생성
3. topic에 메세지 발행
   
   
   

• SNS 게시 방법 (mobile apps전용 SDK 활용)

1. application 생성
2. endpoint 생성
3. endpoint에 메세지 발행
4. 수신 가능 application : Google GCM, Apple APNS, Amazon ADM
   
   
   

• SNS Security

1. HTTPS로 메세지를 보내고 수신함 -> 전송중 암호화 (SSE-SNS, SSE-KMS 두 가지 key 지원)
2. KMS키를 활용하여 전송중 암호화 가능
3. client에서 직접 암호화/복호화 가능 -> SNS에서 기본적으로 지원하는 기능은 아님
4. IAM 정책을 통해 SNS API로의 접근을 제어할 수 있음 (호출측? 제어)
5. S3 Bucket Policy와 같은 SNS Access Policy도 있음 -> 교차계정 접근이나 다른 서비스에서의 접근을 허용하는 데 유용함 (응답측? 제어)
   
   
   

SNS + SQS : Fan Out

• Fan Out 패턴 : 다수의 SQS가 SNS의 Topic을 Subscribe하여 SNS에 수신된 메세지를 받고, SQS가 application에 메세지를 전달하는 방식 -> 특정 application이 직접 다수의 SQS에 붙어 메세지를 전송하면 유실가능성이 있음

• SQS의 기능 활용 가능 : 데이터 지속성, 지연처리, 작업재처리 등

• SQS Policy에 SNS의 write가 가능하도록 설정 필요

• 특정 Region의 SNS에서 다른 Region의 SQS에 메세지 전송 가능
  
  
  

• S3 Events to multiple queues
  : 다수의 SQS로 S3 Event를 전송하는 방법

• SNS to Amazon S3 through Kinesis Data Firehose
  : Kinesis Data Firehose를 활용해 SNS에서 S3로 데이터를 전송하는 방법

• SNS FIFO

1. SQS FIFO와 유사한 특징
2. 순서보장
3. 중복제거
4. SQS Standard와 FIFO 모두 Subscriber가 될 수 있음 (다른 서비스는 불가)
5. SQS FIFO와 동일 처리량
   
   
   

• Message Filtering
  : SNS Topic 구독자들에게 전송할 message를 filtering하는 JSON 정책 -> Filtering 기능이 없으면 모든 구독자들에게 모든 메세지가 전송됨

Amazon Kinesis

• Kinesis : 실시간 스트리밍 데이터(실시간으로 빠르게 생성되는 데이터, SNS/SQS와의 차이?)를 쉽게 수집하고 처리하여 분석할 수 있음 (application logs, metrics, iot 원격측정 데이터 등)
  
  
  

• types

1. Kinesis Data Streams : 데이터 스트림을 수집하여 처리
2. Kinesis Data Firehose : 데이터 스트림을 AWS 내부나 외부의 데이터 저장소로 읽어들임
3. Kinesis Data Analytics : SQL이나 Apache Flink를 활용하여 데이터 스트림을 분석
4. Kinesis Video Streams : 비디오 스트림을 수집하고 처리하여 저장
   
   
   

Kinesis Data Streams

1. 데이터를 프로비저닝할 Shard를 설정해야 함 (갯수도 미리 설정)
2. Shard는 Stream의 용량 결정
3. 데이터 생산자는 SDK를 활용하여 Data Stream에 데이터 전송
4. Record : Data Stream에 전송되는 데이터의 단위
   • Partition Key : Record가 이용할 Shard를 결정
   • Data Blob : 데이터 자체, 최대 1MB
   • Sequence No : Shard내 Record의 위치
5. Shard마다 초당 천 개의 메세지 or 1MB를 보낼 수 있음
6. 데이터를 소비하는 방법
   • Shard마다 초당 2MB처리를 모든 Consumer가 공유
   • Consumer마다 Shard당 1초에 2MB씩 받을 수 있음
7. 데이터는 생산하는 과정 in CLI
   • Data Stream의 이름, partition key, data 3개의 파라미터로 데이터 저장 요청 (인코딩 타입도 설정 가능)
8. 데이터를 소비하는 과정 in CLI
   • Data Stream의 Shard 정보를 가져옴
   • Shard ID를 파라미터로 하여 읽을 데이터의 Shard Iterator를 가져옴 (shard-iterator-type 옵션을 통해 Iterator를 다르게 반환받을 수 있음)
   • 받은 Iterator로 해당 메세지 수신
   • 메세지와 함께 NextShardIterator를 수신하여 다음 요청 시, 다음 메세지부터 받을 수 있게 할 수 있음
9. Shard Iterator를 활용하여 특정 부분부터 데이터를 읽을 수 있음

• 특징

1. 1일~1년까지의 보존기간
2. 데이터를 보존기간내 다시 처리할 수 있음
3. 데이터 임의 삭제 불가 -> 불변성
4. partition key가 같으면 같은 Shard로 들어가고, 해당 key를 기반으로 데이터 정렬
5. Producer는 SDK, Kinesis Producer Library (KPL), Kinesis Agent를 사용하여 데이터 전송
6. Consumer는 SDK, Kinesis Client Library (KCL)를 사용하여 데이터 직접 수신 (Lambda나 Firehost같은 AWS 서비스도 활용 가능)
   
   
   

• Capacity Modes

1. Provisioned Mode
   • 위에서 설명된 특징 모두 적용 (처리량, API접근, Shard설정 등)
   • 한계 : Shard를 프로비저닝할 때마다 시간당 비용 부과
2. On-Demand Mode
   • 프로비저닝/용량관리 필요하지 않음 (자동으로 용량 조정되기 때문)
   • 언제든 용량 조정 가능
   • 초당 4MB 또는 4천개의 Record 처리
   • 30일 동안 측정된 최대 처리량에 기반하여 자동으로 용량 조정
   • 시간당 스트림당 송수신 데이터량(GB단위)에 따라 비용 부과
   • 사전에 사용량을 예측할 수 없을 때 유용
     
     
     

• Kinesis Data Streams Security

1. IAM Policy를 활용하여 Shard 생성 및 데이터 수신 접근 권한을 제어
2. HTTPS로 전송중 암호화
3. 미사용 데이터는 KMS로 암호화
4. Client 자체적으로 데이터 암/복호화 가능
5. VPC Endpoint 사용 가능 -> 인터넷을 거치지않고 private subnet의 인스턴스에서 이용 가능
6. 모든 API 요청은 CloudTail로 모니터링 가능

Kinesis Data Firehose

• Kinesis Data Firehose : 데이터스트림을 여러 source로부터 받아서 처리하고 Batch로 저장하는 방법을 제시함

• 데이터 제공 및 저장 유형

1. Amazon Service
   • Amazon S3
   • Amazon Redshift (웨어하우징 DB) -> 먼저 S3에 저장된 데이터 대상으로 Firehose에서 COPY명령을 내리면, Redshift 저장소로 S3의 데이터가 COPY됨
   • Amazon OpenSearch
2. third party
   • Datadog
   • Splunk
   • New Relic
   • mongoDB
3. Custom API (with HTTP)
   
   
   

• 특징

1. 데이터 저장 이후에 optional하게 모든 데이터 or 실패한 데이터를 백업으로 S3에 저장할 수 있음
2. 자동확장 및 서버리스 기능이 있기에 관리가 필요없는 서비스 (Data Stream과의 차별점)
3. Firehost를 통하는 데이터 대상으로만 요금 부과
4. 자체적으로 1MB단위로 데이터를 묶어서 저장하기 때문에 Near Realtime (완전 실시간x) -> 데이터가 완전히 묶이지 않을경우, 최소 60초의 지연 발생 -> Buffer 기능 활용
5. 데이터 포맷, 변환, 압축 지원
6. Lambda활용 데이터 변환 가능
7. Firehose내 데이터 저장 불가 (Data Stream과의 차별점)
8. Console의 Delivery Stream메뉴에서 설정 가능
   
   
   

• Data Stream vs Data Firehose

Ordering Data

• 사례 : 각각의 ID를 가진 트럭 100대가 도로위에 있고, 각 트럭은 GPS데이터를 AWS에 보내고 있다. AWS에서는 각 트럭의 데이터를 순서대로 받아 각 트럭의 이동을 정확하게 측정하려고 한다.
  
  
  

• Kinesis
  : Partition key를 트럭의 ID로 활용 -> 같은 Partition key일 경우, 동일 Shard로 데이터 전송 -> 특정 트럭 데이터는 동일 Shard에서 계속 처리가 됨 (Kinesis가 트럭의 partition key와 shard id를 해싱하는 방식)

• SQS
  : Group ID를 가지지 않는 한, SQS Queue의 message 소비는 순서가 보장됨

• 특정 그룹마다 연관된 메세지를 보내고 싶을 경우, Group ID 활용 (Group ID in SQS = Partition key in Kinesis) -> Consumer는 자신과 연관된 Group ID의 메세지만 수신

• Kinesis vs SQS (100개의 트럭, 5개의 Kinesis Shard, 1개의 SQS FIFO)

1. Kinesis
   • Shard당 평균 20개의 트럭
   • 각 Shard당 순서가 보장된 데이터
   • 최대 5개의 Consumer
   • 초당 5MB 데이터 수신
2. SQS
   • Only 1 SQS FIFO
   • 각 트럭 ID에 상응하는 Group ID 생성 -> 100개의 Group ID -> 최대 100개의 Consumer
   • 초당 300개의 메세지, 배치 사용 시 초당 3,000개의 메세지
     
     
     

SQS vs SNS vs Kinesis

Amazon MQ

• 온프레미스에서 기존 application을 실행하는 경우, MQTT/AMQP/STOMP/Openwire/WSS protocol 사용

• 온프레미스 application을 cloud로 마이그레이션 하는 경우, SNS/SQS를 사용하는 것이 아닌 기존 protocol을 사용하고 싶을 때 Amazon MQ를 사용하면 됨

• Amazon MQ : 관리형 메세지 브로커 서비스 (for RabbitMQ, ActiveMQ) -> RabbitMQ, ActiveMQ를 cloud에서 사용할 수 있음

• RabbitMQ, ActiveMQ : 개방형 프로토콜(ex. MQTT 등)로의 access 제공
  
  
  

• 특징

1. 확장성(scale)이 크지 않음
2. 고가용성을 위해 Multi-AZ 구축 필요
3. SQS/SNS의 일부 기능을 제공
   
   
   

• 고가용성
  : 장애조치의 저장소로 활용하기 위해 두 가용영역에 걸쳐 EFS 구축