[1권 - 10장] 알림 시스템 설계

[KimH4nKyul]

10장을 읽고 알림 시스템을 어떻게 설계하면 되는 지 배우고 궁금했던 점을 공유하고 함께 논의해 본다.

[KimH4nKyul]

• 듀오링고 알림 시스템

[KimH4nKyul]

5초 내 600만 건이라면 하루에 1000억건을 처리할 수 있다는 얘기인가?

600만/5 = 120만/s
120만 x 86400s = 1036억

하지만 본문에 보니 초당 1만개 처리로 가닥을 잡고 진행한거 같음

[KimH4nKyul]

[KimH4nKyul]

알림을 생성하는 API 서버(또는 Sup-bot Service) 에서 들어온 요청을 SQS FIFO 큐에 먼저 쌓고, 이를 처리하는 Interim Workers가 메시지를 가공하거나 추가 정보를 조회한 뒤, 다시 일반 SQS(Message Queue) 로 전달

[KimH4nKyul]

이후 5000개 이상의 Notification Workers가 이 일반 SQS를 병렬로 소비(Consume)하면서 Firebase Cloud Messaging(FCM), Apple Push Notification Service(APNs) 와 같은 외부 푸시 서비스로 알림을 전송

[KimH4nKyul]

알림 시스템이 분산하면 서비스 1~N과 어떻게 연결되어야 할까?

[KimH4nKyul]

• 로드밸런서, 게이트웨이

[KimH4nKyul]

모든 요청이 하나의(또는 분산된) 로드밸런서를 통한다?

[KimH4nKyul]

@yw7148 각자의 인증 인가 처리나 기타 등등을 위한 백엔드 WAS 게이트웨이를 두는 경우가 있다.
부하 관리를 위한 로드밸런서 + 백엔드를 위한 중간 처리 장치(스프링 게이트웨이 등)

[KimH4nKyul]

알림시스템(스케일아웃) -> 알림 큐 -> 워커(스케일아웃)

위와 같은 구조라면, 코드레벨에서 어떻게 구현되는게 좋을까?

[KimH4nKyul]

1. 알림 시스템에서 알림 받아야 할 대상을 긁어와 루프 돌면서 큐로 페이로드만 전달
2. 작업 서버에 소비자를 두고 퍼블리싱된 메시지를 APNS, FCM 등으로 전달

위와 같이?

[KimH4nKyul]

• 알림 로그 데이터베이스는 아웃박스 패턴을 활용해 보면 좋을거 같은데 어떠신지?
• 애초에 실패시 재시도 보다 서킷브레이커 패턴을 고려해야 하나?

[KimH4nKyul]

굳이 아웃박스 패턴이 아니어도 오케스트레이터를 두면 될 거 같기도 하다. (이벤트 메디에이터 토폴로지 등)

[KimH4nKyul]

실패 시 아웃박스 패턴 혹은 DLT를 고려해 볼 수 있고, 손실에 대비했을 때 아웃박스 패턴(알림 로그)이 적절할 것으로 보임

[yonghanyoon]

FCM에서 알림이 누락될 경우 어떤 방식으로 처리하는지

[KimH4nKyul]

누락된 알림을 식별하는 방법 도출하고 재시도 로직에 적용해 보면 어떨까요?

[yonghanyoon]

FCM error를 통해 식별할 수 있겠지만 FCM 메세지 자체가 누락되는 현상이 있다면? 아니면 그런 경우는 아예 존재하지 않는걸까?

[KimH4nKyul]

• 대규모 FCM시 권장사항
  -> RPS를 낮추라는 결론?

[yw7148]

• 보낸 알림의 상태를 추적할 수 있는 table을 둔다.
• FCM response에 대한 log성 데이터는 두는 게 좋지 않을까?

[yonghanyoon]

100만명 이상에게 알림을 보내야 하는 경우 100만명에 대한 데이터는 어떻게 처리해야 할까?

[KimH4nKyul]

