[AWS] Decoupling App

디커플링 어플리케이션 : SQS, SNS, Kinesis, Active..

메시징 소개

앱을 여러개 배포 할 때, 서로 통신을 해야 한다.

• Sync Comm (app to app)
  동기화 때문에 문제가 생길 수 있다.
  한 앱에서 뭔가 stuck되거나 overflow되면 문제가 된다.
  1. SQS : queue model
  2. SNS : pub/sub model
  3. Kinesis : real-time streaming model
• 이런 경우, 앱을 서로 Decouple하는게 좋다.
• Async Comm / Event Based (app to Queue to app)

Amazon SQS - 표준 Queues 개요

대기열에 메시지를 담는다.

생산자에서 메시지를 큐에 보내고, 큐에 메시지가 쌓인다.
생산자는 여러명일 수 있다.

대기열에 메시지를 처리하고 수신하는 대상은 소비자이다.

소비자는 폴링으로 큐에서 메시지를 수신한다.
소비자 또한 여러명일 수 있다.

큐는 소비자와 생산자를 분리하는 버퍼 역할을 한다.

SQS는 아마존에서 가장 오래된 서비스 중 하나이다.

완전 관리형 서비스이며, 앱을 분리하는 서비스이다.

• 무제한 처리량을 소화 가능하다. 대기열에 원하는 만큼 메시지를 대기시킬 수 있따.
• 각 메시지의 수명은 짧다. 기본 값으로 4일, 최대 14일 있을 수 있다.
• 지연시간이 짧다. 게시 및 수신 시 10밀리 초 이내로 응답이 가능하다.
• 메시지 당 256kb 이하여야 한다.
• 중복 메시지가 있을 수 있다.

생산자는 SDK를 통해 SQS에 메시지를 보낸다.
소비자가 해당 메시지를 읽고, 삭제할 때까지 큐에 남아있는다.

소비자는 일부 코드로 작성해야 하는 앱이다.
보통 EC2나 온프레미스에서 수행 가능하고 람다 함수에서 실행할 수도 있다.
람다에세 메시지를 바로 읽을 수 있다.

소비자는 큐에 메시지를 폴링으로 본다.

한 번에 10개 메시지를 받을 수 잇다.
소비자는 해당 메시지를 처리할 권한이 있다.
해당 메시지를 어떤식으로도 처리하면, 삭제 API를 보내 큐에서 삭제할 수 있다.

여러 소비자를 동시에 가질 수 있다.

각 소비자는 폴링 함수로 메시지 세트를 수신한다.
만약에 특정 소비자가 메시지를 빠르게 처리하지 않으면, 다른 소비자가 해당 메시지를 수신하게 된다.
그래서 적어도 한 번은 전송된다.(중복 전송이 가능하다.)

큐에 메시지가 많을 경우 소비자를 늘려서 수평확장을 할 수도 있다.
이건 ASG를 SQS에 적용하는 예 중 하나가 된다.

ASG 확장 검토하는 지표 중 SQS 대기열을 CloudWatch의 알람 지표로 사용할 수도 있다.
ApproximateNumberOfMessages가 그와 같은 지표이다.

SQS는 앱의 계층 분리를 위해 주로 사용된다.

비디오 처리 서비스가 있다면, 비디오 프로세싱 이후에 버킷에 저장하는 식이 될 것이다.
그런데 처리시간은 대개 매우 오래걸린다.
이를 프론트엔드에서 처리하면 웹사이트가 느려질 것이다.

따라서 파일 처리 요청은 프론트에서 받고 해당 요청을 큐로 보내고, 실제 처리는 백엔드에서 처리하는 식으로
구성하는 것이 좋을 수 있다.

경우에 따라 프론트엔드를 수평확장하거나 백엔드를 확장할 수 있는데 중요한건 독립적이라는 것이다.

SQS 보안

1. In-flight encryption - HTTPS API
2. At-rest encryption - KMS Keys
3. Client side encryption - 암호화 복호화를 프론트에서 처리해야함

엑세스 제어를 위해서 IAM에서 정책 정할 수 있고

SQS 엑세스 정책도 정할 수 있다.

