Amazon SQS

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

• 무제한 처리량을 얻을 수 있다.(자동으로 확장된다)
• 각 메세지는 수명이 짧다.(default 4일, maxinum 14일)
• 지연 시간이 짧다.
• 전송 메세지당 256KB 미만이어야 한다.

Producing Messages

• 소비자가 해당 메세지를 읽고 삭제할 때까지 SQS 대기열에 유지된다.

Consuming Messages

Multiple EC2 Instances Consumers

SQS with Auto Scaling Group

: 소비자가 ASG 내부에서 EC2 인스턴스를 실행하고 SQS 대기열에서 메세지를 폴링한다.

• 이용할 수 있는 지표는 대기열의 길이로 ApproximateNumberOfMessages 라고 한다.(모든 SQS 대기열에서 쓸 수 있는 CloudWatch 지표)

Security

Encryption

• HTTP API
• KMS keys
• Client-side encyption

Access Controls

: IAM 정책은 SQS API에 대한 액세스를 규제할 수 있다.

SQS Access Policies

: SQS 대기열에 대한 교차 계정 액세스를 수행하려는 경우나 SNS 혹은 S3 이벤트 같은 것을 쓸 수 있도록 허용하려는 경우에 매우 유용하다.

SQS Queue Access Policy

Cross Account Access

: EC2

Publish S3 Event Notifications To SQS Queue

: S3

Message visibility Timeout

: 소비자가 메세지를 폴링하면 그 메세지는 다른 소비자들에게 보이지 않게 된다.

• 기본값으로 메세지 가시성 시간 초과는 30초이다.
• 가시성 시간 초과 기간 내에 메세지를 처리하지 않으면 메세지가 두 번 처리될 수 있다.
• 소비자는 ChangeMessageVisibility API를 호출하야 처리 시간을 더 얻을 수 있다.
• Visibility Timeout에서 메시지는 Queues에서 소비된 후에만 숨겨진다. (기본값: 30초, 최소: 0초, 최대: 12시간)

Dead Letter Queue(DLQ)

• 최대 수신 수 임곗값을 설정하면 그 값을 초과했을 경우 SQS에 알리고, 실패 메세지 대기열은 그 메세지를 보관했다가 나중에 처리한다.
• 실패 메세지 대기열은 디버깅 시 아주 유용하다.
• FIFO 대기열은 실패 메세지 대기열도 FIFO 대기열이어야 하고 표준 대기열은 실패 메세지 대기열 역시 표준 대기열이어야 한다.
• SQS 배달 못한 편지 Queues은 다른 SQS Queues(소스 Queues)이 성공적으로 처리(소비)되지 않은 메시지를 보낼 수 있는 곳이다. 문제가 있는 메시지를 격리하여 처리가 성공하지 못한 이유를 디버깅할 수 있으므로 디버깅에 유용하다.

Redrive to Source

Delay Queue

: 소비자들이 즉각적으로 보지 못하도록 메세지를 지연시킨다.

• 매번 메세지를 보낼 때마다 DelaySeconds 파라미터를 사용하여 메세지별 지연 시간을 지정할 수 있다.
• SQS 지연 Queues은 Amazon SQS가 소비자에게 보이지 않는 새 SQS 메시지를 유지하는 기간이다. SQS 지연 Queues에서 메시지가 Queues에 처음 추가될 때 메시지가 숨겨진다. (기본값: 0분, 최대값: 15분)

Long Polling

: 소비자가 SQS로부터 메세지를 요청할 때 만약 대기열이 비어 있다면 메세지가 도착할 때까지 기다리도록 할 수 있다.

• SQS 대기열로 보내는 API 호출을 줄여 효율성을 향상시키고 지연 시간을 줄일 수 있다.
• SQS Long Polling이 활성화되면 Amazon SQS는 반환할 메시지가 없을 때 빈 응답 수를 줄이고 거짓 빈 응답을 제거한다.

SQS Extended Client

: JAVA 라이브러리로 S3 버킷을 대용량 데이터를 담는 리포지토리로 사용한다

• Java용 Amazon SQS 확장 클라이언트 라이브러리를 사용하면 Amazon S3로 대용량 Amazon SQS 메시지를 관리할 수 있다. 이것은 최대 2GB의 메시지를 저장하고 사용하는 데 특히 유용하다.

Must know API

• CreateQueue(MessageRetentionPeriod), DeleteQueue
• PurgeQueue: 대기열 내의 모든 메시지를 삭제한다.
• SendMessage(DelaySeconds), ReceiveMessage, DeleteMessage
• MaxNumberOfmessages: default 1, max 10(for ReceiveMessage API)
• ReceiveMessageWaitTimeSeconds: Long Polling
• ChangeMessageVisibility: 메세지 시간초과를 변경
• 여러 API 호출을 묶음으로 사용하려면 SendMessage, DeleteMessage, ChangeMessageVisibility를 사용할 수 있다. 이는 API 호출 횟수를 줄여주고 결과적으로 비용도 줄여준다.

