#AWS Certified Developer Associate
(1.1 시작)
243. AWS 통합 및 메시징 - 섹션 소개
프로그램 통합에 많이 사용되고 실제 시험에서 SQS 를 자주 뭍는다고 함
244. 메세징 소개 - AWS Integration & Messaging
애플리케이션을 여러개 배포하려고 할 때 커뮤니케이션을 할 수 밖에 없게 됨
애플리케이션 커뮤니케이션은 두가지 패턴으로 나뉨
- 동기(synchronous) 커뮤니케이션 - 각 애플리케이션 직접 연결
- 비동기(Asynchronous) 혹은 이벤트기반(Event based) 커뮤니케이션 - 대기열(queue) 등으로 불리는 미들웨어가 애플리케이션들을 연결함
애플리케이션간 연결(synchronous betwwen applications)은 간혹 문제가 될 수 있음
- sudden spikes of traffic
일반적으로 애플리케이션을 분리(decouple)하고 분리 계층(decoupling layer)을 확장하는것이 좋다
- 대기열 모델의 경우 - SQS
- pub/sub 모델의 경우 - SNS
- 실시간 스트리밍을 하고 대용량 데이터를 다루는 모델 - Kinesis
위 서비스들을 사용해서 독립적으로 서비스를 확장할 수 있다
245. Amazon SQS (Simple Queue Service) - 표준 Queues 개요
SQS는 간단한 대기 서비스
SQS 대기열에 메세지를 보내는 주체를 생산자(producer) 라고 함
SQS 메세지를 수신해야 하는 대상을 소비자(consumer) 라고 함
소비자는 생산자가 메세지를 보냈는지를 대기열에서 확인하고 그 메세지로 처리를 하고 대기열에서 메세지를 삭제함
SQS Queue(대기열 서비스)는 생산자와 소비자 사이를 분리(decouple)하는 버퍼 역할을 함
Amazon SQS - Standard Queue (표준 대기열)
SQS 는 AWS 에서 제공하는 가장 오래된 서비스임
완전 관리형 서비스 , 애플리케이션을 분리하는데 사용됨
Attributes
무제한 처리량을 얻을 수 있음 - 처리량에 재한이 없고 대기열에 있는 메세지 수에도 제한이 없음
각 메세지는 수명이 짦음 - 메세지는 기본값으로 4일동안 대기열에 남아있음, 최대 14일
지연 시간이 짦음 - 게시 및 수신 시 10ms 이내로 응답을 받게 됨
SQS 메세지는 작아야 함 - 전송된 메세지당 256KB 미만이여야 함
중복 메세지가 있을 수 있음 - 애플리케이션 작성 시 염두해야함
최선의 오더(out of order) 메세지 = 품절(best effort ordering) 메세지가 있을 수 있음
SQS - Producing Messages
생산자(prodecer)는 SDK 를 사용하여 SQS 에 메세지를 보냄
- SendMessage : SQS 에 메세지를 보내는 API
소비자가 해당 메세지를 읽고 삭제할 때(메세지가 처리될 때)까지 SQS 대기열에 유지됨
retention - default 4days, up to 14days
SQS - Consuming Message
소비자(consumer)는 일부 코드로 작성해야하는 애플리케이션임 (running on EC2, servers or AWS Lambda ...)
소비자는 SQS 메세지를 폴링(polling) 함 - 즉 소비자가 대기열에 자신의 앞으로 온 메세지가 있는지를 묻는 작업
- 소비자는 한번에 최대 10개의 메세지를 받음
process the message (example : insert the message into an RDS database)
SQS - Multiple EC2 Instances Consumers
위 개념을 확장해보면 여러 소비자를 동시에 가질 수 있음
만약 메세지가 소비자에 의해 충분히 빠르게 처리되지 않으면 다른 소비자가 수신하게 됨
- 적어도 한번은 전송됨 (at least once delivery) (메세지 입장)
- 최선의 오더=품질 메세지(best-effort message ordering)를 메세지 순서를 지정하는 이유
소비자가 메세지를 처리하면 메세지를 삭제해야 함 - 그렇지 않으면 다른 소비자가 메세지를 보게 됨
SQS 큐에서 더 많은 메세지가 있어서 처리량을 늘려야 한다면 소비자를 추가하고 수평 확장을 수행해서 처리량을 개선할 수 있음
SQS with Auto Scaling Group
대기열(Queue Length)의 길이가 특정 수준을 넘어가면 CloudWatch Alarm 설정
- 위 알람으로 오토 스케일링 그룹의 용량 스케일링
더 많은 메세지가 SQS 대기열에 있게 됨
- 만약 웹사이트에 오더가 폭주했다거나 해서 asg가 더 많은 ec2 인스턴스를 제공하면 메세지들을 더 높은 처리량으로 처리할 수 있음
- 위 사례는 일반적인 통합으로 시험에 흔히 출제된다고 함
SQS to decoupling betwwen application tiers
만약 웹에서 비디오를 받아 처리하는 앱이 있다고 할때
처리 요청을 sqs queue 에 보내서
백앤드 소비자가 메세지를 받아 처리하는 식으로 앱을 분리한다면
프론트와 백 앤드 에서 각각 최적의 유형의 ec2 인스턴스 또는 아키텍처를 사용할 수 있다
Amazon SQS - Security
암호화(Encryption) :
전송중 암호화 - HTTPS API
미사용 암호화(at-rest encryption) - KMS key
Client-side encryption - 원한다면 사용 가능, 클라이언트가 자체적으로 암호화 및 암호 해독을 수행해야 함
Access Controls(접근 제어) :
IAM 정책 - SQS API 에 대한 액세스를 규제
SQS Access Policies - s3 버킷 정책과 유사한 SQS 액세스 정책
246. SQS - 표준 Queues 실습
FIFO 는 나중에 하고 standard 먼저 실습한다고 함
왼쪽 항목은 나중에 배우고
메세지 보존 기간은 1분~14일 사이로 지정할 수 있다고 함
기본적으로 대기열 소유자만 큐에 엑세스 할 수 있지만
아래 커스텀 역할을 눌러서 다른 계정, 역할 또는 대기열에 메세지를 보낼 수 있는 IAM 사용자를 설정할 수 있다고 한다
S3 나 SNS 와 통합할 때 유용하다고 함
암호화는 강의와 다르게 기본적으로 활성화 되어있고
Encryption key type 이 SSE-SQS 로 설정되어있다
dead-letter queue (배달 못한 편지 대기열) 은 나중에 설명한다고 함
대기열 생성
이후 메세지 전송 및 수신 탭에 들어가면
콘솔을 통해 메세지를 전송하고 아래 풀링을 통해 메세지를 풀링 할 수도 있다
풀링한 메세지를 선택해서 삭제할 수도 있다
생성한 큐 탭에 들어가서 모니터링을 통해
다양한 메세지들의 시각화된 데이터를 볼 수 있고
암호화 방식이나 액세스 정책을 변경할 수도 있다
편집을 통해 이전에 설정했던 대기열의 속성을 변경할 수도 있고
제거 버튼을 통해 모든 메세지를 제거할 수도 있다고 한다
삭제(delete) 는 대기열 삭제고 제거(purge) 는 모든 메세지를 제거한다고 함
247. SQS Queue 액세스 정책
JSON IAM 정책을 SQS 대기열에 직접 추가한다고 함 - S3 정책 설정과 비슷
usecase 1 : Cross Accound Access (교차 계정 액세스)
usecase 2: Publish S3 Event Notifications To SQS Queue
SQS Queue 를 만들어보자
우선 큐 이름을 EventFromS3 로 하고 다 기본값으로 설정해주고 생성해줬다
이후 작동하지 않는걸 확인한 다음에 정책을 수정한다고 함
s3 로 이동
sqs와 같은 리전에다가 버킷을 하나 만들어주고 이름을 demo-sqs-queue-access-policy-yeonwoo 로 해줬다
이후 속성에서 이벤트 알림 생성으로 들어가서 NewObjects 라는 이름의 이벤트를 생성해주고
이벤트 유형은 모든 객체 생성 이벤트로 해준 다음
아래 대상에서 sqs 대기열을 선택해주고 이전에 만들어줬던 큐를 선택해줬다
그러면
대상의 구성을 확인할 수 없기 때문에 오류 메세지가 나오게 됨
이렇게 SQS 에 정책 설정이 안되면 접근할 수 없기 때문에 정책 설정을 해주러 감
구글링을 통해 iam 정책 검색
Granting permissions to publish event notification messages to a destination - Amazon Simple Storage Service
Thanks for letting us know this page needs work. We're sorry we let you down. If you've got a moment, please tell us how we can make the documentation better.
docs.aws.amazon.com
복사해서 다시 sqs 편집으로 들어와서 액세스 정책 edit 으로 접속해주고
붙여넣기
resource 는 기본값에서 가져오고
조건(condition)은 ArnLike 소스 버킷이 내가 만든 소스 버킷의 이름과 같아야 한다는 조건을 걸어야 함
sourceaccount 도 내 aws 계정의 소스 id 를 붙여넣어준다
{
"Version": "2012-10-17",
"Id": "example-ID",
"Statement": [
{
"Sid": "example-statement-ID",
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": "SQS:SendMessage",
"Resource": "arn:aws:sqs:ap-northeast-1:662307199274:EventFromS3",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "662307199274"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:s3:*:*:demo-sqs-queue-access-policy-yeonwoo"
}
}
}
]
}
위 처럼 sqs 큐의 액세스 정책을 수정한 뒤 s3 이벤트 알람을 생성해주면 정상적으로 생성이 되고
sqs 큐의 메세지를 폴링해보면
위 처럼 testevent 가 온 것을 확인할 수 있다
248. SQS - 메세지 가시성 시간 초과 (Message Visibility Timeout)
소비자가 메세지를 폴링하면 그 메세지는 다른 소비자들에게 보이지 않게 됨 - 가시성 시간 시작
기본값으로 메세지 가시성 시간 초과는 30초
- 30초동안 이 메세지가 처리되어야 한다는 뜻
이 시간동안 동일한 혹은 다른 소비자가 메세지 요청 API 를 호출하면 메세지가 반환되지 않음
- 즉, 가시성 시간 초과 기간 내에서는 그 메세지는 다른 소비자들에게 보이지 않음
- 만약 가시성 시간이 초과되고, 메세지가 삭제되지 않았다면 메세지는 다시 대기열에 올라가고 , 다른 소비자가 ReceiceMessage API call 하면 이 메세지를 또 받게 됨
가기성 시간 초과 기간 내에 메세지를 처리하지 못하면 메세지가 두번 처리될 수 있음
ChangeMessageVisibility - 소비자가 메세지를 처리하는데 시간이 더 필요하다는 것을 알고있고, 해당 메세지를 두번 처리하고 싶지 않다면 이 api 를 호출해서 SQS 에 알려야 함
- 기본적인 시간을 늘리는 방법 - re-processing will take time
- 만약 시간이 너무 짧다면 - 소비자가 메세지를 여러번 읽게 됨 - 중복처리 될 수 있음
사용자는 메세지 처리 시간이 가시성 시간이 초과될 것 같다면 ChangeMessageVisibility api 를 호출하도록 프로그래밍 해야함
sqs 콘솔 1,2를 열고 콘솔 1에서 메세지를 전송한 다음 바로 아래에서 폴링해놓은 뒤
콘솔2에서 메세지를 폴링하면 위처럼 폴링이 진행되도 메세지가 나타나지 않는다
기본값인 30초가 지나야 콘솔 2 에서 메세지가 보이게 됨
위처럼 표시 제한 시간이라고 되있는 곳에서 기본값을 바꿀 수도 있지만
그러면 리프로세싱 시간이 길어질 수 있기 때문에 ChangeMessageVisibility api 를 활용하는게 바람직한 로직이라고 한다
249. SQS - 배달 못한 편지 Queues (Dead Letter Queue)
표시 제한 시간을 초과하는 메세지가 많으면 문제가 발생함 - 계속 반복해서 소비자-대기열 을 오갈 수 있음
- 여기서 몇번이나 이 loop 을 반복할 지 임계값을 설정할 수 있다고 함
- 해당 임계값을 초과하면 SQS 가 메세지가 이상함을 감지할 수 있음
dead letter queue(DLQ) 로 메세지를 보냄
- 배달 못한 편지 대기열에는 나중에 처리할 수 있도록 그 메세지가 포함됨
- 이는 디버깅에 유용함
- DLQ 에도 메세지 보존 기간이 존재함 - 높은 보존 기간을 설정하는 것이 좋다고 함
실습
SQS 콘솔로 가서 이름을 DemoQueueDLQ 로 새로운 대기열을 만들어준다
보존기간도 14일로 제일 길게 설정해준다
이후 이전에 만든 대기열에서 방금 만든 DLQ 로 데드레터를 보내야 하기 때문에
이전 대기열(DemoQueue) 편집으로 들어가준다
아래로 내려서 배달 못한 편지 대기열을 활성화 해주고
아까 만든 dlq 를 선택해준다
최대 수신수는 1에서 1000 사이로 설정할 수 있다고 하는데 강의에선 빠르게 확인하기 위해 3으로만 해줬다
만약 메세지를 3번 수신하고 다시 sqs 큐에 올릴때 위 큐가 아닌 따로 설정해준 dlq 로 올려주는 기능이다
DemoQueue 에서 'hello world posion pill' 이라고 메세지를 전송한 후
아래에서 폴링해보면 메세지를 계속 폴링한다
posion pill 문구가 정상 처리를 방해하는 문구인가보다
이렇게 3번 폴링한 후 4번째에는
이렇게 설정해놓은 dlq 로 메세지가 폴링된다
250. SQS - Queues 지연 (Delay Queue)
대기열 지연은 소비자들이 즉각적으로 보지 못하도록 메세지를 지연시키는 것을 말함
- 15분까지 지연시킬 수 있음, 지연 파라미터의 기본값은 0임
DelaySeconds 파라미터를 통해 메세지마다의 지연값을 설정할 수도 있음
실습
sqs 콘솔로 가서 DelayQueue 이름으로 대기열을 하나 생성해준다
그리고 아래 전송 지연 시간을 10초로 설정해준다
0초가 기본값이고 15분까지 설정할 수 있다고 한다
대기열 생성
아래 폴링을 켜놓고 위 기본값 그대로 메세지를 전송하면
약 10초 뒤에 아래에 메세지가 폴링된다
메세지를 보낼 때 전송지연 파라미터 값을 직접 입력할 수도 있다
251. SQS - 공인 개발자 개념
SQS 와 관련하여 개발자 레벨에서 알아야 할 몇가지 개념
Amazon SQS - Long Polling
소비자가 sqs 로부터 메세지를 요청할 때 만약 대기열이 비어있다면 메세지가 도착할 때까지 기다리도록(wait) 할 수 있음
- 이를 롱 폴링(long polling) 이라고 함
SQS 대기열로 보내는 API 호출을 줄일 수 있음
메세지가 SQS 대기열에 도착하자마자 SQS 대기열이 이를 다시 소비자에게 전송함
롱 폴링 시간은 1~20초 로 설정할 수 있음 - 20 sec preferable
통상 사용자들의 애플리케이션에서 숏폴링(short polling) 보다는 롱 폴링을 사용하는 것을 추천한다고 함
롱 폴링은 대기열 레벨에서 활성화하거나 소비자가 폴링을 위해 SQS 대기열로 API 호출을 보낼 때 WaitTimeSeconds 파라미터를 통해 API 호출 레벨에서 활성화 할 수도 있음
만약 사용자 앱이 너무 많은 호출을 보내서 그로 인해 비용이 발생하고 cpu 연산이 늘어나며 지연 시간이 길어진다는 내용의 유스케이스가 있다면 롱 폴링이 해답이 될 수 있음
SQS Extended Client
대용량 메세지 전송을 위한 Java 라이브러리
기본 개념 - amazon s3 버킷을 대용량 데이터를 담는 리포지토리로 사용하는 것
예시 :
- 생산자(producer) 가 sqs 로 대용량 데이터를 보내려고 함
- 실제로는 그 대용량 메세지가 s3 로 도착하게 됨
- sqs 로 보내지는 것은 amazon s3 버킷에 들어있는 대용량 메세지에 대한 포인터를 가진 작은 메타데이터 메세지임
- 동일하게 소비자에게도 메타데이터가 담긴 메세지가 폴링 됨
흔히 비디오 파일을 처리할 때 사용됨
이와 같은 방식으로 어떤 크기의 메세지도 처리할 수 있음
SQS - Must know API
CreateQueue (MessageRetentionPeriod) , DeleteQueue - 대기열 생성 삭제, 메세지 보존 기간을 인수로 사용 가능
PurgeQueue - 대기열 내의 모든 메세지를 삭제
SendMessage (DelaySeconds) , ReceiceMessage, DeleteMessage - 각각 메세지 전송(지연시간) , 메세지 폴링, 메세지 한개 삭제
MaxNumberOfMessage : 파라미터, 기본값은 1 - 한번에 하나의 메세지를 받는다는 뜻 , 한번에 10개까지 받을 수 있음 (for ReceiveMessage API)
ReceiveMessageWaitTimeSeconds - Long Polling 롱 폴링 활성화
ChangeMessageVisibility : 메세지를 처리할 시간이 더 필요한 경우 메세지 시간 초과를 변경하기 위해 사용
이후 롱 폴링 실습
receive message wait time 을 20초로 늘려줬다
대기열이 비어있을 경우 메세지를 받기 까지 최대 20초를 기다려야 한다는 의미
설정 적용해주고
이후 메세지 폴링을 눌러놓고 위에서 아무 메세지나 전송하면 바로 메세지가 폴링됨을 확인할 수 있다
지연시간이 극히 짧은데 이는 롱폴링을 활성화해서라고 한다
(1.1 끝 - 오늘은 여기까지 허리아프다 ㅠ)
(1.2 시작 - 파트가 길다..)
252. SQS - FIFO Queues
FIFO (First In First Out) - 선입선출 - 첫 번째로 도착한 메세지가 첫번째로 대기열을 떠나도록 순서가 정렬된다는 의미
- 표준 대기열보다 더 확실히 순서가 보장됨
- 생산자가 메세지를 보낸 순서대로 소비자가 수신하게 됨
순서를 보장하기 때문에 이 대기열은 제한된 처리량을 가짐
- 묶음이 아닐땐(without batching) 300 msg/s
- 메세지를 묶어서 보낼때 3000 msg/s
중복을 제거하도록 해주는 SQS FIFO 대기열의 기능으로 인해 정확히 한번만 보낼 수 있게 해줌
실습
FIFO 큐는 이름 뒤에 .fifo 를 꼭 붙여줘야 한다고 함
표준 대기열에 비해 옵션이 많이 생겼다
강의에서도 간단하게 하나만 있었는데
콘텐츠 기반 중복제거 on/off 만 있었던것 같다
일단 기본값으로 놓고 대기열 생성
메세지 중복 제거 ID 를 서로 다르게 해서 3개 메세지를 보내보면
아래부터 차례대로 메세지가 보낸 순서대로 읽어들였음을 알 수 있다
253. SQS - FIFO Queues 고급
SQS FIFO - Deduplication
중복 제거가 적용되는 간격은 5분이다 - 즉 5분 간격 이내 동일한 메세지를 두 번 발송할 경우 두번째 메세지는 거부됨
두가지 중복 제거 방법
- 내용 기반(콘텐츠 기반) 중복 제거 : SQS 로 메세지를 보내자마자 메세지 본문에 대해 SHA-256 방식 알고리즘을 사용하여 해시가 계산됨 - 동일한 메세지 본문이 반복되는 경우 해시도 반복됨 - 이 경우 두번째 메세지가 겨부됨
- 메세지 중복 제거 ID 직접 명시하는 방법 - 만약 동일한 중복제거 ID 가 반복된다면 두번째 메세지는 거부됨
SQS FIFO - Message Grouping
SQS FIFO 대기열로 메세지를 보낼 때 의무적으로 입력해야하는 파라미터인 메세지 그룹 id 를 동일한 값으로 정할 경우 해당 id 에 대해서 한명의 소비자만 갖게 됨 - 그 한명의 소비자를 위해 모든 메세지들이 순서대로 정렬됨
메세지의 서브셋 레벨에서 순서대로 정렬할 필요가 있다면 메세지 그룹 id 로 다른 값을 정해야 함
- 동일한 메세지 그룹 id 를 공유하는 메세지들이 해당 그룹 내에서 순서대로 정렬됨
- 각각의 그룹 id는 서로 다른 소비자를 가짐
- 따라서 SQS FIFO 대기열에서 병렬 처리가 가능
- 그러나 여러 그룹들에 걸쳐서 정렬하는 것은 보장되지 않음
실습
SHA-256 해시 비교를 통한 콘텐츠 기반 중복 제거
콘텐츠 기반 중복제거를 활성화했기 때문에 중복제거 id 는 선택사항이 되었다
hello world 라고 적은 메세지를 처음 보내면 사용 가능한 메세지가 1개로 표시된다
이후 같은 내용의 메세지를 전송을 눌러도 사용 가능한 메세지의 숫자는 늘어나지 않는다
254. Amazon SNS (Simple Notification Service)
이벤트 생산자(event producer)는 한 SNS 주제(topic) 에만 메세지를 보냄
이벤트 수신자(event receivers) 또는 구독자(subscriptions)는 해당 주제와 관련한 SNS 알림을 받으려는 사람임
따라서 sns 주제 구독자는 해당 주제로 전송된 메세지를 모두 받게 됨
주제별 최대 구독자 - up to 12,500,000 (이후 변경될 수 있다고 함)
계정당 가질 수 있는 주제 수 - 최대 10만개
게시할 수 있는 것 - emails, sms or mobile notification , http endpoints , SQS, Lambda, kenisis data
SNS intergrates with a lot of AWS services
sns는 다양한 aws 서비스에서 데이터를 수신하기도 함
aws 에서 알람이 발생하면 이러한 서비스가 지정된 sns 주제로 알림을 보냄
AWS SNS - How to publish
주제 게시(topic publish) - using the SDK
- create a topic
- create a subscription (or many)
- publish to the topic
위 단계를 거치면 모든 구독자가 자동으로 해당 메세지를 받게 됨
직접 게시(direct publish) - 모바일 앱 SDK 전용
- create a platform application
- create a platform endpoint
- publish to the platform endpoint
- 수신 가능 대상 : google, GCM, Apple APNS, Amazon ADM - 모바일 애플리케이션으로 알람을 수신
Amazon SNS - Security
SQS와 동일
암호화(Encryption) :
- 전송 중 암호화(in-flight encryption) : HTTPS API
- 저장 데이터 암호화(At-rest encryption) : KMS keys
- Client-side encryption (암호화-복호화는 클라이언트 몫임)
Access Controls - IAM 정책 중심
- 모든 SNS API 가 IAM 정책으로 규제됨
SNS Access Policies (similar to S3 bucket policies)
255. Amazon SNS and SQS - 팬아웃(Fan Out) 패턴
여러 SQS 대기열에 메세지를 전송하려 할 때, 모든 sqs 대기열에 메세지를 개별적으로 보내면 문제가 발생할 수 있음
- ex) 앱의 비정상 종료, 전송 실패, sqs 대기열의 추가
sns 주제에 한번만 푸시해도 원하는 만큼의 sns 주제의 여러 sqs 대기열을 구독할 수 있음
이때 대기열은 구독자(subscriber)가 되며 귿르 모두 sns 에 전송된 메세지를 받게 됨
팬아웃은 완전히 분리된 모델이므로 데이터 손실이 발생하지 않음
sqs 를 통해 데이터 지속성, 지연처리, 작업 재시도가 가능
팬아웃 패턴으로 더 많은 sqs 대기열을 sns 주제에 구독시킬 수 있음
이를 위해서는 sqs 대기열 접근 정책을 통해 sns 주제를 sqs 대기열에 메세지를 전송하도록 허용해야 함
(usecase) Application : S3 Events to multiple queues
s3이벤트를 여러 대기열로 보내야 하는 상황
s3 이벤트 규칙에는 제약 조건이 있음
- 같은 이벤트 유형 (ex 객체 생성)이나 images/ 등 같은 접두어의 조합에서는 하나의 s3 이벤트 규칙만을 적용할 수 있음
위와 같은 상황에서 동일한 s3 이벤트 알람을 sqs 대기열로 보내려면 fan-out 패턴을 사용해야 함
s3 버킷에 이벤트인 s3 객체가 있다고 가정하고, 이 이벤트를 sns 주제로 전송하기 위해 여러 sqs 대기열을 sns 주제에 구독시키면 됨 - 앱, 이메일, 람다 함수 등도 sns wnwpdp 구독 시킬 수 있음
(usecase) Application : SNS to Amazon S3 through Kinesis Data Firehose
kinesis data firehose(KDF) 를 통해 SNS 를 Amazon S3 로 보내는 방식
sns 는 kdf 와 통합되어있음
Amazon SNS - FIFO Topic
sns 에는 fifo 기능이 있어 주제 내의 메세지에 순서를 지정할 수 있음
이때 구독은 sqs fifo 만 할 수 있음
SQS FIFO 와 유사
- 메세지 그룹 id 에 따라 메세지를 정렬
- 중복된 id 나 콘텐츠에 대해 중복제거를 할 수 있음
- sqs 와 같이 sns fifo 도 제한된 처리량을 가짐
SNS FIFO + SQS FIFO : Fan Out
SQS FIFO 에 팬아웃 할 때는 팬아웃 패턴, 순서, 중복제거가 필요함
SNS - Message Filtering
sns 주제 구독자들에게 전송할 메세지를 필터링하는 JSON 정책
구독에 필터링 정책이 없으면 기본적으로 모든 메세지를 수신하게 됨
위 예시에서 구매 서비스가 sns 주제에 거래 내용을 전송함
거래 내용에는 주문번호와 제품명 등이 있음
여기서 sqs 대기열을 생성해서 모든 주문이 아닌 발주(placed)된 주문만을 처리하도록 하기 위해
sqs 대기열을 sns 주제에 구독시키고 json 필터링 정책을 적용함
- filter policy - State:Placed (발주된 주문)
- filter policy - State:Cancelled (취소된 주문)
- 취소된 주문에 적용한 필터링 정책 - 이메일 구독 생성
등 필터링 사용
256. SNS 실습
FIFO 와 Standard 유형
표준으로 놓고 나머지 모두 기본값으로 생성
생성 완료된 토픽 콘솔창에서 구독 생성
구독할 앤드포인트 유형은
이메일, 이메일-JSON, 플랫폼 애플리케이션 앤드포인트, Amaozn Kinesis Data Firehose(KDF), SQS, AWS Lambda, HTTP, HTTPS, SMS 가 있고 시험에 자주 출제된다고 함
이번 실습에선 단순하게 하기 위해 email 로 선택
내 이메일을 입력해주고 생성해주면
topic 콘솔로 가면 구독에 항목이 하나 추가되고
확인 대기중이라고 나온다
메일로 가서 confirm 해주면
콘솔에서 구독이 승인된 것을 확인할 수 있다
메세지 게시로 가서
이렇게 메세지를 게시해 보면
이렇게 메세지가 도착하는것을 확인할 수 있다
메세지 필터 하는것도 기대했는데 강의에서 다루진 않았다
길어져서 다음 포스트에 kinesis 파트를 이어서 포스팅