🔭AWS SNS와 SQS를 비교하며 살펴보자!

안녕하세요 구독자님, DevOps 소식과 기술 지식을 정리해서 공유해드리는 DevOps 여행을 위한 소식지입니다.

AWS에는 SNS(Simple Notification Service)라는 서비스와 SQS(Simple Queue Service)라는 서비스가 존재합니다. 두 서비스는 이름의 약자가 비슷하고 메시지를 전달 및 처리하는 데에 사용한다는 점이 동일해서 혼동하기 쉬운데요.

그래서 이번 글에서는 AWS SNS와 SQS에 대해 비교하며 살펴보도록 하겠습니다.

메시지(Message)란 어떤 걸 의미하나요?

AWS SNS와 SQS에서 이야기하는 메시지는 말 그대로 문자열이 될 수도 있고, JSON 형식의 데이터일 수도 있습니다.

이런 메시지를 전달하는 서비스가 따로 존재하는 이유는 최근 마이크로서비스 아키텍처가 보편화된 것과도 관련이 깊은데요.

아키텍처 내에 존재하는 수많은 컴포넌트가 서로 데이터를 주고받아야 하는 상황이 빈번하다보니, 효율적이고 안전하게 데이터를 전송할 필요성이 높아진 거죠.

이렇게 메시지를 전송할 때 주로 사용되는 패턴 2가지가 있습니다. 바로 발행/구독(Pub/Sub) 패턴과 메시지 큐(Queue) 패턴인데요.

결론부터 이야기하자면, AWS SNS는 발행/구독 패턴을 따르고, AWS SQS는 메시지 큐 패턴을 따르는 서비스입니다.

각 패턴의 구조를 그림으로 표현하면 아래와 같은데요. 두 구조에 대해서는 AWS SNS와 SQS 서비스에 대해 알아보면서 좀 더 자세히 살펴보겠습니다.

AWS SNS는 어떤 서비스인가요?

AWS SNS는 발행자(Publisher)에서 구독자(Subscriber)로 메시지를 전달할 수 있는 관리형 서비스입니다.

애플리케이션과 애플리케이션 사이의(Application-to-Application, A2A) 알림 전송이 필요할 때 AWS SNS를 사용할 수 있는데요.

뿐만 아니라 애플리케이션이 이용자에게(Application-to-Person, A2P) 알림을 전송할 때에도 활용 가능합니다. 이땐 SMS 문자나 푸시 알림, 이메일 등으로 알림 전송이 가능합니다.

AWS SNS의 메시지 필터링이나 배치 전송, 중복 제거 등의 기능으로 아키텍처 간소화와 비용 절감 효과도 볼 수 있습니다.

그럼 AWS SNS는 어떻게 동작할까요? 위에서 잠깐 이야기한 것처럼, AWS SNS는 발행/구독 패턴을 따르는데요.

발행자는 토픽(Topic)이라는 논리적 접근 포인트에 메시지를 보내는 방식으로 구독자와 비동기적으로 통신할 수 있습니다.

그리고 클라이언트는 AWS SNS의 토픽을 구독해서 토픽에 게시된 메시지를 아래 유형의 엔드포인트로 받아볼 수 있는 것입니다.

이런 AWS SNS의 동작 방식을 그림으로 표현하면 아래와 같습니다.

AWS SNS는 메시지의 순서가 고정되도록 설정 가능하기 때문에 각 애플리케이션으로 보내지는 메시지의 정확성과 일관성 확보가 필요할 때 활용할 수 있는데요.

그리고 이렇게 전송되는 메시지는 AWS Key Management Service(KMS)로 암호화되기 때문에, 전달 과정에 프라이버시 보호가 필요할 때에도 활용 가능합니다.

AWS SNS는 분석, 컴퓨팅, 컨테이너, DB 등 다양한 AWS 서비스에서 발생한 이벤트를 클라이언트에게 알려야 할 때에도 유용하게 활용됩니다.

그럼 AWS SQS는 AWS SNS랑 어떤 점에서 다른가요?

AWS SQS는 마이크로서비스와 분산 시스템, 서버리스 애플리케이션과 함께 활용 가능한 관리형 메시지 큐 서비스입니다.

대규모 데이터에 대해서도 메시지가 누락될 걱정 없이 안정적으로 전달 가능하다는 장점이 있는데요.

또한 위의 AWS SNS와 마찬가지로, AWS Key Management 서비스를 활용해서 민감한 정보도 안전하게 전달 가능합니다.

AWS SQS는 사용량에 따라 유연하고 비용 효율적으로 스케일 조정이 가능하다는 장점도 있습니다.

그렇다면 AWS SQS는 어떻게 작동할까요? 아래 SQS에서 처리되는 메시지의 생명주기를 같이 살펴보며 알아봅시다.

참고로, 최대 메시지 보존 기간(Maximum message retention period)을 설정하면 큐에 해당 기간 이상 존재하는 메시지가 자동으로 삭제됩니다. 최대 메시지 보존 기간의 기본값은 4일입니다.

AWS SQS는 처음에도 잠깐 언급했던 것처럼, 마이크로서비스의 각 컴포넌트를 큐 서버로 간소하고 안정적으로 연결해야 할 때 활용 가능합니다.

그리고 프론트엔드 시스템과 백엔드 시스템을 분리시킬 때에도 AWS SQS를 활용할 수 있는데요.

프론트엔드에선 사용자의 요청이 있을 때 즉각적인 반응을 보내고, 백엔드에선 그 요청과 관련된 복잡하거나 시간이 상대적으로 오래걸리는 작업을 수행하는 비동기적인 작업 처리에 AWS SQS를 활용할 수 있는 것입니다.

마지막으로, 대규모 아키텍처에서 메시지의 순서는 유지하고 중복은 방지하며 메시지 처리가 필요할 때에도 AWS SQS를 활용 가능합니다.

지금까지 AWS SNS와 SQS에 대해 살펴봤는데요. 두 서비스 모두 비동기 방식으로 메시지 전달이 가능하다는 공통점은 있지만...

🔭마치며...

AWS에는 너무나 다양한 서비스가 존재하다보니, 정리하는 과정에서 내용이 참 방대하다는 느낌을 많이 받습니다. 이건 다른 공부나 일도 마찬가지일 텐데요.

그래도 긴 호흡이 필요하단 것은, 그만큼 그 일의 의미가 가볍지 않기 때문이라고 생각합니다.

지금 당장 결과가 눈에 보이지 않더라도, 낙담하지 않고 꾸준히 나아가는 한 주가 되셨으면 합니다.

혹시 이번 내용 관련해서 더 궁금한 점이 있으시다면 아래 메일리 댓글 남겨주세요.😀

그럼, 다음 소식지에서 보다 알차고 흥미로운 내용으로 찾아뵙겠습니다.

오늘도 감사합니다, 구독자님 😺

🔗References

- https://aws.amazon.com/sns/?nc1=h_ls

- https://docs.aws.amazon.com/sns/latest/dg/message-delivery.html

- https://docs.aws.amazon.com/sns/latest/dg/welcome.html

- https://docs.aws.amazon.com/sns/latest/dg/sns-event-sources-and-destinations.html

- https://seohyun0120.tistory.com/entry/AWS-SNS-vs-SQS-%EC%B0%A8%EC%9D%B4%EC%A0%90

DevOps와 클라우드 관련 기술 지식을 공유하는 블로그도 운영 중입니다 :)

🔭DevOps 여행을 위한 안내서