본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
안녕하세요 :)
오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판" 챌린지에 도전하는 마흔 세번째 날입니다.
마흔 두번째 날에는 채팅 프로젝트에 메시지 시퀸스 넘버 생성기 추가에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.
오늘 학습할 내용의 제목은,
Part 4. 서비스 부하 분산을 위한 분리 시작 > Ch 5. 메시지 순서 보장을 위한 메시지 시퀸스 넘버 생성기 추가 >
04-4. 채팅 프로젝트에 메시지 구간 요청 처리 기능 추가
입니다.
💬 채팅 프로젝트에 메시지 구간 요청 처리 기능 추가
- 구간 단위 메시지 조회 · 순서 보장 · 성능 최적화
📌 TL;DR
- 채팅방에서 특정 범위의 메시지만 요청할 수 있는 기능 추가
- 클라이언트가 startSeqId와 endSeqId를 전달하면, 해당 구간 메시지를 반환
- Redis 시퀀스 번호와 DB 복합키 기반으로 순서·정합성 보장
- 누락·중복 없는 조회와 대량 트래픽 대비 성능 고려
- 운영 시에는 구간 범위 제한·캐싱·인덱스 최적화 필요
🎯 배경
- 실시간 채팅에서 무작정 모든 메시지를 불러오면 네트워크·DB 부하가 커집니다.
- 특히 모바일 환경이나 대규모 채팅방에서는 구간 단위 요청이 필수입니다.
- 이번 작업의 목표는 다음과 같습니다.
- 채널별 메시지를 범위(start~end) 기준으로 조회
- 순서 보장과 정합성 유지
- 불필요한 데이터 전송 최소화
⚙️ 구현 내용
- 프로토콜 확장
- FETCH_MESSAGES_REQUEST에 startSeqId·endSeqId 필드 추가
- 서버는 요청 범위에 해당하는 메시지만 조회 후 반환
- DB 쿼리 수정
- 복합 PK(채널ID + 메시지Seq) 기반으로
- SELECT * FROM message
WHERE channel_id = :channelId
AND message_seq BETWEEN :startSeq AND :endSeq
ORDER BY message_seq ASC - 인덱스 최적화로 조회 성능 보장
- Redis 시퀀스 연동
- 최신 시퀀스 번호를 Redis에서 조회
- 범위 끝(endSeqId)이 현재 최대값을 넘지 않도록 조정
- 예외 처리
- 범위 값이 유효하지 않으면 에러 반환
- 조회 결과가 비어도 정상 응답 처리
🧪 테스트
- 로컬·통합 테스트에서 구간별 메시지 조회 검증
- 범위 초과·역순 요청·빈 결과 등 엣지 케이스 처리
- Redis Insight로 시퀀스 값과 DB 데이터 동기 확인
🚀 성능 및 운영 고려
- 범위 제한: 요청 당 메시지 개수 상한 설정(예: 100건)
- 캐싱 전략: 자주 요청되는 구간은 Redis 캐시 활용
- DB 인덱스: (channel_id, message_seq) 복합 인덱스 유지
- 모니터링: 범위 조회 요청 빈도·처리 시간 추적
✅ 체크리스트
- 프로토콜 필드 추가 반영
- 범위 유효성 검사 로직 구현
- DB 쿼리 성능 테스트 완료
- 캐싱·모니터링 설정
- 메시지 구간 요청 기능은 성능·사용성·데이터 정합성의 균형이 핵심입니다. 범위를 나누어 조회하면 네트워크와 DB 부하를 줄일 수 있지만, 잘못 설계하면 순서 뒤틀림·중복·누락 문제가 발생할 수 있습니다.
- Redis 시퀀스 번호를 기준으로 한 범위 검증은 단순하면서도 안정적입니다. 다만 대규모 환경에서는 샤딩·캐싱·비동기 로딩까지 고려해야 합니다.
- 운영 단계에서 요청 패턴을 분석해 범위 상한·프리페치 정책을 조정하면 트래픽이 폭증하는 이벤트 상황에서도 안정적으로 서비스할 수 있습니다.