• cross-accout access를 할 경우
• SNS 같은 것도 서로 연결할 때도 유용하다.

SQS - 메시지 가시성 시간 초과 (Message Visibility Timeout)

소비자가 메시지를 폴링하면 그 메시지는 다른 소비자에게 안 보인다.

이 안보이는 시간을 Message Visibility Timeout이라고 하는데 이 시간은 기본적으로 30초이다.
이 30초동안 메시지가 처리되어야 한다는 말이다.

그 기간동안 ReceiveMessage Request가 와도 메시지가 반환되지 않는다.

그 시간이 지나고 메시지가 삭제되지 않았다면 메시지는 다시 큐에 들어간다.
그러면 다른 소비자가 api를 호출하면 해당 메시지를 받을 수 있게 된다.

만약에 소비자가 해당 메시지를 처리하고 있는데 가시성 시간 초과 이상 시간이 필요할 수도 있다.
이때 ChangeMessageVisibillity라는 api가 있는데 해당 api가 시간을 더 갖게 해준다.

SQS - 롱 폴링

예를 들어 소비자가 대기열에 메시지를 기다리는데, 메시지가 없다면 도착할 때까지 계속 기다릴 것인데, 이게 롱폴링이다.

최대 20초동안 폴링한다.

대기열이 비어있으면 좀 기다려도 좋다는 것이다.

메시지가 대기열에 도착했다면, 메시지가 소비자에게 바로 갈 것이다.
이때 지연시간은 짧다.

이렇게 하는 이유는 api call 횟수를 줄이기 위함이다.

이 시간은 1 ~ 20초 사이에서 구성할 수 있다.

롱 폴링을 구성하는 방법은 두 가지가 있는데, 하나는 대기열 레벨에서 구성하여 폴링하는 아무 소비자에게 수행하게 하는 방법이 있고, 또 하나는 소비자가 직접 WaitTimeSeconds api를 호출하여 롱 폴링하는 방법도 있다.

SQS + FIFO Queues

선입선출이다.

먼저 도착한 메시지가 먼저 떠난다.
우선순위가 확실하게 보장될 수 있다.

순서를 확실히 보장하기 때문에 처리량은 제한이 있다. 300개 /s 처리할 수 잇고, 묶음으로 하면 3000개 /s까지 가능하다.

중복을 제거할 수도 있고, 소비자는 순서대로 오는 것을 보장 받을 수 있다.

SQS + 오토 스케일링 그룹

ASG 내 인스턴스가 큐의 메시지를 받늗다.

CloudWatch가 큐에 메시지가 얼마나 남았는지를 모니터링할 수 있따.

만약에 1000개 이상에 알람을 걸면, 1000개 이상일 경우, 지연이 되고 있다고 판단하고
EC2 instance를 수평 확장하여 메시지를 처리하도록 한다.

그리고 큐에 메시지가 출어들면, 다시 수평 축소를 실시한다.

다른 예로 예를 들어 전자상거래의 거래 내역을 DB (RDS, aurora, DynamoDB) 등에 기록한다고 해보자.
갑자기 사람들이 몰려서 트랜젝션 내역이 넘치게 되면, 디비에 저장하는 부하가 커지고 급기야 유실될 수도 있다.

이런 경우, EC2에서 DB로 바로 쓰기 요청을 하는 대신에 중간에 SQS가 있으면 버퍼 역할을 할 수 있다.

큐는 무한히 확장이 가능하므로 처리량에 문제가 되지 않는다.

이렇게되면 유실되는 메시지는 없다.

여기서 ASG를 이용하여 DB에 쓰기 역할을 하는 인스턴스를 조절할 수 있다.
이때 ASG는 위에서 언급한 것과 같이 메시지 양을 지표로 하여 수평 확장/축소를 하면서 처리량을 조절할 수도 있다.

Amazon Simple Notification Service (SNS)

• 메시지 하나를 여러 수신자에게 보낸다고 가정해보자

Pub/Sub

게시 구동 서비스이다.

주제 별로 구독자로 등록하여 해당 주제에 대한 메시지가 올라오면 수신하는 것이다.
주제 별로 1200만 이상 구독자까지 가능하다.

