디커플링 애플리케이션: SQS, SNS, Kinesis, Active MQ

AWS Integration & Messaging

• Application communication의 두가지 패턴
  • Synchronous communications
    • 애플리케이션이 또 다른 애플리케이션과 직접적으로 연결
  • Asynchronous / Event based
    • 미들웨어가 애플리케이션들을 연결
    • 직접적으로 연결되어 있는 것이 아님
• 트래픽이 급증하거나 예측할 수 없을 때는 애플리케이션들을 분리하고 분리 계층을 확장하는 것이 좋다
  • 대기열 모델 : SQS
  • pub/sub 모델 : SNS
  • 실시간 스트리밍과 대용량 데이터 다루는 모델 : Kinesis

Amazon SQS

• 메시지를 SQS 대기열에 보낼 수 있다
• 모든 메시지는 대기열에 들어간다
• Producer : 메시지를 보내는 주체 (Send messages)
• Consumer : 메시지를 받는 주체 (poll messages)
• 대기열 서비스는 producer와 consumer 사이를 분리하는 버퍼 역할

Amazon SQS - Standard Queue

• 완전 관리형 서비스이며 애플리케이션을 분리하는 데 사용
• 무제한 처리량을 얻을 수 있다
  • 초당 원하는 만큼 메시지를 보낼 수 있고 대기열에도 원하는 만큼 메시지를 포함시킬 수 있다
• 각 메시지는 수명이 짧다
  • 기본값으로 4일동안 대기열에 남아 있고 대기열에 있을 수 있는 최대 시간은 14일이다
• SQS 메시지는 작아야 한다 (256KB 미만)
• 높은 처리량, 높은 볼륨 등이 있어 중복 메시지가 있을 수있다

SQS - Producing Messages

• producer에 의해 256KB의 메시지가 SQS로 전송
• 전송 방법은 SDK 소프트웨어 개발 키트를 사용하여 SQS에 메시지를 보낸다
• 메시지를 SQS에 보내는 API를 SendMessage라고 한다
• consumer가 메시지를 읽고 삭제할 때까지 SQS 대기열에 유지된다

SQS - Consuming Messages

• 일부 코드로 작성해야 하는 애플리케이션
• SQS 메시지를 polling
  • SQS 대기열에 자신의 앞으로 온 메시지가 있는지를 묻는다
• 한 번에 최대 10개의 메세지를 받는다
• 메시지를 처리하면 DeleteMessage API로 삭제

SQS with Auto Scaling Group

• 사용하는 지표 = 대기열의 길이 (ApproximateNumberOfMessages)
• 메시지들을 더 높은 처리량으로 처리할 수 있다

SQS to decouple between application tiers

• 애플리케이션을 분리하여 파일 처리 요청과 실제 파일 처리가 서로 다른 애플리케이션에서 발생하도록 한다
  • 파일 처리 요청을 받을 때마다 SQS 대기열로 메시지를 전송

SQS Security

• Encryption
  • HTTPS API를 사용하여 메시지를 보내고 생성한다
  • KMS 키를 사용하여 미사용 암호화를 얻고 원한다면 클라이언트 측 암호화를 할 수도 있다
• Access Controls
  • IAM 정책은 SQS API에 대한 액세스를 규제할 수 있고 S3 버킷 정책과 유사한 SQS 액세스 정책도 있다

SQS - Message Visibility Timeout

• default로 30초의 시간이 주어진다
• 시간 초과 기간 내에 또 다른 요청이 들어와도 메시지가 반환되지 않는다
• 하지만 가시성 시간 초과가 경과되고 메시지가 삭제되지 않았다면 메시지는 다시 대기열에 들어간다
• 가시성 시간 초과 기간 내에 메시지를 처리하지 않으면 메시지가 두 번 처리될 수도 있다
  • 두 명의 다른 소비자가 수신하거나 동일한 소비자가 두 번 수신하기 때문
