Rand_Chat 프로젝트 백엔드 아키텍처/로직을 정의
개요
-
초기 설계단계에서 부하분산을 위해
단순히 동일 어플리케이션을 여러 인스턴스로 두어부하를 분산하려 계획 -
각 서버로 부하가 분산은 되는 것은 OK
-
하지만여러 문제가 있을것으로 예상되었음.- 상대적으로
부하가 많은 채팅관련 요청으로 인해서인증/인가 관련 시스템이 병목될 것. 하나의 인스턴스가 모든 역할을 함. 이 는 서버다운 시 전체가 다운되어 버릴 것 .- 채팅 서비스의 특성상
웹소켓 스레드 관리가 매우 중요한데 ,웹소켓 관리와 I/O작업을 동시에 하면 상당한 부담 , 위험이 있음.
- 상대적으로
-
따라서부하분산과 가용성모두를 가져가기 위해 다음과 같은 결정을 하였음.각 도메인 별 서버를MSA 방식으로 나누어 분산분산환경에서의 웹소켓,SSE통신유지를 위해Redis Pub/Sub도입- 상대적으로
부하가 적은 인증/인가 서버는1대로 운용하고 , 부하가 많을 것으로 예상되는채팅관련 서버들은2대 이상으로 운용 웹소켓 서버의 특별관리를 위해I/O부담을 주지않기 위해채팅 웹소켓 서버와채팅 I/O서버의 분리
4-1 . 둘 간의 프로세스는WebClient async/non-blocking통신으로 웹소켓 - > I/O서버로의 작업RDBMS의 작업에는쓰기 작업과읽기작업을 나눔 (Master - Slave 구조()- 데이터 영구저장이 중요한 작업에는
RDBMS + Redis를 활용하되 , 영구저장이 중요하지 않은 작업(분산락, 매칭 등)에는Redis만을 사용하여응답속도 , 부하에 초점을 둠
전체 아키텍처
스프링 인스턴스
- 멤버 서버 x 1
- 채팅 매칭 서버 x 2
- 채팅 웹소켓(STOMP) 서버 X 2
- 채팅 I/O 서버 X2
멤버서버
역할
- 프로젝트의 인증과 인가를 담당
- 프로필사진 변경 , 회원정보 변경 등 회원관련 도메인을 담당
특징
- 일반적인 스프링 프로젝트와 동일
- RDBMS + Redis 방식의 I/O작업에 초점
매칭서버
역할
프로젝트의 매칭 대기열,매칭 수락/거절을 담당
특징
SSE 커넥션과 Redis Pub/Sub,Redis를 활용하여매칭대기열을 관리, 매칭알람- 매칭 수락/거절을 통해
매칭대기열 관리, 매칭 성공 시채팅방 생성을 담당 - 리그오브레전드 게임의 매칭시스템을 생각하면 이해가 쉬움.
아키텍처
채팅 웹소켓 서버 , 채팅 I/O서버
채팅 웹소켓 서버
역할
웹소켓,STOMP프로토콜을 통해 채팅방 구독, 채팅방 메시지 전송 등을 담당
특징
- 2대로 운용되며, 웹소켓연결관리 , 통신에 집중하기위해 I/O작업을 피한다.
- I/O 작업은 WebClient API 를 통해 async, Non-Blocking I/O 방식으로 작업한다.
- 분산환경이므로 마찬가지로 Redis Pub/Sub을 통해 전파된다.
채팅 I/O서버
역할
- 채팅과 관련된
I/O API, 웹소켓 서버로부터 받은 ASYNC I/O 요청을 처리한다.
특징
WebFlux WebClient API,Non-Blocking , Async I/o
아키텍처
ERD 및 Redis현황
Redis
ERD
📘 2025/07/15 첨언 — 쿠버네티스를 학습하며 느낀 점
쿠버네티스를 공부하면서, 과거 내가 설계했던 구조에 대해 다시 돌아보게 되었다.
• 여러 EC2 인스턴스에 동일한 서비스 컨테이너를 하나씩 띄우는 방식은 고가용성(HA) 측면에서는 유효한 설계였다.
서비스 장애를 EC2 단위로 격리할 수 있었기 때문이다.
• 하지만 오케스트레이션, 자동 복구, 트래픽 라우팅, 자원 효율성 같은 측면에서는 비효율적인 설계였다는 것을 알게 되었다. 실제로는 하나의 EC2에 여러 컨테이너를 밀도 있게 배치하는 편이 리소스 낭비를 줄일 수 있었다.
• 당시엔 쿠버네티스와 같은 컨테이너 오케스트레이션 도구가 없었고, 수동으로 EC2 + Docker + nginx 등을 구성했기 때문에 틀린 설계는 아니었지만, 확장성과 유지보수 관점에서 한계가 분명했다.
백엔드