Self Introduction

Application 이 여러개 배포할때 소통할수 밖에 없다고 한다.
그 소통을 할때 두개의 방법이있다.

Synchronous communications - 동기
직접적으로 연결이다.

Asynchronous - 비동기/이벤트 기반
대기열이 Application 에 연결되는것이다.

동기적인 연결은 트래픽이 갑작스럽게 증가하면 그것들을 감당할수가 없다.
하지만 중간에 대기열을 두어서 트래픽을 조건에 따라 처리하게 된다면?
그것이 비동기 연결이다.
Buying Service 에서 사면 대기열로 들어가게 되고 Shipping Service 는 최근에 구매 있니? 물어보는것.

그래서 우리는 Traffic 증가하거나 예측할수 없을때 APp 분리하고 분리 계층을 확장해야한다.
분리할때 사용하는 것이 SQS,SNS,Kinesis 이다.

Amazon SQS / What's a queue?

Queue 는 Buffer 역할을 한다.
그리고 Producer 는 메세지를 보내고 하나 또는 그 이상을 보낼수 있다.
그리고 message 는 그 어떤 모든것도 된다.

그리고 Consumer 는 메세지를 Poll 한다.
대기열에게 Message 를 물어보고 정보를 얻는것이다.

Standard Queue

결국 Queue 는 APplication 을 분리할때 사용한다 한다.

무제한의 처리량을 가지고 대기열에 저장할수있는 메세지의 수가 제한이 없다고 한다.
근데 그 buffer 내에서 보존 할수 있는 기간이 4일에서 14일 까지 라고 한다.
낮은 지연시간을 가지고 message 가 작아야한다.

그리고 중복 메세지가 될수있다고 한다.

Producing Message

SDK 를 사요해서 SQS 를 생성한다.
Consumer 가 삭제할떄까지 지속된다고 하고 4일에서 14일까지 유지된다고 한다.

Comsuming MEssage

Comsumer 는 Ec2 INstance,서버 ,람다 등이라고 한다.
메세지를 가져오기 위해 SQS 를 폴링한다고 한다.
이떄 한번에 최대 10개의 메세지를 수신할수 있다고 한다.
그리고 처리한건 삭제해야한다. 다른 소비자가 메세지 못보기 때문..

Multiple EC2 Instances Consumers

소비자들은 메세지를 병렬로 수신하고 처리한다고 한다.
그러면 최소 한 번의 전송을 보장하고
무조건 처리하고는 삭제해줘야한다.
처리량을 향상 시키기 위해서 ASG 를사용해서 수평 확장을 할 수 있다.

ASG 안에 있는 소비자들이 SQS 대기열에 있는 메세지를 폴링한다고 한다.
그때 ASG 는 어떠한 지표가 있어야 Scale in /out 이 되는데 이떄 지표가 대기열의 길이이다.
그래서 대기열의 길이가 어떠한 수준을 넘어가게 되면 CloudWatch Alarm 을 발생하고 그렇게 수평확장을 할수 있게 된다.

SQS to decouple between application tiers

SQS 는 Application tier 간에 decouple 을 하기 위해 사용된다.

Amazon SQS - Security

• Encryption

전송 중 데이터 암호화는 HTTPS API 사용을 한다.
정지 상태 암호화는 KMS key 를 사용하고
스스로 암호화 하고싶을떄는 client 측 암호화를 하면된다.

• Access Control

IAM policies 를 통해서 SQS API 접근을 규제한다.

• SQS Access Policies

SQS 대기열에대한 교차 계정 엑세스를 수행하는 경우에 유용하다.
다른 서비스가 SQS 대기열에 쓸수 있도록 허용하는데 유용하다고 함.

SQS - Message Visibility Timeout

Consumer 가 메세지 Polling 하면 다른 소비자는 못보게 된다.
메세지 가시성 시간 제한 초과는 30초인데 메세지가 처리 되기 까지 30초의 시간을 가지게 된다.
근데 만약 30초가 지나게 되면 SQS 에서 다시 보이게 된다.
가시성 시간 제한 내에서는 다른 소비자한테 보이지 않게 되고 그게 초과되고 삭제 되지 않으면 다시 대기열에 넣어지게 된다.

