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

Amazon SQS - 표준 Queues 개요

• 간단한 대기 서비스
• SQS에 보내면 FIFO로 할 경우 순서대로 소비자가 받은 후 메세지를 삭제
  • FIFO로 안하면 순서를 보장 할 수 없음
• 무제한 처리량을 얻을 수 있음
• 만약 메세지가 소비자가 늦게 처리하면 처리 속도를 늘려야함
  • 처리 속도를 안늘리면은 다른 소비자가 받기에 중복으로 처리가 될 수도 있음
• SQS는 ASG가 이미 되어있음
  • 하지만 EC2는 ASG가 되어있어도 CloudWatch를 통해 알람을 보내 EC2의 ASG를 확장, 축소 시킬 수 있음

SQS - 메시지 가시성 시간 초과

• 소비자가 메세지를 폴링하면 이 메세지는 다른 소비자들에게 안보임
  메시지 가시성 시간 초과 기본값은 30초
  • 30초가 넘으면은 다른 소비자나 동일한 소비자가 또 받게 됨
  • 메시지가 2번 처리가 되는 것임
• 만약 시간이 더 필요하면 ChangeMessageVisibilty API를 사용해서 시간을 늘릴 수 있음

SQS - 롱 폴링

• 대기열에 아무것도 없을때 메시지 도착을 기다리는 것
• 이렇게 하는 이유는 2가지
  • 1번째
    • 지연시간을 줄이기 위해서
  • 2번째
    • SQS로 보내는 API 호출 숫자를 줄이기 위해서
• 롱 폴링을 구성하는 방법은 2가지
  • 1번째
    • 대기열 레벨에서 구성하여 폴링하는 아무 소비자로부터 롱 폴링 활성화
  • 2번째
    • WaitTimeSeconds를 지정하여 소비자가 스스로 롱 폴링 활성화

SQS - FIFO Queues

• FIFO는 선입선출 자료구조 Queue랑 일치함
• 중복을 제거해주는 SQS FIFO 대기열 기능이 있어서 메시지를 한 번만 보낼 수 있음
• SQS로 너무 많은 메시지를 안보내게 처리량에 제한을 할 수 있음
• 선입선출 방식이기에 메시지 순서가 유지 가능
  
  • 이름에 .fifo를 꼭 넣어야함

SQS + 오토 스케일링 그룹

• SQS의 길이를 가져올수있는 CloudWatch가 있음
  • CloudWatch Metric -Queue Length
    ApproximateNumberOfMeesages
• CloudWatch Alarm에서 해당 길이로 알람을 보내서 ASG 축소, 확장이 가능
• 예시
  • 대대적인 세일 행사를 진행, 수 많은 고객이 주문 할 예정임
  • RDS에 애플리케이션이 직접 요청을 넣을텐데
    • 이러면은 특정 트랜잭션에 오류가 발생했을때 트랜잭션이 유실이 됨
  • 그래서 SQS를 버퍼로 사용하면은 오류가 발생해도 계속 소비자를 찾기때문에 트랜잭션이 유실이 안됨

Amazon Simple Notification Service (AWS SNS)

• 메시지 하나를 여러 수신자에게 보낼때 사용
  • 통합 개념
  • 예시 - 구매 서비스 애플리케이션
    • 이메일 알림
    • 사기 탐지 서비스
    • 배송 서비스
    • SQS 대기열
    • 메시지를 보낼때 수신 서비스를 새로 추가할때마다
      통합을 생성하고, 작성해야함
    • 대신 Pub/Sub을 사용하여서 SNS 주제로 전송이 가능하다.
      • SNS Topic
        • 이메일 알림
        • 사기 탐지 서비스
        • 배송 서비스
        • SQS 대기열
    • 위와 같은 구조로 SNS Topic가 알아서 보내는 개념

SNS 및 SQS - 팬아웃 패턴

• 메시지를 여러 SQS 대기열을 보내고 싶은데 모든 SQS 대기열에 개별적으로 보내면 문제 발생 가능
  • 예시
    • 애플리케이션이 중간에 비정상적으로 종료, 전달에 실패
    • SQS 대기열이 더 추가 됨
• SNS 주제에 메시지를 전송 한 후 원하는 수의 SQS 대기열이 SNS 주제를 구독하는게 팬아웃 패턴
• 구매 서비스
  • SNS Topic
    • SQS Queue 1번
      
      • 결제 서비스
    • SQS Queue 2번
      • 쇼핑 서비스
• 위 처럼 구매 서비스에서 SNS Topic에 메시지를 던지고 각자의 SQS 대기열에서 메시지를 읽게 하는 것
• 리전 간 전달도 가능
• SNS FIFO 가능
  • 메시지 그룹 ID에 따라 순서를 매기고
  • 중복 제거 ID를 활용해 중복 데이터 제거
  • SNS FIFO는 SQS FIFO만 사용이 가능, FIFO 대기열이 동일해서 가능
