본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
안녕하세요 :)
오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 스물 다번째 날입니다.
스물 네번째 날에는 왜 캐싱 레이어가 필요한가에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.
오늘 학습할 내용의 제목은,
Part 4. 서비스 부하 분산을 위한 분리 시작 > Ch 3. 모놀리틱 서비스 분해를 위한 단방향 카프카 연동 >
01. 지금까지 만들어진 채팅 프로젝트 리뷰
입니다.
🧩 단일 서버의 한계를 넘어서 – 모놀리틱 채팅 서비스 구조 리뷰와 분해 시작
- 이번 포스팅에서는 지금까지 구현한 채팅 서비스의 구조를 점검하고, 모놀리틱 구조의 한계를 해결하기 위한 구조 분리에 대해 이야기해 보겠습니다. 특히, 이후 Kafka를 활용한 서비스 간 비동기 통신 구조 도입을 위한 기초를 다지는 시간이기도 합니다.
✅ 지금까지 구현된 채팅 서비스 정리
- 현재까지 구현한 채팅 서비스는 하나의 서버에 모든 기능이 들어가 있는 모놀리틱 구조입니다. 구현된 주요 기능은 다음과 같습니다.
- 🔐 인증 기능
- 👥 사용자 간 연결 요청/수락/거부/삭제
- 💬 다이렉트/그룹 채팅 생성 및 메시지 전송
- 🚪 채널 입장/퇴장 관리
- 📱 오프라인 사용자 대상 푸시 로직 (mock 처리)
- 푸시 기능은 실제로 외부로 보내지는 구조는 아니지만, 비즈니스 로직과 인터페이스가 갖춰진 상태이며, 추후 실제 푸시 시스템과 연동만 하면 됩니다.
🚨 단일 서버 구조의 문제점
- 하나의 서버가 모든 기능을 담당하는 현재 구조는 성능과 확장성에서 심각한 한계를 가지고 있습니다.
- 물리적 한계
- 트래픽이 증가하면 CPU, 메모리, IO 자원이 포화됩니다.
- 특히 채팅처럼 소켓 커넥션이 장시간 유지되는 서비스는 커넥션 수 자체가 서버에 큰 부담입니다.
- 커넥션 관리 이슈
- 커넥션 한 개당 리소스가 소모되고, 이 수가 많아지면 서버가 아무 일 안 해도 과부하가 올 수 있습니다.
- 고가용성 부재
- 현재 모든 기능이 하나의 서버에 있기 때문에 이 서버가 다운되면 서비스 전체가 중단됩니다.
⚙️ 지금까지 적용한 부하 분산 전략
- 단일 서버 구조의 한계를 극복하기 위해, 일부 부하 분산 시도를 진행했습니다.
- 🗂️ DB 분리 (쓰기/읽기 노드)
- 읽기 전용 노드를 만들어 일부 SELECT 요청을 분산함으로써 DB 부하 감소.
- 🧠 Redis 캐시 도입
- 초기에는 세션 저장소로만 활용했지만, 이후에는 DB 조회 캐싱 레이어로 활용.
- 캐시 도입 후 테스트 기준으로 약 50%의 DB 조회 요청이 캐시로 대체됨.
- 이러한 구조는 트래픽에 대한 수평 확장성을 제공하지만, 서비스 자체의 확장성에는 한계가 있습니다.
🧱 모놀리틱의 구조적 한계
- 단일 서버에서 채팅 커넥션을 독립적으로 관리하고 있기 때문에, A 서버에 접속한 사용자는 B 서버에 접속한 사용자와 소통할 수 없습니다.
- 소켓 기반 커넥션이 서버 로컬에 종속되기 때문에, 서버를 여러 대 띄워도 각 서버가 고립된 월드처럼 작동합니다. (예: 게임에서 서버별 월드)
🔄 구조 분해의 방향
- 앞으로는 지금까지의 기능을 바탕으로, 다음과 같은 기능 단위로 서버를 분리할 예정입니다.
| 역할 | 설명 |
| 인증 서버 | 사용자 인증, 로그인 관리 |
| 커넥션 서버 | 소켓 커넥션 유지 및 관리 |
| 채팅 서버 | 메시지 송수신, 채널 관리 |
| 친구 서버 | 관계 설정 및 조회 |
| 푸시 서버 | 푸시 알림 처리 |
- 이처럼 구조를 분리하면, 각 서버가 독립적으로 스케일 아웃 가능하며 장애 발생 시에도 전체 장애를 방지할 수 있습니다. 물론, 이들 사이의 연동을 위해 Kafka 같은 비동기 메시징 시스템이 필요하게 됩니다. 그 이야기는 다음 포스팅에서 이어갈 예정입니다.