• Consumer가 시간이 더 필요하다는 것을 알면 ChangeMessageVisibility API를 호출해 더 많은 시간을 확보하고 가시성 시간 초과 기간을 늘릴 수 있다

Amazon SQS - Long Polling

• consumer가 대기열에 메시지를 요청하는데 대기열에 아무것도 없다면 메시지 도착을 기다린다
• 지연 시간을 줄이기 위해서
• SQS로 보내는 API 호출 숫자를 줄이기 위해서
• 효율성과 대기 시간을 증가시킨다
• WaitTimeSeconds를 지정함으로써 consumer가 스스로 long polling을 선택할 수 있다
• SQS 대기열에 대한 API 호출 수를 최적화하고 지연 시간을 줄이는 방법

Amazon SQS - FIFO Queue

• 대기열에 첫번 째 도착한 메시지가 첫 번째로 나간다
• SQS 대기열의 처리량에는 제한이 있다
  • 묶음이 아닐 경우 초당 300개의 메시지를 처리
  • 묶음으로 보낼 경우 초당 3,000개를 처리
• 중복을 제거하도록 해주는 SQS FIFO 대기열의 기능으로 정확히 한 번만 보낼 수 있도록 해준다
• 분리가 발생하거나 메시지의 순서를 유지할 필요가 있을 때 FIFO 대기열을 사용
• Configuration에 있는 Content-based deduplication이라는 설정으로 5분 이내의 짧은 시간동안 동일한 메시지가 두 번 발송됐을 경우 중복을 방지하는 설정

SQS with Auto Scaling Group

• ASG 내의 EC2 인스턴스에 메시지를 SQS 대기열에 polling
  • ASG을 자동으로 대기열 크기에 따라 확장시키기 위함 (CloudWatch 지표인 대기열 길이를 보고 결정)
• ApproximateNumberOfMessages : 대기열에 몇 개의 메시지가 남아 있는지를 나타냄
  • 이를 기반으로 Alert를 지정할 수 있다
• 분리나 급격히 증가한 로드 혹은 시간 초과 등의 문제에서 신속한 스케일링이 필요한 경우에는 SQS 대기열을 사용한다

Amazons SNS

• Pub / sub : 게시 / 구독
• 각 구독자는 SNS 주제에서 해당 메시지를 수신하고 보관 할 수 있다
• event producer은 한 SNS 주제에만 메시지를 보낸다
• event consumer 또는 구독자는 해당 주제와 관련한 SNS 알림을 받는다
• 주제별로 최대 1,200만 이상의 구독자까지 가능
• 계정당 가질 수 있는 주제 수는 최대 10만 개
• SQS와 통합하여 메시지를 대기열로 직접 보낼 수도 있다
• 메시지를 수신한 후 함수가 코드를 수행하도록 lambda에 보낼 수 있다

AWS SNS - How to publish

• Topic Publish (using the SDK)
  • 주제 생성
  • 하나 또는 여러개의 구독 생성
  • 주제 게시
• Direct Publish (for mobile apps SDK)
  • 플랫폼 애플리케이션 생성
  • 플랫폼 엔드 포인트 생성
  • 플랫폼 엔드포인트에 게시

Amazon SNS - Security

• SQS와 동일
• 전송 중 암호화와 KMS 키를 사용한 저장 데이터 암호화
• 클라이언트 측 암호화
• 암호화와 암호 해독은 클라이언트 몫
• 액세스 제어는 IAM 정책 중심

SNS + SQS : Fan Out

• SNS 주제에 메시지를 전송한 후 원하는 수의 SQS 대기열이 SNS 주제를 구독하게 하는 것
• 대기열이 구독자로서 SNS로 들어오는 모든 메시지를 받게 된다
• SQS로 작업을 다시 시도할 수 있을 뿐 아니라 데이터 지속성, 지연 처리도 수행할 수 있다
• SNS 주제를 구독하도록 더 많은 SQS 대기열을 추가할 수도 있다
  • SQS 액세스 정책에서 SNS 주제가 SQS 대기열에 쓰기 작업을 할 수 있도록 허용해야 한다