• 단 번에 전달할 수 없으니, 병렬로 쪼개서 보내는 과정이 필요할 거 같음
• 그렇다면 이를 어떻게 실현할 수 있는지 조사해 봐야할 듯

[KimH4nKyul]

100만명을 청크 단위로 조회(페이징 같은 기술) -> 청크 단위 배치 페이로드를 큐 발행 -> 소비 하는 병렬 워커 (또는 워커가 소비할 때 페이로드를 청크로 분해) -> 병렬로 FCM 전송

[KimH4nKyul]

페이징 자체가 조회 속도를 느리게 할 수 있으니 대안이 필요하다.

[KimH4nKyul]

@yw7148 캐싱을 적극적으로 활용할 지점을 찾을 것

[renechoi]

흠…

[hyojin202406]

AWS Simple Email Service (SES)* 는 대량 이메일 발송 및 수신을 위한 클라우드 기반 이메일 서비스로,
트랜잭션 이메일, 마케팅 캠페인, 알림 메일 등을 안정적으로 전송할 수 있도록 지원함.

[문제상황]
SES에서 이메일이 차단되는 현상 발생

• 수십~수백만건의 이메일 알림을 한번에 요청 시 유효하지 않은 이메일로 메일을 보낼 때 응답 지연이 발생하면,
  AWS WAF나 SES 자체적인 보호 메커니즘이 이를 비정상적인 트래픽(DDoS 공격)으로 오판할 가능성이 있음
• 이메일 유효성 검증 기능을 추가할 경우 성능 저하 현상 발생

[해결방법]
유효한 이메일 검증 후 전송

• SES를 사용하기 전에 AWS Lambda + Amazon DynamoDB + AWS SNS 등을 활용해 이메일 주소 유효성 검사를 진행하는 방법이 있다고 함.

[hyojin202406]

• 주기적으로 배치를 돌려서 이메일 유효성 검증
  • 이메일 검증 실패시 알림 보내지 않는다.

[KimH4nKyul]

이상한 이메일로 보내면 뭔가 검증하면서 응답 지연이 발생한단 의미

[KimH4nKyul]

"수십~수백만건의 이메일 알림을 한번에 요청 시 유효하지 않은 이메일로 메일을 보낼 때 응답 지연이 발생하면,"
이 부분의 문제가 먼저 선행 처리 되어야 할 거 같음

• 응답을 무조건 받아야 하는걸까...

[KimH4nKyul]

[알림의 중복 발송을 최소화하는 방법에는 어떤 것들이 있었을까?]

At-most-once (최대 한 번) 전달
At-least-once (최소 한 번) 전달
Exactly-once (정확히 한 번) 전달

정확히 한 번 전달이 불가능한 이유는 네트워크 파티션의 가능성 때문입니다. 예를 들어, 다음과 같은 시나리오를 생각해보겠습니다:
송신자가 메시지를 보내고 수신자가 이를 받았다고 가정해봅시다. 수신자는 확인 응답(ACK)을 보내지만, 네트워크 문제로 이 ACK가 송신자에게 도달하지 못합니다. 이때 송신자는 다음 중 하나를 선택해야 합니다:

메시지를 다시 보내지 않음 -> 메시지가 전달되지 않을 위험
메시지를 다시 보냄 -> 중복 전달의 위험

이러한 상황에서 송신자는 수신자의 상태를 정확히 알 수 없기 때문에, exactly-once 전달을 보장할 수 없습니다.
하지만 실제 시스템에서는 "effectively once" 또는 "exactly-once processing"이라는 개념을 구현하여 이 문제를 해결하려 합니다. 이는 주로 다음과 같은 방법으로 구현됩니다:

메시지에 고유 식별자 부여
수신자 측에서 중복 메시지 감지 및 제거
멱등성(idempotency) 보장

예를 들어 Kafka나 다른 현대적인 메시징 시스템들은 이러한 방식으로 "effectively once" 전달을 구현하고 있습니다. 이것이 진정한 의미의 exactly-once는 아니지만, 실무에서는 충분히 유용한 수준의 보장을 제공합니다.

