[FCM] 알림을 만들어보자 - 1. 어떤 기술을 사용할까?

낙경·2024년 4월 23일

코끼리 개발 일지

목록 보기

4/7

상황

우리 사이트는 이미 개발 중이고, 실제 오픈을 앞두고 있다.
거의 다 개발이 완료된 상황에서, 백엔드분들이 손을 떼게 되어 프론트엔드 인원만 남은 상황에 중요한 한가지를 빼먹었음을 깨달았다.

그것은 바로 알람기능 이었다.

단순히 어떠한 이벤트가 발생하면 메세지함에 표시되는 것은 물론이고, 브라우저 PUSH등을 활용하여 웹 사용자도 알림을 받아볼 수 있으면 좋겠다고 생각했다.

문제

하지만 알림 기능을 위해 어떤 기술을 선택할지가 문제였다.

Kafka?

처음에는 이런 알림이나 메세지 처리에 있어서 Kafka가 아주 많이 사용된다는 것을 보고 Kafka를 선택하려 했다.

강의를 보다보니, 뭔가 이상하다는 생각이 들었다.
프로듀서와 브로커, 컨슈머를 통해 데이터 처리를 쉽게 할 수 있다는 것은 너무 좋은 장점이었다.
하지만 보통 이 경우 로그나 분석 등 여러 요구사항이 함께 있을 때 사용하기 좋은것이지, 단순히 알람처리를 위해 Kafka 클러스터를 구축하기에는 너무 오버스펙이라는 생각이 들었다.

특히, Kafka 클러스터를 구축하고 싶으면 최소 3개의 브로커(애플리케이션 서버)가 필요하다는 것은.. 꽤나 어려웠다.

왜 문제?

공부를 위해서 시작한 프로젝트라 프론트엔드와 백엔드는 AWS 프리티어를 이용중이다.

그리고 원래는 프론트엔드와 백엔드의 서버가 아예 다른 인스턴스에 분리되어있었는데, 백엔드가 손을 떼게되면서 프론트엔드 서버가 있던 인스턴스 내로 백엔드 서버도 이관하게 되었다.

이정도로 비용을 0에 가깝게 쓰고 싶은 우리팀인데, 단순히 알림 기능 하나를 위해 세개의 추가 인스턴스를 사용하는 것은 무리였다.
물론 도커를 통해 한ㅔ 인스턴스 내에 클러스터를 구축하는 경우도 봤는데, 이 경우 Kafka의 이점(한 인스턴스가 망가져도 괜찮아~)을 활용하지 못한다는 점에서 의미가 조금 퇴색된 것 같았다.

사실 이런 저런 이유를 말했지만, 가장 큰 문제는 비용이다. 여러 서버를 돌릴만큼의 여유는 우리에게 없다. 프론트엔드 서버 백엔드 서버도 한 인스턴스 내에서 굴리는 판국에..

결론

FCM + 메세지 전송 서버 구축

사실, FCM은 가장 먼저 생각했던 솔루션이었다.
처음엔 백엔드 서버 내에 직접 FCM 관련 코딩을 해서 알림을 보내려 했다. Kafka에서도 최종적으로 컨슈머 단에서는 FCM을 사용하려고 했다.

어떻게 사용할 예정?

하지만 조금 생각을 바꿔서 메세지 전송 서버를 최소한의 인스턴스 비용 (t2.nano)으로 새롭게 구축하고, 아래와 같은 흐름으로 처리를 하기로 했다.

흐름

백엔드 서버에서는 메세지 이벤트 발생시, 메세지를 생성해서 메세지 서버에 보낸다.
메세지 서버는 데이터가 도착할 시, 메세지용 DB에 데이터를 저장한다.
DB에 저장된 데이터는, 클라이언트에서 메세지함을 확인할 때 사용된다.
또 데이터가 도착할 시, FCM에 요청을 하여 클라이언트에게 여러 방법(iOS, AOS, web ...)으로 알림을 보낼 수 있게 한다.