*이미지 출처 - https://beabetterdev.com/

개념

SNS와 SQS는 AWS에서 제공하는 메시지 전달 서비스로, 각각이 가진 특징으로 효율적이고 안정적인 시스템 구축이 가능하다.

AWS SNS(Simple Notification Service)

애플리케이션 대 애플리케이션(A2A) 및 애플리케이션 대 개인(A2P) 통신에 사용되는 분산 pub/sub 시스템

pub/sub 이란?

메세지를 공급하는 주체와 소비하는 주체를 분리해 제공하는 메세징 방법

→ 우체통(Topic)에 집배원(Publisher)이 신문을 배달하는 행위가 있고, 우체통에 신문이 배달되기를 기다렸다가 빼서 보는 구독자(Subscriber)의 행위가 있다.

💡 이를 푸시 알림에 적용해보면, 다음과 같이 이해할 수 있다.

• 서버에서 메시지 전송 - Topic 메시지 게시(pub)
• 사용자의 특정 이벤트 - Topic 가입(sub) 및 메시지 푸시

💡 이를 채팅 서비스에 적용해보면, 다음과 같이 이해할 수 있다.

• 채팅방 생성 - pub/sub 구현을 위한 Topic이 생성됨
• 채팅방 입장 - Topic 구독
• 채팅방에서 메세지를 송수신 - 해당 Topic으로 메세지를 송신(pub) / 수신(sub)

SNS를 사용하면, 다양한 유형의 Subscriber에게 메시지를 전송할 수 있다.

A2A

• AWS SQS 대기열
• AWS Lambda 함수
• HTTP endpoint

A2P

• end-user 장치
  • SMS 메시지
  • 전자 메일
  • 푸시 알림

위와 같이 여러 프로토콜을 지원한다는 장점이 있고, 이들과 결합하여 더욱 복잡한 시스템의 구축이 가능하다.

👍🏻 SNS의 장점!

확장성의 측면에서, 자동으로 메시지 전달 처리를 확장해주기 떄문에 시스템의 규모가 커질 때 별도의 구성이나 관리가 필요없다. 또한 여러 가용 영역에 메시지가 저장되어 서비스 중단이나 데이터 손실이 거의 없는 높은 내구성을 가진다.

AWS SQS(Simple Queue Service)

마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 위한 완전관리형 메시지 대기열(Queue)

대부분의 메시징 미들웨어와 같은 구성 요소로 구성된다.

종류	기능
Producers	처리할 작업 메시지를 SQS에 등록
Queue	메시지를 저장하는 큐
Consumers	큐 대기열에 있는 메시지 목록을 조회하여 받아옴(pull)

👍🏻 SNS의 장점!

확장성의 측면에서, 자동으로 큐를 확장하고 관리해주기 때문에 시스템 성장 시 별도의 구성이나 관리가 필요하지 않다. SNS와 마찬가지로 여러 가용 영역에 메시지가 저장되어 서비스 중단이나 데이터 손실 역시 거의 없는 높은 내구성을 가진다.

또한, 비동기적으로 작업을 처리하여 시스템의 응답 시간을 개선하고 다양한 작업을 동시에 처리할 수 있다는 장점이 있다.

👨‍👩‍👧‍👦 우리 엄빠도 어렸다 는 지금!

• 동기 방식: 스케줄링된 작업이 수행되는 동안 해당 작업이 끝날 때까지 기다리는 방식
  • 푸시알림을 보내는 작업이 스케줄링될 때마다 그 작업이 끝날 때까지 기다리는 경우
  • 스케줄링된 작업이 끝나기 전까지 다음 작업 실행 X
• 비동기 방식: 스케줄링된 작업이 완료되기를 기다리지 않고 다음 작업을 계속 실행하는 방식 ☑️
  - 푸시알림을 보내는 스케줄링 작업이 백그라운드에서 실행
  - 다음 작업과는 독립적으로 처리됨

차이점은?!

	SNS	SQS
통신 형태	A2A, A2P	A2A
메시지 처리	- 푸시 메커니즘: 사용자에게 메시지를 전송(push)한다 - Fanout: 같은 메시지를 여러 방향으로 발행	- 긴 폴링(풀) 메커니즘: 사용자가 대기열에서 메시지를 가져온다(pull) - Decouple: 여러 서비스로 분리하여 병렬식 비동식 처리
시스템 종류	pub/sub 시스템	큐잉 시스템
메시지 보관	메시지를 받는 사용자가 없으면 몇 번 시도 후에 삭제된다 (메시지 지속X)	메시지는 일정 기간동안 유지된다 (메시지 지속 가능: 1분~14일)
활용	실시간 알림이 필요한 애플리케이션에 사용 → 하나의 메시지를 사용자들이 각각 다른 방식으로 활용 [EX] ① 최종 사용자에게 이메일, SMS 및 푸시알림을 실시간으로 전송(Apple, Googlr, FireOS, Windows 장치 등) ② 여러 가입자에게 메시지 브로드캐스트(모든 사용자에게 동일한 푸시알림 출력) ③ SNS를 사용하여 분산된 앱 간에 이벤트를 전달하거나, 다양한 비즈니스 시스템에서 레코드를 업데이트 ④ 실시간 경고 및 애플리케이션 모니터링	메시지 처리에 사용 → 하나의 메시지를 사용자들이 동일한 방식으로 활용 [EX] ① 비동기 처리 워크플로우 ② 여러 SQS 대기열을 사용하여 메시지를 병렬로 처리 ③ 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션의 분리 및 확장 ④ 신뢰할 수 있는 메시징 보증(주문, 정확한 1번의 처리)을 통해 이벤트 전송, 저장 및 수신

