
프로젝트에서 제공하는 기능 중, 실시간 티켓팅 기능의 경우 단기간에 대량의 트래픽이 몰리는 상황을 가정할 수 있었다. 만약 단일 서버 구조를 선택한다면 앞서 이야기한 경우가 발생했을 때, 티켓팅과 관련이 없는 서비스의 응답 시간에도 영향을 미칠 것이라 판단하여 MSA 구조를 도입하였다.
현재 프로젝트의 구조는 Gateway가 최전방에 위치하며 그 뒤로 Auth, Core, Ticket 서비스가 각자 존재하는 상태이다. Gateway 부분은 NGINX 같은 L7 스위치를 사용할 수도 있었지만 Nest에서도 자체적으로 Microservice 관련 패키지를 제공하였기에 이를 사용하였다.
// cliet 생략
server
├── ...
├── gateway
│ ├── ...
│ └── src
│ ├── auth
│ ├── core
│ ├── socket
│ └── ticket
└── services
├── auth
├── core
└── ticket
현재 프로젝트에서는 Nest에서 제공하는 통신 방식 중, default인 TCP 방식을 사용하고 있다. 따라서 해당 방식을 기준으로 설명한다. (사실 다른건 아직 안써봐서 몰?루)