주제 선정 배경

현재는 Nest 서버가 웹소켓과 API 서버 역할을 동시에 수행하고 있다. 하지만 이런 구조에서는 부하테스트나 트래픽 추적 시 어려움이 있을 것 같다는 의문이 들었다. 서버를 분리하면 병목 현상을 줄일 수 있고, 소켓과 API 관련 로그가 분리되어 문제점 파악도 더 쉬울 것 같다. 이러한 맥락에서 서버를 목적에 맞게 분리했을 때의 장점과 단점을 분석해보고자 한다.

api 서버와 socket서버의 분리

분리했을 때의 장점

1. 장애 전파가 없을 것이다.
   • 소켓 서버가 죽더라도 게임 진행은 힘들지만 기본적인 기능(방 나가기, 로그아웃)은 여전히 이용 가능하다.
2. 트래픽에 대한 추적이 용이해 질 것이다.
   • 소켓 관련 트래픽, api 관련 트래픽에 대해 분리하여 확인할 수 있을 것이다.
3. 소켓용 서버는 비교적 가벼운 프레임워크를 활용 가능할 것이다.
   • 소켓 통신에 대한 트래픽이 많을 것으로 예상되는데, 소켓 통신만 간단히 구현한다면 보다 가벼운 프레임워크를 사용하여 불필요한 오버헤드를 감소시킬 수 있고, 전체적인 코드 베이스도 보다 간단해 질 것으로 예상된다.
4. 단일 책임 원칙을 보다 준수하는 구조가 될 것이다.
   • nest 서버는 api 로직만, 소켓 서버는 소켓 통신 관련 로직만 포함한다면 서버의 책임 분할이 가능하다.

분리했을 때의 단점(거의 장점의 반대)

1. 장애 전파의 위험성

   • 소켓의 트래픽 과부하로 서버가 죽는다면 api 기능도 이용이 불가능해지는데, 이는 프로젝트의 완성도를 떨어뜨릴 가능성이 큼.

2. 트래픽 추적이 비교적 어려워짐.

   • 서버의 트래픽을 추적할 때, api에 대한 트래픽과 소켓에 대한 트래픽을 분리하여 확인하기가 어려워 질 것이다.

3. 비용 효율성 저하

   • 소켓에 대한 트래픽이 커져 서버의 확장이 필요한 시점에 전체 서버를 수직확장을 하는 것보다 소켓 서버만을 수직확장 하는 것이 비용적으로 효율적이라고 한다.

   ---

요약 (by 클로드)

배경:

1. 현재 Nest.js로 웹소켓과 API를 통합 운영 중
2. 트래픽 추적과 부하테스트의 어려움 인식
3. 병목 현상과 문제 파악을 위한 서버 분리 검토

장점:

1. 장애 격리 가능 : 소켓 서버 장애 시에도 기본 API 기능 유지
2. 모니터링 용이성 : 트래픽과 로그를 서비스별로 분리 추적
3. 최적화된 기술 스택 : 웹소켓 서버에 경량 프레임워크 사용 가능
4. 책임 분리 : 각 서버가 단일 책임만 담당