AWS의 S시리즈에 대해 알아봅시다.
0. 간략 정리
keyword: Messaging, 분산 어플리케이션, 디커플링
Queue란? 대기열(보관통),
왜 대기열을 사용할까요?
→ 서비스의 디커플링(분산)을 위해서 사용합니다.
만일 한 서버가 모든 작업 수행한다고 했을 때,
해당 서버에서 하나의 프로세스에서 오류가 난다면?
나머지 프로세스들도 모두 문제가 생깁니다.
(예를 들어 아마존-쇼핑사이트-의 모든 구매, 발송, 민원 처리 등이 단 하나의 서버에서 돌아간다면 어떨까요?)
한 이벤트 발생으로 인해 후속으로 조치해줘야 하는 이벤트들을 분산해서 처리할 수 있도록 도와주는 것이 SQS, SNS입니다.
그럼 SQS와 SNS차이가 뭐길래 따로 서비스가 존재하는 것일까요?
→ 둘의 가장 큰 차이는
SQS는 1:1
SNS는 1:多
관계라는 것입니다.
여기 SQS, SNS를 이용한 사례가 잘 나타난 그림이 있습니다.
출처: https://www.youtube.com/watch?v=mXk0MNjlO7A
1. SQS
공식 사이트:
AWS에서 가장 먼저 만들어진 리소스입니다.
AWS는 원래 클라우드 컴퓨팅 서비스를 하기 위함이 아닌, 아마존 웹사이트의 원활한 관리를 위해 만들어졌습니다.
Amazon이 본인들의 웹사이트를 관리할 때 가장 먼저 필요하다고 생각한 서비스가 바로 SQS라는 겁니다! (아마 블랙프라이데이 등의 이벤트마다 서버가 다운되는 문제를 겪으며 SQS가 가장 필요하다고 생각한 것은 아닐까 하고 추측합니다.)
따라서 SQS는 큰 이커머스 사이트 운영을 위해서 필수적인 서비스 중 하나라는 것을 추측해볼 수 있습니다.
마이크로 서비스, 분산 시스템 및 서버리스 애플리케이션을 위한 완전관리형 메시지 대기열
Amazon Simple Queue Service(SQS)는 마이크로 서비스, 분산 시스템 및 서버리스 애플리케이션을 쉽게 분리하고 확장할 수 있도록 지원하는 완전관리형 메시지 대기열 서비스입니다. SQS는 메시지 중심 미들웨어를 관리하고 운영하는 데 따른 복잡성과 오버헤드를 없애고 개발자가 차별화 작업에 집중할 수 있도록 지원합니다. SQS를 사용하면 메시지를 유실하거나 다른 서비스를 가동할 필요 없이 소프트웨어 구성 요소 사이에서 어떤 볼륨의 메시지든 전송, 저장 및 수신할 수 있습니다. AWS 콘솔, 명령줄 인터페이스 또는 원하는 SDK, 3가지 간단한 명령을 사용하여 몇 분 만에 SQS를 시작할 수 있습니다.
SQS는 도대체 뭐하는 서비스인가요?
쉽게 말해서 메시지 큐 서비스입니다.
→ ‘메시지들을 쌓아놓고 순서대로 처리한다’는 뜻입니다.
그럼 여기서 말하는 메시지는 뭐고 굳이 큐라는 걸 왜 써야 할까요?
예를 들어 여행관광웹사이트가 있다고 해봅시다.
여기에 여행지를 찾는 고객 한 명 접속했다고 생각해봅시다.
그리고 이 웹사이트는 ec2에 있다고 쳐봅시다.
고객이 찾는 검색관련 모든 정보는 하나의 메시지로 축약되어 SQS로 전달 됩니다. 메시지가 쌓이게 되면 또 다른 ec2인스턴스가 작동을 하고, 이 인스턴스는 어플리케이션 서버가 됩니다.
유저가 LA에서 뉴욕으로 가는 여행편을 알아봤다면 어플리케이션 서버는 수많은 여행사 웹사이트를 검색하여 좋은 딜을 찾아줍니다. 그리고 그 결과를 웹사이트에 돌려줍니다.
그럼 어플리케이션 서버가 죽으면? 큐가 지워질까요? 아닙니다!
성공할 때까지 특정 시간 동안 SQS에 머뭅니다.
(실패 된 메시지도 큐에 보관됩니다 -Dead Letter Queues-.)
이 점이 SQS를 사용하여 얻는 이점입니다.
SQS 실사용 예:
아테나스랩의 오늘학교 서비스에서 데이터 마이그레이션을 위해 SQS를 사용했습니다.
SQS의 특징
- 어플리케이션 컴포넌트 분리
- 컴포넌트 분리로 인해 어플리케이션을 독립적으로 실행
- 컴포넌트 분리로 인해우 용이한 메시지 운용 가능
2. 메시지 보관
- 최대 256KB에 해당하는 text 포맷 메시지 보관 가능
- XML, JSON, TXT 형태의 메시지 보관 가능
3. 메시지 가져오기
- AWS SQS API를 통한 메시지 꺼내오기 가능 (거의 모든 기능은 API로 구현 가능)
4. Buffer
- 프로세싱을 위한 데이터를 전달받는 컴포넌트와 데이터를 만들어내는 컴포넌트 사이에 존재하는 버퍼
5. Pull based
SQS는 메시지를 큐에 담아 놓는다는 것이 핵심 개념입니다.
사용하는 큐에는 두 가지 종류가 있습니다.
이 두 가지 차이에 대해 아는 것이 중요합니다 (시험에도 자주 나온다고 합니다).
SQS Queue 두 가지 종류
- Standard Queue (default)
- 초당 메시지를 주고받는 횟수가 거의 무제한
- 최소 한 번은 꼭 메시지를 전달 시킴
- 최대한 메시지가 들어온 순서대로 메시지가 나갈 수 있게 해줌
- 아주 가끔 중복 메시지가 전달 될 수 있음, 그리고 이 순서가 어긋날 수도 있음 (두 번째 특성 때문에)
2. FIFO (First In First Out) → 순서가 중요한 금융권 등에서 쓰이기 좋음
- 메시지가 들어온 순서대로 메시지가 밖으로 나감
- 딱 한 번만 메시지를 전달함 (실패해도 알바 아님)
- - 메시지 중복 허용 X
- - Consumer가 다시 요청 할 때까지 특정 시간 동안 Queue에 들어있음
- 초당 메시지를 주고 받는 횟수가 정해져있음
- - 300 TPS (transaction per second)
여기서 몇 가지 의문이 생길 수 있습니다.
“그런데 큐는 원래 기본적으로 FIFO 아닌가요?”
→ 맞습니다, 그런데 standard는 FIFO의 원칙을 철저히 따르지 않아서 그렇습니다.
- 그럼 FIFO만 쓰는 것이 낫지 않나요?
→ 아닙니다, 위의 FIFO가 가지는 한계를 보시고 Standard와 FIFO 중에 더 본인의 서비스에 적합한 큐를 선택하여 사용하시는 것이 좋습니다.
*간단히 정리하면 Standard는 횟수 제한이 없지만 순서가 안 지켜질 수 있고,
FIFO는 순서는 꼭 지켜지지만 횟수 제한이 있습니다.
문제1) 이건 어떤 종류일까요?
정답은 standard입니다.
SQS settings
1. Visibility Timeout
Queue에서 빠져나간 메시지를 Consumer가 읽은 후 Queue안에서 그 메시지가 invisible상태로 유지되는 시간
예컨대 여러 대의 어플리케이션 서버가 있고
메시지를 한 어플리케이션 서버가 픽업해갔다면,
똑같은 메시지를 다른 어플리케이션 서버가 픽업하지 못하도록
픽업된 메시지를 숨김(인비저블)처리 해야합니다.
픽업된 메시지를 얼마동안 숨길건지에 대한 세팅입니다.
디폴트는 30초 최대는 12시간입니다. (최소는 0초)
어플리케이션 서버는 30초 안에(디폴트) 메시지 내용을 처리하고 삭제 시켜야 합니다.
만약에 실패하거나 30초 안에 수행을 못하면 다시 메시지 큐 안에서 나타나게 되고
어플리케이션 서버가 픽업 하길 기다립니다.
- 만약에 처리해야하는 작업이 너무 길어서 기본으로 30초 이상이 걸리는데
이걸 실패 처리 (다시 메시지 큐에 나타나도록)하고 싶지 않다면 어떻게 할까요?
→ 이럴 때 Visibility Timeout을 바꿔주면 됩니다.
2. 폴링
폴링이란?
커스터머가 큐에 새로운 메시지가 들어왔는지 정기적으로 체크를 하는 것입니다.
메시지를 가지고 오는 것과는 다른 개념입니다.
- Short Polling
- Queue가 비어있어도 즉시 response를 반환 함
- Queue가 비어있을 때 빈 response가 반환 됨
- 빈 response에 대해서도 비용을 지불해야 함
2. Long Polling
- 정기적으로 Queue를 검사 함
- Long poll timeout이 되거나 Queue에 메시지가 들어가면 response가 반환 됨 (비어있는 response를 받을 일이 없음, 쓸모없는 데이터를 받을 일이 없다는 말임)
- 비용을 절감할 수 있음, 따라서 Short Polling보다 선호 됨
3. Dead Letter Queues, MaxinumReceives
대기열에 있던 이벤트가 실패하면 다시 대기열에 나타납니다.
만일 영원히 실패할 수 밖에 없는 태스크라면 어떨까요? 그곳에 영원히 붙잡혀 있을 것입니다. @.@
→ 이를 방지하기 위해 MaxinumReceives를 설정할 수 있습니다.
MaxinumReceives란?
몇 번 이상 실패하면 실패로 간주하고 다음으로 넘어가게 하는 것입니다.
(마치 멜론에서 연속 재생 시 한 곡 재생이 3번 이상 실패하면 다음 곡으로 넘어가는 것과 같다고 생각하면 됩니다.)
이렇게 실패한 이벤트들은 Dead Letter Queues에 저장이 됩니다.
그런데 Dead Letter Queues는 원래 디폴트로 있는게 아니라서, 직접 Dead Letter Queues 목적의 큐를 만든 다음에 기존의 큐에 Dead Letter Queues로 연결해줘야 합니다.
4. Delay Queues
큐 안의 메시지 전달을 지연시킬 수 있습니다.
0초부터 15분까지 사이에서 결정할 수 있습니다.
2. SNS(Simple Notification Service)
공식 사이트:
완전관리형 pub/sub 메시징, SMS, 이메일 및 모바일 푸시 알림
Amazon Simple Notification Service(Amazon SNS)는 애플리케이션 간(A2A) 및 애플리케이션과 사용자 간(A2P) 통신 모두를 위한 완전관리형 메시징 서비스입니다.
SNS 특징
- 클라우드로부터 Notifications를 전달받는 용도로 사용
- 어플리케이션으로부터 전달받은 메시지들은 다른 어플리케이션 혹은 구독자 (사람이 될 수도 있고 웹사이트 등 서비스가 될 수 있음)들에게 전달됨
- 1:多 관계 (app to app, app to person), Fan out pattern
- Push based
출처: https://www.youtube.com/watch?v=bktTomENEX8&list=PL0FVXJOlM-fYYxwftQ80tOFBcB8IP96uQ&index=2
SNS 활용 용도
- Push Notifications
- 디바이스로 -핸드폰 & 태블릿(IOS, 구글, 윈도우, 안드로이드 호환)- 안드로이드, IOS 별로 맞춰서 알아서 메시지를 보내줌, 호환성이 매우 뛰어남
2. Email
- SQS 혹은 다른 http endpoint로 전송
3. Lambda
- Lambda를 호출하여 message 처리
- 다른 SNS로 보내거나 다른 AWS 리소스로 전송
PUB — SUB MODEL
이 친구를 이해하려면 꼭 알아야 하는 개념이 있습니다.
바로, PUB — SUB MODEL입니다.
PUB — SUB MODEL이란?
PUBLISH
: ‘메시지를 특정 토픽으로 보내다.’ 라는 뜻입니다.
SUBSCRIBE
: ‘내가 구독한 토픽으로 들어오는 메시지를 전달 받는다.’ 라는 뜻입니다.
e.g)
쇼핑몰 웹사이트 어플리케이션이 있다고 가정해봅시다.
손님A가 물건 구매 (구매 성공) 시,
이 구매 성공 메시지는 SNS로 전달 후 TOPIC으로 전달(여기서는 ‘구매 성공 토픽’)됩니다.
그리고 이 메시지는 ‘구매 성공’ 토픽을 보고 있는 구독자에게 전달 됩니다.
(서비스에서 사용하는 토픽들은 구매 성공, 구매 실패, 배송 시작, 배송 완료 등 다양한 종류가 있습니다. 이 토픽들을 보고 있는 구독자들이 있습니다. 람다함수, 이메일, 핸드폰 기기 등…)
Topic
구독자들이 Subscribe하고 메시지를 전달받는 만남의 광장 역할
출처: https://www.youtube.com/watch?v=mXk0MNjlO7A
SNS 장점
- 메시지를 즉시 보냄(딜레이 X)
- 간편함(다른 어플리케이션과의 연동도 편리함)
- 뛰어난 호환성
- 저렴한 비용
- SNS구축 및 토픽 생성에는 비용이 발생하지 않음, 토픽에 특정 메시지가 들어오고 구독자들로부터 메시지가 읽혀질 때만 비용이 발생됨
5. 메시지 필터링 가능
- 구매, 환불 토픽을 만들고 어떤 람다함수는 구매만 처리하게, 다른 람다 함수는 환불만 처리하게 세팅 할 수 있음
SNS VS SQS
3. SES(Simple Email Service)
공식 페이지:
서울 리젼은 2020년 7월부터 사용 가능
대용량 인바운드 및 아웃바운드 클라우드 이메일 서비스
Amazon Simple Email Service(SES)는 개발자가 모든 애플리케이션 안에서 이메일을 보낼 수 있는 경제적이고, 유연하며, 확장 가능한 이메일 서비스입니다.
SES 특징
- 마케팅팀 혹은 개발자들에게 특정 이벤트 발생 시 email notification을 보낼 수 있음
- 이메일을 보내거나 받을 수 있음
- 이메일을 받을 시 Lambda 혹은 SNS를 트리거 시킬 수 있음
SES 사용 용도
- Email 자동화
- - 온라인 쇼핑 (배송 상태, 구매 내역 등)
- - 마케팅 이메일 (뉴스레터, 스페션 오퍼 등)
SES VS SNS
이메일은 SNS로도 보낼 수 있는데, 왜 SES가 있을까요?
→ 간단하게 말하면 SES는 이메일 말고는 아무 것도 하지 않습니다.
그리고 SNS는 텍스트 이메일만 보낼 수 있습니다. (HTML 이메일 보내기 불가능)
SES
- Email Messaging Service
- 람다함수 & SNS Notification 호출
- 들어오고 나가는 이메일 처리 가능
- 메시지를 보내기 위해 이메일 주소만 있으면 됨
SNS
- PUB/SUB Messaging Service
- 다양한 메시지 타입 지원
- 람다함수 호출
- Notification을 받기 위해 Consumer는 토픽을 꼭 subscribe 해야 함
- 주고 받기를 수행하기 위해 일종의 프로토콜을 지켜야 함
제가 SQS, SNS, SES에 대해 사내 발표를 진행했었는데,
팀원이 SES에 관한 질문을 주어 답변한 적이 있어
아래에 팀원이 준 질문과 그에 답변을 같이 기재해보았습니다.
- 질문 내용
“구글 계정으로 SES서비스를 이용하여 대량 메일을 보낼 경우 구글 측에서 전송량에 리밋을 걸어서 원하는 만큼 메일을 보낼 수 없다. 이 부분에 대한 해결책이 있는지?”
- 답변
SES 이메일 인증을 해봐서 아시겠지만,
SES에서는 이메일은 인증만 받을 뿐
SES에 해당 이메일 계정의 로그인 정보를 이용하여 해당 도메인의 서비스를 이용해서 메일을 주고 받는 게 아닙니다.
e.g.) 내가 SES를 통해 내 다음 메일로 보낸 메일
발신자가 nameunskadms@hanmail.net로 되어있습니다.
해당 계정에 로그인해서 1월 11일자의 발신 기록을 보겠습니다.
해당 계정에서는 해당 날짜에 메일을 보낸 이력이 아예 없습니다.
아마 AWS 계정 자체에 limit이 걸려있어서 문제 발생하는 것으로 예상 됩니다.
AWS 계정에서 메일 보낼 수 있는 limit늘리는 방법은 아래 블로그 참고하면 좋을 것 같습니다.
https://medium.com/sjk5766/aws-ses-smtp를-활용한-대량-메일-전송-시스템-정리-e32863abbe4c
사용 예제
AWS 공식 문서에 내용 정리가 잘 되어있어, 문서만 잘 따라하면 사용은 간단합니다.
이메일을 보낼 주소들을 배열로 만들어 위 사진 params의 ToAddress 값으로 넣으면 됩니다.
4.같이 비교되는 기타 서비스
: Kafka, ActiveMQ, RapidMQ, RabbitMQ 등
- SQS: Queue model
- SNS: Pub(publish)/sub(subscribe) model
- Kinesis: Real-time streaming model
1. Kinesis
https://aws.amazon.com/ko/kinesis/
kafka 비교
https://haloworld.tistory.com/146
2. Amazon MQ
Active MQ란?
온프레미스였던 걸 클라우드로 옮길 때 사용하는 서비스입니다.
managed Apache ActiveMQ와 같습니다.
https://www.datadoghq.com/blog/activemq-architecture-and-metrics/
https://aws.amazon.com/ko/blogs/korea/amazon-mq-managed-message-broker-service-for-activemq/
[Spring] Spring boot에서 Amazon MQ(Active MQ) 연결하기
https://zorba91.tistory.com/316
3. Event bridge
https://aws.amazon.com/ko/eventbridge/
https://www.youtube.com/watch?v=RoKAEzdcr7k
SNS랑 비슷한 서비스입니다.
EventBridge는 나온지 얼마 안 되었고
토픽이 아니라 이벤트 버스라는 개념을 사용합니다.
서드파티 인터그레이션이 쉽고,
한 룰마다 맥시멈 5타겟 설정이 가능합니다.
AWS SQS vs SNS vs EventBridge — When to Use What?
https://www.youtube.com/watch?v=RoKAEzdcr7k
참고
- 인프런
- 유튜브 채널: Be a better dev
- Udemy
사내 AWS 스터디에서 발표한 내용입니다.
모쪼록 읽으시는 분들에게도 조금이나마 도움이 되기를 바랍니다 :)