---

여러분의 생각은?

[KimH4nKyul]

보내는 건 여러번 보낼 수 밖에 없으나, 수신 측에서 중복 전달됨을 감지할 수 있어야 함

[KimH4nKyul]

핸드셰이크와 비슷한 구조 @hyojin202406 @yw7148

[KimH4nKyul]

Q. 키를 어딘가에 저장하고 있어야 하나요?

[KimH4nKyul]

Q. 키를 어딘가에 저장하고 있어야 하나요?
-> A. @yw7148 알림 서버 또는 작업 서버 단에 DB를 두고 탐지

[god3v]

You Cannot Have Exactly-Once-Delivery

[hyojin202406]

보안

appKey, appSecret 메커니즘 관련 알고리즘 비교하기

알고리즘	특징	이유
SHA-256 (단순 해시)	단방향 해시, 무결성 확인 가능	해시값 자체만으로 인증이 불가능 (HMAC 사용 필요)
RSA (비대칭 암호화)	공개/개인 키 방식, 높은 보안성	속도가 느리고 구현이 복잡
AES (대칭 암호화)	데이터 암호화	인증보다는 암호화에 초점
HMAC-SHA256	대칭 키 기반 메시지 인증	빠르고 안전하며 무결성을 검증 가능

[yonghanyoon]

사용자들의 발송 상태 관리는 어떤 방법이 효율적일까?

[KimH4nKyul]

상태를 관리하면 됩니다.

[yonghanyoon]

굿;

[hyojin202406]

필수 항목: 생성, 요청, 완료, 실패

[yonghanyoon]

클라이언트에 보낸 후 상태의 경우 로그성으로 관리하고, DB의 경우 발송 실패, 완료 또는 보냈다 정도만 관리?

[Cheondongmin]

쩐다

[KimH4nKyul]

사용자가 받았다를 -> 이메일을 열었음 확인 / 클릭 이벤트 추적 등으로 할 수도 있을거 같은데 정말 굳이? 라는 느낌이 많이 듬 -> 바로바로 확인할 일도 아닌거 같음

[KimH4nKyul]

문자(SMS)는 진짜로 어떻게 하지?

• 통신사 Delivery Receipt(DR) 확인 @hyojin202406

[KimH4nKyul]

LMS 한도 초과로 인한 확인 불가 문제도 있다~ @hyojin202406

[renechoi]

쩐다

[Cheondongmin]

한국에서 많이 사용되는 사기업 SMS 메시지 업체

서비스 제공업체	SMS 단가 (1건당)	LMS 단가 (1건당)	비고
KT Communis	10원	28원	발송량에 따른 구간 단가 협의 가능
NHN Cloud	9원	30원	월 50건의 SMS와 10건의 LMS 무료 제공
솔라피(Solapi)	18원	45원	월 발송량에 따라 최대 57.69% 할인
LG U+	27.5원	-	대표번호 문자수신 서비스 요금
카페24	20원	60원	요금제에 따라 SMS 단가 변동

참고 사항:

• KT Communis: 발송량에 따라 구간 단가 협의가 가능.
• NHN Cloud: 월 50건의 SMS와 10건의 LMS 무료 제공 후, 각각 9원과 30원의 단가가 적용.
• 솔라피(Solapi): 월 발송량에 따라 최대 57.69%의 할인이 적용.
• 카페24: 요금제에 따라 SMS 단가가 변동되며, 예를 들어 '절약형' 요금제는 300건의 SMS를 6,000원에 제공.

각 서비스의 요금 체계는 발송량, 서비스 유형, 추가 기능 등에 따라 달라질 수 있으므로, 자세한 내용은 각 서비스 제공업체의 공식 웹사이트를 참고하시기 바랍니다....

[Cheondongmin]

첫회사때 솔라피 썼었는데 개 극혐이였음

NCP 에서 제공해주는거나

그냥 비즈뿌리오 쓰셈

[KimH4nKyul]

