가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 10장 ) 알림 시스템 설계

 

 

알림 시스템 설계 

• 알림  
  • 고객에게 중요한 정보를 비동기 적으로 제공 

 

1단계 문제 이해 및 설계 범위 확정 

• 알림의 종류 
• 실시간 시스템 여부 
  • ex) 연성 실시간 시스템 (soft real-time) : 가능한 빨리 전달, 약간의 지연 가능 
• 지원 단말의 종류 
• 사용자에게 보낼 알림을 만들 사람 
• 사용자에게 알림 on/off 설정 기능 제공 여부 (opt-out)
• 하루에 보낼 수 있는 알림의 갯수 제한 

 

 

 

2단계 개략적 설계안 제시 및 동의 구하기 

• 알림 유형별 지원 방안
  • IOS 푸시 알림
    • 알림 제공자 (provider) 
      • 알림 요청을 만들어 애플 푸시 알림 서비스 (APNS: Apple Push Notification Service)로 보내는 주체 
      • 필요 정보 
        • 단말 토큰 (device token) 
          • 알림 요청을 보내는데 필요한 고유 식별자 
        • 페이로드 (payload) 
          • 알림 내용을 담은 JSON 딕셔너리(dictionary) 
      • APNS 
        • 애플이 제공하는 원격 서비스 
  • 안드로이드 푸시 알림 
    • FCM(Firebase Cloud Messaging)을 사용 
  • SMS 메시지 
    • 제 3 사업자의 서비스를 많이 이용 
      • ex) Twilio, Nexmo 
      • 대부분 상용 서비스이기 때문에 이용 요금을 내야함 
  • 이메일 
    • 고유 이메일 서버를 구축할 수 있음에도 상용 서비스를 사용이 많음 
      • ex) Sendgrid, Mailchimp
      • 전송 성공률이 높고 데이터 분석 서비스도 제공 
• 연락처 정보 수집 절차 
  • 모바일 단말 토큰, 전화번호, 이메일 주소 등의 정보가 필요 
    • 사용자가 서비스 앱을 설치하거나 처음으로 계정을 등록하면 API 서버는 해당 사용자의 정보를 수집하여 데이터베이스에 저장 
      • 한 사용자가 여러 단말을 가질 수 있고, 알림이 모든 단말에 전송되어야 한다면 user 테이블과 device 테이블을 별도로 저장 
• 알림 전송 및 수신 절차 
  • 구성
    • 알림 시스템을 사용하는 여러 서비스 
      • ex) 마이크로 서비스, 크론잡, 분산 시스템 컴포넌트 등 
    • 알림 시스템 
      • 알림 전송/수신 처리의 핵심 
      • 사용 서비스에 알림 전송을 위한 API를 제공하고 제 3자 서비스에 전달할 알림 페이로드를 만들어 낼 수 있어야 함 
      • 하나의 서버로 구성할 경우 다음과 같은 문제점이 발생 
        • SPOF 
          • 알림 서비스 서버가 한대라면, 하나의 서버 장애가 전체 서비스의 장애로 이어짐
        • 규모 확장성 
          • 한대 서비스로 구성한다면 데이터 베이스나 캐시등 중요 컴포넌트를 개별적으로 확장 불가 
        • 성능 병목 
          • 자원을 많이 사용하는 모든 알림 기능을 한 서버로 처리하면 사용자 트래픽이 많이 몰리는 시간에는 시스템이 과부하 상태에 빠질 수 있음 
      • 데이터 베이스와 캐시를 알림 시스템의 주 서버에서 분리
      • 알림 서버를 증설하고 자동으로 수평적 규모 확장이 이뤄질 수 있도록 stateless로 구성 
      • 알림 종류에 따른 메시지 큐를 별도로 구성하는 등 메세지 큐를 이용해 시스템 컴포넌트 사이의 강결합을 끊어야 함 
      • 제공 기능 
        • 알림 전송 API 
          • 스팸 방지를 위해 사내 서비스 또는 인증된 클라이언트만 사용할 수 있도록 제한 
        • 알림 검증 
          • 이메일 주소, 전화번호 등에 대한 기본적 검증을 수행 
        • 데이터베이스 또는 캐시 질의 
          • 알림에 포함시킬 데이터를 가져오는 기능 
        • 알림 전송 
          • 알림 데이터를 메시지 큐에 넣음 
            • 메세지 큐를 여러개 사용하는 경우 알림의 병렬 처리 가능 
    • 캐시 대상
      • 사용자 정보, 단말 정보, 알림 템플릿 등 
    • 데이터 베이스 
      • 사용자, 알림, 설정 등 다양한 정보 저장 
    • 메세지 큐 
      • 시스템 컴포넌트간 의존성 제거 
      • 다량의 알림이 전송되어야 하는 경우를 대비한 버퍼역할도 수행
        • 제3자 서비스 중 하나에 장애가 발생하더라도 다른 종류의 알림은 정상 동작 
    • 작업 서버 
      • 메세지 큐에서 전송할 알림을 꺼내 제 3자 서비스에게 전달 담당 서버 
    • 제 3자 서비스 
      • 사용자에게 알림을 실제로 전달하는 역할 
      • 상황에 따라서 사용 가능 여부가 달라질 수 있기 때문에 확장성에 유의 
        
        • ex) FCM은 중국에서 사용 불가, 중국에서는 Jpush, pushY와 같은 서비스를 사용해야 함 
    • IOS, 안드로이드, SMS, 이메일 단말 
      • 사용자가 알림을 수신하는 단말 
  • 플로우
    
    • 1) API를 호출하여 알림 서버로 알림 전달 
    • 2) 알림 서버가 사용자 정보, 단말 토큰, 알림 설정과 같은 메타데이터를 캐시나 데이터베이스에서 가져옴 
    • 3) 전송할 알림에 맞는 이벤트를 만들어 해당 이벤트를 위한 큐에 push 
    • 4) 작업 서버가 메시지 큐에서 알림 이벤트를 pop
    • 5) 작업 서버가 알림을 제3자 서비스에게 전달 
    • 6) 제3자 서비스가 사용자 단말로 알림을 전송 

 

 

