Search
Duplicate
🌋

푸쉬 알림 아키텍쳐

: 특수한 응답유형인 푸쉬 알림 아키텍쳐

Push Notification

Push Notification이란?
: 서버에서 발생한 이벤트를 특정 클라이언트에게 이벤트 발생 사실을 통지하는 기술
Push Notification의 핵심 원리
: 먼저 OSPNS가 필요, OSPNS는 Operationg System Push Notification Service로 구글은 통상적으로 FCM, IOS는 APNS를 사용하는 듯 하다.
: 해당 2개의 OSPNS에 스마트폰 application과 백엔드 서버를 등록해야 한다.
: 간단하게 설명하면, Application을 FCM project에 등록할 때에는 Application의 패키지 이름과, Application의 고유 식별자를 이용
: FCM에 등록을 마치면 Application과 FCM의 통신에 활용되는 google-services.json이라는 설정파일을 받을 수 있고, 이를 App과 함께 배포
: Server는 별다른 등록이 불필요하며, Firebase Console에서 프로젝트마다 지정된 apiKey와 senderId를 서버에서 불러오면 됨
Application의 Token 발급
사용자가 채팅방에 들어갈 경우(특정 유형이 메시지를 받겠다는 요청) 일어나는 일들은 다음과 같습니다.
1.
Application에서는 Backend Server에 자신이 특정 채팅방에 입장하겠다는 요청을 보냅니다.
2.
Server에서는 해당되는 채팅방 그룹에, 해당 사용자의 id를 등록해둡니다.
3.
이전 ApplicationToken 발급 Phase에서 등록되었던 FCM token을 가져옵니다.
4.
token을 특정 Messaging Group에 추가해달라는 요청을 FCM에 보냅니다.
5.
FCM에서는 해당 Messaging Grouptoken을 추가합니다.
2번과 4번이 중복되어 보일 수도 있으나, 2번은 해당 채팅방에 대한 권한 확인을 위해 필요하고, 4번은 실제 메시지 발송을 위해 필요합니다.
이 외에도 이벤트 소식 등을 회원들에게 알리는데에도 Message group을 활용할 수 있습니다.(전체 알림 on/off가 아닌, 특정 알림 수신에 대한 동의 여부가 Message group)
Server의 Message 발송
사용자가 채팅방에 메시지를 남길 경우 다음과 같은 일들이 일어납니다.
1.
ApplicationBackend 서버에 메시지 발송 요청을 보냅니다.
2.
Backend 서버는 이 사용자가 해당 그룹에 속하는지 판단하고, message를 다듬습니다.(ex. 발송인이 누구인지 명시하는 경우)
3.
Backend 서버는 FCM에 해당 그룹에 속한 모든 기기에게 메시지를 발송토록 요청합니다.
4.
FCMMessaging Group의 테이블로부터, 모든 기기들의 token을 얻습니다.
5.
FCM은 각 token에 해당하는 endpoint에 메시지를 발송합니다.
6.
message를 받은 사용자 기기는, 사용자가 해당 채팅창을 보고 있다면, 해당 message를 무시하며, 보고있지 않다면 OS api를 이용해, notification을 사용자의 기기에 띄웁니다.

push notification의 사용 사례

채팅방 예시는 사용자가 해당 채팅방을 보고 있지 않을 때, 서버 → 클라이언트의 단방향 통신 방식에만 한정됩니다.
채팅방을 보면서 서버에도 채팅을 보내야 하는 양방향 통신의 경우에는 HTTP 대신 XMPP를 사용하거나, socket을 이용하는 경우가 많습니다.
push notification은 위에서 살펴본 SNS application 외에도 다양한 사용사례들이 있습니다.
Mail 도착 Notification
쇼핑앱 Event Notification
스포츠 문자 중계

push notification의 구현과 관련된 기술

사실 위의 원리는 매우 간단하게 설명한 내용들이라, push notification을 더 깊게 이해하려면 알아야 하는 기술들이 있습니다. 여기서는 그 기술들의 목록만 짚고 넘어가겠습니다.
HTTP/XMPP : FCM이 message를 보내기 위해 사용하는 프로토콜입니다.
Publish/Subscribe pattern : 비동기 메시징 패러다임입니다.
Android Service : 앱이 실행중이지 않더라도 독립적으로 백그라운드에서 동작하며, event등을 처리해주는 실행 단위입니다.

push notification의 구현

현재 시점에서는 참고가 될만한 링크만을 걸어두며, 이 응답 유형이 핵심적인 요소는 아니기 때문에, 이후에 시리즈의 전반적인 내용이 정리되고 나면 추가토록 하겠습니다. firebase.google.com

참고) push notification을 Presentation Layer에서 처리하나요?

그것이 Controller를 의미한다면 아닙니다.
실제로는 push notification은 일반적인 웹 계층의 Presentation Layer에서 처리된다고 말할 수는 없습니다.
하지만 Clean Architecture에서 말하는 의존성 그래프에서 Usecase(Service layer)보다 바깥쪽에 위치해야 하는 역할이기도 하고, ‘응답 유형’을 설명할 때 같이 설명해두는 것이 좋을 것 같아 여기서 소개하게 되었습니다.
실제 Spring에서 구현할 때에는 Service Layer에 작성하는 경우가 있지만, 실제로는 사용자가 채팅창에 메시지를 보내는 1개의 Service에서 FCM에 전달하는 것이 아니라, 중간에 Event를 이용해 느슨하게 연결하는 경우가 많습니다.
ex) 메시지 전송 Service 수행→ 메시지 전송 Event 발생 → FCM 요청 Service 수행

참고