그래서 그 기간 내에 처리 되지 않으면 메세지는 두번 처리될수 있다.
그리고 APi 를 불러서 시간을 좀더 얻을수 있고
만약 이 기간이 너무 길면 재 처리 하는데 까지의 시간이 더 걸릴수있고
기간이 너무 짧으면 복제 될수있다.

Amazon SQS - Long Polling

대기열에 아무것도 없다면 메세지 도착을 기다리면 된다.
지연시간을 줄이기 위해 그리고 API 호출 숫자를 줄이기 위해 이것을 사용한다.

Amazon SQS - FIFO Queue

FIFO 는 순서를 보장 한다.

Standard 와는 다르게 FIFO 는 처리량에 제한이 있다.
그리고 중복 제거해서 한번에 한번만 전송가능하다.
분리 발생 or 순서유지 필요하다.

그리고 만약 load 가 너무 크면 tansaction 이 사라질수있다.
Transaction에 오류 생기면 해당 고객 transaction 유실...
비지니스에 좋지않다.

DB에 바로 요청을 쓰는대신 트랙잰션을 SQS 대기열에 먼저 쓰는 방법도 있다.
이렇게 하면 유실되는 요청이 없다.

이렇게 분리도 가능하다.
분리 or 급격히 증가한 로드 혹은 시간초과 등의 문제에서 신속한 스케일링을 할떄 SQS 사용하면 된다.

Amazon SNS

하나의 메세지를 많이 보낼때 수신 서비스 추가할떄마다 통합을 생성해야한다.
이게 번거로울 수 있음.

그래서 구독을 사용할수 있는데 구매 서비스가 메세지를 SNS Topic 으로 보내고 해당 Topic 에서는 구독자가 많은데 그 구독자들에게 모두 메세지를 보낼수있다.

그래서 결국 Amazon SNS 는 하나의 SNS Topic 에만 메세지 보낸다.

SNS에서 구독자에게 게시할 수 있는 것은
SNS에서 직접 이메일을 보낼 수 있고
SMS 및 모바일 알림을 보낼 수도
지정된 HTTP 또는 HTTPS 엔드포인트로 직접 데이터를 보낼 수도 있음
SQS와 같은 특정 AWS 서비스와 통합하여 메시지를 대기열로 직접 보낼 수도
메시지를 수신한 후 함수가 코드를 수행하도록 Lambda에 보내거나, Firehose를 통해 데이터를 Amazon S3나 Redshift로 보낼 수도 있음

그리고 반대로 AWS 서비스에서 데이터를 수신도 하기도 한다.

Amazon SNS - Security

SQS 와 동일하다.

SNS + SQS : Fan Out

다수의 SQS 대기열로 메세지 보내려고 할때 모든 SQS 대기열에 개별전송을 하게 된다면 문제가 발생한다. 그럴떄 팬아웃 패턴을 사용하게 된다.

그래서 SNS 를 사용해서 원하는 만큼 SQS 대기열을 SNS Topic 에 구독해서 모든 SQS 에 메세지를 일관적으로 보내면된다.
SNS 에서 수신하게 되면 모든 SQS 대기열에 수신되게 되고 데이터도 손실되지 않는다.

이렇게 여러개 동일한 S3 Evnet 알람을 보내고 싶을떄 S3 이벤트를 SNS Topic 으로 보내고 SQS 로 전달할수도 있다.

또 똑같이 Kinesis Data Firehose 를 사용해서 S3 로 직접 데이터 보낼수 있다.

Amazon SNS - FIFO Topic

SQS FIFO 특징과 같다.

Amazon SNS - Message Filtering

SNS Topic 구독자들에게 전송할 메세지를 필터링 하는 Json 정책이다.

필터 정책 없으면 해당 구독은 모든 메세지를 수신하게 된다.

Kinesis Overview

실시간 스트리밍 데이터를 손쉽게 수집하고 처리하여 분석할수 있다.
실시간 데이터를 수집한다고 보면 된다.
Data 가 빠르게 실시간으로 생성 - > 실시간 데이터 스트림 간주....

Kinesis Data Streams

