AWS 메시징 디커플링

메시징

• 애플리케이션 여러개 배포할 때 커뮤니케이션을 한다
  • 서비스끼리 정보와 데이터를 공유해야할 때 사용한다
• 애플리케이션 커뮤니테잇녀을 두 가지 패턴으로 나뉘어진다
  • 동기 커뮤니케이션
    • 직접적으로 연결하여 동기 커뮤니케이션을 연결한다
    • 트래픽이 갑자기 급증하거나 아무것도 예측할 수 없을 때 애플리케이션을 분리하고 분리 계층을 확장하는 것이 좋다
  • 비동기 혹은 이벤트 기반
    • 대기열이라 불리는 미들웨어로 애플리케이션을 연결한다
    • BuyingService가 Queue에 데이터를 넣으면 Shipping Service는 확인하다가 해당 요소를 반환하면 배송 서비스는 자기가 원하는 행동을 한다
    • 직접적으로 연결되어 있지 않기 때문에 비동기라고 한다
• SQS: Queue Model
• SNS: Pub/Sub Model
• Kinesis: 실시간 스트리밍, 대용량 데이터

SQS

• SQS의 핵심은 대기열이다
  • 간단한 대기 서비스
• 생상자: 메시지를 보내는 주체를 생산자라고 한다
• 소비자: 소비자는 대기열에서 메시지를 폴링한다
• 버퍼: SQS는 생산자와 소비자 사이를 분리하는 버퍼역할을 한다
  

1. Standard Queue

• SQS는 AWS에서 제공하는 가장 오래된 서비스이다
• 완전 관리형 서비스이며 애플리케이션 디커플링하는데 도움이 된다

속성

• 무제한 처리량
  • 처리량과 대기열의 메시지 수에 제한이 없다
• 수명이 짧다
  • 기본적으로 4일간 최대는 14일 동안 대기열에 있을 수 있다
  • 소비자는 큐에 있는 데이터를 읽고 처리한 후 대기열에서 삭제해야한다
• 지연시간이 짧다
  • 10 밀리초이내로 응답받을 수 있다
• 256KB
  • 메시지 크기는 256KB미만이어야 한다
• 중복메시지가 있을 수 있다 (At Least Once)

2. 메시지 가시성 시간초과

• 소비자가 메시지를 폴링하면 다른 소비자는 해당 메시지를 볼 수 없다
• 소비자가 ReceiveMessage 요청을하면 가시성 시간초과가 시작된다
  • 기본값은 30초로, 30초 이내에 메시지가 처리되어야한다
  • 다른 소비자가 요청을 해도 메시지가 반환되지 않는다
  • 가시성 시간 초과 기간 내에서는 그 메시지는 다른 소비자들에게 보이지 않는다
  • 시간이 경과되고 메시지가 삭제되지 않았다면 다시 대기열에 넣고 다른 소비자들도 볼 수 있다
• 메시지 시간내에 처리하지 않으면 두 번 처리될 수 있다
• 시간내에 처리 못하겠다면 ChangeMessageVisibility API를 호출하여 두 번 처리되는걸 막아야한다
  

3. Long Polling

• 소비자가 대기열에 메시지를 요청하는데 대기열에 아무것도 없다면 메시지 도착을 기다린다
• 메시지를 계속 기다려서 지연시간을 줄이고, API 호출 숫자를 줄인다
• 대기열에 메시지가 없다면 1초에서 최대 20초동안 기다린다
• 구성방법
  • 대기열 레벨에서 구성하여 폴링하는 아무 소비자로부터 롱 폴링 활성화한다
  • WaitTimeSeconds를 설정하여 롱 폴링을 하도록 설정할 수 있다

4. FIFO Queue

• FIFO방식으로 메시지를 받을 수 있도록 보장한다
• 때문에 대기열 처리량에 제한이 있고 초당 300개의 메시지를 처리할 수 있다
  • 메시지를 묶음으로 보낸다면 초당 3,000개를 처리할 수 있다
• FIFO 대기열 기능으로 인해 정확히 한 번만 보낼 수 있게 해준다
  

5. SQS With ASG