[알림 시스템의 경우에 필요한 QPS 정리]
각 컴포넌트들을 고려했을 때
하루 86400초를 기준으로 푸시 알림 1천만건 / SMS 발송 1백만건 / 이메일 전송 5백만건을 처리해야 한다면,

푸시 알림은 115QPS, SMS는 11QPS, 이메일은 57QPS로 발송 시에 필요 QPS는 합계 평균 185QPS로 고려할 수 있음

피크 시간대를 고려하면 4~5배 정도의 처리가 필요하기 때문에 868QPS 정도로 산정될 수 있고,
이 때 다른 API의 성능 지연을 고려하면 전체 평균 1300QPS 정도의 능력이 고려될 수 있음

[yonghanyoon]

(기억 안 남) 어떤 기업에서 수백만 건의 알림을 몇 초 만에 보냈다고함
그게 어떻게 가능?

[o3ozzvb]

병렬처리?

[o3ozzvb]

수백만 건의 알림을 몇 초 만에 보내려면 고성능 분산 시스템과 비동기 처리가 핵심!

1. 메시지 큐(Kafka, RabbitMQ)로 대량 알림 처리
2. CDN & 클라우드 서비스 (FCM, SNS) 활용
3. 비동기 이벤트 기반 아키텍처 적용
4. 서버리스(AWS Lambda)로 대량 트래픽 자동 확장
5. Redis 캐싱으로 빠른 알림 대상 조회
6. 다중 채널 동시 활용 (푸시, 이메일, SMS)

💡 결국 핵심은 "대량 병렬 처리 + 네트워크 분산 전송"

[KimH4nKyul]

다중 채널이란 뭘까요? 알림 유형(APN, FCM, SMS, EMail 등)으로 나눈 버퍼를 의미하는 걸까요?

[Cheondongmin]

📌 다중 채널(Multi-Channel)이란?

**다중 채널(Multi-Channel)**이란 사용자에게 알림을 전달할 수 있는 여러 가지 통신 방법(채널)을 의미합니다.
즉, APN(iOS 푸시 알림), FCM(안드로이드 푸시 알림), SMS, Email 등 다양한 알림 방식을 의미하는 개념입니다.

---

🔹 다중 채널(Multi-Channel)의 정의

다중 채널이란 사용자가 선호하는 방식으로 정보를 받을 수 있도록 여러 개의 알림 채널을 지원하는 것을 뜻합니다.
이 개념은 사용자의 환경(iOS, Android, Web, Email 등)에 따라 알림을 효과적으로 전달하기 위해 필요합니다.

✅ 다중 채널의 예시:

채널	설명	주요 사용 사례
APN (Apple Push Notification)	iOS 기기로 푸시 알림 전송	iOS 앱 푸시 알림
FCM (Firebase Cloud Messaging)	안드로이드 기기로 푸시 알림 전송	Android 앱 푸시 알림
SMS	휴대폰 문자 메시지	OTP, 긴급 알림
Email	이메일로 알림 전송	뉴스레터, 계정 정보 업데이트
Web Push	브라우저에서 푸시 알림 제공	웹사이트 방문자에게 알림

🚀 즉, 다중 채널이란 "알림 유형별로 나눈 버퍼"라기보다는 "사용자에게 알림을 보낼 수 있는 다양한 방식"을 의미합니다.
→ 버퍼는 메시지를 처리하는 내부적인 개념, 다중 채널은 사용자가 알림을 받는 다양한 경로를 의미합니다.

---

🔹 다중 채널이 필요한 이유

1️⃣ 사용자 맞춤형 알림 제공

• 사용자가 선호하는 알림 방식이 다름.
  • 예제: 어떤 사용자는 앱 푸시 알림을 선호하지만, 어떤 사용자는 SMS를 더 신뢰할 수 있음.
• 사용자가 알림을 못 받을 경우 대체 채널로 재전송 가능.
  • 예제: FCM(푸시 알림)이 실패하면, 대신 SMS 또는 Email로 재전송.

2️⃣ 서비스 안정성 강화

