[SSE, Redis Pub/Sub, RDB] 확장성 있는 알림 기능 구현[SSE, Redis Pub/Sub, RDB] 확장성 있는 알림 기능 구현

확장성(Scalability)이란 소프트웨어가 증가하는 부하나 수요를 처리할 수 있는 능력을 의미한다. 즉, 사용자가 늘어나거나, 데이터가 증가하거나, 새로운 기능이 추가되더라도 시스템이 성능 저하 없이 원활하게 작동할 수 있는지를 나타내는 개념이다.
확장성이라고 하면 수평적 확장 혹은 수직적 확장 등 주로 DB나 서버 인스턴스에서 많이 들어봤을 개념이다.

우선 왜 폴링 롱 폴링은 제외 했는가?
- 폴링은 주기적인 확인 요청으로 비 효율적이다.
- 롱 폴링이 응답을 무한정 기다리지 않는다. 타임아웃 시간을 관리해줘야하며, 재요청 로직까지 고려해줘야 한다.
표를 봤을 때 WebSocket이 더 효과적으로 보이는데 왜 SSE를 사용했는가?
- 알림은 서버에서 일방적으로 주는 단방향 통신이다. 양방향 통신이 필요없는 상황에서는 SSE가 WebSocket보다 리소스를 더 효율적으로 사용한다.
- 자동 재연결, 단간한 설정 그리고 HTTP 기반 인프라 활용 등의 장점으로 SSE가 더 적합하다.

위 그림을 보면 Redis Pub/Sub의 역할을 쉽게 알 수 있다.
Redis Pub/Sub은 Redis를 사용하는 모든 서버에 구독과 발행을 시행한다.
- 'Check' 라는 이벤트를 구독하면, 누군가 'Check'라는 이벤트를 발행했을 때 해당 이벤트 내의 데이터를 읽고 처리하도록 로직을 구성하게 되는 것이다. 즉, Redis에 연결된 특정 서버한테만 이벤트를 발생시킬 수는 없다.
- 쉽게 생각하면 차 빼달라는 아파트 방송은 모두가 듣지만, 차주만 행동에 옮긴다. (차주가 행동에 안옮길 수 도 있다.....)
Redis를 활용한 처리 방식을 선택
- 서버를 연결하는 방법에는 다양한 네트워크 토폴로지가 있다.
  - 중앙 집중형, 버스형, 링형, 메쉬형, 트리형 등등
- Redis Pub/Sub은 중앙 집중형 토폴로지에 가깝다.
  - 어쨌든 여러 서버들의 공통 자원을 저장하는 어딘가가 필요한데, Redis 만한게 없긴하다.
  - 중앙 관리의 편의성은 한곳에서만 관리하면 돼서, 편리하다는 점이 있다.
  - 다만 Redis 서버의 성능과 용량이 네트워크 통신량보다 많아지만 병목이 될 수 있다.
- 결론은 가진 인프라에서 가장 쉽게 구현할 수 있기 때문이었다.

결과부터 말하자면, 위와 같이 알림 기능에 대한 ERD를 작성했다.
- 행동을 매수, 매도, 공지 사항 등을 Enum 처럼 사용한다고 할 수 있다.
- ex) action=1 일 때 "(param1)을 (param2)원에 (param3)개를 매수했습니다." 라고 알림이 생성된다.
- 이때 param들은 경우에 따라서 다른 테이블의 ID와 연결될 수 있다.
그렇다면 왜 param은 3개 까지 밖에 안만들었는가?
- 프로젝트 내에서 필요한 알림의 종류를 생각했을 때 param이 들어가도 많아봤자 3개 였다.
- 하지만 이건 확장성을 높였지만 반대로 떨어진것 이기도 하다.
  - 여기서 확장성을 좀더 높이려면 행동부터 param3까지 JSON 형태로 한 Column에 저장해는게 더 좋았을 수 도 있다.
  - 특히 프로젝트에 사용한 PostgreSQL은 JSON 타입을 다루는데 MySQL보다 뛰어나기 때문이다.
FaceBook이 Meta로 바뀌는 것은 어떻게 처리하는가?
- 각각의 action에 따라서 param을 저장할 때 FaceBook이 아닌 기업 정보가 저장된 테이블의 ID로 저장해둔다.
- 예를들어 Facebook의 ID가 10245라면 기업 정보가 저장된 테이블의 name만 바꿔준다면, 알림 문자열을 생성할 때 id를 통해 name을 가져오면 되기 때문에, 능동적인 알림 생성이 가능하다.

codebylhbs