프로젝트에서 푸시알림 기능을 맡아 사용할 기술을 찾아보던중 AWS SNS 라는 것을 처음 접했다. 단순히 푸시알림을 구현하는 데만 신경쓴다면 FCM을 사용해도 상관없겠지만 AWS SNS에 Lambda, SQS 등을 함께 사용하면 추후 기능을 확장하는데 용이할 것이라 생각되어 AWS SNS를 쓰기로 정했다.
Lambda 란
Lambda는 AWS에서 제공하는 서버리스 컴퓨팅 플랫폼 이다.
서버리스(Serverless) ?
서버리스(Serverless)는 클라우드 컴퓨팅의 모델 중 하나로 개발자가 서버를 직접 관리할 필요가 없는 아키텍처를 의미한다.
서버리스는 동적으로 서버의 자원을 할당한다. 사용자가 없다면 자원을 할당하지 않고 대기하다 요청이 들어오면 그 때 자원을 할당해서 요청을 처리하고 다시 대기 상태로 들어가게 된다.
- 자원을 효율적으로 사용할 수 있고
- 대기상태를 제외한 실제 사용 자원에 대해서만 청구되기 때문에 굉장히 경제적이며
- 해당 서버는 클라우드 제공 기업에서 전적으로 관리하기 때문에 개발자는 스케일링, 업데이트, 백업, 보안 등 서버에 대해 일절 관리하거나 신경 쓸 필요가 없어 비즈니스 로직에 집중하여 개발을 할 수 있다
따라서 코드를 계속 실행시키기 보다는 특정한 시기에만 실행시키는 경우에 Lambda를 사용하면 유용하다.
- 서버 띄우지 않고 간단한 코드를 실행시키고 싶은 경우
- 특정 기간 또는 특정 주기로 코드를 실행시켜야 하는 경우
- 트리거가 실행될때만 코드를 실행시키고 싶은 경우
Lambda 트리거 기능
람다 트리거란, 람다 함수를 실행할 수 있는 이벤트를 일컫는다.
간단하게 예를 들면, S3에 파일이 적재되면 이를 이벤트로 받아 람다 함수를 실행 할 수도 있고, 브라우저에 url을 치면 rest api로서 람다 함수를 실행 할 수도 있다.
이처럼 람다는 다른 AWS 서비스와 유기적으로 연동될 수 있다는 점에서 굉장히 파워풀 하다고 볼 수 있다.
람다 트리거는 다음과 같이 변화나 호출 같은 이벤트가 발생할 경우 함수 코드가 돌아가게 하여 값을 반환하게 할 수 있다.
- 데이터변화 : DB 데이터가 바뀌면 람다 함수 실행
- API Endpoint와 결합을 시켜서 직접 또는 Endpoint로 호출
- 리소스 상태 변화 : (CloudWatch를 통해) 리소스 상태가 어떻게 변화가 되었다면 람다 함수를 실행해서 이벤트에 대응
- Cron 주기별로 실행 : 정기적인 작업이 있을 경우 람다 활용
- API로 접근 가능한 모든 서비스/기능 호출 가능하기 때문에 외부 서비스 호출 가능
AWS SNS(Simple Notification Service) 란
AWS SNS는 애플리케이션 대 애플리케이션(A2A) 및 애플리케이션 대 개인(A2P) 통신에 사용되는 분산 pub/sub 시스템이다.
Publisher 는 Topic에 대한 메시지를 게시(pub)하고 Consumer 는 메시지를 수신하기 위해 이러한 Topic에 가입(sub)하여 Publisher가 SNS에 메시지를 보낼 때 메시지가 Subscriber에게 푸시된다.
AWS SQS 대기열, AWS Lambda 함수 및 HTTP endpoint과 같은 다양한 유형의 Subscriber에게 메시지를 전송할 수 있다(A2A). 또한 SNS를 사용하여 end-user 장치에 SMS 메시지, 전자 메일 및 푸시 알림을 보낼 수 있다.(A2P)
AWS SQS (Simple Queue Service)
AWS SQS는 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 위한 완전관리형 메시지 대기열이다.
대부분의 메시징 미들웨어와 마찬가지로 SQS는 세 가지 주요 구성 요소로 구성된다.
- Producers : 처리할 작업 메시지를 SQS에 등록
- Queue : 메세지를 저장하는 큐
- Consumers : 큐 대기열에 있는 메시지 목록을 조회하여 받아옴
SNS vs. SQS
SNS와 SQS의 주요 차이점
- SNS는 A2A와 A2P 통신을 지원하는 반면, SQS는 A2A 통신만 지원한다.
- SQS가 큐잉 시스템인 반면, SNS는 pub/sub 시스템이다. 일반적으로 SNS를 사용할 땐 Topic을 통해 여러 소비자에게 동일한 메시지를 보낸다. 이에 비해 대부분의 경우에서 SQS 대기열의 각 메시지는 한 소비자에 의해서만 처리된다.
- SQS를 사용하면 메시지가 긴 폴링(풀) 메커니즘을 통해 전달되는 반면, SNS는 푸시 메커니즘을 사용하여 가입된 엔드포인트로 메시지를 즉시 전달한다.
- SNS는 일반적으로 실시간 알림이 필요한 애플리케이션에 사용되는 반면, SQS는 메시지 처리 사용 사례에 더 적합하다.
- SNS는 메시지를 지속하지 않는다. 메시지를 존재하는 구독자에게 전달한 다음 삭제한다. 이에 비해 SQS은 메시지를 지속할 수 있다.(1분에서 14일).
| SNS | SQS |
| Topic(Pub/Sub) | Queue |
| Push: 사용자에게 메세지 전송 | Pull: 사용자가 메세지를 가져온다 |
| Fanout: 같은 메세지를 여러 방향으로 발행 | Decouple: 여러 서비스로 분리하여 병렬식 비동기 처리 |
| 메세지를 받는 사용자가 없으면 몇 번 시도하다가 삭제된다. | 메세지는 일정 기간동안 유지된다. |
| 하나의 메세지를 사용자들이 각각 다른 방식으로 활용 | 하나의 메세지를 사용자들이 동일한 방식으로 활용 |
AWS SNS 사용 예
- 최종 사용자에게 이메일, SMS 및 푸시 알림을 실시간으로 전송 (Apple, Google, Fire OS 및 Windows 장치에 푸시 알림)
- 여러 가입자에게 메시지 브로드캐스트(예: 앱의 모든 사용자에게 동일한 푸시 알림 출력).
- SNS를 사용하여 분산된 앱 간에 이벤트를 전달하거나, 다양한 비즈니스 시스템에서 레코드를 업데이트(예: 인벤토리 변경).
- 실시간 경고 및 애플리케이션 모니터링.
AWS SQS 사용 예
- 비동기 처리 워크플로우
- 여러 SQS 대기열을 사용하여 메시지를 병렬로 처리
- 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션의 분리 및 확장
- 신뢰할 수 있는 메시징 보증(주문 및 정확한 한 번의 처리)을 통해 이벤트를 전송, 저장 및 수신
SNS + SQS
AWS SNS와 SQS 모두 자체적으로 유용하지만, 이들을 결합해 보다 강력하고 신뢰할 수 있는 시스템을 만들 수도 있다. 예를 들어, SNS와 SQS를 함께 사용하면 이벤트에 대한 즉각적인 알림이 필요한 애플리케이션에 메시지를 전달할 수 있으며, 다른 애플리케이션이 나중에 처리할 수 있도록 SQS 대기열에 지속될 수도 있다.
또한 SNS와 SQS를 결합하여 엔드 투 엔드 메시지 정렬을 보장할 수 있다. 예를 들어, 메시지가 Topic에 게시되는 정확한 순서로 구독된 SQS FIFO 대기열에 메시지를 배달하는 SNS Topic을 사용할 수 있다. SQS FIFO 큐의 소비자는 큐로 전송되는 것과 동일한 순서로 메시지를 수신한다.
SNS + SQS + Lambda 의 다른 예는 여기 를 참고하자.
Reference.
'기타' 카테고리의 다른 글
| 우아한 테크코스 프리코스 회고 (0) | 2023.03.23 |
|---|---|
| 오브젝트 (역할, 책임, 협력/캡슐화와 응집도에 대하여) (0) | 2023.03.23 |
| [Web] HTTP, Web Server, WAS (0) | 2022.07.28 |
| 2022 AWS Cloud 입문 세미나 (0) | 2022.07.28 |
| Docker 란 (0) | 2022.07.28 |
댓글