• 특정 채널(APN, FCM 등)에 장애가 발생해도 대체 채널을 통해 메시지 전달 가능.
  • 예제: FCM이 다운되었을 때 SMS로 긴급 알림을 보내는 방식.

3️⃣ 다양한 디바이스 환경 지원

• 앱을 설치하지 않은 사용자는 SMS/Email을 통해 알림을 받을 수 있음.
• 웹사이트 방문자는 Web Push로 알림을 받을 수 있음.

---

🔹 다중 채널을 활용하는 알림 시스템의 구조

다중 채널을 지원하려면 각 채널별로 메시지를 처리할 수 있도록 설계해야 합니다.

✅ 설계 개요

[알림 요청] → [알림 서버] → [메시지 큐]
                            → [APN (iOS)]
                            → [FCM (Android)]
                            → [SMS Gateway]
                            → [Email 서버]

✅ 작동 순서

1. 사용자가 알림 요청을 보냄 (예: "이벤트 시작 알림").
2. 알림 서버는 사용자의 설정을 조회하여 어떤 채널로 보낼지 결정.
3. 결정된 채널에 따라 메시지 큐를 통해 각 채널별 전송 시스템으로 전달.
4. APN, FCM, SMS, Email 등 각 채널을 통해 사용자에게 알림 전송.

✅ 예제 시나리오 (푸시 알림 실패 시 SMS로 대체)

[사용자 요청] → [알림 서버] → [FCM 전송 실패] → [SMS로 대체 전송]

---

🔹 다중 채널 시스템을 설계할 때 고려할 점

1️⃣ 사용자 설정(User Preferences)

• 사용자가 원하는 알림 채널을 선택할 수 있도록 설정.
• 예: 앱 푸시는 받고 싶지만, SMS는 원하지 않는 경우.

2️⃣ 알림 우선순위 설정

• 중요도가 높은 메시지는 푸시 알림이 실패하면 SMS로 대체 전송.
• 예: OTP(로그인 인증) 는 FCM이 실패하면 SMS로 보내야 함.

3️⃣ 비용 고려

• 푸시 알림은 무료, 하지만 SMS는 비용이 발생함.
• 불필요한 비용을 줄이기 위해 FCM → Email → SMS 순으로 전송하는 정책을 설정.

4️⃣ 확장성(Scalability)

• 천만 건 이상의 알림을 효율적으로 처리하기 위해 메시지 큐 기반 아키텍처를 활용.

---

💡 결론

✅ 다중 채널(Multi-Channel)은 "알림 유형(APN, FCM, SMS, Email 등)으로 나눈 버퍼"가 아니라, 알림을 전달하는 다양한 방식을 의미함.
✅ 다중 채널을 사용하면 사용자 맞춤형 알림 제공, 서비스 안정성 강화, 다양한 디바이스 환경 지원이 가능함.
✅ 다중 채널 설계를 할 때는 사용자 설정, 알림 우선순위, 비용, 확장성을 고려해야 함.
✅ 푸시 알림이 실패하면 SMS나 Email로 대체 전송하는 방식을 구현하면 안정적인 알림 시스템을 구축할 수 있음.

🚀 즉, 다중 채널 시스템은 "버퍼" 개념이 아니라, "사용자가 알림을 받을 수 있는 다양한 경로를 제공하는 것"이다! 🎯

[KimH4nKyul]

[알림시 전송률 제한 장치를 두는 이유]

• 결국 사용자 경험의 관점임
• 너무 많은 알림이 동시 다발적으로 발생하는 경우에 사용자가 알림을 꺼버릴 수 있음

[KimH4nKyul]

개발 영역의 관점에선 사용 가능한 인터페이스에 대한 부하가 발생한다는 점 처리해야 할 QPS 지표를 높일 수 있음

[Cheondongmin]

알림 내용이 소실되면 안되기 때문에 알림 데이터를 DB에 보관하고 재시도 메커니즘을 구현해야 한다.

-> 대부분 MQ에선 Retry, Dead Letter Queue 기능을 제공하기 때문에 로그 DB를 사용하지 않고 DLQ 기능을 사용해도 될 듯