FIFO Queue

: 표준 대기열 보다 더 확실히 순서가 보장된다.

• SQS FIFO(선입선출) Queues에는 SQS 표준 Queues의 모든 기능과 함께 다음 두 가지 기능이 있다. 첫째, 메시지를 보내고 받는 순서는 엄격하게 유지되며 메시지는 한 번 배달되고 소비자가 처리하고 삭제할 때까지 사용할 수 있다. 둘째, 중복된 메시지는 Queues에 포함되지 않는다.

Duplication

Message Grouping

• 동일한 메세지 그룹 ID를 공유하는 메세지들이 해당 그룹 내에서 순서대로 정렬된다.

Amazon SNS

• 많은 AWS 서비스는 AWS애서 알림이 발생하면 지정된 SNS 주제로 알림을 보낸다.
• Amazon SNS는 HTTP(S), SQS, Lambda, 모바일 푸시, 이메일 또는 SMS 엔드포인트에 메시지를 게시할 수 있다.

How to Publish

Topic Publish

Direct Publish

Security

Encryption

• HTTP API
• KMS keys
• Client-side encyption

Access Controls

: 모든 SNS API가 IAM 정책으로 규제된다.

SQS Access Policies

: SNS 주제에 교차 계정 액세스 권한을 갖거나 S3 이벤트 같은 서비스가 SNS 주젝에 작성할 수 있도록 허용하려는 경우에 매우 유용하다.

SNS + SQS: Fan Out

: SNS 주제로 한 번 메시지를 전송하면 원하는 숫자 만큼의 SQS 대기열들이 SNS 주제를 구독하도록 해서 SNS로 전송된 모든 메시지를 수신할 수 있도록 한다.

• 더 많은 SQS 구독자를 추가하기 위해서 SQS 큐 접근 정책을 설정해서, SQS 큐에 주제에 대한 쓰기 권한을 부여해야 한다.

Application: S3 Events to multiple queues

• 팬아웃 패턴을 이용하여 여러 개의 SQS 큐에 동일한 S3 이벤트 알림을 보낼 수 있다.

Application: SNS to Amazon S3 through Kinesis Data Firehose

FIFO Topic

• 메세지 그룹 ID를 기준으로 정렬하고, 중복 제거 ID나 중복 제거 기반 콘텐츠를 통해 중복을 제거할 수 있다.
• 이 기능은 구독자로 SQS FIFO 큐만 받을 수 있다.

SNS FIFO + SQS FIFO: Fan Out

Message Filtering

: SNS 주제로 구독중인 큐에 보내는 메세지를 필터링하는 JSON 정책

Kinesis

Kenesis Data Streams

: 시스템에 빅데이터를 스트리밍하는 방법

• Kinesis Data Stream이 최대 365일 동안 기록을 유지하도록 구성할 수 있다.

Capacity Modes

Provisioned mode

: 몇 개의 샤드 프로비저닝을 선택한 후 수동 혹은 API를 사용해 확장한다.

On-demand mode

: 용량을 프로비저닝하거나 관리할 필요가 없는 모드

미리 용량이 예측되지 않는다면 프로비저닝 모드를, 용량 이벤트 계획이 가능하다면 프로비저닝 모드를 선택한다.

Security

• IAM 정책을 사용해 샤드 생성 및 읽기에 대한 액세스를 제어
• HTTPS를 이용한 전송 중 암호화 및 KMS를 이용한 저장 중 암호화
• 클라이언트 측에서 데이터를 암호화 및 복호화하도록 구현
• VPC 엔드포인트
• CloudTrail
• 모든 API 호출을 모닡링 할 수 있다.

Kinesis Producers

: Kinesis에서 데이터를 가져온다.

• AWS SDK: 생산자는 어떤 SDK도 가능하다.
• Kinesis Producer Library(KPL): C++, Java와 같이 여러 언어를 지원한다.
• Kinesis Agent: 로그 파일을 모니터링
• "hot partition"을 피하고자 파티션 키를 잘 분배해야 한다.

ProvisionedThroughputExceeded

• Kinesis 데이터 스트림의 용량 제한은 데이터 스트림 내의 샤드 수로 정의된다. 데이터 처리량 또는 읽기 데이터 호출 수로 인해 제한을 초과할 수 있다. 각 샤드는 1MB/s의 들어오는 데이터와 2MB/s의 나가는 데이터를 허용한다. 충분한 용량을 제공하려면 데이터 스트림 내의 샤드 수를 늘려야 한다.
• 실패한 메세지 처리를 위해 재드라이브 정책으로 배달 못한 편지 Queues(DLQ)를 구현할 수 있다.