3단계 상세 설계

• 안정성 
  • 데이터 손실 방지 
    • 데이터를 데이터 베이스에 보관하고 재시도 메커니즘을 구현해야 함 
      • ex) 알림 로그 데이터베이스를 유지하는 방법 
  • 알림 중복 전송 방지 
    • 중복을 탐지하는 메커니즘을 도입하고 오류를 신중하게 처리해야 함 
      • ex) 보내야 할 알림이 도착하면 이벤트 ID를 검사하여 처리된 이벤트인지 확인 
• 알림 템플릿 
  • 알림 구성은 비슷한 구성을 재활용하는 경우가 많으므로 템플릿의 인자나 스타일, 추적 링크만 조정하면 지정한 형식에 맞춰 알림을 만들어내는 알림 템플릿을 활용할 수 있음 
  • 전송될 알림의 형식을 일관성 있게 유지하고 오류 가능성이나 알림 작성에 드는 시간을 줄일 수 있음 
• 알림 설정 
  • 사용자, 알림 별로 알림 설정 데이터를 저장해두고 알림을 보내기 전에 확인하면 알림을 상세히 조절 가능 
• 전송률 제한 
  • 사용자에게 너무 많은 알림을 보내면 피로도가 높아지므로, 사용자가 받을 수 있는 알림의 빈도를 제한할 수 있음 
• 재시도 방법 
  • 해당 알림에 대한 전송이 실패하면 재시도 전용 큐에 넣고 재시도하고, 반복문제 발생시 개발자에게 통지하도록 할 수 있음 
    • ex) DLQ
• 푸시 알림과 보안 
  • IOS와 안드로이드의 경우 알림 전송 API는 appKey와 appSecret을 사용하여 보안을 유지 
    • 인증되거나 승인된 클라이언트만 해당 API를 사용하여 알림을 보낼 수 있음 
• 큐 모니터링 
  • 큐에 쌓인 알림의 개수에 따라서 이벤트 처리 속도를 확인할 수 있음 
    • ex) kafka consumer lag 
• 이벤트 추적 
  • 알림 확인율, 클릭율, 실제 앱 사용으로 이어지는 비율과 같은 매트릭은 사용자를 이해하는데 중요 
  • 데이터 분석 서비스는 이벤트 추적 기능도 제공함 
    • 즉, 알림 시스템을 만들면, 데이터 분석 서비스와도 통합해야만 함 

 

 

4단계 마무리 

• 안정성 
• 보안 
• 이벤트 추적 및 모니터링 
• 사용자 설정 
• 전송률 제한