• ASG 내의 EC2 인스턴스에 메시지를 SQS 대기열에서 폴링한다
• 대기열 크기를 보고 오토 스케일링 여부를 결정한다
  • ApproximateNumberOfMessages를 기반으로 지표를 지정하여 CloudWatch를 이용해 오토스케일링을 한다
    

사용예시

• 백엔드에서 DB로 저장을 할 때 요청 수가 너무 많아서 트랜잭션이 제대로 되지 않는다
• 하나의 ASG에서는 메시지를 SQS Queue에 담는다
• 다른 ASG는 메시지를 받아 DB에 저장을 한다
• 만약 요청 수가 늘어나도 EC2는 오토스케일링을 하여 안정적으로 처리할 수 있다
• SQS는 버퍼로 사용하여 모든 트랜잭션이 데이터베이스에서 쓰이도록 할 수 있다
  

SNS

• Amazon Simple Notification Service
• Pub/Sub 방식이다
• 계정당 가질 수 있는 토픽 수는 최대 10만개이고, 토픽별로 최대 1,200만 이상의 구독자까지 가능하다
• SQS와 보안이 똑같다
  • 기본적으로 있는 전송 중 암호화
  • KMS 키를 이용한 저장 데이터 암호화
  • 클라이언트 측 암호화
  • IAM 정책
  • SNS 액세스 정책
    

1. SNS + SQS: Fan Out

• 다수의 SQS 대기열로 메시지를 보내려고 할 때 유용하다
• 모든 대기열에 메시지를 보내려고 하면 실패하거나, 중복되어 보내거나 하는 문제가 발생할 수 있다. 이럴때 FanOut으로 SNS 토픽으로 한 번 메시지를 전송하고 원하는 만큼 SQS 대기열을 SNS 토픽에 구독시키는 것이다
  

장점

• 완벽히 디커플링되었고, 데이터 손실이 없다
• SQS로 데이터 지속성, 지연처리, 작업 재시도 등의 효과를 얻을 수 있다
• SQS 대기열을 구독자로 더 추가할 수 있다
• 다른 리전의 SQS대기열에 메시지를 보내는 것도 가능하다

2. FIFO

• SQS FIFO와 같은 기능을 한다
• 메시지 그룹 ID에 따라 메시지를 정렬하고 중복된 ID나 컨텐츠를 중복제거할 수 있고 SQS 스탠다드와 SQS FIFO 모두 구독자가 될 수 있다
• SQS FIFO 대기열과 같은 제한된 처리량을 갖는다
• SQS만 구독할 수 있다

3. 메시지 필터링

• SNS 토픽 구독자들에게 전송할 메시지를 필터링하는 JSON 정책이다
• 메시지 필터링을 하게되면 정책에 부합되는 메시지만 전송한다
  

Kinesis

• Kinesis를 활용하면 실시간 스트리밍 데이터를 손쉽게 수집하고 처리하여 분석할 수 있다
  • 데이터가 빠르게 실시간으로 생성된다면 모두 실시간 데이터 스트림으로 간주할 수 있다
• Kinesis Data Streams
  • 데이터 스트림을 수집하여 처리하고 저장한다
• Kinesis Data Firehose
  • 데이터 스트림을 AWS 내부나 외부의 데이터 저장소로 읽어 들인다
• Kinesis Data Analytics
  • SQL 언어나 Apache Flink를 활용하여 데이터 스트림을 분석한다
• Kinesis Video Streams
  • 비디오 스트림을 수집하고 처리하여 저장한다
    

1. Kinesis Data Streams

• 시스템에서 큰 규모의 데이터 흐름을 다루는 서비스이다
• 여러 개의 샤드로 구성되어 있고, 이 샤드는 1부터 N개가 이루어져 있다
  • Data Stream을 시작할 때 스트림을 여러개의 샤드로 구성하겠다고 결정한다
  • 데이터는 모든 샤드에 분배된다
  • 샤드는 데이터 수집률이나 소비율 측면에서 스트림의 용량을 결정한다
• 보존기간은 1일 ~ 365일 사이로 설정할 수 있다
• 기본적으로 데이터를 다시 처리하거나 확인할 수 있다
• 데이터가 Kinesis로 들어오면 삭제할 수 없으며, 파티션 키가 같으면 같은 샤드로 들어가고 키를 기반으로 데이터를 정렬할 수 있다

1). 생산자