[Cheondongmin]

DB에 로그는 남겨야 한다고 생각
(데이터분석, DLQ 큐 유실로 인한 문제발생 등)

굳이 DB를 통한 재시도로 불필요한 오버헤드를 만들 필요가 없다는 말

[yonghanyoon]

알림 시스템에선 정상적으로 알림을 보냈지만 FCM에서 알림이 누락되어 알림을 받아야 할 사용자가 알림을 받지 못하였다면?

[Cheondongmin]

[알림 전송 요청]
↓
[FCM API 호출]
↓
[응답 확인] → 성공 → [DB 기록: SUCCESS]
↓
→ 실패 → 응답 코드 분석
→ 일시적 오류 (DLQ로 이동 후 재시도)
→ 영구 오류 (DB에 EXPIRED_TOKEN 저장)

[DLQ 처리] → 성공 → [DB 업데이트: SUCCESS]
↓
→ 실패 → [DB 업데이트: PERMANENT_FAILURE]

[Batch Job 을 실행하든... API를 뚫든... ] → PERMANENT_FAILURE 데이터 조회
↓
→ 서버 문제 (Rate Limiting 적용 후 재시도)
→ 토큰 문제 (사용자에게 새로운 토큰 요청)
→ 기타 오류 (관리자 알림 발송)

[KimH4nKyul]

카카오 알림 서비스로 시작하는 서버 개발

[hyojin202406]

밑에 제가 올린 논제가 해당 영상에서 나오는 내용입니다 !

[o3ozzvb]

[사용자에게 보내는 알림의 빈도를 제한하는 방법]

1. 기본 Rate Limiting
   1-1. 시간 단위 제한 (Fixed Window)
   • 예) "사용자당 1시간에 최대 5개 알림"과 같은 정책 적용
   • Redis 같은 캐시 시스템을 활용하여 사용자별 알림 카운트 저장, 제한 초과 시 전송 차단.
   • 장점 : 간단한 구현
   • 단점 : 초반 5개 알림 빠른 수신 이후, 나머지 알림을 받지 못할 수 있음
     1-2. 슬라이딩 윈도우 (Sliding Window) 방식
   • 최근 X분 동안 보낸 알림 개수를 제한하는 방식
   • Redis의 Sorted Set 을 활용하여 타임스탬프 기반으로 처리.
   • 장점 : 좀 더 유연한 알림 제한 가능
   • 단점 : 좀 더 복잡한 구현 방식
2. Batching (일괄 처리)

• 여러 개의 알림을 한 번에 묶어서 보내는 방식
• 예) 푸시 알림의 경우, "새로운 이벤트 3개가 있습니다!" 와 같은 방식으로 전달
• 장점 : 불필요한 알림을 줄이고 사용자 경험 향상
• 단점 : 실시간성이 떨어짐

3. Priority Queue 활용

• 중요도에 따라 알림을 보내는 우선순위를 조정하는 방식
  3-1. 긴급 알림과 일반 알림 구분
  • 긴급 알림은 즉시, 일반 알림은 일정 시간동안 모아서 전송.
  • RabbitMQ, Kafka 같은 메시지 큐에서 우선순위 큐(Priority Queue) 사용 가능
  • 우선순위 설정 예시) 보안 경고(로그인 시도) : 중요도 높음 -> 즉시 전송, 채팅 메시지 : 중요도 높음 -> 즉시 전송, 일반 알림 : 중요도 낮음 -> 배치 처리
  • 장점 : 중요한 알림만 즉시 전달 가능
  • 단점 : 우선순위 설계 필요

4. 사용자 설정 옵션 제공

• 사용자가 직접 알림 빈도를 조절할 수 있도록 제공하는 방식
• 장점 : 사용자 경험이 향상됨
• 단점 : 사용자가 설정하지 않으면 기본 정책 필요

5. AI 기반 스마트 알림 시스템

