본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
안녕하세요 :)
오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 마흔 한번째 날입니다.
마흔 번째 날에는 Nginx를 도입하여 인증 서비스에 고가용성과 확장성을 확보한다에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.
오늘 학습할 내용의 제목은,
Part 4. 서비스 부하 분산을 위한 분리 시작 > Ch 5. 메시지 순서 보장을 위한 메시지 시퀸스 넘버 생성기 추가 >
02. 레디스 사용하여 채팅방 기준 메시지 시퀸스 넘버 생성하기
입니다.
💬 Redis로 채팅방별 메시지 시퀀스 번호 생성하기
- 이번 글에서는 채팅 시스템에서 채팅방(또는 채널) 기준의 메시지 시퀀스 번호를 Redis로 생성하는 POC 예제를 소개합니다.
- 목적은 메시지 순서 보장과 유실 최소화를 위해 Redis를 시퀀스 아이디 생성기로 사용하는 방법을 검증하는 것입니다.
- 본 예제는 파트2 챕터2에서 만든 단순 다이렉트 채팅 예제를 기반으로 하며, Redis 의존성 추가, AOF 설정, 시퀀스 생성기 구현, 그리고 동작 검증까지 다룹니다.
🛠 핵심 아이디어
- 채널별 고유 키 생성 → Redis에서 INCR로 시퀀스 발급
- AOF + RDB 영속화 설정 → 장애 발생 시 유실 범위 최소화
- 단일 노드로 먼저 검증 → 이후 클러스터로 확장 가능
📦 구성 및 환경 설정
- 프로젝트 복제 후 docker-compose.yml에 Redis 서비스 추가
- Redis 실행 시 설정:
- appendonly yes
- appendfsync everysec → 성능과 내구성의 균형
- Redis Insight로 설정값 확인:
- CONFIG GET appendfsync
- CONFIG GET save
- 애플리케이션에 spring-boot-starter-data-redis 의존성 추가
💻 구현 요약
DTO: MessageNotification
- 필드: content, Long seqId
서비스: MessageSeqIdGenerator
- buildMessageSeqIdKey(channelId) → message:%d:seq_id 형태의 키 생성
- getNext(channelId) → redisTemplate.opsForValue().increment(key)
- peek(channelId) → 현재 값 조회(증가 없음)
메시지 핸들러 적용
- 메시지 전송 시 getNext(channelId)로 seqId 발급
- Notification 객체에 포함해 전송
🔍 동작 검증
- Postman으로 다이렉트 채팅 메시지 전송 → Redis에서 채널별 시퀀스 값 증가 확인
- Redis Insight로 예시 확인:
- Redis를 중지 후 재시작 → AOF 덕분에 시퀀스 값 복구 확인
⚠️ 주의사항 & 확장
- 단일 Redis 노드 → 장애 시 위험 → Redis Cluster + replica 구성 권장
- appendfsync always → 안전하지만 성능 저하 큼, everysec이 현실적
- INCR는 원자성 보장 → 별도 락 불필요
- Redis를 시퀀스 생성기로 쓰는 방법은 간단하면서도 실무적인 방법입니다. 채널 단위로 독립된 시퀀스를 유지하면 메시지 순서 재정렬, 중복 처리, 재전송 보정이 훨씬 단순해지기 때문입니다.
- 다만, 운영 환경에서는 영속화 전략과 복제 구조를 반드시 설계해야 하며, 시퀀스 값이 중요하면 모니터링과 알림 체계를 통해 비정상 동작을 빠르게 감지해야 합니다. 또한 시퀀스 포맷을 채널ID-타임스탬프-증분 같이 구성하면 디버깅과 장애 복구에 도움이 됩니다.