계정 당 가질 수 있는 주제는 10만개이다.

직접 이메일, 문자, HTTP, HTTPS로 데이터를 보낼 수도 있고,
SQS에 보낼 수도 있고 람다나 키네스로 보낼 수도 있다.

다양한 서비스에서 메시지를 받을 수도 있다.

알람, ASG 등....

Topic Publish using the SDK

SDK로 주제를 배포하고 게시할 수 있다.
이렇게 하면 구독자는 메시지를 받게 된다.

Direct Publish for mobile apps SDK

플랫폼 앱을 만들고, 엔드포인트를 생성하고 엔드포인트에 게시한다.
Google GCM, Apple APNS, Amazon ADM 등이 구독자가 될 수 있다.

보안은 SQS와 동일하다.

엑세스 제어는 IAM 정책 위주이다.

SNS Access Policies - cross access, aws service

SNS 및 SQS 팬 아웃 패턴

메시지를 여러 SQS 대기열에 보내고 싶은데, 모든 SQS에 개별적으로 메시지를 보내면
일부 앱이 비정상 동작하거나 해서 문제가 될 수 있다.

이 때 팬 아웃 패턴을 사용한다.

우선 SNS로 메시지를 게시하고, SQS가 해당 주제를 구독하게 하는 것이다.

이 대기열은 구독자로써 이 메시지를 큐에 넣게 된다.

완전히 분리된 모델이며 데이터 손실도 없다.

SQS로 작업을 다시 시도할 수 있고 구독자를 늘릴 수도 있다.

SQS 엑세스 정책에서 SNS 주제가 들어올 수 있게 해야 한다.

리전 간 전달도 가능하다.

S3 Events to multiple queues
이벤트 세 개를 여러 대기열에 넣는 경우도 살펴보자.

예를 들어 S3 버킷에서 image/에 object를 생성하는 이벤트를 알리고 싶다면,
해당 이벤트를 SNS에 큐에 넣고 여러 SQS 큐에 알리고, 더 나아가서 람다 함수에도 전달할 수 있다.

KDF(Kinesis Data Firehore)를 통해 SNS에서 S3로 직접 데이터를 전송할 수 있다.

SNS - FIFO Topic

pub이 순서대로 메시지를 게시하면, 구독자는 메시지를 순서대로 받을 수 있는 기능이 있다.

처리량은 제한적이다. (SQS FIFO 처리량과 같다.)
그 이유는 SQS FIFO 대기열만이 이걸 받을 수 있기 때문이다.

SNS FIFO + SQS FIFO: Fan Out

SQS FIFO를 활용하여 팬아웃을 하려면, 순서, 중복제거가 필요하다.
fan out + ordering + depulication

SNS - Message Filtering

SNS 주제를 구동할 때, 전송되는 메시지를 필터링하는데 사용되는 JSON 정책이다.

어떤 필터링도 있으면 메시지를 그냥 받는다.

Amazon Kinesis 개요

실시간 스트리밍 데이터를 손쉽게 수집하고 처리하여 분석한다.

실시간 데이터는 앱 로그, 계측, 웹사이트 클릭 스트림, IoT 원격 측정 데이터 등이 포함된다.

데이터까 빠르게 실시간으로 들어오면 된다.

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

Kinesis Data Stream 개요

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

이 시스템은 여러개의 Shard로 구성되어 있고, 1... N까지 번호가 매겨지며, 미리 프로비저닝해야 한다.
다시 말해 이 시스템을 시작할 때 예를 들어 나는 6개의 Shard를 구성하겠다고 결정해야 한다.
데이터는 이제 이 샤드에 분배된다.

샤드는 데이터 수집률이나 소비율 측면에서 스트림의 용량을 결정한다.

생산자가 있는데 앱일 수도 있고 계측기일 수도 있다. 이 생산자가 데이터를 Kinesis Data Stream으로 보낸다.
생산자는 기본적으로 Low Level SDK를 통해 Record를 전달하는데 이 Record는 2가지 요소로 구성된다.

