실시간 알림 서비스 트래픽 처리 경험
약 120초
이벤트 스트림 기반 실시간 알림 서비스에서 수만 동시 접속 처리 경험
인턴 때 실시간 푸시 알림 서비스 팀에서 일했습니다. 이벤트성 공지가 나갈 때 동시 접속 3만 건이 몰리면 웹소켓 커넥션 수가 서버 `ulimit`을 초과해 신규 연결이 거부됐습니다.
처음엔 서버를 더 추가하면 된다고 생각했는데, 스티키 세션 방식이라 특정 서버에만 커넥션이 쏠리는 문제가 있었습니다. 팀에서 Redis Pub/Sub을 이용해 서버 간 메시지를 브로드캐스트하는 방식으로 전환했고, 저는 그 과정에서 커넥션 당 메모리 사용량을 프로파일링하는 작업을 맡았습니다.
실패 경험은 Redis 채널이 많아지자 구독 메모리가 예상보다 빠르게 올라가는 것을 초반에 모니터링하지 않아 뒤늦게 발견한 것입니다. 그 이후론 새로운 인프라 구성 요소를 도입할 때 메모리·커넥션 지표를 처음부터 대시보드에 추가하게 됐습니다. 규모를 다루는 일은 코딩보다 계측과 관찰이 더 많은 시간을 차지한다는 걸 그때 배웠습니다.
이 결의 특징
인턴 때 동시 접속 3만 건에서 웹소켓 커넥션이 서버 ulimit을 초과해 신규 연결이 거부된 구체적 사건이 있습니다. Redis Pub/Sub으로 서버 간 메시지 브로드캐스트로 전환했으나 Redis 채널이 많아지자 구독 메모리가 예상보다 빠르게 올라가는 실패를 초반에 못 본 흔적이 있습니다.
이 결이 통하는 자리
커넥션 당 메모리를 프로파일링하는 작업을 직접 수행하고, 뒤늦게 발견한 메모리 증가 문제가 '새 인프라 요소를 도입할 때 메트릭을 처음부터 대시보드에 추가한다'는 구체 행동으로 바뀐 자리에서 면접관의 공감이 생기는 결이 보입니다.