develop/AWS

[SAA] Integration & Messaging: SQS, SNS, Kinesis, Active MQ

hsleeee 2024. 6. 27. 10:00
반응형
SMALL

1. Amazon SQS(대기열 모델 사용)

  • Standard Queue
    • AWS의 첫번째 서비스 중 하나, 가장 오래된 서비스
    • 완전 관리형 서비스, 애플리케이션 분리 시 사용
    • Attributes
      • 무제한 처리량, 대기열에 저장 가능한 메시지 수의 제한이 없음
      • 메시지 보존 기간의 기본 값은 4일, 최대 기간은 14일
      • 지연 시간이 짧음(<10ms on publish and receive)
      • 전송되는 메시지는 256kb로 제한
    • 중복 메시지가 발생할 수 있음(at least once delivery, occasionally)
    • Can have out of order message (best effort ordering)
      • Producing Messages
      • SDK를 사용하여 SQS에 메시지를 생성(SendMessage API)
      • 메시지는 소비자가 해당 메시지를 읽고 삭제할 때까지 SQS 대기열에 유지
      • 메시지 보존 기간: default 4 days, max 14 days
      • SQS Standard: 무제한 처리량 제공
      • Consuming Messages
      • 소비자(EC2 인스턴스, 서버, 또는 AWS Lambda에서 실행)
      • 메시지를 가져오기 위해 SQS를 폴링(한번에 최대 10개의 메시지 수신)
      • 메시지를 처리(ex: 메시지를 RDS 데이터베이스에 삽입)
      • DeleteMessage API를 사용하여 메시지 삭제
      • Multiple EC2 Instance Consumers
      • 소비자들은 메시지를 병렬로 수신하고 처리
      • 최소 한번의 전송 보장
        • 각 소비자는 poll 함수를 호출하여 다른 메시지 세트를 수신하게 됨, 만일 메시지가 소비자에 의해 충분히 빠르게 처리되지 않으면 다른 소비자가 수신하게 됨, 따라서 적어도 한 번은 전송이 됨
      • 최선의 노력으로 메시지 순서 보장(Best-effort message ordering)
      • 소비자들은 메시지를 처리한 후에 삭제해야 함
      • 처리량을 향상시키기 위해 소비자를 추가하고 수평 확장을 할 수 있음
    • SQS With Auto Scailing Group (ASG)
      • 소비자가 ASG 내부에서 EC2 인스턴스를 실행하고, SQS 대기열에서 메시지를 폴링함
      • ASG는 일종의 Metric에 따라 확장되어야 하는데, 이때 사용하는 Metric은 대기열의 길이임(ApproximateNumberOfMessage)
      • 경보를 설정할 수 있는데, 댇기열의 길이가 특정 수준을 넘어가면 CloudWatch Alarm을 설정하면 됨, 이 경보는 AutoScaling Group의 용량을 n 만큼 증가시키는데, 그러면 더 많은 메시지가 SQS 대기열에 존재하게 도딤
      • ex: 웹사이트에 주문이 폭주해서 오토 스케일링 그룹이 더 많은 EC2 인스턴스를 제공하면 메시지들은 더 높은 처리량으로 처리할 수 있게 됨
      • SQS to decouple between application tiers
        • 애플리케이션 계층간에 분리를 위해 사용됨
    • Security
      • Encryption
        • 전송 중 데이터의 암호화는 HTTPS  API 사용
        • 정지 상태(at-rest) 데이터의 암호화는 KMS 키 사용
        • 클라이언트가 직접 암/복호화를 수행하려는 경우 클라이언트 측 암호화 사용
      • Access Controls
        • IAM 정책을 사용하여  SQS API에 대한  액세스를 규제
      • SQS Access Policies(S3 버킷 정책과 비슷)
        • SQS 대기열에 대한  교차 계정 액세스를 수행하는 경우에  유용
        • 다른 서비스(SNS,S3 등)가  SQS 대기열에 슬 수 잇도록 허용하는 데 유용
  • Message Visibility Timeout
    • 소비자가 메시지를 폴링하면 그 메시지는 다른 소비자에게는 보이지 않게  됨
    • 기본적으로 '메시지 가시성 시간 제한 초과'는 30초
    • 즉 메시지는 처리되기까지  30초의 시간을 갖게됨
    • 메시지 가시성 시간 제한이 초과되면 메시지는 SQS에서 "가시"상태가 됨
    • 즉 가시성 시간 제한 기간 내에서는 메시지는 다른 소비자에게 보이지 않고, 가시성 시간 제한이 초과되고 메시지가 삭제되지 않앗다면 메시지는 대기열에 다시 넣어짐
    • 메시지가 가시성 시간 내에 처리되지 않으면 메시지는 두 번 처리될 수도 있음
    • 소비자는 ChangeMessageVisibility라는 API를 호출하여 더 많은 시간을 얻을 수 있음
    • 가시성 시간 제한이 너무 길 경우(시간 단위), 소비자가 충돌했을 때 이 메시지가 다시 나타날 때까지 (SQL 대기열에 보일 때 까지) 몇 시간이 걸릴 수 있음
    • 가시성 시간 제한이 너무 짧을 경우(초 단위) 처리할 시간이 충분하지 않으면 다른 소비자가 메시지를 여러 번 읽고  해당 요청이 여러번 처리될 수 있음
  • Long Polling
    • 소비자가 대기열에서 메시지를 요청할 때 대기열에 메시지가 없다면 메시지가 도착할 때 까지 "대기"할 수 있음
    • 이를 롱 폴링이라고 한다.
    • 롱 폴링은 SQS로의 API 호출 수를 줄이고, 애플리케이션의 효율성을 향상 시키며, 응답 지연 시간을 감소 시킴
    • 대기 시간은 1초부터 20초 사이로 설정 가능
    • 롱 폴링은 숏 폴링에 비해 선호됨
    • 롱 폴링은 대기열 수준이나 WaitTimeSeconds API를 사용하여 API 수준에서 활성화할 수 있음
  • FIFO(First In First Out) Queue
    • 처리량에 제한이 있음, 배치 처리 없이는 초당 300개의 메시지 처리, 배치 처리를 사용하면 초당 3,000개의 메시지 처리 가능
    • 중복 메시지를 제거하여 정확히 한 번만 전송 가능
    • 소비자에 의해 메시지는 순서대로 처리됨
  • SQS with Auto Scaling group (ASG)
    • 애플리케이션이 요청을 처리할 때 특정 트랜잭션에 오류가 발생한다면 해당 고객 트랜잭션이 유실될 수 있음
    • 이때 쓰기 대상 DB에서 SQS를 버퍼로 사용 가능
    • DB에 요청을 바로 쓰는 대신, 트랜잭션을 SQS 대기열에 먼저 쓰면 처리량 문제 발생 X