1. Partition Key
2. 최대 1MB의 데이터 블록

파티션 키는 레코드가 이용할 샤드를 결정하는데 사용되고, 데이터 블록은 데이터 그 자체이다.

이제 생산자는 데이터를 스트림에 보낼 때 1MB/s로 전송하거나 1000msg/sec per shard 로 전송할 수 있다.

kinesis Data Stream 이후에 소비자에게는 다음의 Record가 전달되는데

1. Partition Key
2. Sequence Number - 샤드 내에서 몇 번째인지 나타냄
3. 데이터 블록

shard 당 2MB/s를 소비자에게 공유할 수도 있고,
소비자마다 샤드 당 2MB/s씩 받을 수도 있다.

효율성을 높인 소비 유형, 즉 효율성을 높인 펜아웃 방식이라면 말이다.

Kinesis Data Streams 특징

• 보존 기간은 1일에서 365일 사이로 설정할 수 있으며, 이 말은 기본적으로 데이터를 다시 처리하거나 확인할 수 있다는 뜻이다.
• 데이터가 일단 Kinesis로 들어가면 삭제할 수 없으며, 이 특징을 immutability(불변성)이라고 한다.
• 데이터 스트림으로 메시지를 전송하면, 파티션키가 추가되고 파티션 키가 같은 메시지들은 같은 샤드로 들어가게 되어 키를 기반으로 데이터를 정렬할 수 있다.
• 생산자는 SDK, Kinesis Producer Library (KPL), Kinesis Agent를 사용하여 데이터를 전송할 수 있고,
• 소비자는 Kinesis Client Library(KCL), AWS SDK로 데이터를 사용할 수 있다.
• AWS에서 관리하는 Lambda나 Kinesis Data Firehose, Kinesis Data Anlytics를 활용할 수도 있다.

Capacity Modes

• Provisioned Mode
  프로비저닝할 샤드 수를 정하고 API를 활용하거나 수동으로 조정한다.
  Kinesis Data Stream에 있는 각 샤드는 초당 1MB나 1000개의 레코드를 받아들이고,
  출력량의 경우에는 각 샤드가 초당 2MB를 방출한다. (일반적인 혹은 더 나은 펜아웃 방식에 적용 가능)
  프로비저닝한 샤드 만큼 비용을 낸다.
• On-demand Mode
  프로비저닝하거나 용량을 관리할 필요가 없다.
  시간에 따라 용량이 조절된다.
  기본적으로 초당 4MB 또는 초당 4000개의 레코드를 처리하지만
  이 용량은 지난 30일 동안 관측한 최대 처리량에 기반하여 자동으로 조정된다.
  이 유형에서는 시간당 스트림당 송수신 데이터량에 따라 비용이 부과된다.

보안

리전에 배포된다.
IAM 정책을 사용하여 샤드를 생성하거나 샤드에서 읽어 들이는 접근 권한을 제어할 수 있다.
in flight using HTTPS
KMS
클라이언트 암호화 가능
VPC 엔드포인트 사용 가능 - 인터넷을 거치지 않고 프라이빗 서브넷의 인스턴스에 직접 접근 가능
모든 API요청은 CloudTrail로 감시 가능

Kinesis Data Firehose 개요

생산자에서 데이터를 가져옳 수 있는 유용한 서비스이다.
생산자는 앱, 클라이언트, SDK 등등이 될 수 있다.

그리고 Kinesis Data Streams, CloudWatch, IoT도 데이터를 생산할 수 있다.

이 데이터가 최대 1MB의 Record로 들어오면, 이 데이터를 선택적으로 람다함수를 통해 변환할 수도 있다.
이 데이터를 받으면, 배치 형태로 쓸 수 있다.

Kinesis Data Firehose가 데이터를 쓰는 법을 알기 때문에 별도로 코드를 짤 필요가 없다.

Write Destination

1. AWS Destination
   • Amazon S3
   • Amazon Redshift(S3에 먼저 쓰면, Kinesis Data Firehose가 복사 명령을 보낸다.)
   • Amazon ElasticSearch
2. 3rd-party Partner Destination
   • Datadog
   • Slunk
   • New Relic
   • mongoDb
