패스트캠퍼스 환급챌린지 29일차 : 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 강의 후기

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

안녕하세요 :)

오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 스물 아홉번째 날입니다.

스물 여덟번째 날에는 왜 LB가 필요한가에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.

오늘 학습할 내용의 제목은,

입니다.

🔢 왜 메시지 시퀀스 넘버 생성기가 필요한가?

유니크 아이디, 순서 보장, 그리고 채널 기반 메시지 정렬까지
- 이번 포스팅에서는 서비스 구조 개선을 위한 마지막 작업인 메시지 시퀀스 넘버 생성기 추가에 대해 다룹니다. 단순히 메시지에 고유한 아이디를 붙이는 차원을 넘어, 메시지 순서 보장과 샤딩 환경에서의 확장성을 고려한 설계 이유와 구현 방향을 소개합니다.

💬 현재 메시지 ID는 어떻게 관리되고 있을까?

현재 메시지 테이블에서는 각 메시지에 대해 Auto Increment 정수값을 사용하여 고유한 ID를 생성하고 있습니다. 이 방식은 단일 데이터베이스 환경에서는 문제가 없지만, 다음과 같은 한계를 갖고 있습니다.
- 🔄 클라이언트에서 누락 메시지 감지 불가
  예: 메시지 1, 2 이후 5를 받으면 3, 4가 누락된 건지 판단 불가
- 🔥 DB 확장성 부족
  Auto Increment는 단일 마스터에서만 안전하게 사용 가능하므로, 샤딩 시 ID 충돌 가능성 있음

🧱 샤딩 환경에서 생기는 문제점

향후 메시지 테이블에 대한 DB 샤딩이 예정되어 있습니다. 이 경우 여러 DB 인스턴스가 존재하게 되는데, 각각의 DB는 독립적으로 Auto Increment를 수행하므로 다음 문제가 발생합니다.
- ✅ ID 충돌 문제
  각 DB가 100, 101 등 동일한 ID를 발급할 수 있음
- ❌ 범위 기반 ID 관리의 한계
  예: DB1은 1~~10,000 / DB2는 10,001~~20,000 식으로 관리하면 유연성 제약 발생

📡 메시지 순서 보장과 누락 확인의 어려움

현재 구조에서는 메시지가 어떤 채널에서 생성됐는지 알 수 있는 정보가 DB에 없습니다. 이로 인해 다음 문제가 발생합니다.
- 메시지 1번은 채널 A에서, 메시지 2번은 채널 B에서 생성돼도 ID는 순차적으로 할당됨
- 동일 채널에 있는 유저에게는 순서가 어긋난 메시지가 전달될 수 있음
- 클라이언트는 마지막으로 받은 ID와 다음 메시지 ID의 간격만 보고는 누락 여부 판단이 불가능함
예: 1번, 2번 메시지 이후 5번 메시지가 도착하면, 중간에 3번, 4번이 누락된 건지 아닌지 알 수 없음

🧩 해결책: 채널 기반 시퀀스 넘버와 Redis 도입

✔️ 해결 전략
1. 메시지 테이블에 채널 정보 추가
  → channel_id + sequence_number 복합키 구조 도입
2. DB Auto Increment 대신 외부 시퀀스 생성기 도입
  → Redis를 이용해 채널별 시퀀스를 발급받도록 구현
💡 왜 Redis인가?
- 빠르고, 단일 쓰레드로 순차성을 보장
- INCR 명령으로 간단하게 채널별 시퀀스를 분리해서 발급 가능
- 구현이 상대적으로 단순하며 분산 환경에서도 신뢰 가능

🧠 메시지 순서 보정 기능도 함께 도입

이번 작업은 단순히 메시지에 고유한 번호를 부여하는 걸 넘어서, 서비스의 확장성과 사용자 경험을 함께 고려한 설계였습니다.이처럼 데이터의 정렬, 순서, 누락 여부는 클라이언트 UI에는 보이지 않지만, 사용자 경험을 좌우하는 핵심 요소입니다. 앞으로도 이런 세밀한 시스템 설계를 통해 더욱 견고한 서비스를 만들어가고 싶습니다.
특히, Redis 기반의 시퀀스 발급기는 수평 확장을 위한 중요한 인프라 요소로 느껴졌습니다. 채널 기반으로 시퀀스를 분리해 관리함으로써, 샤딩 환경에서도 일관된 순서성과 안정성을 유지할 수 있다는 점에서 큰 의미가 있다고 생각합니다.
이처럼 데이터의 정렬, 순서, 누락 여부는 클라이언트 UI에는 보이지 않지만, 사용자 경험을 좌우하는 핵심 요소입니다. 앞으로도 이런 세밀한 시스템 설계를 통해 더욱 견고한 서비스를 만들어가고 싶습니다.

패스트캠퍼스 환급챌린지 31일차 : 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 강의 후기 (1)	2025.07.31
패스트캠퍼스 환급챌린지 30일차 : 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 강의 후기 (1)	2025.07.30
패스트캠퍼스 환급챌린지 28일차 : 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 강의 후기 (0)	2025.07.28
패스트캠퍼스 환급챌린지 27일차 : 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 강의 후기 (2)	2025.07.27
패스트캠퍼스 환급챌린지 26일차 : 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 강의 후기 (2)	2025.07.26

코딩스쿨