Record 의 key는 이용할 shard 를 결정한다 Bolb 은 값 자체이다.
Kinesis Data Stream 은 System 에서 큰 규모의 데이터 흐름을 다루는 서비스 이고 데이터는 Shard 에 분배된다. Shard 는 Stream 용량을 결정한다.
또한 Sequence # 는 Record 위치 알려주는 것이다.

이렇게 1일에서 1년까지 유지된다.
데이터를 재처리하거나 확인가능하다
Kinesis 로 데이터가 삽입된다면 삭제할수없다.
동일한 파티션을 공유하는 데이터는 동일한 샤드로 전송된다.

두개의 모드가 있는데

Provisioned Mode 는 사용량을 예측가능할때 사용하고
On-demand Mode 는 사용량 예측 이 안될때 사용한다.

Kinesis Data Streams Security

IAM Policies 를 사용해서 엑세스 권한 제어 가능하다.
HTTPS 엔드포인트를 통한 전송 중 데이터 암호화
KMS를 사용하여 데이터 정지 상태에서의 암호화
클라이언트 측에서 데이터의 암호화/복호화 구현 가능 (더 어려움)
VPC 내에서 액세스하기 위해 Kinesis에 대한 VPC 엔드포인트 사용 가능
모든 API 요청은 CloudTrail을 사용하여 모니터링 가능

Kinesis Data Firehose

Producer 로 부터 데이터를 가져올수 있는 아주 유용한 서비스 이다.
Firehose 를 통과하는 데이터에 대해서만 비용 지불한다.
거의 실시간을 데이터를 처리한다.

Kinesis Data Streams vs Firehose

Ordering data into Kinesis

각 Truck 이 ID 가 있다고 가정하자.
그 ID 는 partition key 로 데이터를 Kinesis 로보 내게 되고 동일한 partition key는 항상 동일한 shard 로 가기때문에 트럭의 데이터를 정확한 순서로 보낼수 있게 된다.

SQS Standard 에는 순서가 없다.

consumer 의 수를 늘리고 싶으면 group ID 를 사용하면 된다.

Kinesis vs SQS ordering

100개 트럭 있을때 5개 kinesis shard 가 있고 1 SQS FIFO 를 가정해보자

Kinesis Data Stream 은 한개의 shard 당 20개 트럭이 배치되고
각 샤드에서 트럭의 데이터는 순서대로 처리될꺼고
병렬로 되니까 한번에 5개 처리된다.

SQS FIFO 는 대기열 하나 밖에없고 100개의 다른 그룹 ID가 생선된다.
그래서 100명의 소비자를 가지게 되고 또한 초당 300개 메세지를 가질수있게 된다.

SQS vs SNS vs Kinesis

• SQS

소비자가 SQS 대기열에서 메시지를 요청하여 데이터를 가져오는 (pull) 모델
데이터를 처리한 후 소비자가 대기열에서 삭제하여 다른 소비자가 읽을 수 없도록 함
소비자의 수에는 제한이 없음
관리형 서비스이기 때문에 처리량을 프로비저닝할 필요가 없음
FIFO 대기열을 사용해야 순서를 보장할 수 있음
메시지에 지연 기능이 있음

• SNS

게시/구독 모델로 다수의 구독자에게 데이터를 푸시하면 메시지의 복사본을 받게 됨
SNS 주제별로 12,500,000 구독자를 가질 수 있음
데이터가 SNS에 전송되면 지속되지 않음 (제대로 전달되지 않으면 데이터를 잃을 수 있음)
100,000 개의 주제로 확장 가능함
처리량을 프로비저닝할 필요 없음
SQS와 결합하여 팬아웃 아키텍처 패턴을 이용할 수 있음
SNS FIFO 주제를 SQS FIFO 대기열과 결합할 수 있음

• Kinesis

Standard: 소비자가 Kinesis로부터 데이터를 가져옴 (pull). 샤드당 2 MB/s
Enhanced-fan out: Kinesis가 소비자에게 데이터를 푸시함. 샤드 하나에 소비자당 2 MB/s
Kinesis 데이터 스트림에서는 데이터가 지속되기 때문에 데이터를 다시 재생할 수 있음
실시간 빅데이터 분석, ETL 등에 사용됨
X days 후에 데이터가 만료됨
프로비저닝 모드 혹은 온디맨드 용량 모드가 있음