고민사항
현재 퀴즈 애플리케이션의 패키지 구조는 아래와 같습니다.
Game 도메인이라는 패키지가 존재하고, 해당 패키지 안에 Game 도메인과 관련한 CRUD를 책임지는 Game API 서비스가 존재하고, 게임 진행 비동기 서비스를 담당하는 Game Engine 서비스가 존재합니다.
여기서 2가지 고민사항이 발생합니다.
첫번째는, Game API 를 책임지는 서비스와 WebSocket을 통해 게임 비동기 서비스를 담당하는 Game Engine 서비스가 하나의 패키지에 있지 않도록 하고싶다 입니다.
고민을 한 이유는, 현재 Game API 서비스는 게임 시작 요청이 들어오면 Game 진행 로직을 Game Engine 서비스에게 위임하고 있는 방식인데, 이때 비동기 로직을 통해 별도의 스레드에서 실행하게 됩니다.
여기서 Game Engine 서비스는 퀴즈게임을 진행하는 사람수 에 따라 많은 스레드를 사용하면서 CPU를 점유하기 때문에, Game API 서비스와 Game Engine 서버를 분리시키고 다중 서버로 확장하기 쉽도록 구조를 가져가는 것이 좋다고 생각했습니다.
즉, 이벤트를 발행하는 방식을 통해 서버를 분리하고 느슨할 결합을 유지할 수 있도록 추후에 개선할 수있다고 생각했습니다.
두번째 고민사항은 Game Engine 서비스의 너무 많은 책임 입니다.
Game Engine 서비스는 특정 방에서 진행되는 퀴즈게임을 컨트롤하는 역할(게임 로직 책임)을 수행합니다.
하지만 게임 로직 책임 이외에도 게임 결과를 계산하고, 게임 결과를 기록하기 위해서 Game레포지토리, GameResult레포지토리, Room레포지토리등 많은 인프라스트럭쳐 빈들에 의존하게 됩니다.
그래서 서비스 로직이 복잡해지고 무거운 책임을 지고 있기 때문에, 게임 결과 계산, 게임 결과 기록등과 같은 책임을 별도의 서비스에게 위임하는 것이 좋겠다고 생각되었습니다.
개선 방안
최종적으로 개선한 방안은 아래와 같습니다.
우선 추후에 게임 엔진 담당 서버와 API가 분리될 수 있다는 점과, 게임 엔진 담당 서버의 확장성을 고려해서 Game API 서비스와 Game Engine서비스의 패키지를 분리합니다.
그리고 GameEngine 서비스에 있던 무거운 책임을 Game 결과 서비스와 Game 랭킹 서비스로 분리하여 단일 책임 원칙을 지키도록 개선했습니다.
->
'프로젝트 > CStar' 카테고리의 다른 글
[프로젝트] 수동 DB 마이그레이션 관리의 문제점..그리고 flyway 사용해보기?! (0) | 2024.09.09 |
---|---|
[프로젝트] 게임 엔진 ThreadPool Size는 어떻게 설정해야 할까? [작성중] (1) | 2024.09.08 |
[프로젝트] CStar 조회 쿼리 개선해보기 (0) | 2024.09.08 |
[프로젝트] Redis 아키텍처 적용해보기(feat. sentinel) [작성중] (0) | 2024.09.07 |
[프로젝트] Redis 를 Queue로 활용했을때 성능 & 동시성 체크해보자 (0) | 2024.09.04 |