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 호출 숫자를 줄이기 위해서
- 1번째
- 롱 폴링을 구성하는 방법은 2가지
- 1번째
- 대기열 레벨에서 구성하여 폴링하는 아무 소비자로부터 롱 폴링 활성화
- 2번째
- WaitTimeSeconds를 지정하여 소비자가 스스로 롱 폴링 활성화
- 1번째
SQS - FIFO Queues
- FIFO는 선입선출 자료구조 Queue랑 일치함
- 중복을 제거해주는 SQS FIFO 대기열 기능이 있어서 메시지를 한 번만 보낼 수 있음
- SQS로 너무 많은 메시지를 안보내게 처리량에 제한을 할 수 있음
- 선입선출 방식이기에 메시지 순서가 유지 가능
- 이름에 .fifo를 꼭 넣어야함
SQS + 오토 스케일링 그룹
- SQS의 길이를 가져올수있는 CloudWatch가 있음
- CloudWatch Metric -Queue Length
ApproximateNumberOfMeesages
- CloudWatch Metric -Queue Length
- CloudWatch Alarm에서 해당 길이로 알람을 보내서 ASG 축소, 확장이 가능
- 예시
- 대대적인 세일 행사를 진행, 수 많은 고객이 주문 할 예정임
- RDS에 애플리케이션이 직접 요청을 넣을텐데
- 이러면은 특정 트랜잭션에 오류가 발생했을때 트랜잭션이 유실이 됨
- 그래서 SQS를 버퍼로 사용하면은 오류가 발생해도 계속 소비자를 찾기때문에 트랜잭션이 유실이 안됨
Amazon Simple Notification Service (AWS SNS)
- 메시지 하나를 여러 수신자에게 보낼때 사용
- 통합 개념
- 예시 - 구매 서비스 애플리케이션
- 이메일 알림
- 사기 탐지 서비스
- 배송 서비스
- SQS 대기열
- 메시지를 보낼때 수신 서비스를 새로 추가할때마다
통합을 생성하고, 작성해야함 - 대신 Pub/Sub을 사용하여서 SNS 주제로 전송이 가능하다.
- SNS Topic
- 이메일 알림
- 사기 탐지 서비스
- 배송 서비스
- SQS 대기열
- SNS Topic
- 위와 같은 구조로 SNS Topic가 알아서 보내는 개념
SNS 및 SQS - 팬아웃 패턴
- 메시지를 여러 SQS 대기열을 보내고 싶은데 모든 SQS 대기열에 개별적으로 보내면 문제 발생 가능
- 예시
- 애플리케이션이 중간에 비정상적으로 종료, 전달에 실패
- SQS 대기열이 더 추가 됨
- 예시
- SNS 주제에 메시지를 전송 한 후 원하는 수의 SQS 대기열이 SNS 주제를 구독하는게 팬아웃 패턴
- 구매 서비스
- SNS Topic
- SQS Queue 1번
- 결제 서비스
- SQS Queue 2번
- 쇼핑 서비스
- SQS Queue 1번
- SNS Topic
- 위 처럼 구매 서비스에서 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 버킷으로 보냄
- AWS 수신처
- 정리
- Kinesis Data Firehose는 완전 관리되는 서비스
관리가 필요하지 않음
자동으로 용량 크기 조정
서버리스므로 관리 할 서버가 없음
- 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가 많을수록 소비자도 많아짐
- 그룹 2개가 있으면, 소비자 2개가 있으면
- SQS vs Kinesis 트럭 100개
- Kinesis
- Kinesis는 샤드 5개일 경우
- 샤드 마다 20개의 트럭의 정보가 저장 됨
- 샤드가 5개이기에 샤드마다 하나의 소비자가 필요함
- 예로 트럭 10,000대가 많은 데이터를 전송, 정렬 할 때 쓰기 좋음
- SQS FIFO
- 대기열은 하나 뿐임
- 트럭 100개니깐 그룹 ID 100개 생성해야함, 소비자도 최대 100개
- SQS FIFO는 그룹 ID 숫자에 따른 동적 소비자 수를 원할 때 쓰는게 좋음
- Kinesis
- 예시 상황
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 네트워크 파일 시스템으로 다중 가용 영역 마운트로 설정해서
- 장애 조치가 일어날때마다 활성 대기열과 동일한 데이터를 가짐
'스터디 > AWS SAA' 카테고리의 다른 글
섹션 19: 솔루션 설계자 관점의 서버리스 개요 (0) | 2024.01.10 |
---|---|
섹션 18: AWS의 컨테이너: ECS, Fargate, ECR 및 EKS (1) | 2024.01.09 |
섹션 16: AWS 스토리지 추가 기능 (0) | 2024.01.06 |
섹션 15: CloudFront 및 AWS 글로벌 액셀러레이터 (1) | 2024.01.05 |
섹션 14: 아마존 S3 보안 (1) | 2024.01.04 |