• 사용자의 행동을 학습하여 알림 빈도 자동 조절
• 장점 : 개인화된 알림 제공 가능
• 단점 : AI 학습을 통한 데이터 수집 필요

[hyojin202406]

1. IF) 알림 서버에서 CPU 100% 부하 상황이나, 시스템 스레드가 고갈된다면 대처방안 고민해보기
2. 연계서버와 알림서버 간의 지연응답이 지속될 경우 설계 방안 고려해보기
3. 알림 서버에서 알림 생성 중 알림이 유실 될 경우 개선 방안 고려해보기

[hyojin202406]

2. 비동기 알림 생성 방식:

   • 연계 서버는 알림을 생성하는 것이 아니라, 알림 서버에 알림 생성 요청을 보냄.
   • 알림 서버는 내부적으로 알림 생성 작업을 비동기적으로 처리하고, 연계 서버는 비동기 방식으로 빠르게 응답을 받음.
   • 이 방식으로 알림 요청과 알림 생성 작업을 분리하여, 알림 생성 작업이 무거워지거나 커지더라도 연계 서버에는 영향을 주지 않음.

3. 알림 생성 상태 확인 불가:

   • 연계 서버는 알림 메시지가 정상적으로 만들어졌는지 여부를 알 수 없음.
   • 이를 해결하기 위해, 알림 생성 실패 내역을 조회할 수 있는 API를 제공함.

[KimH4nKyul]

[알림 생성 실패 케이스]

• API 응답 실패
• DB 응답 실패
• 아 모르겠다 ^_^

[KimH4nKyul]

연계 서버 - 알림 서버 간에 부하

• 보통 분산한다.
• 사이에 로드밸런서나 게이트웨이를 둬서 트래픽도 분산한다.
• 비동기 처리를 고려해 본다.

[Cheondongmin]

🔍 FCM 메시지 전송 시 일시적 오류(Transient Error)와 영구 오류(Permanent Error)

FCM 메시지를 전송할 때 발생하는 오류는 크게 일시적 오류(Transient Error) 와 영구 오류(Permanent Error) 로 나눌 수 있음
이를 올바르게 분류하면 효율적인 재시도 및 오류 대응이 가능

---

🔹 1. 일시적 오류 (Transient Error)

✔ 재시도를 통해 해결될 가능성이 높은 오류
일시적 오류는 일시적인 네트워크 문제, 서버 문제, 과부하 등으로 인해 발생하는 오류로, 일정 시간이 지나면 해결될 가능성이 높기 때문에 재시도할 가치가 있음.

✅ 대표적인 일시적 오류 코드

오류 코드	설명	대응 방법
Unavailable	FCM 서버가 다운되었거나, 일시적인 장애 발생	지수적 백오프(Exponential Backoff) 재시도
InternalError	FCM 내부 오류 발생	짧은 대기 후 재시도
Timeout	응답 시간이 초과됨	재시도 (FCM 서버 부하로 발생 가능)
DeviceNotAvailable	디바이스가 네트워크에 연결되지 않음	TTL(Time-To-Live) 설정하여 디바이스가 온라인이 되면 수신
QuotaExceeded	단시간 내 너무 많은 메시지를 전송함	속도를 조절하고, 일정 시간 후 재시도

---

✅ 4. 최적화된 처리 흐름

1. FCM 메시지 전송
2. FCM 응답 체크
   • SUCCESS → 정상 처리
   • FAILURE → 오류 유형 분석
3. 일시적 오류(Transient Error) 발생 시
   • DLQ에 저장 후 지수적 백오프 적용하여 재시도
   • 3~5회 이상 실패 시 PERMANENT_FAILURE로 기록
4. 영구 오류(Permanent Error) 발생 시
   • NotRegistered → DB에서 토큰 삭제 후 사용자에게 새로운 토큰 요청
   • InvalidRegistration → 요청 로직 수정
   • MessageTooBig → 메시지 크기 조정
   • InvalidPackageName → 설정 확인
5. 최종적으로 실패한 메시지 Batch 처리
   • 일정 주기로 DB의 PERMANENT_FAILURE 데이터 조회
   • 실패 원인 분석 후 적절한 후속 조치 수행