• 필터링 정책 기능
  • SNS Topic에 메시지가 State:Placed이면 필터링 정책을 사용하여
  • 발주된 데이터만 SQS 대기열에만 넣을 수 있음
  • SNS Topic에 메시지가 State:Cancle이면 필터링 정책을 사용하여
  • 취소된 데이터만 SQS 대기열에 넣을 수 있음

Amazon Kinesis 개요

• 실시간 스트리밍 데이터를 손쉽게 수집하고 처리하여 분석 가능
• 실시간 데이터 종류
  • 애플리케이션 로그
  • 계측
  • 웹 사이트 클릭 스트림
  • IoT 원격 측정 데이터 등
  • 어떤 것도 포함됨
• 데이터가 빠르게 실시간으로 생성되면 모두 실시간 데이터 스트림임
• Kinesis는 네 가지 서비스로 구성되어있음
  • Kinesis Data Stream
  • Kinesis Data Firehose
  • Kinesis Data Analytics
  • Kinesis Video Stream

Kinesis Data Stream 개요

• 큰 규모의 데이터 흐름을 다루는 서비스
• 샤드로 구성되어 있음
  • 샤드는 데이터 수집률이나 소비율 측면에서 스트림의 용량을 결정
• 생산자는 데이터를 Kinesis Data Stream으로 보냄
  • 생산자는 매우 다양함
    • 애플리케이션
    • 데스크톱
    • 휴대전화
    • 클라이언트
    • 매우 낮은 수준에서 AWS SDK 활용
    • 더 높은 수준에서 Kinesis Producer Library (KPL)
  • 레코드
    • 근본적으로 두 가지 요소 구성됨
      • 파티션 키와 최대 1MB 크기의 데이터 블롭으로 구성 됨
      • 파티션 키: 레코드가 이용할 샤드를 결정하는데 사용
      • 데이터 블롭: 값 자체를 의미
• Kinesis Stream에서 서버리스로 처리 할 경우
  • Lambda 함수 사용 가능
• 정리: 생산자 -> Kinesis Data Stream -> 소비자
• Kinesis는 들어오면 삭제 불가능
  • 이러한 특징은 불변성이라고 함
• 같은 샤드로 들어가면 키를 기반으로 데이터 정렬 가능
• 프로비저닝
  • 샤드 수를 정할수 있음, API를 활용하거나 수동으로 조정
  • 샤드는 각 샤드마다 초당 1MB나 1천 개의 레코드를 받을 수 있음
  • 출력은 각 샤드마다 초당 2MB
• 온디맨드
  • 프로비저닝을 하거나, 용량을 관리 할 필요가 없음
  • 시간에 따라 언제든 용량 조정 가능
  • 기본적으로 초당 4MB 또는 초당 4천개의 레코드 처리
  • 30일 동안 관측한 최대 처리량에 기반하여 자동으로 조정
• 모든 요청은 ColudTrail로 감시 가능

Kinesis Data Firehose 개요

• 생산자에서 데이터를 가져올 수 있는 유용한 서비스
  생산자는 Kinesis Data Stream에서 본 무엇이든 됨
• 생산자
  • 애플리케이션
  • 클라이언트
  • SDK
  • KPL
  • Kinesis Agent
  • AWS IoT
  • CloudWatch
  • Kinesis Dta Stream
  • 모두 Kinesis Data Firehose로 생산 가능
• 데이터 전송하면 Kinesis Data Firehose는 람다 기능 활용해서
  데이터 변환할지 선택이 가능
• Kinesis Data Firehose 수신처
  • AWS 수신처
    • 아마존 S3, 모든 데이터를 아마존 S3에 쓸 수 있음
    • Kinesis Data Firehose 복사 명령어 보냄
    • S3의 데이터를 아마존 레드시프트로 복사
  • Amazon ElasticSearch
  • 써드 파티 파트너 수신처
    • 데이터독
    • 스플렁크
    • 뉴렐릭
    • 몽고DB
  • 데이터가 수신처로 전송 후 2가지의 옵션이 있음
    • 모든 데이터 백업으로 S3 버킷으로 보냄
    • 실패 데이터는 실패 S3 버킷으로 보냄
• 정리
  • Kinesis Data Firehose는 완전 관리되는 서비스
    관리가 필요하지 않음
    자동으로 용량 크기 조정
    서버리스므로 관리 할 서버가 없음
• 근 실시간 서비스임
  • 최소 60초의 지연시간이 발생하거나
  • 데이터를 수신처에 보내는데 적어도 1MB 데이터의 버퍼가 차야함
  • 그래서 실시간 서비스 -> 실시간에 가까운 서비스
• 데이터 스토리지가 없어 Kinesis Data Firehose 데이터는 반복하는 기능 지원 안함
• Kinesis Data Stream은 반복하는 기능 지원함 데이터 스토리지가 있어서

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

