프로젝트/CStar

🎯 문제상황프로젝트를 진행해감에 따라서 데이터 베이스 변경사항을 기록해놓으면 좋을 것 같다고 생각해서, 그동안은 resource 경로에 직접 테이블 변경 사항 sql문을 적어주었다.   이렇게 기록을 해주고, 어플리케이션을 시작할 때마다 모든 변경사항들이 자동으로 반영되어 최신화 되도록 하기 위해서 application-local.yml에서 아래 처럼 설정해주었다. 위는 실제 애플리케이션 구동마다 해당 sql문을 순차적으로 실행하게 된다. 문제는 여기서 발생하는데, 아래처럼 init_schema.sql은 이미 테이블이 생성되어 있다면 생성하지 않도록 되어있다. 하지만 아래 제약 조건을 거는 파일(즉, 테이블 내부의 설정을 변경하는 파일)의 경우에는, 애플리케이션이 시작될 때마다 제약 조건이 걸리게 되고..

고민사항현재 퀴즈 애플리케이션의 패키지 구조는 아래와 같습니다.  Game 도메인이라는 패키지가 존재하고, 해당 패키지 안에 Game 도메인과 관련한 CRUD를 책임지는 Game API 서비스가 존재하고, 게임 진행 비동기 서비스를 담당하는 Game Engine 서비스가 존재합니다. 여기서 2가지 고민사항이 발생합니다.첫번째는, Game API 를 책임지는 서비스와 WebSocket을 통해 게임 비동기 서비스를 담당하는 Game Engine 서비스가  하나의 패키지에 있지 않도록 하고싶다 입니다.고민을 한 이유는, 현재 Game API 서비스는 게임 시작 요청이 들어오면 Game 진행 로직을 Game Engine 서비스에게 위임하고 있는 방식인데, 이때 비동기 로직을 통해 별도의 스레드에서 실행하게 됩..

보호되어 있는 글입니다.

테이블 더미데이터 삽입(약 100만개)프로젝트에 적용시켜 볼 조회쿼리에 대한 성능을 측정하기로 했다.성능 측정에 필요한 테이블에 약 100만개 정도의 데이터를 삽입하기로 했다. 프로젝트에서 사용한 테이블 구조는 아래와 같다. 복잡한 조회에 사용되는 테이블은 크게 아래 4개와 같다.game, member_game_result, game_quiz, quiz 그래서 4개의 테이블에 약 100만개의 데이터를 삽입해주었다.아래와 같은 코드를 통해 정합성을 맞춰주면서 랜덤 데이터를 최대한 넣어 주었습니다!더보기퀴즈 테이블(quiz) -> 100만개 생성-- 높은 재귀(반복) 횟수를 허용하도록 설정-- (아래에서 생성할 더미 데이터의 개수와 맞춰서 작성하면 된다.)SET SESSION cte_max_recursion..

[현재 문제 점] [Redis 아키텍처] [Sentinel 적용해보기]

🎯 문제점현재 사용자의 선착순 정답 데이터를 Queue에 적재하고, 게임 엔진 서비스에서 사용자 정답 데이터를 꺼내서 정답인지 판단하고 응답해주고 있다. 정답 데이터 양식은 아래와 같다.class AnswerResult( val answer: String, val quizId: Long, val roomId: Long, val playerId: Long, val nickname: String,)  컬렉션 프레임워크의 Queue 자료구조를 사용했다면 동시성 패키지에서 제공해주는 스레드 안전한 자료구조를 사용했을 것이다.하지만 Redis의 List 자료구조를 사용하기 때문에 동시성 문제가 발생하는지, 시간복잡도 등을 체크해보면 좋을 것 같다. https://redis.io/doc..

문제점현재 Redis의 List를 이용해서 Queue 방식으로 사용자의 정답 제출 데이터를 입력 받고 있다.그리고 게임 엔진 서비스는 Redis Queue에 들어온 데이터를 하나씩 꺼내보면서, 정답인지 아닌지 판단하고 결과를 응답해주고 있다. 이 과정에서 게임 엔진 서비스는 Queue에 데이터가 있는지 없는지 확인하기 위해 while 문을 돌면서 데이터가 존재하지는지 확인하고 있다.. . . 생략while (checkTimeIn(startTime) && notExistWinner) { logger.info { "[WARN] busy waiting..." } gameAnswerQueueService.poll(roomId, quiz.id) ?.takeIf { it.answer == q..

🎯 배포 & 테스트 자동화 해보자구!이번에 CStar(퀴즈 애플리케이션 프로젝트 이름) 프로젝트는 배포까지 경험해볼 생각으로 도전했다.그럼 배포를 해봐야겠지..? 어차피 배포할거 빠르게 배포하고, 개발을 진행하면서 지속적으로 배포하면 좋겠다고 생각했기 때문에 개발 초기단계 부터 배포 과정을 거치기로 했다. 일전에 테스트가 많아지고 PR/코드리뷰/병합을 할때마다 테스트 수동실행에 불편함을 느껴서 Github Actions를 통해 테스트 자동화를 적용시켜본 적이 있었다. 이번에도 마찬가지로 이슈/PR/코드리뷰와 함께 프로젝트를 진행하기 때문에 테스트 자동화를 진행했다.   추가적으로 배포 과정 또한 자동화를 시켜켜서, 조금은 편하게(?) 지속적으로 배포해볼 생각이다.(배포 서버를 수동으로 접속해서,,, 수..

🎯 이슈/PR 템플릿 자동화이전 프로젝트에서는 아래와 같이 노션 공유페이지에 이슈/PR 템플릿을 공유하고, 필요할때마다 복사/붙여넣기를 활용해서 이슈/PR을 작성했다.  하지만 생각보다 너무 번거롭고 귀찮아서 이번에는 Github 자체에 템플릿을 등록할 수 있도록 세팅해보았다. github workflow나 기타 github 세팅에 필요한 파일들은 .github 파일안에 작성할 수 있다.위처럼 ISSUE_TEMPLATE라는 이름으로 디렉토리를 만들었고 안에는 아래와 같이 여러 이슈 템플리 양식을 만들어놓았다. 마찬가지로 PR 템플릿도 아래와 같이 만들어 두었다.  위 처럼 .github 파일 안에 만들어 놓으면, 이슈/PR 발행 시 쉽게 템플릿을 가져와서 사용할 수 있다.     🎯 느낀점별것 아니지..

🎯 테이블 고민했던 점Game 테이블은 특정 방에서 진행된 한번의 퀴즈 게임을 의미한다.Game 테이블을 통해서 추후에 퀴즈 시작시간, 종료 시간, 참여자, 풀이한 문제목록 등의 정보 조회가 필요할 것이라고 판단되었다. 그렇다면 Game 테이블이 진행한 게임의 Quiz ID 목록을 가지고 있어야할까?이 부분은 중간에 game_quiz 테이블을 두어서 특정 게임에 어떤 quiz가 사용되었는지 중간 맵핑 테이블을 두기로 하였다.(game 테이블과 quiz 테이블이 다대다 관계이기 때문) 마찬가지로 game과 member 간에 다대다 관계를 가질 수 있기 때문에, member_game_result라는 중간 테이블을 두었는데, 이 테이블은 특정 방의 게임 중에서도 특정 회원의 구체적인 게임 결과를 기록하는 테..