• 카프카와 비슷하게 파티션 키와 데이터가 있고, 파티션키는 레코드가 이용할 샤드를 결정하는데 사용된다
• 생산자는 데이터를 스트림으로 보낼 때 초당 1MB를 전송하거나 샤드당 천 개의 메시지를 전송할 수 있다
• 즉 여섯개의 샤드가 있다면 초당 6MB를 얻거나 총 6천개의 메시지를 얻을 수 있다

2). 소비자

• 파티션 키, 시퀀스 번호, 데이터가 있는 레코드를 넘겨준다
• 샤드마다 초당 2MB의 처리량을 모든 소비자가 공유할 수도 있고, 소비자 마다 샤드당 1초에 2MB씩 받을 수 있다

2. Kinesis Data Firehose

• 생산자로부터 데이터를 가져올 수 있는 유용한 서비스이다
• 완전 관리형 서비스로 거의 실시간 데이터 처리이다
  • Firhose에서 수신처까지 배치로 데이터를 보내기 때문에 완전 실시간은 아니다
  • 버퍼링이 잘되어 있으면 거의 실시간 서비스가 된다
• 여러 데이터 형식과 전환, 변환, 압축을 지원하며 필요한 경우 람다를 활용하여 자체적인 데이터 변환을 할 수 있다
  

1). Data Streams vs Data Firhose

• Data Streams
  • 대규모 데이터를 수집하는데 사용되는 스트리밍 서비스이다
  • 생산자와 소비자를 위한 사용자 전용 코드가 있다
  • 200ms 또는 70ms인 실시간이며 스케일링은 직접 관리한다
  • 규모와 처리량을 높이기 위해 샤드 분할과 샤드 병합을 수행한다
  • 데이터 저장 기간을 1 ~ 365일까지 설정할 수 있다
  • 이를 통해 여러 소비자가 동일한 스트림에서 읽을 수 있게 하며 다시 읽는 것도 가능하다
• Data Firhose
  • 수집 서비스로 S3, RedShift, OpenSearch등으로 스트리밍한다
  • 완전 관리형 서비스이다
  • 거의 실시간 서비스이고 자동 스케일링된다
  • 데이터 저장소가 없어서 데이터를 다시 읽을 수 없다

SQS vs SNS vs Kinesis

• SQS
  • 소비자가 메시지를 요청해서 데이터를 가져오는 Pull 모델이다
  • 데이터를 처리한 후 소비자가 대기열에서 삭제해서 다른 소비자가 읽을 수 없도록 해야한다
  • 소비자 수는 제한이 없다 (작업자와 소비자가 함께 소비하고 대기열에서 삭제한다)
  • 관리형 서비스라서 처리량을 프로비저닝 할 필요 없다
  • 빠르게 수백 수천개의 메시지로 확장할 수 있다
  • 순서를 보장하려면 FIFO를 활성화해야하고, 지연시간이 있어서 30초 등 일정 시간뒤에 대기열에 나타나도록 할 수 있다
• SNS
  • Pub/Sub 모델로 다수의 구독자에게 데이터를 푸시하면 메시지의 복사본을 얻게된다
  • 토픽별로 1,250만명의 구독자까지 가능하며 데이터가 한 번 SNS에 전송되면 저장되지 않는다
    • 제대로 전달되지 않으면 데이터를 잃을 가능성이 있다
  • 처리량을 프로비저닝하지 않아도 되고 원한다면 SQS와 연결할 수 있다 (팬아웃)
• Kinesis
  • 스탠다드 (Pull 모드), 향상된 팬아웃(소비자에게 데이터를 푸시)가 있다
  • 데이터 스트림에서는 데이터가 저장되기 때문에 다시 읽을 수 있다
  • 실시간 데이터 분석, 빅 데이터, ETL에 사용된다
  • 샤드를 직접 확장해서 데이터가 언제 만료될지 정할 수 있다
  • 프로비저닝 모드로 샤드 수를 직접 조절하거나, 온디맨드로 자동으로 조정하게 할 수 있다

Amazon MQ

• RabbitMQ와 ActiveMQ 두 가지 기술을 위한 관리형 메시지 브로커 서비스이다
• 확장성이 크지 않다
• 고가용성을 위해 장애 조치와 함께 다중 AZ 설정을 할 수 있다