• Kinesis와 SQS FIFO가 어떻게 데이터를 정렬되는지?
  • 예시 상황
    
    • 트럭이 100개가 있음
    • 트럭 ID가 각자 있음
    • GPS 위치를 주기적으로 AWS에 보냄
    • 트럭의 순서대로 데이터를 소비 후 트럭 이동 위치 추적
  • Kinesis
    • 트럭이 5개가 있다면은
    • 트럭 1의 GPS 데이터를 보낼 때, Kinesis로 트럭 1의 파티션 키를 해시함
      • 계산을 하여서 샤드 1번으로 간다는 걸 아는거임
    • 트럭 2, 3, 4..도 위와 같이 파티션 키 해시 후 데이터를 넣음
    • 이렇게 재분할 하는것을 파티션이라고 함, 그래서 파티션 키
    • 이 후 샤드 레벨에서 각 트럭의 순서에 따른 데이터를 얻을 수 있음
  • SQS
    • SQS 표준에는 순서가 없음
    • SQS FIFO라는 선입 선출에 순서가 있음
    • SQS FIFO 그룹 ID를 사용하지 않으면은 모든 메시지가 소비되는 방식은 보내진 순서에 따름
      소비자는 하나만 존재함
    • 만약 소비자 숫자를 스케일링하고 서로 연관된 메시지를 그룹화 할려면
      그룹 ID를 사용 할 수 있음
    • 그룹 ID
      • Kinesis 파티션 키와 개념이 비슷
      • 그룹 ID 사용하면 FIFO 대기열은 내부에 두 개 그룹이 생김
      • 정의한 그룹마다 소비자를 가짐
        • 그룹 2개가 있으면, 소비자 2개가 있으면
          독자적으로 그룹1, 2를 읽을 수 있음
        • 그룹ID가 많을수록 소비자도 많아짐
  • SQS vs Kinesis 트럭 100개
    • Kinesis 
      • Kinesis는 샤드 5개일 경우
      • 샤드 마다 20개의 트럭의 정보가 저장 됨
      • 샤드가 5개이기에 샤드마다 하나의 소비자가 필요함
      • 예로 트럭 10,000대가 많은 데이터를 전송, 정렬 할 때 쓰기 좋음
    • SQS FIFO
      • 대기열은 하나 뿐임
      • 트럭 100개니깐 그룹 ID 100개 생성해야함, 소비자도 최대 100개
      • SQS FIFO는 그룹 ID 숫자에 따른 동적 소비자 수를 원할 때 쓰는게 좋음

SQS vs SNS vs Kinesis

• SQS
  • 소비자가 SQS 대기열에서 요청해서 데이터를 가져오는 (Pull) 모델
  • 데이터 처리 후 소비자가 대기열에서 삭제해야지 다른 소비자가 못읽음
  • 관리된 서비스이므로 처리량 프로비저닝 할 필요 없음
  • 순서 보장할려면 FIFO 대기열 활성화
  • 지연 기능 있어서 대기열에 일정 시간 뒤 나타나게 가능
• SNS
  • 게시 / 구독 (Pub / Sub) 모델
  • 다수의 구독자에게 데이터를 푸시하면 메시지 복사본을 받음
  • 데이터가 한 번 SNS에 전송하면 지속되지 않음
    • 제대로 전달 안되면 잃을 가능성 있음
  • 처리량 프로비저닝 안해도됨
  • SQS 결합 가능
  • 팬아웃 아키텍처 패턴 사용하면
    • SNS와 SQS 결합
    • SNS FIFO와 SQS FIFO 대기열과 결합
• Kinesis
  • 2가지 소비 모드가 있음
  • 샤드당 출력 2MB 속도 지원
  • 향상된 팬아웃 유형 소비 매커니즘
    • Kinesis가 소비자에게 데이터 푸시
    • 샤드 하나에 소비자당 2MB 속도 나옴
      • 처리량이 훨씬 높음
    • Kinesis Stream 더 많은 애플리케이션 읽기 가능
    • Kinesis Data Stream 데이터가 지속돼서 다시 재생 가능
    • 따라서 실시간 빅 데이터 분석, ETL 등 활용
  • 용량 모드 2가지 있음
    • 프로비저닝
      • 원하는 사드 양을 미리 지정
    • 온디맨드
      • 샤드 수가 Kinesis 데이터 스트림에 따라 자동으로 조정

Amazon MQ

• SQS와 SNS는 AWS 독점 기술이기에 클라우드 네이티브 서비스임
• 각자 사용하는 API 세트가 따로 있음
• 온프레미스에서 기존 애플리케이션을 실행하는 경우
  • 개방형 프로토콜
    • MQTT
    • AMQP
    • STOMP
    • WSS
    • Openwire
    • 등
• 애플리케이션을 클라우드에 마이그레이션 할 때 SQS, SNS 프로토콜, API 사용 하기 위해
  애플리케이션을 기존에 쓰던 개방형 프로토콜 쓰고싶을때 Amazon MQ 사용
  • RabbitMQ
  • ActiveMQ
• 위 2개로 관리형 메시지 브로커사용 가능
• 고가용성 안좋음, 서버에서 실행돼서 서버 문제가 있을 수 있음
• EFS 네트워크 파일 시스템으로 다중 가용 영역 마운트로 설정해서
• 장애 조치가 일어날때마다 활성 대기열과 동일한 데이터를 가짐