2. Amazon SNS

  • Pub(게시)/Sub(구독)을 통해 메시지를 SNS 주제(Topic)로 전송할 수 있음
  • 해당 주제에는 많은 굳독자가 있고, 각 구독자는 SNS 주제에서 해당 메시지를 수신하고 보관할 수 있음
  • Amazon SNS에서 이벤트 생산자는 한 주제에만 메시지를 전송
  • 이벤트 수신자는 해당 주제와 관련한 SNS 알림을 받으려는 사람, 원하는 만큼 생성 ㄱ가능
  • 주제에 대한 각 구독자는 모든 메시지를 수신(메시지 필터링을 위한 기능도 있음)
  • 주제당 최대 12,500,000개의 구독 가능
  • 주제의 수는 100,000개로 제한
  • SNS에서 구독자에게 게시할 수 있는 것은
    • SNS에서 직접 이메일 전송
    • SMS 및 모바일 알림 전송
    • 지정된 HTTP or HTTPS 엔드포인트로 직접 데이터 전송
    • SQS와 같은 특정 AWS 서비스와 통합하여 메시지를 대기열로 전송
    • 메시지 수신 후 함수가 코드를 수행하도록  Lambda에 전송
    • Firehose를 통해 데이터를 Amazon S3나 RedShift로 전송
  • 다양한 AWS 서비스에서 데이터를 직접 수신도 가능, AWS에서 알림이 발생하면 SNS에서 데이터 수신
    • CloudWathch Alams
    • AWS Budgets
    • Lambda
    • Auto Scaling Group(Notifications)
    • S3 Bucket(Events)
    • DynamoDB
    • CloudFormation(State Changes)
    • AWS DMS(New Replic)
    • RDS Events
  • How to Publish
    • Topic Publish(using the SDK)
      • 주제 생성
      • 하나 또는 여러개의 구독 생성
      • SNS에 주제 게시
    • Direct Publish(for mobile apps SDK)
      • 플랫폼 애플리케이션 생성
      • 플랫폼 엔드포인트 생성
      • 플랫폼 엔드포인트에 겍시
      • 수신 가능 대상은 Google GCM, Apple APNS, Amazon ADM 등
  • Security
    • SQS와 동일
    • Encryption
      • 전송 중 데이터의 암호화는 HTTPS  API 사용
      • 저장 데이터 데이터의 암호화는 KMS 키 사용
      • 클라이언트가 직접 암/복호화를 수행하려는 경우 클라이언트 측 암호화 사용
    • Access Controls
      • IAM 정책을 사용하여  SQS API에 대한  액세스를 규제
    • SNS Access Policies(S3 버킷 정책과 비슷)
      • SQS 대기열에 대한  교차 계정 액세스를 수행하는 경우에  유용
      • 다른 서비스(SNS,S3 등)가  SQS 대기열에 슬 수 잇도록 허용하는 데 유용
  • SNS + SQS: Fan Out
    • SNS 주제에 메시지를  전송한 후 원하는 수의 SQS 대기열이 SNS 주제를 구독하게 하여 이 대기열은 구독자로서 SNS로 들어오는 모든 메시지를 수신하게 됨
    • SNS에서 한 번 푸시하면 구독하는 모든 SQS 대기열에서 수신
    • 완전히 분리된 모델이며 데이터 손실 X
    • SQS로 작업을  재시도할 수 있을 뿐만 아니라 데이터 지속성, 지연 처리 수행 가능
    • 시간이 지남에 따라 SNS 주제를 구독하도록 더 많은 SQS 대기열 추가 가능
    • 이를 위해서는  SQS 액세스 정책이 SNS 쓰기 작업을 할 수 있도록 허용해야 함
    • 리전간 전달 가능 - 다른 리전의 SQS 대기열과 함께 작동
  • SNS FIFO + SQS FIFO: Fan Out
    • 팬아웃, 순서 지정, 중복 제거 기능이 필요한 경우 SNS FIFO와 SQS FIFO를 조합하여 원하는 기능 구현
    • Message  Filtering
      • SNS 주제의 구독으로 전송되는 메시지를 필터링하기 위해 JSON 정책을 사용
      • 구독에 필터 정책이 없는  경우, 해당 구독은 모든 메시지를 수신

