이 글은 24년 하반기 AWS Certified Solutions Architect - Associate(이하 AWS SAA-C03) 자격증 취득을 위해서 아래 유데미 강의를 보고, 공부한 내용을 정리하였습니다.
https://www.udemy.com/course/best-aws-certified-solutions-architect-associate
메시징
- 여러개의 애플리케이션을 배포할 때, 서로가 통신할 방법이 필요함
구분
- 동기 : 직접적으로 연결, 트래픽이 늘면 동기일 때 문제가 될 수 있음
- 비동기 / 이벤트기반 : 직접적으로 소통 X
서비스 종류
- SQS : 대기열 모델
- SNS : pub/sub 모델
- Kinesis : 실시간 스트리밍, 대용량 데이터
SQS
표준 큐 개요
- SQS 대기열에는 메시지가 들어감... 큐는 생산자와 소비자를 분리하는 버퍼 역할
- 생산자(Producer) : SQS 대기열에 메시지를 보내는 주체, 여러개 가능
- 소비자(Consumer) : 메시지를 폴링(수신) 하는 대상
표준 대기열용 SQS
- AWS에서 가장 오래된 서비스
- 완전관리형 서비스로 애플리케이션을 분리하는데 사용
특징
- 무제한 처리량을 얻을 수 있음, 처리량과 대기열에 있는 메시지 수에 제한이 없음
- 각 메시지는 수명이 짧음(기본 4일, 최대 14일)
- 기간 내에 소비하고 삭제해야하는데, 안쓰면 소실됨
- 지연시간 짧음 10ms 미만
- 메시지 당 256KB 제한
- 중복 메시지가 있을 수 있음(적어도 한 번의 전송)
- 최선의 오더 메시지를 보냄(품절된 메시지를 보낼 수도 있음)
생산자
- SDK를 사용해서 메시지를 보냄(SendMessage API)
- 메시지에는 주문 ID, 소비자 ID, 기타 속성이 포함됨
소비자
- EC2 인스턴스, 온프레미스 서버, 람다 함수 등에서 읽어감
- 소비자는 SQS 메시지를 폴링함(자기 앞으로 온 메시지가 있는지 질의, 한번에 최대 10개의 메시지를 받음)
- 소비자는 메시지 처리 후 DeleteMessage API로 대기열에서 삭제
- 소비자는 수평 확장을 해서 처리량을 개선할 수 있음
- ASG와 조합이 좋음 (대기열의 길이로 CloudWatch 알람을 설정해서 스케일링)
아키텍처 예시
요청 - 프론트엔드 ASG - SQS로 SendMessage - 백엔드 프로세싱 어플리케이션 ASG에서 polling - S3 넣기
SQS 보안
- 전송 중 암호화 HTTPS API
- KMS key로 암호화
- 클라이언트 측 암호화
- Access Controls : IAM 정책
- SQS 액세스 정책 : S3 정책과 유사함
`메시지 가시성 시간 초과
- 소비자가 메시지를 폴링하면 다른 소비자들에게 보이지 않게됨
- 기본적으로 '가시성 시간 초과'는 30초로 30초 동안 처리되어야한다는 뜻, 이 동안은 다른 소비자들은 못봄
- 이 시간이 지나면 다시 대기열에 메시지를 넣음(즉, 2번 처리될 수도 있는 것)
- 소비자가 이 메시지를 처리하는데 시간이 더 필요한 걸 알고 있다면, 'ChangeMessageVisibility API'를 호출해서 시간을 더 얻을 수 있음
롱 폴링
*롱 폴링 : 소비자가 대기열에 메시지를 요청했는데 아무것도 없다면 대기하게 됨
- 목적 : 지연 시간 줄이기
- 1~20초로 구성가능.. 길수록 좋음
구성방법
1. 대기열 레벨에서 구성하여 폴링하는 아무 소비자로부터 롱 폴링 활성화
2. 소비자가 스스로 WaitTimeSeconds를 지정하여 롱 폴링하도록 선택 가능
FIFO 큐
- 선출선입.. 순서가 확실하게 보장됨, 소비자가 정확히 동일한 순서로 메시지를 받게해줌
- 처리량에 한계가 있음.. 묶음이 아닐 때 300msg/s, 묶음일 때 3000msg/s
- 중복을 제거하여 정확히 한번만 보냄
- 이름에 .fifo를 붙여야함
SQS+ASG
- SQS+ASG 조합에서 ASG 內 EC2에서 메시지를 폴링함
- 대기열 크기에 따라 스캐일링을 하기 위함
`- 사례 : 수많은 주문을 DB에 저장할 때, 빠른 속도로 쓰여야하는데, SQS를 버퍼로 쓸 수 있음
ㄴ 앞뒤로 ASG를 넣어서 쓰기 속도를 조정하고, 안정적으로 DB에 쓸 수 있음.. 쓰기가 성공한걸 확인하고, 큐에서 지우면 되기 때문에 확인작업도 가능함
`- 사례2 : 디커플링 어플리케이션 티어... 프론트 - SQS - 백엔드
SNS
- 메시지 하나를 여러 수신자에 보낼 때, 직접 통합을 쓸 수 있음..
- Pub / Sub (게시/구독) 패턴을 써서 해결 가능
- 메시지를 SNS 주제로 게시 -> 주제에는 많은 구독자가 있음 -> SNS 주제에서 해당 메시지를 수신
Amazon SNS
- 이벤트 생산자는 오직 한 SNS 주제(topic)에만 메시지를 보냄
- 이벤트 소비자(구독자)는 알람을 받으려는 사람... 해당 주제로부터 모두 메시지를 받음
- 주제별로 최대 1,200만 이상의 구독자 가능, 계정당 10만개 주제 가능
`- 구독자 : 이메일, SMS, 모바일 알람, HTTPS 엔드포인트, SQS, 람다, Kinesis Data Firehose
- 생산자 : AWS에서 알람이 발생할 만한 거
- SDK로 주제 배포 : 주제 생성 - 구독 생성 - SNS 주제에 게시
- 모바일앱 SDK로 직접 배포 : 플랫폼 애플리케이션 - 플랫폼 엔드포인트 - 플랫폼 엔드포인트에 게시
ㄴ Google, GCM, Apple ARNS, Amazon ADM
- 보안 : 전송 중 보안(https), KMS 키, 클라이언트 측 암호화
- 액세스 제어 : IAM 정책 중심
- SNS 액세스 정책 : S3 정책과 유사함
Fan Out(팬아웃) 패턴
- 다수의 SQS 대기열로 메시지를 보내려할 때, 개별적으로 전송하지 않고, SNS 토픽으로 한 번 메시지를 전송하고, SQS 큐들을 메시지를 받는 구독자로 두는 것
- 완전히 분리된 모델, 데이터 손실없음
- SQS로 데이터 지속성, 지연 처리, 작업 재시도 효과
- 필요에 따라 SQS 대기열을 SNS 주제의 구독자로 더 추가 가능
- SQS 대기열 접근 정책을 SNS 토픽이 '쓰기' 할 수 있도록 허용해둬야함
- 교차 리전 배송 : 한 리전의 SNS 토픽이 다른 리전의 SQS 대기열에 메시지를 보내는 것
- 사례 : S3 이벤트(접두사에 따라 한 개의 이벤트 규칙만 가능함) 를 여러 대기열로 보낼 때, 이벤트를 SNS 주제로 보내고, 여러 대기열이 팬 아웃 패턴으로 구독하게 하면 됨
- 사례2 : Kinesis Data Firehose로 SNS에서 S3로 직접 데이터를 보낼 수 있음.. SNS가 KDF와 직접적으로 통합되어 있기 때문에 SNS-KDF-S3 가능
FIFO 주제
- 순서대로, 중복제거 가능, SQS FIFO 큐와 통합하여 사용
- SQS FIFO와 동일한 처리량
메시지 필터링
- JSON 필터링 정책 적용 가능
- 각각의 구독자에 특정 메시지만 들어가도록 필터링 가능
`Kinesis
- 실시간 스트리밍 데이터를 손쉽게 수집하고, 처리하여 분석 가능
ㄴ 실시간 데이터 : 애플리케이션 로그, 계측, 웹사이트 클릭 스트림, IoT 원격 측정 데이터...
4가지로 구성됨
1. Kinesis Data Streams : 데이터 스트림을 수집하여 처리하고 저장
2. Kinesis Data Firehose : 데이터 스트림을 AWS 내부/외부의 데이터 저장소로 읽어드림
3. Kinesis Data Analytics : SQL 언어나 Apache Flink를 활용하여 데이터 스트림 분석
4. Kinesis Video Stream : 비디오 스트림 수집,처리,저장 (시험X)
Kinesis Data Streams
- 시스템에서 큰 규모의 데이터 흐름을 다루는 서비스
- 여러개의 샤드로 구성(1~N번까지 번호가 매겨짐.. 사전에 프로비저닝)
- 데이터는 모든 샤드에 분배됨
- 샤드는 데이터 수집률이나 소비율 측면에서 스트림 용량을 결정
성능
- 생산자는 레코드를 전달함 (레코드는 파티션 키(이용할 샤드 결정)와 최대 1MB의 데이터 블롭(값 자체)으로 구성)... 샤드 당 1MB/s 혹은 1000메시지/s 를 전달가능
- 소비자는 레코드를 받음 (파티션 키, 시퀀스 번호(샤드에서의 위치 정보), 데이터 블롭으로 구성)... 2MB/s로 모든 소비자가 공유 혹은 소비자마다 샤드당 2MB/s 받기 가능
특징
- 보존 기간은 1일~365일... 데이터를 다시 처리하거나 확인 가능
- 불변성, 한번 Kinesis로 데이터가 들어오면 삭제할 수 없음
- 데이터 스트림으로 메시지를 전송하면 파티션 키가 생기는데, 파티션 키가 같으면 같은 샤드로 들어가서 키를 기반으로 데이터 정렬 가능
사용 방법
- 생산자는 SDK, KPL(Kinesis Producer Library), Kinesis Agent로 데이터 전송 가능
- 소비자는 KCL, SDK로 직접 작성 / 람다, Kinesis Data Firehose, Kinesis Data Analytics 활용도 가능
용량 유형
1. 프로비저닝 유형
- 프로비저닝할 샤드 수를 정하고, API로 수동 조절
- 각 샤드는 초당 1MB 혹은 1,000개 레코드 받고, 초당 2MB 출력 가능
- 샤드를 늘리면 비용 발생
2. 온디멘드 유형
- 시간에 따라 용량이 조정됨
- 기본적으로 초당 4MB 혹은 4,000개의 레코드 처리
- 30일 동안 관측한 최대 처리량에 기반하여 자동으로 조정됨
- 시간당 스트림당 송수신 데이터양에 따라 비용 발생
보안
- IAM 정책으로 샤드를 생성하거나 샤드에서 읽는 권한 제어 가능
- HTTPS 전송중 암호화
- KMS 미사용 데이터 암호화
- 클라이언트 측 암호화
- VPC 엔드포인트를 쓸 수 있어서, 프라이빗 서브넷 인스턴스에서 접근 가능
- API 요청을 CloudTrail로 감시 가능
Kinesis Data Firehose
- 생산자로부터 레코드를 받고, 원한다면 람다함수로 데이터를 변환하여, 일괄적으로 작성(소비)함
`- 수신처 : S3, RedShift(웨어하우징 데이터베이스.. S3에 먼저 작성하고 복사 명령이 실행됨), OpenSearch
ㄴ 서드파티도 가능 : datadog, splunk, mongoDB...
ㄴ HTTP 엔드포인트가 있는 커스텀 수신처
특징
- 완전 관리형, 자동 스케일링, 서버리스
- 데이터를 AWS 수신처로 보낼 수 있고, 타사 파트너나 HTTP 엔드포인트로 보낼 수 있음
- Firehose를 통과하는 데이터에 대해서만 비용 지불
- 거의 실시간으로 동작
- 버퍼 인터벌을 0초~900초로 설정 가능, 버퍼 크기도 1MB 이상 설정해야함
* 버퍼 : 대상을 전송하기 전에 쌓아놓는 기능.. 버퍼 차면, 한번에 모아보내기
- 여러 데이터 형식과 전환, 변환, 압축 지원
- 실패한 모든 데이터를 S3 백업 버킷으로 보낼 수 있음
`KDS vs KDF
KDS
- 대규모 데이터를 수집하는데 사용되는 스트리밍 서비스
- 생산자와 소비자를 위한 사용자 지정 코드를 직접 작성
- 실시간(~200ms)
- 스케일링 관리(샤드 분할/병합)
- 프로비저닝한 용량에 따라 비용 지불
- 1~365일 동안 데이터 저장
- 여러 소비자가 동일 스트림에서 읽을 수 있게하며, 재사용 지원
KDF
- 수집 서비스로 데이터를 S3, RedShift, OpenSearch, 서드파티, HTTP로 스트리밍
- 완전관리형, 서버리스
`- 근 실시간
- 자동 스케일링
- KDF를 통과하는 것만 비용 지불
- 데이터 스토리지 없어서, 리플레이는 불가
Kinesis와 SQS FIFO에서 정렬 원리
Kinesis
- 파티션 키를 이용.. 같은 파티션 키를 지정하면 해당 키가 항상 동일한 샤드로 전달
- 파티션 키가 직접 샤드에 연결된건 아니고, 파티션 키를 해시해서 어느 샤드로 보낼지 결정됨
SQS
- SQS 스탠다드는 순서가 없고, SQS FIFO만 순서가 있음
- 그룹 ID를 쓰지 않으면, 메시지는 보내진 순서대로 소비되고, 소비자는 하나만 존재
- 소비자 수를 늘리려면 그룹 ID를 사용해야함.. 정의한 그룹마다 소비자를 가짐
`차이점
100개의 메시지, 5개의 kinesis 샤드, 1개 SQS FIFO 일 때...
Kinesis
- 샤드당 20개 메시지를 가짐.. 메시지는 각 샤드에 순서대로 정렬
- 최대 소비자 개수 5개 뿐... 샤드마다 하나의 소비자가 필요하기 때문
- 초당 최대 5MB 데이터 수신
SQS FIFO
- 각 트럭 ID에 상응하는 그룹 ID 100개 생성 가능
- 소비자도 최대 100개가 될 수 있음
- 초당 300개.. 배치를 쓰면 3,000개의 메시지를 가짐
SQS vs SNS vs Kinesis
SQS
- 소비자가 대기열에 메시지를 요청해서 데이터를 가져오는(pull) 모델
- 데이터 처리 후 소비자가 대기열에서 삭제해야함
- 작업자나 소비자 수는 제한이 없음
- 관리된 서비스, 처리량 프로비저닝할 필요 없음
- FIFO 큐를 쓰면 순서 보장 가능
- 각 메시지에 지연 기능으로 일정 시간 뒤에 대기열에 나타나게 할 수 있음
SNS
- 게시/구독 모델, 다수의 구독자에게 데이터를 푸시하면 메시지의 복사본을 받게됨
- 주제별로 1,250만 명의 구독자까지 가능
- 데이터가 한 번 SNS에 전송되면 지속되지 않음(제대로 전달되지 않으면 데이터 유실)
- 최대 10만 개의 주제로 확장 가능
- 처리량 프로비저닝 필요 없음
- 필요에 따라 SQS와 결합하여 팬 아웃 패턴 쓸 수 있음
Kinesis
- 두 가지 소비 모드
1. 표준 모드 : 소비자가 Kinesis로부터 데이터 가져옴
- 샤드당 2MB
2. 향상된 팬 아웃 모드 : 소비자에게 데이터를 푸시
- 샤드 당 소비자 당 2MB (더 처리량 많음, Kinesis 스트림에서 더 많은 애플리케이션 읽기 가능)
- Kinesis 데이터 스트림에선 데이터가 지속됨(리플레이 가능)
- 실시간 빅데이터 분석, ETL 등에 활용
- 샤드레벨에서 순서보장 가능
- 미리 Kinesis 데이터 스트림마다 원하는 샤드 양을 지정해야함
- 샤드를 직접 확장해서 데이터가 언제 만료될지 정해야함(1~365일)
- 두 가지 용량 모드
1. 프로비저닝 용량 모드 : Kinesis 데이터 스트림으로부터 원하는 샤드 양 미리 지정
2. 온디맨드 용량 모드 : 샤드 수가 자동으로 조정됨
Amazon MQ
- SQS, SNS는 AWS의 독점 기술.. 클라우드 네이티브 서비스임 -> 각자 API 형식 있음
- 온프레미스에서 기존 애플리케이션을 실행하는 경우 개방형 프로토콜인 MQTT, AMQP, STOMP, Openwire 등을 사용할 수 있음
- 클라우드에 마이그레이션할 때는, SQS/SNS 프로토콜 혹은 API를 기존에 온프레미스에서 쓰던 프로토콜과 연결하기 위해 Amazon MQ를 쓸 수 있음
Amazon MQ란
- RabbitMQ와 ActiveMQ 두 가지 기술을 위한 관리형 메시지 브로커 서비스
ㄴ 온프레미스 기술로 개방형 프로토콜 액세스를 제공함
- Amazon MQ는 확장성이 크지는 않음(SQS/SNS는 무한확장)
- Amazon MQ는 서버에서 실행되기에 서버 문제가 있을 수 있기 때문
- 고가용성, 페일오버를 위해 다중 AZ 설정 가능
- SQS와 같은 단일 큐 기능과 SNS처럼 보이는 주제 기능을 단일 브로커의 일부로 제공함
`MQ의 고가용성
- 각 AZ에 Amazon MQ 브로커 추가(Active-StandBy 상태)
- 장애 조치를 위한 백엔드 스토리지로 EFS 정의(다중 AZ에 마운트)
- 클라이언트는 Active 브로커를 바라보다가 문제가 생기면 StandBy쪽으로 페일오버 되는데 이때 EFS로 네트워크 파일 공유를 하고 있기에 유실없이 사용 가능
'인프라 > AWS' 카테고리의 다른 글
이 글은 24년 하반기 AWS Certified Solutions Architect - Associate(이하 AWS SAA-C03) 자격증 취득을 위해서 아래 유데미 강의를 보고, 공부한 내용을 정리하였습니다.
https://www.udemy.com/course/best-aws-certified-solutions-architect-associate
메시징
- 여러개의 애플리케이션을 배포할 때, 서로가 통신할 방법이 필요함
구분
- 동기 : 직접적으로 연결, 트래픽이 늘면 동기일 때 문제가 될 수 있음
- 비동기 / 이벤트기반 : 직접적으로 소통 X
서비스 종류
- SQS : 대기열 모델
- SNS : pub/sub 모델
- Kinesis : 실시간 스트리밍, 대용량 데이터
SQS
표준 큐 개요
- SQS 대기열에는 메시지가 들어감... 큐는 생산자와 소비자를 분리하는 버퍼 역할
- 생산자(Producer) : SQS 대기열에 메시지를 보내는 주체, 여러개 가능
- 소비자(Consumer) : 메시지를 폴링(수신) 하는 대상
표준 대기열용 SQS
- AWS에서 가장 오래된 서비스
- 완전관리형 서비스로 애플리케이션을 분리하는데 사용
특징
- 무제한 처리량을 얻을 수 있음, 처리량과 대기열에 있는 메시지 수에 제한이 없음
- 각 메시지는 수명이 짧음(기본 4일, 최대 14일)
- 기간 내에 소비하고 삭제해야하는데, 안쓰면 소실됨
- 지연시간 짧음 10ms 미만
- 메시지 당 256KB 제한
- 중복 메시지가 있을 수 있음(적어도 한 번의 전송)
- 최선의 오더 메시지를 보냄(품절된 메시지를 보낼 수도 있음)
생산자
- SDK를 사용해서 메시지를 보냄(SendMessage API)
- 메시지에는 주문 ID, 소비자 ID, 기타 속성이 포함됨
소비자
- EC2 인스턴스, 온프레미스 서버, 람다 함수 등에서 읽어감
- 소비자는 SQS 메시지를 폴링함(자기 앞으로 온 메시지가 있는지 질의, 한번에 최대 10개의 메시지를 받음)
- 소비자는 메시지 처리 후 DeleteMessage API로 대기열에서 삭제
- 소비자는 수평 확장을 해서 처리량을 개선할 수 있음
- ASG와 조합이 좋음 (대기열의 길이로 CloudWatch 알람을 설정해서 스케일링)
아키텍처 예시
요청 - 프론트엔드 ASG - SQS로 SendMessage - 백엔드 프로세싱 어플리케이션 ASG에서 polling - S3 넣기
SQS 보안
- 전송 중 암호화 HTTPS API
- KMS key로 암호화
- 클라이언트 측 암호화
- Access Controls : IAM 정책
- SQS 액세스 정책 : S3 정책과 유사함
`메시지 가시성 시간 초과
- 소비자가 메시지를 폴링하면 다른 소비자들에게 보이지 않게됨
- 기본적으로 '가시성 시간 초과'는 30초로 30초 동안 처리되어야한다는 뜻, 이 동안은 다른 소비자들은 못봄
- 이 시간이 지나면 다시 대기열에 메시지를 넣음(즉, 2번 처리될 수도 있는 것)
- 소비자가 이 메시지를 처리하는데 시간이 더 필요한 걸 알고 있다면, 'ChangeMessageVisibility API'를 호출해서 시간을 더 얻을 수 있음
롱 폴링
*롱 폴링 : 소비자가 대기열에 메시지를 요청했는데 아무것도 없다면 대기하게 됨
- 목적 : 지연 시간 줄이기
- 1~20초로 구성가능.. 길수록 좋음
구성방법
1. 대기열 레벨에서 구성하여 폴링하는 아무 소비자로부터 롱 폴링 활성화
2. 소비자가 스스로 WaitTimeSeconds를 지정하여 롱 폴링하도록 선택 가능
FIFO 큐
- 선출선입.. 순서가 확실하게 보장됨, 소비자가 정확히 동일한 순서로 메시지를 받게해줌
- 처리량에 한계가 있음.. 묶음이 아닐 때 300msg/s, 묶음일 때 3000msg/s
- 중복을 제거하여 정확히 한번만 보냄
- 이름에 .fifo를 붙여야함
SQS+ASG
- SQS+ASG 조합에서 ASG 內 EC2에서 메시지를 폴링함
- 대기열 크기에 따라 스캐일링을 하기 위함
`- 사례 : 수많은 주문을 DB에 저장할 때, 빠른 속도로 쓰여야하는데, SQS를 버퍼로 쓸 수 있음
ㄴ 앞뒤로 ASG를 넣어서 쓰기 속도를 조정하고, 안정적으로 DB에 쓸 수 있음.. 쓰기가 성공한걸 확인하고, 큐에서 지우면 되기 때문에 확인작업도 가능함
`- 사례2 : 디커플링 어플리케이션 티어... 프론트 - SQS - 백엔드
SNS
- 메시지 하나를 여러 수신자에 보낼 때, 직접 통합을 쓸 수 있음..
- Pub / Sub (게시/구독) 패턴을 써서 해결 가능
- 메시지를 SNS 주제로 게시 -> 주제에는 많은 구독자가 있음 -> SNS 주제에서 해당 메시지를 수신
Amazon SNS
- 이벤트 생산자는 오직 한 SNS 주제(topic)에만 메시지를 보냄
- 이벤트 소비자(구독자)는 알람을 받으려는 사람... 해당 주제로부터 모두 메시지를 받음
- 주제별로 최대 1,200만 이상의 구독자 가능, 계정당 10만개 주제 가능
`- 구독자 : 이메일, SMS, 모바일 알람, HTTPS 엔드포인트, SQS, 람다, Kinesis Data Firehose
- 생산자 : AWS에서 알람이 발생할 만한 거
- SDK로 주제 배포 : 주제 생성 - 구독 생성 - SNS 주제에 게시
- 모바일앱 SDK로 직접 배포 : 플랫폼 애플리케이션 - 플랫폼 엔드포인트 - 플랫폼 엔드포인트에 게시
ㄴ Google, GCM, Apple ARNS, Amazon ADM
- 보안 : 전송 중 보안(https), KMS 키, 클라이언트 측 암호화
- 액세스 제어 : IAM 정책 중심
- SNS 액세스 정책 : S3 정책과 유사함
Fan Out(팬아웃) 패턴
- 다수의 SQS 대기열로 메시지를 보내려할 때, 개별적으로 전송하지 않고, SNS 토픽으로 한 번 메시지를 전송하고, SQS 큐들을 메시지를 받는 구독자로 두는 것
- 완전히 분리된 모델, 데이터 손실없음
- SQS로 데이터 지속성, 지연 처리, 작업 재시도 효과
- 필요에 따라 SQS 대기열을 SNS 주제의 구독자로 더 추가 가능
- SQS 대기열 접근 정책을 SNS 토픽이 '쓰기' 할 수 있도록 허용해둬야함
- 교차 리전 배송 : 한 리전의 SNS 토픽이 다른 리전의 SQS 대기열에 메시지를 보내는 것
- 사례 : S3 이벤트(접두사에 따라 한 개의 이벤트 규칙만 가능함) 를 여러 대기열로 보낼 때, 이벤트를 SNS 주제로 보내고, 여러 대기열이 팬 아웃 패턴으로 구독하게 하면 됨
- 사례2 : Kinesis Data Firehose로 SNS에서 S3로 직접 데이터를 보낼 수 있음.. SNS가 KDF와 직접적으로 통합되어 있기 때문에 SNS-KDF-S3 가능
FIFO 주제
- 순서대로, 중복제거 가능, SQS FIFO 큐와 통합하여 사용
- SQS FIFO와 동일한 처리량
메시지 필터링
- JSON 필터링 정책 적용 가능
- 각각의 구독자에 특정 메시지만 들어가도록 필터링 가능
`Kinesis
- 실시간 스트리밍 데이터를 손쉽게 수집하고, 처리하여 분석 가능
ㄴ 실시간 데이터 : 애플리케이션 로그, 계측, 웹사이트 클릭 스트림, IoT 원격 측정 데이터...
4가지로 구성됨
1. Kinesis Data Streams : 데이터 스트림을 수집하여 처리하고 저장
2. Kinesis Data Firehose : 데이터 스트림을 AWS 내부/외부의 데이터 저장소로 읽어드림
3. Kinesis Data Analytics : SQL 언어나 Apache Flink를 활용하여 데이터 스트림 분석
4. Kinesis Video Stream : 비디오 스트림 수집,처리,저장 (시험X)
Kinesis Data Streams
- 시스템에서 큰 규모의 데이터 흐름을 다루는 서비스
- 여러개의 샤드로 구성(1~N번까지 번호가 매겨짐.. 사전에 프로비저닝)
- 데이터는 모든 샤드에 분배됨
- 샤드는 데이터 수집률이나 소비율 측면에서 스트림 용량을 결정
성능
- 생산자는 레코드를 전달함 (레코드는 파티션 키(이용할 샤드 결정)와 최대 1MB의 데이터 블롭(값 자체)으로 구성)... 샤드 당 1MB/s 혹은 1000메시지/s 를 전달가능
- 소비자는 레코드를 받음 (파티션 키, 시퀀스 번호(샤드에서의 위치 정보), 데이터 블롭으로 구성)... 2MB/s로 모든 소비자가 공유 혹은 소비자마다 샤드당 2MB/s 받기 가능
특징
- 보존 기간은 1일~365일... 데이터를 다시 처리하거나 확인 가능
- 불변성, 한번 Kinesis로 데이터가 들어오면 삭제할 수 없음
- 데이터 스트림으로 메시지를 전송하면 파티션 키가 생기는데, 파티션 키가 같으면 같은 샤드로 들어가서 키를 기반으로 데이터 정렬 가능
사용 방법
- 생산자는 SDK, KPL(Kinesis Producer Library), Kinesis Agent로 데이터 전송 가능
- 소비자는 KCL, SDK로 직접 작성 / 람다, Kinesis Data Firehose, Kinesis Data Analytics 활용도 가능
용량 유형
1. 프로비저닝 유형
- 프로비저닝할 샤드 수를 정하고, API로 수동 조절
- 각 샤드는 초당 1MB 혹은 1,000개 레코드 받고, 초당 2MB 출력 가능
- 샤드를 늘리면 비용 발생
2. 온디멘드 유형
- 시간에 따라 용량이 조정됨
- 기본적으로 초당 4MB 혹은 4,000개의 레코드 처리
- 30일 동안 관측한 최대 처리량에 기반하여 자동으로 조정됨
- 시간당 스트림당 송수신 데이터양에 따라 비용 발생
보안
- IAM 정책으로 샤드를 생성하거나 샤드에서 읽는 권한 제어 가능
- HTTPS 전송중 암호화
- KMS 미사용 데이터 암호화
- 클라이언트 측 암호화
- VPC 엔드포인트를 쓸 수 있어서, 프라이빗 서브넷 인스턴스에서 접근 가능
- API 요청을 CloudTrail로 감시 가능
Kinesis Data Firehose
- 생산자로부터 레코드를 받고, 원한다면 람다함수로 데이터를 변환하여, 일괄적으로 작성(소비)함
`- 수신처 : S3, RedShift(웨어하우징 데이터베이스.. S3에 먼저 작성하고 복사 명령이 실행됨), OpenSearch
ㄴ 서드파티도 가능 : datadog, splunk, mongoDB...
ㄴ HTTP 엔드포인트가 있는 커스텀 수신처
특징
- 완전 관리형, 자동 스케일링, 서버리스
- 데이터를 AWS 수신처로 보낼 수 있고, 타사 파트너나 HTTP 엔드포인트로 보낼 수 있음
- Firehose를 통과하는 데이터에 대해서만 비용 지불
- 거의 실시간으로 동작
- 버퍼 인터벌을 0초~900초로 설정 가능, 버퍼 크기도 1MB 이상 설정해야함
* 버퍼 : 대상을 전송하기 전에 쌓아놓는 기능.. 버퍼 차면, 한번에 모아보내기
- 여러 데이터 형식과 전환, 변환, 압축 지원
- 실패한 모든 데이터를 S3 백업 버킷으로 보낼 수 있음
`KDS vs KDF
KDS
- 대규모 데이터를 수집하는데 사용되는 스트리밍 서비스
- 생산자와 소비자를 위한 사용자 지정 코드를 직접 작성
- 실시간(~200ms)
- 스케일링 관리(샤드 분할/병합)
- 프로비저닝한 용량에 따라 비용 지불
- 1~365일 동안 데이터 저장
- 여러 소비자가 동일 스트림에서 읽을 수 있게하며, 재사용 지원
KDF
- 수집 서비스로 데이터를 S3, RedShift, OpenSearch, 서드파티, HTTP로 스트리밍
- 완전관리형, 서버리스
`- 근 실시간
- 자동 스케일링
- KDF를 통과하는 것만 비용 지불
- 데이터 스토리지 없어서, 리플레이는 불가
Kinesis와 SQS FIFO에서 정렬 원리
Kinesis
- 파티션 키를 이용.. 같은 파티션 키를 지정하면 해당 키가 항상 동일한 샤드로 전달
- 파티션 키가 직접 샤드에 연결된건 아니고, 파티션 키를 해시해서 어느 샤드로 보낼지 결정됨
SQS
- SQS 스탠다드는 순서가 없고, SQS FIFO만 순서가 있음
- 그룹 ID를 쓰지 않으면, 메시지는 보내진 순서대로 소비되고, 소비자는 하나만 존재
- 소비자 수를 늘리려면 그룹 ID를 사용해야함.. 정의한 그룹마다 소비자를 가짐
`차이점
100개의 메시지, 5개의 kinesis 샤드, 1개 SQS FIFO 일 때...
Kinesis
- 샤드당 20개 메시지를 가짐.. 메시지는 각 샤드에 순서대로 정렬
- 최대 소비자 개수 5개 뿐... 샤드마다 하나의 소비자가 필요하기 때문
- 초당 최대 5MB 데이터 수신
SQS FIFO
- 각 트럭 ID에 상응하는 그룹 ID 100개 생성 가능
- 소비자도 최대 100개가 될 수 있음
- 초당 300개.. 배치를 쓰면 3,000개의 메시지를 가짐
SQS vs SNS vs Kinesis
SQS
- 소비자가 대기열에 메시지를 요청해서 데이터를 가져오는(pull) 모델
- 데이터 처리 후 소비자가 대기열에서 삭제해야함
- 작업자나 소비자 수는 제한이 없음
- 관리된 서비스, 처리량 프로비저닝할 필요 없음
- FIFO 큐를 쓰면 순서 보장 가능
- 각 메시지에 지연 기능으로 일정 시간 뒤에 대기열에 나타나게 할 수 있음
SNS
- 게시/구독 모델, 다수의 구독자에게 데이터를 푸시하면 메시지의 복사본을 받게됨
- 주제별로 1,250만 명의 구독자까지 가능
- 데이터가 한 번 SNS에 전송되면 지속되지 않음(제대로 전달되지 않으면 데이터 유실)
- 최대 10만 개의 주제로 확장 가능
- 처리량 프로비저닝 필요 없음
- 필요에 따라 SQS와 결합하여 팬 아웃 패턴 쓸 수 있음
Kinesis
- 두 가지 소비 모드
1. 표준 모드 : 소비자가 Kinesis로부터 데이터 가져옴
- 샤드당 2MB
2. 향상된 팬 아웃 모드 : 소비자에게 데이터를 푸시
- 샤드 당 소비자 당 2MB (더 처리량 많음, Kinesis 스트림에서 더 많은 애플리케이션 읽기 가능)
- Kinesis 데이터 스트림에선 데이터가 지속됨(리플레이 가능)
- 실시간 빅데이터 분석, ETL 등에 활용
- 샤드레벨에서 순서보장 가능
- 미리 Kinesis 데이터 스트림마다 원하는 샤드 양을 지정해야함
- 샤드를 직접 확장해서 데이터가 언제 만료될지 정해야함(1~365일)
- 두 가지 용량 모드
1. 프로비저닝 용량 모드 : Kinesis 데이터 스트림으로부터 원하는 샤드 양 미리 지정
2. 온디맨드 용량 모드 : 샤드 수가 자동으로 조정됨
Amazon MQ
- SQS, SNS는 AWS의 독점 기술.. 클라우드 네이티브 서비스임 -> 각자 API 형식 있음
- 온프레미스에서 기존 애플리케이션을 실행하는 경우 개방형 프로토콜인 MQTT, AMQP, STOMP, Openwire 등을 사용할 수 있음
- 클라우드에 마이그레이션할 때는, SQS/SNS 프로토콜 혹은 API를 기존에 온프레미스에서 쓰던 프로토콜과 연결하기 위해 Amazon MQ를 쓸 수 있음
Amazon MQ란
- RabbitMQ와 ActiveMQ 두 가지 기술을 위한 관리형 메시지 브로커 서비스
ㄴ 온프레미스 기술로 개방형 프로토콜 액세스를 제공함
- Amazon MQ는 확장성이 크지는 않음(SQS/SNS는 무한확장)
- Amazon MQ는 서버에서 실행되기에 서버 문제가 있을 수 있기 때문
- 고가용성, 페일오버를 위해 다중 AZ 설정 가능
- SQS와 같은 단일 큐 기능과 SNS처럼 보이는 주제 기능을 단일 브로커의 일부로 제공함
`MQ의 고가용성
- 각 AZ에 Amazon MQ 브로커 추가(Active-StandBy 상태)
- 장애 조치를 위한 백엔드 스토리지로 EFS 정의(다중 AZ에 마운트)
- 클라이언트는 Active 브로커를 바라보다가 문제가 생기면 StandBy쪽으로 페일오버 되는데 이때 EFS로 네트워크 파일 공유를 하고 있기에 유실없이 사용 가능
