여기어때, 자체 알림 플랫폼 NotiHub 구축으로 알림 관리 혁신

NotiHub는 중앙 집중형 구조로 인해 단일 장애점(SPOF) 문제를 안고 시작했으며, 이를 해결하기 위해 HPA(Horizontal Pod Autoscaler) 기반의 Scale-out을 통해 가용성을 확보했다. 또한, 무중단 배포(Zero-downtime Deployment)를 통해 서비스 중단을 최소화하고, 다중 레이어 캐싱(Multi-layer Caching)을 통해 성능과 안정성을 동시에 잡았다. 특히, Kafka Consumer Group을 활용하여 데이터 처리의 일관성을 유지하면서도 분산 처리를 가능하게 했다. 이러한 설계는 트래픽 증가에 유연하게 대응하고, 특정 컴포넌트의 장애가 전체 시스템에 미치는 영향을 최소화하는 데 기여한다.

NotiHub는 외부 서비스(Jira, Slack API 등)와의 연동을 위해 B2B Gateway를 통한 이중 검증 구조를 도입하여 보안을 강화했다. 단일 키 노출 위험(Single Key Exposure Risk)을 방지하기 위해, 시스템 전역에서 사용하는 Static Key와 각 엔드포인트 별로 발급된 Dynamic Key를 동시에 검증하는 방식을 채택했다. Static Key는 애플리케이션 기동 시 Secret Store에서 조회하여 인메모리 캐싱(In-memory Caching)함으로써 1차 검증 속도를 높였다. 이러한 설계는 보안 요구사항(Security Requirements)을 충족하면서도, 외부 서비스와의 안전한 통신을 보장한다.

NotiHub는 유실 없는 알림 전송을 위해 이벤트 브로커(Event Broker)로 Kafka를 선택했다. Kafka Consumer Group 메커니즘(Kafka Consumer Group Mechanism)을 통해 다수의 Processor Pod가 이벤트를 균등하게 나누어 처리하며, 특정 Pod에 장애가 발생하더라도 리밸런싱(Rebalancing)을 통해 유실 없이 작업을 이어받도록 설계했다. 또한, CPU 점유율(CPU Utilization) 기준의 HPA를 설정하여 트래픽 폭증 시 물리적 자원을 확장하도록 구성했다. 이러한 설계를 통해 이벤트 유실(Event Loss)을 방지하고, 안정적인 알림 전송을 보장한다.

NotiHub는 사용자 설정 변경을 실시간으로 반영하기 위해 3중 캐시 구조(3-layer Cache)를 사용한다. Local Cache(In-memory) → Redis → API/DB 순으로 캐시 계층을 구성하여 성능과 데이터 일관성을 모두 확보했다. 특히, Redis 장애(Redis Failure) 발생 시, 각 인스턴스의 로컬 캐시를 우선 활용하고, 최악의 경우 API 서버를 직접 호출하는 Fallback 구조(Fallback Structure)를 통해 서비스 중단을 방지한다. 또한, 재연결 및 업데이트 제어(Reconnect and Update Control)를 통해 Redis 연결 문제 발생 시 시스템 부하를 최소화한다. 이러한 설계를 통해 Redis 장애에도 알림 서비스의 연속성(Service Continuity)을 보장한다.

NotiHub는 슬랙 API Rate Limit 문제를 해결하기 위해 두 가지 전략을 도입했다. 첫째, Processor 레벨에서 자동 복원(Automatic Recovery)을 시도하여, no_text, msg_too_long, blocks_too_many 등의 오류 발생 시 메시지를 분할하거나 blocks/attachments를 나눠 재전송하도록 처리한다. 둘째, 조건 엔진(Condition Engine)과 Handlebars 템플릿 렌더링(Handlebars Template Rendering)을 통해, 페이로드의 특정 필드 값에 따라 전송 여부를 결정하고, 사용자 친화적인 슬랙 메시지를 생성한다. 이러한 전략은 슬랙 API의 제약(Slack API Limitations)을 극복하고, 안정적인 알림 전송을 가능하게 한다.