3. Amazon Kinesis

  • Kinesis를 활용하면 실시간 스트리밍 데이터를 쉽게 수집하고 처리하여 분석 가능
  • 애플리케이션 로그, 매트릭, 웹사이트 클릭 스트림, IoT 원ㄱ격 측정  데이터 등의 실시간 데이터 수집
  • Kinesis Data Streams: 데이터 스트림을 캡처,처리 및 저장
    • 보존 기간은 1일 ~ 365일 사이로 설정
    • 데이터 재처리 및 확인  가능
    • Kinesis로 ㄷ데이터가 삽입된 후에는 삭제 불가(불변성)
    • 동일한 파티션을 공유하는 데이터는동일한 샤드로 전송(순서 보장), 키를  기반으로 데이터 정렬 가능
    • 생산자: AWS  SDK, Kinesis Producer Library(KPL), Kinesis Agent
    • 소비자
      • 직접 작성:  Kinesis Client Library(KCL),  AWS SDK
      • 관리형: AWS Lambda, Kinesis Data Firehose, Kinesis Data Analytics
    • Capacity Modes
      • Provisioned Mode
        • 사전에 프로비저닝할 샤드 수를 정하고 수동 또는  API를 사용하여 스케일 조정
        • 각 샤드당  1mb/s로  레코드를 받아드림(or 초당 1,000개의 레코드)
        • 출력량의 경우 각 샤드당 2mb/s(일반적인 소비 유형 또는 향상된 팬아웃 방식에 적용)
        • 샤드를 프로비저닝할 때 마다 시간당 비용 부과
      • On-demand mode
        • 용량을 사전에  프로비저닝  하거나 관리할 필요  X
        • 기본적으로는 4mb/s의 처리량 또는 초당  4,000개의 레코드  처리
        • 지난 30일간 관측된 최대 처리량에 기반하여 자동으로 스케일 조정
        • 시간당/스트림당 송수신 데이터양(gb단위)에 따라 비용 부과
    • Security
      • IAM 정책을 사용하여 액세스 및 권한 부여 제어
      • HTTPS 엔드포인트를 통한 전송중 데이터 암호화
      • KMS를 사용하여 데이터 정지 상태에서의 암호화
      • 클라이언트 측에서 데이터의 암/복호화 구현 가능(더 어려움)
      • VPC내에서 액세스 하기 위해 Kinesis에 대한 VPC 엔드포인트 사용 가능
      • 모든 API 요청은 CloudTrail을 사용하여 모니터링 가능
  • Kinesis Data Firehose: 데이터 스트림을 AWS 데이터 저장소로 로드
    • 완전  관리형 서비스, 관리 작업 필용 X, 자동 스케일링 및 서버리스 기능 제공
      • AWS: Reshift,  Amazon S3, OpenSearch와 통합
      • Third-party: Splunk,  MongoDB,  DataDog, NewRelic  등
      • Custom: HTTP EndPoints
    • Firehose를 통과하는 데이터에 대해서만 비용 지불
    • 거의 실시간으로 데이터 처리
      • 전체 배치가 아닌 경우 최소 60초의 지연 시간
      • 한번에 적어도 1mb 이상의 데이터가 있을 때까지 기다렬야 함
    • 다양한 덷이터 형식, 전환, 변환, 압축 지원
    • AWS Lambda를 사용하여 사용자 정의 데이터 변환 가능
    • 실패한 데이터 또는 모든 데이터를 백업용 S3 Bucket으로 전송 가능
  • Kinesis Data Analytics: SQL 또는 Apache Flink를 사용하여 데이터 스트림을 분석
  • Kinesis Video Streams: 비디오 스트림을 캡처, 처리 및 저장