→ 이들을 결합하면 더 강력해지겠지?

SNS와 SQS를 함께 사용하면 이벤트에 대한 즉각적인 알림이 필요한 애플리케이션에 메시지를 전달할 수 있음과 동시에, 다른 애플리케이션이 나중에 처리할 수 있도록 SQS 대기열에 지속될 수도 있다.

메시지가 Topic에 게시되는 정확한 순서로 구독된 SQS FIFO 대기열에 메시지를 배달하는 SNS Topic을 사용할 수 있다. SQS FIFO 큐의 소비자는 큐로 전송되는 것과

우리들의 이야기

이러한 플랫폼을 사용하면 좋은 점은 무엇일까?

단순 푸시알림 구현에는 FCM 만 사용해도 되겠지만, 당장 트랜잭션 처리나 동시성 문제 등으로 하나의 서버 내에서 API와 푸시알림 스케줄링이 모두 이루어지는 것이 서버가 점점 무거워지는 이유 중 하나라고 생각했다.

사용자 수가 늘어남에 따라 특정 시간에 보내는 푸시알림이 대용량으로 처리되어야 하는 순간이 필요할 수 있다. 서버에서 단순히 FCM으로 구현한 현 상황에서 대용량의 푸시를 보낸다면 사실상 비동기가 아닌 동기처리 방식으로 보내면서 푸시의 대기 요청이 쌓이게 될 것이다. (현재는 쓰레드 풀이 10으로 설정되어 한번에 10개까지 비동기로 보낼 수 있다)

아마 이러한 이유로 다른 API 호출 작업과 겹쳐지면서 서버가 다운되거나 복불복으로 알림이 오는 등의 문제가 발생했을 가능성이 크다 🚨

이것이 바로 비동기 메시지 처리 방식인 Queue를 활용해야 하는 이유이다.

또한, SNS와 SQS 중 어떤 것을, 혹은 둘 다 사용해야 하는가에 대한 질문에서는
FCM이라는 A(Application)과의 통신을 해야 하므로, A2A가 지원되는 것을 기본으로 하면서 여러 소비자에게 동일한 메시지를 보내는 것(ex. 전체 공지 등)보다 하나의 소비자가 이벤트를 발생시킬 때마다 보내는 메시지가 적합하다고 생각한다. 물론 우리 서비스의 특성상 부모자식 두 유저가 한 쌍으로 움직여서 이를 다수의 소비자로 고려해야 할지, 단일 소비자로 고려해야 할지에 의문이 남아있지만 일단은 SQS 하나만 운영해도 괜찮다고 생각한다.

현재는 푸시알림 기능을 MVP로 최소한의 구현만이 이루어진 상태이지만, 서비스의 확장성을 생각해보면 알림에 대한 항목과 그 메시지들이 점점 쌓일 때 감당해야 할 서버의 부하를 미리 고려하는 것도 좋은 방법일 것 같다!

AWS SQS를 사용하면 단순 푸시 메시지 전송뿐만 아니라 스케줄링 작업도 효율적으로 처리할 수 있다!

AWS SQS는 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 위한 완전관리형 메시지 대기열(Queue)라고 앞서 설명했다.

즉, 분산된 아키텍처에서 비동기 메시지 전달을 지원할 수 있기에 스케줄링 작업과 같이 분산되어 처리되어야 할 작업에 적합한 것이다!

⚡ AWS SQS를 사용하여 스케줄링 작업을 효율적으로 구현하는 방법

1. 스케줄링 작업을 메시지로 전달

   특정 시간 또는 주기적으로 실행되어야 하는 작업을 메시지로 전달 가능

   → 메시지를 큐에 보내는 것은 특정 작업을 예약하는 것
   

2. Worker 서버 구성

   SQS에서 메시지를 받아 작업을 처리하는 Worker 서버 구성 가능

   → Worker 서버에서는 메시지를 직접 꺼내와 작업을 처리하고 결과를 반환할 수 있다
   

3. 가용성 및 확장성

   • 여러 Worker 서버를 사용하여 작업을 병렬 처리
   • 필요에 따라 SQS 큐의 용량을 조절하여 처리량을 관리

4. 지연 및 실패 처리

   메시지의 Delayed Delivery 기능을 사용하여 메시지를 일정 시간 동안 대기시키는 지연 시간 설정 가능

   → 특정 시간 후에 작업을 실행하거나, 예상치 못한 실패 시 다시 시도하는데 유용
   

5. 비동기성과 분리

   스케줄링 작업을 SQS를 통해 비동기적으로 처리함으로써 애플리케이션의 주요 로직과 분리
   ⇒ 애플리케이션의 응답 시간을 최적화하고 병목 현상을 줄일 수 있습니다.
   

6. 모니터링과 로깅

   각 메시지의 상태 및 처리 이력을 추적
   

7. Dead Letter Queue(DLQ)

   작업 처리 중에 예외가 발생하는 경우, SQS의 Dead Letter Queue를 활용하여 실패한 작업을 따로 관리하고 분석할 수 있음
   

8. 스케일 아웃

   • 작업 부하가 증가하면 필요에 따라 Worker 서버를 추가하여 확장가능
   • 또한 AWS에서 제공하는 관리형 서비스인 Amazon ECS, AWS Lambda 등과 연계하여 더욱 유연한 확장이 가능
     
     

참고 자료

AWS SNS vs. SQS (feat. Lambda)

[AWS] AWS SNS와 SQS를 사용한 이벤트 처리 구현하기 (w.Spring Boot)