Application : S3 Events to multiple queues

• S3 객체를 생성하여 S3 버킷에 이벤트를 형성하고 이 이벤트를 SNS 주제로 전송한 후 Fan out 패턴으로 많은 SQS 대기열이 SNS 주제를 구독하게 한다

Amazon SNS - FIFO Topic

• 주제의 메시지 순서를 지정하는 FIFO기능이 존재
• SQS FIFO와 유사하다
  • 메시지 그룹 ID에 따라 순서를 매기고 중복 제거 ID를 활용하거나 내용을 비교하여 중복 데이터를 제거하며 SQS FIFO 대기열을 FIFO SNS 주제의 구독자로 설정

SNS - Message Filtering

• SNS 주제를 구독할 때 전송되는 메시지를 필터링하는 데 사용하는 JSON 정책
• 만약 필터링이 존재하지 않다면 모든 메시지를 받아들인다 (default)

Kinesis

• 실시간 스트리밍 데이터를 손쉽게 수집하고 처리하여 분석할 수 있다
  • 애플리케이션 로그, metrics, 웹 사이트 클릭 스트림, IoT 원격 측정 데이터
• Kinesis Data Streams
  • 데이터 스트림을 수집하여 처리하고 저장
• Kinesis Data Firehose
  • 데이터 스트림을 AWS 내부나 외부의 데이터 저장소로 읽어 들임
• Kinesis Data Analytics
  • SQL언어나 Apache Flink를 활용하여 데이터 스트림을 분석
• Kinesis Video Stream
  • 비디오 스트림을 수집하고 처리하여 저장

Kinesis Data Streams

• 시스템에서 큰 규모의 데이터 흐름을 다루는 서비스
• 데이터를 대규모로 수집할 때 쓰는 스트리밍 서비스
• producer와 customer에 대해 커스텀 코드를 사용할 수 있다
• 여러 개의 샤드로 구성 (1번 - N번)
  • 사전에 사용자가 프로비저닝 해야함
• 데이터가 모든 샤드에 분배된다
• 샤드는 데이터 수집률이나 소비율 측면에서 스트림의 용량을 결정
• record는 두 가지 요소로 구성
  • 파티션 키와 최대 1MB 크기의 데이터 blob dmfh rntjd
  • 파티션 키는 레코드가 이용할 샤드를 결정하는 데 사용
  • 데이터 blob은 값 자체를 의미

• 1일 에서 365일 사이로 설정하여 보관
• 데이터가 kinesis로 들어오면 삭제할 수 없다
• 데이터 스트림으로 메시지를 전송하면 파티션 키가 추가되고 파티션 키가 같은 메시지들은 같은 샤드로 들어가게 되어 키를 기반으로 데이터를 정렬
• 모든 API 요청은 CloudTrail로 감시 할 수 있다

Kinesis Data Firehose

• consumer에서 데이터를 가져올 수 있는 유용한 서비스
• 수집 서비스로 데이터를 수신처에 전송한다
• 서버리스이고 근 실시간으로 이루어 진다 (near-real-time)
• Data Firehost의 수신처
  • S3, Amazon Redshift, Amazon ElasticSearch
  • 3rd-party Partner Destinations (Datadog, mongoDB)
  • Custom Destinations (HTTP endpoint)

Amazon MQ

• RabiitMQ와 ActiveMQ 두 가지 기술을 위한 관리형 메시지 브로커 서비스
• 개방형 프로토콜 액세스를 제공
• RabiitMQ와 ActiveMQ은 온프레미스 기술
• 확장성이 크지 않다
• Amazon MQ는 서버에서 실행되므로 서버 문제가 있을 수도 있다
• 다중 AZ 설정을 실행할 수 있다