본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
안녕하세요 :)
오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 스물 일곱번째 날입니다.
스물 여섯번째 날에는 왜 모놀리틱 분해가 필요한가 어떻게 분해할 것인가에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.
오늘 학습할 내용의 제목은,
Part 4. 서비스 부하 분산을 위한 분리 시작 >
Ch 4.책임 분리로 진행하는 모놀리틱 서비스 분해와 Nginx 연동 >
01. 인증 서비스를 분리하는 이유
입니다.
🔐 왜 인증 서비스를 분리했는가?
- 모놀리틱 구조 분해의 두 번째 단계
🧱 모놀리틱 구조의 한계
- 이번 프로젝트에서는 채팅, 인증, 푸시 기능이 모두 한 서버에 통합된 모놀리틱 구조로 출발했습니다. 푸시 서버를 먼저 분리한 데 이어, 이번에는 인증 서비스를 별도 서버로 분리하는 작업을 진행하게 되었습니다.
🔍 인증 서비스 분리의 이유
- 1. 서로 다른 통신 방식
- 인증 서비스: REST API 기반
- 채팅 서비스: WebSocket 기반
- 2. 기능적 책임 분리
- 인증: 사용자 등록, 로그인, 세션 발급
- 채팅: 메시지 송수신, 채널 관리
🔁 푸시 서버 분리와의 차이점
- 푸시 서버는 분리하더라도 클라이언트에 영향을 주지 않는 구조였습니다. 서버 사이드에서만 Kafka로 메시지를 전달하면 되었기 때문입니다.
- 하지만 인증 서버는 다릅니다. 기존에는 클라이언트가 하나의 엔드포인트만 바라보면 되었지만, 이제는 인증 서버와 채팅 서버 각각의 엔드포인트를 알아야 합니다. 즉, 클라이언트 코드도 수정이 필요합니다.
⚙️ 구현 및 연동 구조
- 인증 서버는 자체적으로 Redis와 DB에 접근해 세션과 사용자 정보를 관리합니다.
- 채팅 서버는 사용자가 인증을 마치고 받은 세션 ID를 전달받아, 해당 사용자가 실제 로그인된 사용자인지 Redis와 DB를 통해 검증합니다.
- 인증 서버를 여러 개 띄우는 경우, 클라이언트가 직접 그 수만큼 엔드포인트를 알아야 하는 문제가 발생합니다. 이를 해결하기 위해 추후에는 Nginx 등 로드 밸런서를 도입할 예정입니다.
⚡️ 분리의 실질적 효과
- 인증 서비스만 독립적으로 스케일 아웃 가능
- 클라이언트와 서버 간 계약 명확화
- 서버별 의존성 최소화
- 향후 유지보수 및 장애 대응의 유연성 증가
- 이번 인증 서비스 분리 작업은 단순한 기술 분할이 아니라, 책임 분리와 확장성 확보를 위한 전략적 선택이었습니다. 특히 푸시 서버와 달리, 클라이언트에 영향이 있다는 점에서 훨씬 더 실질적인 구조 변화였습니다.
- 이 작업을 통해 느낀 점은 다음과 같습니다:
- 서비스 분해는 기술 트렌드가 아니라 현실 문제에 대한 해답이어야 한다.
- 분리의 기준은 '통신 방식', '기능 책임', '확장 가능성' 등 다양한 요소를 고려해야 한다.
- 분리는 곧 복잡성의 증가이기도 하므로, 실제 필요성이 뒷받침되어야 한다.
- 지금까지의 분리는 일종의 POC(Proof of Concept) 성격도 있습니다. 큰 리스크 없이 시도해보며 시스템의 향후 방향성을 확인하는 기회였고, 그 의미는 단순한 구현 이상이었다고 생각합니다.
