#Backend

여기어때 이벤트 기반 통합 알림 플랫폼 구축기 Part 2. How?

Summary

개인 웹훅의 저주에서 벗어나기: 여기어때의 초당 수천 건 알림 처리 플랫폼 NotiHub 구축기

Kafka와 슬랙봇 샤딩으로 해결한 분산 알림 시스템의 확장성 및 안정성 확보 전략

이 아티클은 여기어때가 파편화된 알림 시스템을 통합하며 겪은 기술적 도전과 해결책을 상세히 다룹니다. 단순한 알림 전달을 넘어, 대규모 트래픽에서의 슬랙 API 한계를 극복하는 방법과 시스템 가용성을 극대화하는 3중 캐시 전략 등 실무에서 바로 참고할 수 있는 아키텍처 인사이트를 제공합니다.

01개인 계정 종속성을 제거하고 전사 알림을 통합 관리하는 중앙 집중형 NotiHub 설계
02슬랙 API의 속도 제한을 회피하는 봇 풀 기반의 '슬랙봇 샤딩' 기술 적용
03Kafka Consumer Group과 HPA를 결합하여 급격한 트래픽 증가에 유연하게 대응
04Redis 장애 시에도 서비스 중단을 막는 Local-Redis-API 3중 캐시 및 Fallback 로직
05Handlebars 템플릿 엔진과 조건 엔진을 활용한 고도로 유연한 메시지 렌더링

RECOMMENDATION

사내 알림 시스템의 가시성을 확보하고 싶은 데브옵스 엔지니어나, 슬랙 API의 Rate Limit 문제로 골머리를 앓고 있는 백엔드 개발자에게 강력히 추천합니다.

The Problem

개별 직원이 생성한 슬랙 웹훅에 의존하는 구조로 인해 담당자 퇴사 시 알림이 중단되는 종속성 문제와 전사적인 알림 정책 수립 및 모니터링이 불가능한 한계가 있었습니다. 또한, SaaS가 제공하는 고정된 알림 포맷과 경직된 라우팅 설정으로 인해 팀별 요구사항에 맞는 유연한 대응이 어려웠습니다.

The Solution

Kafka를 이벤트 브로커로 활용하여 Receiver와 Processor를 분리한 중앙 집중형 알림 플랫폼 NotiHub를 구축하고, 슬랙 API의 Rate Limit을 극복하기 위해 봇 풀을 활용한 샤딩 및 채널별 큐 격리 전략을 도입했습니다. 성능과 가용성을 위해 Local Cache, Redis, API/DB로 이어지는 3중 레이어 캐시 구조와 HPA 기반의 물리적 확장 설계를 적용했습니다.

The Result

초당 수천 건의 메시지 전송 시 발생하던 429 Too Many Requests 오류를 해결하여 안정적인 전송 환경을 확보했으며, 해시 기반 샤딩을 통해 메시지 업데이트 및 스레드 무결성을 보장했습니다. 중앙화를 통해 전사 알림 관리 효율을 높이면서도 각 팀이 원하는 조건별 라우팅과 커스텀 템플릿 사용이 가능해졌습니다.

Trade-off

중앙 집중형 구조를 채택함으로써 단일 장애점(SPOF) 리스크가 발생했으나, 이를 완화하기 위해 무중단 배포, HPA, 다중 레이어 캐싱 및 Fallback 기제 등 복잡한 방어 기제를 설계해야 했습니다. 본문에 구체적인 비용 수치는 없으나, 고가용성 확보를 위한 인프라 자원 및 관리 로직의 복잡도가 증가하는 트레이드오프가 수반되었습니다.