solution

• 매우 잘 분산된 파티션 키를 사용한다.
• 기하급수적인 백오프를 통해 재시도를 구현해서 예외 상황을 재시도할 수 있게 한다.
• 샤드 스케일링

Kinesis Data Streams Consumers

: 소비자는 스트림으로부터 레코드를 가져오고 처리한다.

Kinesis Consumers

Custom Consumer

Shared(Classic) Fan-out Consumer

• 공유된 팬아웃 소비자는 풀 방식으로, 소비하는 애플리케이션이 적을 경우에 유용하다.

Enhanced Fan-out Consumer

• 향상된 팬아웃 소비자는 푸시 방식으로 소비하는 애플리케이션을 같은 스트림에서 여러 개를 가질 수 있다.

AWS Lambda

: 서버를 이용하지 않고 데이터를 소비하는 방식

• 배치 크기와 배치 영역을 구성할 수 있다.

Kinesis Client Library(KCL)

• Java 라이브러리는 Kinesis Data Streams에서 읽기 워크로드를 공유하는 분산 애플리케이션의 레코드를 읽을 때 도움을 준다.
• 각 샤드는 KCL 인스턴스에 의해서만 읽힌다.(4개의 샤드가 있다면 최대 4개의 KCL 인스턴스가 있음)

Kinesis Operation

Shard Splitting

: 샤드를 2개로 분할할 때 사용한다.

• 더 많은 샤드를 갖는데 스트림의 용량을 늘릴 때 사용한다.

Merging Shards

: 용량ㅇ을 줄이거나 비용을 절감하고 싶다면 트래픽이 적은 2개의 콜드 샤드를 그룹으로 묶어 하나의 새 샤드로 병합한다.

Kinesis Data Firehose

: 생산자로부터 데이터를 가져온다.

• 데이터를 보낼 수 있는 파트너가 있다.
• 완전한 관리 서비스로 관리 기능이 없고 오토 스케일링이 되면 서버리스이다.
• 실시간 서비스는 아니고 실시간에 가까운 서비스이다.

Destination

Amazon S3

Amazon Redshift(COPY through S3)

Amazon ElasticSearch

Kinesis Data Streams vs Firehose
Kinesis Data Streams은 데이터를 대규모로 수집하는 스트리밍 서비스로 생산자와 소비자 관련 자체 사용자 정의 코드를 작성한다. 200밀리초 또는 70밀리초로 실시간이다. 스케일링은 자체적으로 관리한다. 샤드 분할이나 샤드 병합을 하여 처리량을 늘린다. 데이터 저장은 1일에서 365까지다. 같은 스트림에서 여러 소비자를 읽을 수 있고 리플레이 기능을 지원한다.
Kinesis Firehose는 데이터를 S3, Redshift, 일래스틱서치, 타사 파트너 또는 사용자 정의 HTTP로 데이터를 스트리밍 하기 위한 수집 서비스이다. 완전히 관리되기 때문에 관리할 서비스가 없고 실시간에 근접하다. 오토 스케일링이 가능하다. 데이터 스토리지가 없다.
Kinesis Data Streams + kinesis DData Firehose는 거의 실시간 데이터를 S3 및 Redshift에 로드하기 위한 기술의 완벽한 조합입니다. Kinesis Data Firehose는 AWS Lambda를 사용한 사용자 지정 데이터 변환을 지원한다.

Kinesis Data Analytics for SQL applications

: 다이어그램 기억해두기

• 데이터의 소스는 키네시스 데이터 스트림과 파이어호스이다.

Kinesis Data Analytics for Apache Flink

Flink로 키네시스 데이터 스트림, 아마존 MSK에서는 데이터 읽기가 가능하나 키네시스 데이터 파이어호스는 불가능하다. 따라서 이를 이용한 실시간 분석이 필요하다면 SQL을 이용해야 한다.

Ordering data into Kinesis

: "Partition Key"를 사용하여 데이터를 전달한다.

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

Ordering data into SQS

• SQL FIFO 그룹 ID를 사용하지 않으면 모든 메세지가 소비되는 방식은 보내진 순ㅅㅇ에 ㄸ따르며 소비자는 하나만 존재한다.

Kinesis vs SQS ordering

: 경우에 따라 적절한 모델은 달라지며, SQS FIFO는 그룹 ID 숫자에 따른 동적 소비자 수를 원할 때 사용하면 좋다.Kinesis 데이터 스트림에 샤드당 데이터를 정렬할 때 사용한다

SQS vs SNS vs Kinesis