---

🎯 결론

• 일시적 오류(Transient Error): 재시도를 통해 해결 가능 (DLQ + 백오프 적용)
• 영구 오류(Permanent Error): 재시도로 해결 불가능 → 즉시 DB 반영 및 사용자 피드백 필요
• FCM 응답 코드 기반으로 처리 분류 → 비효율적인 재시도를 최소화하고, 사용자 경험을 최적화할 수 있음.

[DongGunYoon]

📬 푸시 알림 시스템의 'DeviceNotAvailable' 오류 처리 메커니즘

푸시 알림 발송 시 사용자의 디바이스가 오프라인 상태인 경우(Firebase Cloud Messaging(FCM), Apple Push Notification Service(APNs) 기준), 알림 전달이 어떻게 처리되는지의 상세한 흐름을 정리했습니다.

🚩 1. 메시지 큐잉(Message Queuing) 메커니즘

알림 서비스는 디바이스가 오프라인 상태일 때 메시지를 즉시 폐기하지 않고, 일정 시간 동안 서버의 큐에 보관합니다.

• FCM의 경우:

  • 기본 보관 기간: 최대 4주(기본값)
  • 개발자가 직접 TTL(Time-To-Live) 설정 가능
    • 예시: 1시간(3600초), 1일(86400초)

• APNs (Apple Push Notification Service)

  • "Store-and-forward" 구조를 사용
  • 기본 보관 기간은 최대 28일
  • TTL 설정(Expiry 옵션)을 통해 개발자 지정 가능

---

🚩 2. 디바이스 재연결 시 알림 전달 프로세스

디바이스가 다시 온라인 상태가 될 때 알림 메시지가 전달되는 흐름입니다.

① 디바이스 온라인 상태로 전환

• 모바일 운영체제가 네트워크 연결을 감지
• 디바이스는 자동으로 FCM/APNs 서버와의 연결을 재설정

② 디바이스 인증 및 토큰 확인

• 디바이스는 각 푸시 서비스에 자신의 고유한 토큰으로 인증
• 이 과정은 OS가 자동으로 처리

② 메시지 존재 확인 및 전달

• FCM/APNs 서버는 메시지 큐에서 디바이스 토큰에 해당하는 메시지를 찾음
• TTL이 유효한 메시지를 찾아 디바이스로 즉시 전송

③ 메시지 전달 완료 및 큐에서 삭제

• 디바이스가 메시지를 수신한 후 서버 큐에서 해당 메시지는 제거됨

---

🚩 2. 메시지 축약(중복 방지) 메커니즘

• 동일하거나 중복된 메시지가 여러 개 존재할 때 메시지를 병합하여 처리할 수 있습니다.

플랫폼	메시지 병합 처리 기능
FCM	collapse_key 설정을 통해 동일한 키의 메시지 병합 후 최신 메시지만 전송
APNs	apns-collapse-id 헤더 설정을 통해 동일한 id를 가진 메시지를 최신 메시지로 병합

---

📌 요약 정리

• TTL은 메시지 발송 주체가 지정할 수 있습니다.
• 오프라인 상태의 디바이스는 메시지를 서버가 TTL에 따라 일정 시간 보관 후 온라인 상태가 되는 순간 전달됩니다.
• 메시지 병합 기능을 활용해 효율적 알림 관리가 가능합니다.

[Cheondongmin]

SPOF 해결법 (메시지 큐 도입) [말이 너무 어렵게 써있어서 그냥 정리해봄]

1. 알림 서버는 메시지를 메시지 큐에만 넣고 작업 서버가 큐에서 꺼내 처리 → 서버 간 역할 분리
2. 알림 서버가 죽어도 메시지는 메시지 큐에 남아 있음 → 장애 후에도 복구 가능
3. 작업 서버(Worker)가 여러 개 있으면 부하를 분산할 수 있음 → 한 서버가 죽어도 다른 서버가 메시지를 처리