2025-11-15

1일 1아티클

LY

Pushsphere

배경

LINE의 거대 서비스는 새해 인사, 지진, 미사일 경보 등 불특정 순간에 대량 알림 전송 필요

  1. 외부 시스템 불안정성 : 푸시 알림은 애플(APNs)/구글(FCM) 서버를 거치는데, LINE이 원하는 수준의 안정성 및 속도 X
  2. 단순 재시도의 함정 : 실패하면 재시도한다는 단순함은 대규모 트래픽에서 위험
    • 언제까지 재시도할까? : 문제가 생긴 서버에 계속 재시도 → 부하만 가중
    • 어느 서버로 바꿀까? : 수천 대의 서버 중 어느 서버가 건강한 상태인지 판단 어려움
  3. 할당량(Quota) 문제
    • 애플이나 구글은 서버가 감당 가능한 수준으로 알림 양(할당량)을 제한
    • 실패한 재시도도 이 할당량에 포함, 무작정 재시도 시 할당량이 빠르게 소모되는 문제

Pushsphere

  1. Pushsphere 게이트웨이 서버
    • 통합 인터페이스 : 애플/구글 상관없이, 개발자는 Pushsphere에 알림 전송 → 자동으로 플랫폼에 맞는 형식 변환
    • 고성능 통신 : 고성능 비동기 기술 Netty 활용 → 대량의 요청 막힘없는 처리
  2. Pushsphere 클라이언트
    • 재시도 인지 로드 밸런서 : 요청 보낼 서버 선택 시, 이전에 실패한 서버는 피해서 요청
    • 할당량 인지 재시도 : 재시도 전, 지금 할당량이 남아있는지 확인 → 429(Too Many Requests) 방지
    • 서킷 브레이커 : 각 서버마다 서킷 브레이커 설치. 특정 서버에서 실패나 시간 초과 지속 발생 시, 해당 서버로의 전송 회로를 끊은 뒤 건강한 다른 서버로 대체

성과

  1. 장애 알림 급감
  2. 최종 전송 실패 급감
    • 시스템이 스스로 문제 감지 및 회피 → 실패 사례 X
  3. 안정적 인프라
    • 중앙 집중형 로드밸런서 대신, 클라이언트가 각각 알아서 트래픽은 분산하는 CSLB(클라이언트 사이드 로드밸런싱) 도입 → 단일 장애 지점 제거, 시스템 전체 안정성 향상

오늘 배운 것

내일 할 일

참고자료

results matching ""

    No results matching ""