Overview
트래픽이 갑자기 급증하거나 아무것도 예측할 수 없을 때
일반적으로 애플리케이션을 분리
하고 분리 계층(decouple)을 확장
하는 것이 좋습니다.
- 대기열 모델
- pub/sub 모델
- 실시간 스트리밍 및 대용량 데이터
SQS
SQS
SQS - 표준(Standard) 대기열
- 가장 오래됨
- 애플리케이션 분리하는데 사용되는
완전 관리형 서비스
입니다.
- 속성 :
- 무제한 처리량
- 즉 초당 원하는 만큼 메시지를 보낼 수 있고 대기열에도 원하는 만큼 메시지를 포함시킬 수 있습니다.
- 메시지는 수명이 짧습니다.
- 지연 시간이 짧습니다.
- SQS는 메시지를 보내거나 SQS에서 메시지를 읽을 때마다 게시 및 수신 시 10밀리초 이내로 매우 빠르게 응답을 받게 됩니다.
- SQS의 메시지는 작아야 합니다.
* 전송된 메시지당 256KB 미만이어야 합니다.
- 중복 메시지가 있을 수 있습니다.
최선의 오더
라는 뜻으로 품절 메시지를 보낼 수도 있습니다.
SQS - 메시지 생산자
생산자
는 SDK 소프트웨어 개발 키트를 사용하여 SQS에 메시지를 보낼 겁니다.
- 소비자가 해당 메시지를
읽고 삭제
할 때까지 SQS 대기열에 유지됩니다.
EX)
패킷과 같은 오더를 처리한 다음 센터로 배송하려고 합니다.
- Order Id
- Customer Id
- 원하는 속성등의 일부 정보
가 포함된 메시지를 SQS 대기열에 보냅니다.
SQS - 메시지 소비자
소비자
는 일부 코드로 작성해야 하는 애플리케이션이고
이러한 애플리케이션은 EC2 인스턴스에서 실행될 수 있습니다.
- AWS Lambda의 람다 함수에서 실행할 수도 있습니다.
- 대기열에는 소비자가가 있고 소비자는
SQS 메시지를 폴링
합니다.
- 소비자는 아마 한 번에 최대 10개의 메세지를 받을 겁니다.
- 여러분의 코드인
소비자
는 이 메시지들을 처리
할 책임이 있습니다.
- 이후 소비자가 이 메시지들을
DeleteMessage API
로 대기열에서 삭제
합니다.
다중 EC2 인스턴스 소비자
SQS 대기열
은 메세지를 동시에 수신하고 처리할 소비자를 여러 개 가질 수 있습니다.
적어도 한번
은 전송이 됩니다.
- 최선의 노력으로
메시지 순서 지정을 하는 이유
입니다.
- 소비자가
메시지를 처리
하면 메시지를 삭제
해야 합니다.
- SQS 대기열에서
더 많은 메시지가 있어서 처리량을 늘려야 하면
소비자를 추가하고 수평 확장을 수행해서 처리량을 개선할 수 있습니다.
SQS - ASG (Auto Scaling Group)
SQS - 애플리케이션 계층 간에 분리
SQS 보안
-
암호화
HTTPS API
를 사용하여 전송 중 암호화를 합니다.
KMS 키
를 사용하여 미사용 암호화를 얻습니다.
- 클라이언트가 자체적으로 암호화 및 암호 해독을 수행하는 클라이언트 측 암호화를 합니다.
-
액세스 제어
- SQS API에 대한 액세스를 규제할 수 있습니다.
-
SQS 액세스 정책
- S3 버킷 정책과 유사합니다.
- SQS 대기열에 대한 교차 계정 액세스를 수행하려는 경우
- NS 혹은 Amazon S3 같은 다른 서비스가 SQS 대기열에 S3 이벤트 같은 것을 쓸 수 있도록 허용
SQS 대기열 액세스 정책
- 교차 계정 액세스
- S3 버킷이 있으면 이것이 이벤트 알림을 SQS 대기열에 게시
SQS - 메시지 가시성 시간 초과
- 소비자가 메시지를 폴링하면 그 메세지는 다른 소비자들에게 보이지 않게 됩니다.
- 기본값으로 메시지 가시성 시간 초과는 30초입니다.
- 그 말은 이 30초 동안 메시지가 처리되어야 한다는 거죠 그렇죠?
- 가시성 시간 초과 기간 내에서는 그 메시지는 다른 소비자들에게 보이지 않습니다.
가시성 시간 초과
가 경과되고 메시지가 삭제되지 않았다면 메시지는 대기열에 다시 넣습니다.
-
가시성 시간 초과 기간 내에 메시지를 처리하지 않으면 메시지가 두 번
처리될 수도 있다는 것을 알 수 있습니다.
-
소비자가 메시지를 처리하는 데 시간이 더 필요하다는 것을 알고 있고
해당 메시지를 두 번 처리하고 싶지 않다면
소비자
는 ChangeMessageVisibility API
를 호출하여 SQS
에 알려야 합니다.
- ChangeMessageVisibility
- 메시지를 처리하지 않아 가시성 시간 초과 기간을 벗어날 때 사용합니다.
-
기본값으로 매우 높은 값 예를 들어 시간으로 설정하면
소비자가 충돌했을 때 이 메시지가 다시 나타날 때까지
즉 SQS 대기열에 보이기까지 몇 시간이 걸립니다.
-
몇 초와 같이 매우 낮은 값으로 설정하면
소비자가 어떤 이유로든 해당 메시지를
처리할 시간이 충분하지 않으면 다른 소비자가 메시지를 여러 번 읽을 것이며
중복 처리될 수 있습니다.
SQS - Dead Letter Queue
- 소비자가 가시성 시간 초과 내에 메시지를 처리하지 못하는 상태
그러면 메시지가 자동으로 대기열로 돌아갑니다.
- 메시지를 얼마나 많이 돌아가게 할 수 있는 임계값을 설정할 수 있습니다.
- 최대 수신 임곗값을 초과하면, 메시지는 DLQ로 갑니다.
Dead Letter Queue
가 존재하는 이유?
- 데드 레터 대기열에 있고
SQS 대기열이기 때문에 메시지 보관 기간에 제한이 있어서 일정 시점에서 만료
됩니다.
- 따라서 데드 레터 대기열에 14일 정도의 높은 보존 기간을 설정하는 것이 좋습니다.
SQS DLQ - 소스로 리드라이브
- 데드 레터 대기열 관리를 위한 기능
데드 레터 대기열 메시지
를 사용해 무엇이 잘못되었는지 이해하는 데 도움이 되는 기능입니다.
메시지가 처리되지 않은 이유를 파악한 후 소비자 코드를 수정하고 메시지가 올바르게 나오는 경우,
데드 레터 대기열에서 소스 SQS 대기열로 해당 메시지를 리드라이브합니다.
Delay Queue
대기열 지연
은 소비자들이 즉각적으로 보지 못하도록 메시지를 지연시키는 것입니다.
15분까지 지연
시킬 수 있습니다.
- 지연 파라미터의
기본값은 0초
입니다.
- 매번 메시지를 보낼 때마다
DelaySeconds 파라미터
를 사용하여
메시지별 지연 시간을 지정할 수도 있습니다.
Long Polling
- 예를 들어 소비자가 대기열에 메시지를 요청하는데
대기열에 아무것도 없다면 메시지 도착을 기다리면 됩니다
이것을 롱 폴링
이라고 합니다.
- 이유 두 가지 :
- 첫 번째는 지연 시간을 줄이기 위해서.
- 두 번째는 SQS로 보내는 API 호출 숫자를 줄이기 위해서.
- **롱 폴링은 애플리케이션의 효율성과 대기 시간을 증가시키면서 SQS로의 API 호출 수를 감소시킵니다.
1초
부터 20초
사이로 구성이 가능합니다.
- 구성 방법 :
- 대기열 레벨에서 구성하여 폴링하는 아무 소비자로부터 롱 폴링을 활성화하는 방법
- WaitTimeSeconds를 지정함으로 소비자가 스스로 롱 폴링을 하도록 선택
SQS 대기열에 대한 API 호출 수를 최적화하고
지연 시간을 줄이는 법을 묻는다면 롱 폴링을 떠올리세요
SQS를 통한 요청-응답 시스템
- 이 패턴을 실행하기 위해서
- SQS Temporary Queue Client 즉, SQS 임시 대기열 클라이언트가 답입니다.
- 이는 AWS에서 직접 생성한 사용 가능 클라이언트이고 또
Java 클라이언트
입니다.
- 실제 SQS 대기열을 만들고 없애는 대신
가상의 대기열을 활용하니까 비용 면에서도 더 효율적이죠.
SQS FIFO 대기열
FIFO
- 선입선출
- 표준 대기열 보다 더 확실히 순서가 보장되는 것입니다.
소비자
가 SQS FIFO 대기열
로부터 메시지를 불러올 때
정확히 동일한 순서로 메시지를 받게 해 줍니다.
- 제한된 처리량
- 묶음이 아닐 경우에는 초당 300개의 메시지
- 메시지를 묶음으로 보낼 경우의 처리량은 초당 3000개
- SQS FIFO 대기열의 기능으로 인해 정확히 한번만 보낼 수 있게 해 줍니다.
분리가 발생
하거나 메시지의 순서를 유지
할 필요가 있을 때 FIFO 대기열을 확인해야 합니다.
Amazon SNS
- 메시지 하나를 여러 수신자에게 보낸다고 가정해 봅시다.
Amazon SNS
- "이벤트 생산자"는 한 SNS 주제에만 메시지를 보냅니다.
"이벤트 수신자"
또는 구독자
는 해당 주제와 관련한 SNS 알림을 받으려는 사람입니다.
- SNS 주제 구독자는 해당 주제로 전송된 메시지를 모두 받게 됩니다.
- 주제별로 최대 1,200만 이상의 구독자까지 가능합니다.
- 계정당 가질 수 있는 주제 수는 최대 10만 개이고 늘릴 수도 있습니다.
SNS 게시 방법
- SDK 주제 게시를 통해
- 주제를 만듭니다.
- 여러 개의 구독을 만듭니다.
- 주제를 게시합니다.
- 모바일 앱 SDK 전용 직접 게시 방법
- 플랫폼 애플리케이션을 만든 다음
- 플랫폼 엔드 포인트를 만들고
- 플랫폼 엔드 포인트에 게시하면 됩니다.
Google
, GCM
, Apple APNS
또는 Amazon ADM
구독자
SNS - 보안
Amazon SNS는 SQS와 동일합니다
-
암호화
HTTPS API
를 사용하여 전송 중 암호화를 합니다.
KMS 키
를 사용하여 미사용 암호화를 얻습니다.
- 클라이언트가 자체적으로 암호화 및 암호 해독을 수행하는 클라이언트 측 암호화를 합니다.
-
액세스 제어
- SQS API에 대한 액세스를 규제할 수 있습니다.
-
SQS 액세스 정책
- S3 버킷 정책과 유사합니다.
- SQS 대기열에 대한 교차 계정 액세스를 수행하려는 경우
- NS 혹은 Amazon S3 같은 다른 서비스가 SQS 대기열에 S3 이벤트 같은 것을 쓸 수 있도록 허용
SNS + SQS: Fan Out
- SNS 주제에 한 번만 푸시해도
원하는 만큼의 SNS 주제의 여러 SQS 대기열을 구독할 수 있습니다.
- 완전 계층 분리되며, 데이터 손실은 없습니다.
- SQS를 통해 데이터 지속성, 지연 처리 작업 재시도가 가능하며
팬아웃 패턴으로 더 많은 SQS 대기열을 SNS 주제에 구독시킬 수 있습니다.
- SQS 대기열 접근 정책을 통해 SNS 주제를 SQS 대기열에 메시지를 전송하도록 허용해야 합니다.
Kinesis
Kinesis
는 실시간으로 데이터를 수집, 처리 분석, 스트리밍하는 역할을 하며
실시간으로 생성된 데이터를 분석 또는 처리하기 위해 앱으로 보내고자 할 때 사용합니다.
앱 로그
, 지표
, 웹사이트 클릭스트림
IoT 텔레메트리 데이터
등이 해당합니다.
- 컴포넌트 :
Kinesis Data Streams
Kinesis Data Firehose
Kinesis Data Analytics
- SQL이나 Apache Flink로 데이터 스트림을 분석
Kinesis Video Streams
Kinesis Data Streams
- 보존 기간은 1일부터 365일까지
- 데이터를 재처리하거나 재생할 수 있습니다.
- 저장된 데이터는 삭제가 불가능합니다. (불변성)
- 같은 파티션에 공유된 데이터는 같은 샤드를 통해 전송되어 키 기반 정렬이 가능합니다.
생산자
- SDK, KPL, Kinesis 에이전트를 사용할 수 있습니다.
소비자
- KCL, SDK를 직접 만듬
- AWS Lambda, Kinesis Data Firehose Kinesis Data Analytics 같은 관리된 소비자
- 용량 모드 :
- 프로비저닝된 용량 모드
- 프로비저닝할 샤드 수를 정하고 직접 또는 API를 통해 조정합니다.
- 온디맨드 모드
- 용량을 프로비저닝하거나 관리할 필요가 없습니다.
- 기본적으로는 초당 4 MB 또는 4,000개의 레코드를 처리합니다.
- 용량은 자동으로 최근 30일 간 최대 사용량에 따라 조정됩니다.
- 시간 단위로 스트림당 데이터량(GB)에 따라 비용이 부과됩니다.
Kinesis Data Firehose
- 목적지까지 전송되는 데이터를 저장하는 것입니다.
- 거의 실시간 서비스라 할 수 있습니다.
- 별도로 관리할 필요가 없고 자동으로 확장되며 서버가 없습니다.
- AWS의 Redshift, Amazon S3, and Elasticsearch
- 타사 파트너와 사용자 지정 HTTP 엔드 포인트가 있습니다.
- 비용은 Firehose에서 처리한 데이터에만 부과됩니다.
- 거의 실시간에 가깝게 처리됩니다.
- 지연 시간은 최소 60초로 지정되어 있어 배치를 채울 만큼 충분한 처리량이 없거나
최소 용량인 32 MB에 미달하는 경우 그대로 전송되고
배치의 크기를 조정할 수는 있지만 32 MB 미만으로는 설정할 수 없습니다.
- 여러 형태의 데이터 포맷과 변환 압축을 지원하고
앞서 설명한 Lambda를 통한 사용자 지정 데이터 변환도 지원합니다.
- 처리에 실패하거나 처리된 모든 데이터를 S3 백업 버킷에 보낼 수도 있습니다.
Kinesis Data Streams vs Firehose
Kinesis Data Streams
- 대규모로 데이터를 수집하는 스트리밍 서비스
- 사용자 지정 코드를 작성해 데이터 전송과 소비에 사용할 수 있습니다.
- 실시간 처리 (0 ~ 200 ms)
- 스케일링 관리 (샤드 추가/분할/통합)
- 1-365일간 보존되며 따라서 재생 기능을 지원합니다.
Kinesis Data Firehose
- S3 Redshift, Elasticsearch 타사, HTTP로 전송하는 것이 목적입니다.
- 완전 관리형 서비스
- 데이터는 버퍼에서 배치로 쓰이기 때문에 거의 실시간으로 작동합니다.
- 확장은 자동으로 이루어집니다.
- 데이터 저장소가 없습니다.
- 데이터를 재생할 수 없습니다.
Kinesis Data Analytics
- 완전 관리형 모델
- 프로비저닝할 서버가 없습니다.
- 자동으로 확장됩니다.
- 실시간 분석이 목적입니다.
- 비용은 처리된 만큼 부과되므로, 실제 사용량에 기반하며 실시간 쿼리를 통해 스트리밍을 생성할 수 있습니다.
- 사용 :
Kinesis vs SQS ordering
트럭은 100대
가 있고 Kinesis 샤드가 5개
SQS FIFO 대기열이 1개
라고 가정,
- Kinesis Data Streams
- 평균적으로 가지는 값은 샤드당 트럭 20대
- 트럭 데이터는 각 샤드에 순서대로 정렬됩니다.
- 동시에 가질 수 있는 최대 소비자 개수는 5개뿐입니다.
- 샤드가 5개인 경우에 초당 최대 5MB의 데이터를 수신할 수 있으며 꽤 많은 편입니다.
- SQS FIFO
- SQS FIFO 대기열이 하나
- 각 트럭 ID에 상응하는 그룹 ID를 100개 생성합니다.
- 소비자도 최대 100개가 될 수 있습니다.
- 규모를 보면
SQS FIFO에서 최대 초당 300, 혹은 배치를 사용하면 3,000개의 메시지를 가집니다.
SQS vs SNS vs Kinesis
- SQS
- 메시지를 요청해서 데이터를 가져오는(pull) 모델
- 데이터를 처리 후에 소비자가 대기열에서 삭제하서 다른 소비자가 읽을 수 없게 합니다.
- 작업자나 소비자 수가 제한이 없습니다.
- 관리된 서비스이므로 처리량을 프로비저닝할 필요가 없습니다.
- 순서를 보장하려면 FIFO 대기열을 활성화합니다.
- 각 메시지에 지연 기능이 있습니다.
- SNS
- 다수의 구독자에게 데이터를 푸시하면 메시지의 복사본을 받게됩니다.
- SNS 주제별로 1,250만 명의 구독자까지 가능합니다.
- 데이터가 한 번 SNS에 전송되면 지속되지 않습니다.
- 제대로 전달되지 않는다면 데이터를 잃을 가능성이 있습니다.
- 게시-구독 모델은 최대 10만 개의 주제로 확장 가능합니다.
- 처리량을 프로비저닝하지 않아도 됩니다.
- 팬아웃 아키텍처 패턴을 이용하면 SQS와 결합할 수 있습니다.
- SNS FIFO 주제를 SQS FIFO 대기열과 결합할 수 있죠.
- Kinesis
- 표준모드
- 소비자가 Kinesis로부터 데이터를 가져옵니다.(pull)
- 샤드당 2 MB/s의 속도를 지원해요
- 향상된 팬아웃 유형의 소비 메커니즘
- 샤드 하나에 소비자당 2 MB/s의 속도가 나옵니다.
- 데이터를 다시 재생할 수 있어요.
- Kinesis 데이터 스트림에서는 데이터가 지속되기 때문에
- 실시간 빅 데이터 분석, ETL 등에 활용됩니다.
- 샤드 레벨에서 정할 수 있습니다.
- 1에서 365일까지 데이터를 보존할 수 있습니다.
- 프로비저닝 용량 모드
- Kinesis 데이터 스트림으로부터 원하는 샤드 양을 미리 지정합니다.
- 온 디맨드 용량 모드
- 샤드 수가 Kinesis 데이터 스트림에 따라 자동으로 조정됩니다.
Amazon MQ
애플리케이션을 마이그레이션할 때
전부 재설계를 하는 대신
메시지 대기열을 클라우드로 그냥 옮기고 싶을 수 있습니다.
Amazon MQ를 사용합니다.
Amazon MQ
는 클라우드
에서 Apache ActiveMQ
를 관리합니다.
- SQS나 SNS 만큼 확장되진 않는데 프로비저닝되기 때문입니다.
- 전용 머신에서 실행됩니다.
- 장애 조치에 대해 고가용성을 설정할 수 있습니다.
- SQS처럼 대기열 기능도 있습니다.
- SNS처럼 주제 기능도 있습니다.
재설계하지 않고
온프레미스에서 클라우드로 애플리케이션을 마이그레이션할 때
그 애플리케이션이 MQTT나 MQP 같은 표준 프로토콜을 사용한다면
Amazon MQ를 사용해야 한다는 것입니다
Amazon MQ - 고가용성
From
AWS Certified Solutions Architect Associate 시험합격!