이전글 Part1 에서는 푸시를 처리하고 실제 유저들에게 전송하기 위한 직전까지의 과정에 대한 내용이었습니다.
이번글에서는 전송을 위한 구조와 그 데이터 처리에 대한 내용을 다뤄봅니다.
먼저 이번 앱 푸시를 위한 프로젝트를 진행할 때에 가장 신경을 써야 했던 부분은 다음과 같습니다.
- 자동화가 포함된 푸시
- 앱이 백그라운드, 포그라운드 상태에 관계없이 트래킹이 가능해야함
- 키워드 알림
먼저 일반적인 관리자가 직접 작업을 예약하거나, 특정 유저의 이벤트 발동시에만 전송되는 푸시알림에 있어서는, 엄청난 양의 푸시가 지속적으로 전송되는 것이 아니기 때문에, 그 시점마다 즉시 서버에서 FCM을 통해서 사용자의 기기에 푸시를 전송해도 무리가 되지는 않는다고 생각합니다.
하지만, 지속적으로 다른 시점에 꾸준히 알림을 전송해 주어야 했고, 무엇보다 키워드 알림이라는 기능으로 인하여, 예상하지 못한 변수들이 생길 것 같아 조금은 더 안정적인 푸시 전송 구조를 가지고 있어야 한다고 생각했습니다.
그래서 가장 기본적인 아파치 카프카를 이용해 푸시알림을 기기로 전송하는 로직을 구현하기로 하였습니다.
카프카를 사용한 이유
- 앞선 글에서 설명한 것처럼 푸시전송을 트리거하는 서버가 분산되어 있기 때문에 각 서버에서 처리하게 된다면 효율성이 떨어지게 됩니다.
- 푸시알림의 특성상, 야간 알림 허용 여부, 마케팅 알림 허용 여부등 푸시를 사용자에게 전송할 때에 조건들이 있는데, 이 조건은 푸시데이터를 만드는 시점이 아닌, 실제 전송 직전에 처리하는 것이 바람직 하다고 생각하였습니다.
- 전송 실패시 재시도 및 각종 케이스에 대응하는 것에 있어 카프카를 사용했을 때에 처리가 수월해 집니다.
- 카프카라는 이벤트 브로커의 특성상 처리시 이벤트(메시지)가 사라지게 되는 것이 아니기 때문에 로깅과 같은 전처리, 후처리 작업에 용이합니다.
기존 시스템
먼저 기존에 개발을 해왔던 푸시 시스템에 대한 설명입니다.
원래는 푸시나, 알림을 보내는 시점이 많지가 않았고, 서비스 알림밖에 존재하지 않았기 때문에, 각 요청 서버별로 푸시를 전송하는 시점마다 반복적으로 아래의 작업들을 진행해 주어야 했습니다.
- 푸시를 전송해야 하는 시점에 푸시 데이터를 생성한다.
- 보낼 타겟 그룹을 찾고, 알림허용, 광고 수신 여부, 야간 알림 허용등의 필터링을 거친다.
- 데이터와 필터링된 데이터들을 각각 데이터를 처리하고, 저장한 뒤에 FCM서버로 전송한다.
- FCM서버로 받은 응답결과를 저장한다.
이렇게 되었을 때에 가장 큰 단점은 푸시를 보내는 시점별, 서비스별로 각각 필터링과 서비스에 맞는 푸시데이터를 구조화 해주어야 한다는 단점이 가장 컸습니다.
물론 실패시 재시도와 같은 안정성 부분에서도 어느정도 노력을 기울이면 커버는 가능했지만, 효율적인 로직을 설계하기는 상당히 까다로웠습니다.
그렇다면 이벤트 브로커를 사용하게 된다면 어떻게 구현할 수 있을까요?
이벤트 브로커를 활용한 시스템
위에서 처리한 로직들을 분류해서 보면 조금 편하게 이해할 수 있는데, 기존에 서버별로 처리하던 작업은 아래와 같이 한 단계만 거치게 됩니다.
- 푸시를 전송할 시점에 데이터를 만들어 카프카 프로듀서를 통해 카프카로 전송을 합니다.
그 뒤에 카프카 컨슈머가 동작하고 있는 푸시서버에서 아래와 같은 통합된 로직을 실행하게 됩니다.
- 보낼 타겟 그룹을 찾고, 알림허용, 광고 수신 여부, 야간 알림 허용등의 필터링을 거친다.
- 데이터와 필터링된 데이터들을 각각 데이터를 처리하고, 저장한 뒤에 FCM서버로 전송한다.
- FCM서버로 받은 응답결과를 저장한다.
카프카를 사용했을 때의 장점같은 경우 서버간의 데이터를 통신구조를 간소화할 수 있다는 장점이 있겠지만, 실제로 이번 푸시와 같은 서비스를 구현할 때에는 데이터를 주고 받는 것에 있어서도 장점으로 작용 하였지만, 실질적인 코드의 품질에서도 좋은 영향이 있었던 것 같습니다.
후기
물론 간단하게 보았을 때 위와 같은 그림으로 설명 할 수 있었지만, 이번에 저희 서비스에 대한 푸시 서비스를 개발하였을 때는 조금 많은 시행착오를 경험한 것도 사실...
실제로는 크로스 플랫폼 앱 개발, 서버, 어드민 개발을 병행하였기 때문에 어쩌면 2주만에 배포까지 도달 한 것이 다행이라고 생각한다.
아래 이미지는 그 흔적들
글에서는 서버쪽에서의 컨트롤만 다루었지만, 실제로 이번에 개발을 진행할 때에는 이전에 푸시 개발시점과는 다르게,
서버는 실제 로직 구현보다는 설계쪽에서 힘이 더 들였는데, 과연 결과는 어떨까
앱에서는 각종 플로우의 시점마다 기기권한과 서비스측 허용여부를 다루어 줘야 했는데, 이번에는 서비스의 특성상 이 부분을 구현하는 것이 조금 까다로웠다.