Kinesis Data Streams Kinesis Data Firehose
대규모로 데이터를 수집하는 스트리밍 서비스 S3, Redshift,  OpenSearch, third-party, http로 데이터 스트리밍
생산자와 소비자에  대해  커스텀 코드 사용 가능 완전 관리형 서비스
Real-timee (~ 200ms) Near  real-time(버퍼 시간 최소  60초)
용량 직접 조절 가능(샤드 분할 및 병합) 자동 스케일링
제공한 용량만큼 비용 지불 Firehose를 통과하는 데이터에 대해서만 비용 지불
1 ~ 365일까지 데이터 저장 데이터 저장 기능 X
여러 소비자가 같은 스트림에서  읽어올 수 있고 반복 기능도 지원 데이터를 반복하는 기능 지원 X

 

4. SQS vs SNS vs Kinesis

  • SQS
    • 소비자가 SQS 대기열에서 메시지르 요청하여 가져오는 PULL 모델
    • 데이터를 처리한 후 소비자가 대기열에서 삭제하여 다른 소비자가 읽을 수 없도록 함
    • 소비자의 수에는 제한 X
    • 관리형 서비스이기  때문에 처리량을 프로비저닝할 필요 X
    • FIFO 대기열을 사용해야 순서 보장 가능
    • 메시지에 지연 기능  존재
  • SNS
    • 게시/구독 모델로 다수의 구독자에게 데이터를 푸시하면 메시지의 복사본을 수신
    • SNS 주제별로 12,500,000 구독자를 가질 수 있음
    • 데이터가 SNS에 전송되면 지속되지 않음(제대로 전달되지 않을 경우 데이터 손실 가능)
    • 100,000 개의 주제로 확장 가능
    • 처리량을 프로비저닝할 필요 X
    • SQS와 결합하여 팬아웃 아키텍쳐 패턴 사용 가능
    • SNS FIFO 주제를 SQS FIFO 대기열과 결합 가능
  • Kinesis
    • Standard: 소비자가 Kinesis로부터 데이터를 가져옴(PULL), 샤드당 2mb/s
    • Enhanced-fan out: Kinesis가 소비자에게 데이터 푸시 샤드 하나에 소비자당 2mb/s
    • Kinesis데이터 스트림에서는 데이턱가 지속되긱 때문에 데이터를 다시 재생할 수 있음
    • 실시간 빅데이터 분석, ETL등에 사용
    • n 일 후에 데이터 만료
    • 프로비저닝 모드 / 온디멘드 용량 모드

5. Amazon MQ

  • SQS, SNS는 AWS의 고유한 프로토콜로 클라우드 네이티브 서비스이다. 각자 사용하는 API SET가 따로 있음
  • 온프레미스에서 실행되는 전통적인 애플리케이션은 MQTT, AMQP, STOMP, Openwire, WSS 등의 오픈 프로토콜 사용 가능
  • 애플리케이션을 클라우드에 마이그레이션 하는 경우에는 SQS, SNS 프로토콜 혹은 API를 사용하도록 애플리케이션을 재구성하는 대신 MQTT, AMQP와 같이 기존에 쓰던 애플리케이션을 이용하고 싶을 때 Amazon MQ 사용
  • RabbitMQ, ActiveMQ를 위한 관리형 메시지  브로커 서비스
  • SQS, SNS 만큼 확장성이 크지 않음
  • 서버에서 실행되며, 장애 조치를 위해 Multi-AZ에서 실행 가능
  • SQS와 유사한 대기열 기능 및 SNS와 유사한 주제 기능이 모두 제공
반응형
LIST
저작자표시