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