3. Custom Destination
   • HTTP Endpoint

이렇게 수신처에 데이터를 보내고나면, 모든 데이터를 백업으로 S3 버킷에 보내거나, 혹은 수신처에 보내지 못한 데이터를 실패 S3 버킷에 보낼 수 있다.

• 완전 관리되는 서비스이다. 용량도 자동으로 조절된다.
• 보내는 데이터에 대해서만 과금된다.
• 거의 실시간 서비스이다.
  • 배치가 꽉 채워지지 않은 경우, 최소 60초의 지연이 발생한다.
  • 또는 한 번에 최소한 1MB데이터를 채워서 보내야 한다.

Kinesis Data Streams vs Kinesis Data Fire hose

• Kinesis Data Streams
  • 데이터를 대규모로 수집할 때 쓰는 스트리밍 서비스고, 생산자와 소비자에 대해 커스텀 코드를 쓸 수 있다.
  • 실시간 (지연시간 70ms ~ 200ms)
  • 샤드 분할 혹은 병합을 통해 용량이나 처리량을 늘릴 수 있다.
  • 1 ~ 365 일 보관 가능
• Kinesis Data Fire hose
  • 수집 서비스로 다른 서비스에 스트리밍해준다.
  • 완전 관리형
  • 거의 실시간 (60초)
  • 자동 스케일링
  • 데이터저장 X
  • 데이터 양 만큼 과금

Kinesis와 SQS FIFO에 대한 데이터 정렬

Ordering data into Kinesis

Kinesis에 데이터를 순서대로 보내기 위해서는 파티션 키를 사용하면 된다.
파티션 키는 일종의 ID와 같다.

파티션 키가 같은면 같은 샤드로 가는 성질을 이용하는 것이다.

Ordering data into SQS

보내진 순서에 따라 나간다.

그룹 ID를 사용하면, FIFO 내부에 두 개의 그룹이 생기고, 소비자 별로 독립적으로 데이터를 내보낼 수 있다.

SQS FIFO의 경우, 소비자의 수에 따라 그룹ID를 늘릴 수 있으므로, 소비자가 동적으로 변하는 모델에 적합하다.
Kinesis 데이터 스트림의 경우 샤드 당 데이터를 정리하고 싶을 때 적합하다.

SQS sv SNS sv Kinsesis

SQS는 소비자가 대기열에서 메시지를 요청해서 메시지를 보내는 식이고, 소비자가 읽고 데이터를 삭제한다.
소비자나 생산자의 수에 구애 받지 않고, 빠르게 확장할 수 있다.
FIFO 시 설정 후에 사용 가능하다.
메시지 지연시간을 적용할 수 있어서 30초 등 일정시간 뒤에 대기열에 나타나도록 할 수 있다.

SNS는 게시/구독 모델로 다수의 구독자에게 메시지를 푸시할 수 있다.
데이터가 SNS에 전송되면 지속되지 않아 데이터를 잃을 수 있다.
처리량을 프로비저닝 할 필요없다.

Kinesis
소비자가 데이터를 가져오는 모드
Kinesis가 데이터를 출력하는 모드

데이터가 지속되기 때문에 다시 재생할 수 있다.
실시간 빅데이터 등 에 사용 가능하다.
1 ~ 365일 데이터 보과 가능

프로비저닝 모드, 온디멘드 모드 존재

Amazon MQ

SQS, SNS는 독점 기숭이다.

온프레미스에서 이 서비스를 사용하고 싶을 때에는 오픈프로토콜인 MQTT, AMQP, STOMP, WSS, Openwire를 사용할 수 있다.

MQ를 사용하면 오픈프로토콜을 AWS에서 쓸 수 있다.

RabbitMQ와 ActiveMQ 두 가지 기술을 위한 메시지 브로커 서비스이다.

Amazon MQ는 SQS / SNS 처럼 확장성이 크지는 않다.
왜냐면 서버에서 실행해야 해서 서버에 문제가 있을 수 있기 때문이다.

고가용성을 위해 장애조치와 다중 AZ처리를 할 수 있다.