[싹틔움] 04/05 개발일지 알림서버 분리 MSA 방식

🌱 개요

싹틔움 메인서버에서 알림 기능을 구현하는 서버를 따로 분리해 MSA 방식으로 구현하고자 했다.

 

🌱 왜 굳이 서버를 분리할까?

1. 독립적인 확장성

알림 기능은 사용량이 급격하게 늘어날 수 있는 부분이다. 그렇기 때문에 MSA 로 분리하면 알림 서버만 별도로 스케일 업/아웃할 수 있어 유연성이 증가한다.

 

2. 장애 격리

알림기능에 트래픽이 몰리거나, 카카오 등 외부 API 알림 기능을 구현할 때 이 기능에서 문제가 생겨도 메인 서버에 영향을 주지 않아 안정성이 증가한다.

 

3. 독립적인 배포 및 개발

알림 서버는 다른 주기로 배포하거나, 다른 언어나 프레임 워크로 개발이 가능해진다. 

 

4. 유지보수 용이성

관심사가 명확하게 분리되어 집중적으로 관리할 수 있고 다른 팀원들과 협업시에도 수월하다. 코드베이스가 작아지고 역할이 명확해져서 유지보수하기 쉬워진다고 볼 수 있다.

 

5. 비동기 처리와 성능 개선

Kafka, RabbitMQ, Redis Stream 같은 메세지 큐와 연계해서 알림을 비동기로 처리하면 메인 서버는 빠르게 응답만 하고 알림 처리는 뒤에서 따로 처리가 가능하다.

 

6. 보안 분리

만약 알림서버에서 외부 서비스와 연결이 되고 메인 서버와 이를 분리한다면 보안 설정도 개별적으로 적용할 수 있어서 더 안전한 구성이 가능해진다.

---

🌱 메세지 큐 도입?

알림서버를 분리하고 메세지 큐를 도입하는 것이 꼭 필요할까

꼭 필요한 것은 아니다. 간단한 시스템이나 초기 단계 MVP 라면, 그냥 REST API 로 직접 알림 로직을 호출해도 된다.

하지만 규모가 커지거나, 성능/확장성/안정성이 중요해질수록 메세지 큐는 사실상 필수적이다.

 

💡 메세지 큐랑 연계하면 좋은 점

1. 비동기 처리로 성능 향상

알림은 사용자가 직접 기다릴 필요가 없는 작업이다.

메세지 큐를 사용해서 메인 서버는 빠르게 응답만 하고, 알림은 백그라운드에서 따로 처리하도록해 사용자 경험을 개선시킨다.

 

2. 트래픽 폭주 시 안정성

예를 들면 10시 일괄 알림, 또는 많은 수의 알림을 보내야하는 등 특정 시간에 알림이 몰릴 수 있는데, 메세지 큐는 알림 요청을 큐에 쌓아두고 순차 처리를 하기 때문에 안정성이 증가한다.

 

3. 재시도, 실패 처리

외부 푸시 서버가 일시적으로 다운되었을 때, 메세지 큐는 재시도 로직과 같은 기능으로 안정적인 처리를 도와준다.

 

4. 알림 서버를 유연하게 분리 가능

메인 서버와 알림 서버를 완전히 분리하고 메세지 큐로만 연결을 시키면 서로 독립적으로 운영이 가능하다.

 

5. 확장성

Kafka 나 RabbitMQ 를 통해 메세지를 여러 컨슈머 인스턴스가 동시에 처리가 가능하다.

이후 알림서버를 증축한다면 병렬로 처리해 대규모 트래픽에 유리하다.