알림기능 기술 선택(SSE, Redis Pub/Sub, Socket.IO)

채팅 기능에 이어 알림기능을 구현하게 되었다. 지난번에도 알림기능을 구현한 경험이있는데, 당시 시간도 촉박하고 아는것이 별로 없어 기술 선택시 다양하게 고려해보지 못했다. 하지만 이번에는 최종프로젝트인 만큼 여러 기술 중 우리의 서비스에 맞는 기술들을 엄밀히 고려해보려 한다.

구현하려는 기능

• 커뮤니티/리뷰의 새글 등록 및 댓글 등록시 알림
• 읽음/안읽음 기능
• 알림 클릭시 해당 게시물로 연결

이번 구현하는 알림기능에서 필요한 부분은 이렇게 세 가지가 있다.

해당 기능을 충족하는 기술 선택을 위해 여러 기술들에 대해 알아보았다.

 

고려 기술

1. Server-Sent Events (SSE)

• 특징:
  • 서버에서 클라이언트로 단방향 스트리밍을 제공.
  • HTTP 기반으로 작동하며, 브라우저와의 호환성이 높음.
  • 연결 유지 비용이 비교적 낮음.
• 장점:
  • 구현이 상대적으로 간단하며, HTTP 프로토콜을 그대로 사용하므로 방화벽 문제를 덜 겪음.
  • 메시지가 순서대로 전달되므로, 순차적인 알림이 중요한 경우 유리.
• 단점:
  • 단방향 통신만 지원하므로, 클라이언트에서 서버로의 즉각적인 응답이 필요한 경우에 한계가 있음.
  • 지원하는 브라우저가 제한적일 수 있으며, 특히 오래된 브라우저에서는 호환성 문제가 발생할 수 있음.

2. Redis Pub/Sub

• 특징:
  • Redis의 Pub/Sub 기능을 사용하여 메시지를 발행/구독 패턴으로 전달.
  • 주로 백엔드 시스템 간의 통신에 사용되며, 실시간 데이터 전송에 강점.
• 장점:
  • 높은 성능과 낮은 레이턴시로, 많은 클라이언트에게 동시에 메시지를 전달하는 데 유리.
  • 스케일링이 용이하며, 클러스터링 및 샤딩을 통해 확장 가능.
  • 복잡한 메시지 처리 및 분배 로직을 구현할 수 있음.
• 단점:
  • 클라이언트와의 통신을 직접적으로 지원하지 않으므로, Pub/Sub을 사용하려면 추가적인 서버 레이어(WebSocket 등)가 필요함.
  • 클라이언트가 연결되어 있지 않으면 메시지를 놓칠 수 있음(메시지 큐잉이 기본적으로 제공되지 않음).

3. Socket.IO

• 특징:
  • WebSocket을 기반으로 하며, 다양한 폴백 메커니즘을 통해 광범위한 환경에서 안정적인 양방향 통신을 지원.
  • 실시간 채팅, 게임, 알림 시스템 등에 널리 사용됨.
• 장점:
  • 양방향 통신을 지원하므로, 클라이언트와 서버 간의 실시간 상호작용이 필요할 때 유리.
  • 연결 상태에 따른 다양한 이벤트 처리(재연결, 연결 끊김 등)가 용이.
  • 브라우저와의 호환성 문제를 내부적으로 해결(예: 폴링, FlashSocket 등 폴백 메커니즘).
• 단점:
  • WebSocket을 지원하지 않는 환경에서는 성능이 저하될 수 있음.
  • 서버 부하가 커질 수 있으며, 특히 스케일링 시 추가적인 복잡성이 따를 수 있음.

 

선택

Redis Pub/Sub + Socket.IO

 

우선, Redis Pub/Sub을 선택한 이유는

알림 service뿐만 아니라 리뷰서비스, 커뮤니티 서비스 등 다양한 서비스에서 데이터를 주고받는 여러 서비스 아키텍처를 사용하며, 여러 서버에 실시간으로 다른서버에 전달하는 수평적 확장성의 필요가 있었다.

또한, 추후 유저에게 대규모 알림시스템과 같은 비동기 작업 처리가 필요한 기능이 개발될 수도 있는 것을 고려하여 선택하게 되었다.

 

그리고 Redis Pub/Sub이 클라이언트와의 통신을 직접적으로 지원하지 않기때문에 클라이언트와의 통신 기능을 하는 SSE와 Socket.IO 사이에서 고민하게 되었는데,

알림 기능이 단방향이긴하나, 읽음 안읽음 그리고 클릭시 해당 게시물로의 연결과 같은 알림 후 상호작용포함되어있기 때문에 확장성이 높은 양방향 통신인 Socket.IO를 선택하게 되었다.

 

 

1:1 채팅에 이어 또 다시 socket.IO를 사용하게되었는데, 한 기술에 대해 전문성을 가질 수 있는 기회라 여기고 더 열심히 고민하고 시도해봐야겠다.