확장 가능한 알림 시스템 설계 구상

Scalable Notification Design

 

확장 가능한 알림 시스템의 설계는 오랜 시간 저의 지적 호기심을 자극해왔던 주제입니다.

WAS를 스케일 아웃 할 경우에, 개별 WAS가 DB에 저장되어 있는 알림 정보를 특정 시간마다 조회해와서
알림을 발송할 경우, 중복 알림 발송이 발생할 수 있기에 수평확장 가능하지 않다고 판단했고,
이에 따라 하나의 큐처럼 동작하는 별도의 알림 서버를 구성해서 그곳으로 알림 요청을 보내야한다고 판단했습니다.

그러나 이 경우, 하나의 큐에서 알림들을 받아 처리하기 때문에, 이 역시 확장가능하지 않다고 생각했었는데요,
쿠팡 Reveal2021과 가상 면접 사례로 배우는 대규모 시스템 설계 기초의 내용을 접한 뒤,
이렇게 구성하면 되겠구나 하는 생각이 들어 도식표를 그려봤습니다.

하나의 알림 큐에 모든 알림 요청을 담고,
알림 큐는 알림 종류에 따라 해당 알림 큐에 요청을 분류해서 전달합니다.

가령 이메일 알림이면 이메일 알림 큐로, SMS알림이면 SMS알림 큐로 분류해서 전달하는거죠.

그리고 각 알림 큐에서 알림 아이템을 가져와서 알림을 처리하는 인스턴스들이 존재하는데요,
이 인스턴스들을 스케일아웃하면 각 알림 종류에 대한 스케일 아웃이 가능해질 거라고 생각했습니다.
또한, 알림을 실패했을 경우, 알림 큐에 다시 아이템을 담아서 재시도할 수 있습니다.

재시도할 때마다 횟수를 내부에 카운팅하여 일정 횟수 이상 실패시 별도 프로세스를 수행할 수도 있겠습니다.

현재 진행중인 MyRSS 프로젝트에선 주 1회 구독한 블로그의 새글을 모아서 메일로 보내주는 기능과,
구독중인 블로그의 새글을 Slack으로 알림 받기 기능을 이 알림 시스템 설계에 적용할 수 있을 것 같습니다.

가령 주1회 보내는 메일 서비스의 경우,
같은 날 같은 시간에 보낸다고 가정한다면, 회원 수가 늘어나면 
메일 발송 건수도 늘어나기 때문에, 큐에 담아서 처리하되,
전체 메일 발송에 소요되는 시간을 보고 담당하는 인스턴스의 수를 조절하는 게 가능할 것 같습니다.

소소하게 구상해본 내용을 기록해봤는데요,
추후 실제 적용하게 될지, 적용한다면 구상했던 내용과 어떻게 달라질지 기대됩니다.