인프런 커뮤니티 질문&답변

저도 정확하진 않지만, 제가 참여한 서비스에서는 AppNotice 와 Notification 을 구분했었습니다. AppNotice 같은 경우는 전체가 대상이고, 이벤트 마케팅 등 알림을 허용하지 않은 유저에게는 푸시 알림을 보내지 않는 것도 제어가 더 쉬웠던 것 같아요.

안녕하세요, 인프런 AI 인턴입니다.

최민준님, 대규모 서비스에서의 1:N 알림 전송에 대한 고민이시군요. 대규모 서비스에서 데이터베이스에 과도한 부담을 주지 않기 위한 알림 시스템 설계는 매우 중요한 문제입니다.

일반적으로 알림들을 개별적으로 데이터베이스에 저장하는 대신, 공지 사항이나 업데이트와 같은 일대다 알림을 효율적으로 처리하기 위해 몇 가지 방법을 사용할 수 있습니다:

1. 이벤트 기반으로 알림 처리: 사용자 행동 또는 특정 이벤트를 기반으로 메시지 큐에 알림 이벤트를 전송하고, 별도의 알림 서비스가 이 메시지 큐를 구독해서 알림을 생성합니다. 이 때, 실제 사용자에게 알림을 전송하는 부분(예: 이메일, SMS, 앱 푸시 등)은 분산 처리를 통해 성능 문제를 완화할 수 있습니다.

2. 알림 집계: 유저에게 발송되는 알림을 즉시 전송하는 대신, 일정 기간 동안의 알림을 모아서 한 번에 전송할 수 있습니다. 이 방법은 사용자에게 너무 많은 알림이 가는 것을 방지하고, 시스템의 부하를 분산시킬 수 있는 방법입니다.

3. 동적 알림 생성: 모든 사용자에게 동일한 알림을 저장하는 대신, 알림이 필요할 때 동적으로 생성하는 방식입니다. 예를 들어, ‘스프링 핵심 원리 - 기본편 강의에 새소식이 있어요!!‘와 같은 알림은, 실제로 사용자가 알림을 확인할 때 그 정보를 기반으로 알림 내용을 생성합니다.

4. 알림 서비스의 분리 및 특화: 알림 관련 로직과 데이터를 처리하는 별도의 서비스를 구축하여, 알림 시스템의 성능과 확장성을 보장할 수 있습니다. 이렇게 함으로써 애플리케이션의 주요 기능과 알림 시스템을 분리하여 관리할 수 있습니다.

이 중 어떤 방법을 선택할지는 애플리케이션의 요구 사항과 기술 스택, 그리고 예상되는 트래픽 양에 따라 달라질 수 있습니다. 추상화 및 라이브러리를 효율적으로 활용하면, 다양한 방법으로 이 문제를 해결할 수 있습니다.

인프런과 같은 플랫폼에서는 이러한 방식들 중 하나 또는 여러 가지를 조합하여 사용할 가능성이 높습니다. 각각의 방법은 상황에 따라 장단점이 있으므로, 서비스의 특성과 이용자들의 사용 패턴을 고려하여 적합한 전략을 선택하시는 것이 중요합니다.

제 생각에는, n대1로 모든 대상에 대한 알림을 제어하는 것이 불가능하다고 생각합니다. 읽은 메세지와 읽지 않는 메세지를 구분 하려면, 그 status를 서버측에서 소유해야 하고 또 그것이 member 각각에 정해지는 터라, 각 member에 대한 insert는 불가피하다고 생각해요. 혹은 본래 notification과 member의 관계는 다대다인데, 확인이라는 관계를 두어 1대 다, 다 대1로 풀어가는 것은 어떨까요. 알림 자체는 한번으로 마무리 되나 확인이라는 관계를 통해 member의 확인 status를 저장할 수 있으니까요. 결론적으로는 결국은 member 수만큼 insert를 하긴 해야 상태에 따른 처리를 할 수 있지 않을까 생각합니다. 사실 뭐 데이터 베이스에 저장되는 양은 정말 많겠지만, 사실 테이블 컬럼수가 크지 않고 타입에 따른 데이터 크기가 작다면, 수가 많다 한들 그리 큰 문제가 아닐것 인데, 다만 io디스크를 많이 잡아먹는다면 그게 문제일 터라, redis를 활용한다던지, 또 저도 주워들은 것인데, 이런 구현에 rabbitmq인가 그런것들도 활용된다고 들었어요.

저도 궁금하네요~