분류 전체보기

🎯 문제점현재 사용자의 선착순 정답 데이터를 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라는 중간 테이블을 두었는데, 이 테이블은 특정 방의 게임 중에서도 특정 회원의 구체적인 게임 결과를 기록하는 테..

🎯 기획현재 나에게 직접 필요한 서비스를 만들어서 사용해보고 싶다고 생각했다. 컴퓨터 공학등과 같은(현재 기술 면접을 위한 암기중..) 질문을 등록하고, 실시간으로 나에게 문제를 물어봐줄 수 있으면 좋겠다고 생각했다.(누워서도 그냥.. 심심찮게 풀어보면 너무 편할듯?!) 여러명이서 접속해서 먼저 맞추기와 같이 퀴즈 게임식으로 만들어도 재밌겠다고 생각했다.비슷한 서비스를 찾아보면 충분히 있을법 하지만..?! 당연히 개발 성장과 낭만을 위하여(..?) 직접 만들어보고 배포하는 학습을 진행해보려고 한다.(배포 해보자~!!!) 🎯 구상🔗 WebSocket자.. 그럼 이제 기획을 해봐야 하는데..!!실시간 퀴즈 서비스..? 어떻게 해야되지?! 우선 여러사람과 퀴즈 풀이를 하기위해서 기본적인 회원 API는 필..

Concurrent HashMap이 뭘까?일전에 Java의 동시성 문제의 해결책으로 쓰레드 안정성을 제공하는 java.util.concurrent 패키지를 언급했었는데, 구체적으로 알아보지 못했었다. java.util.concurrent 패키지에서 제공하는 Concurrent HashMap이 무엇인지 알아보고, 어떻게 동작하는지 학습해보겠다! ConcurrentHashMap우선 ConcurrentHashMap이 어떻게 생겼는지 알아보기 위해서 코드를 열어보았는데 정확히 6386줄이다. 두둥...public class ConcurrentHashMap extends AbstractMap implements ConcurrentMap, Serializable { . . . }위와 같이 생겼는데, 동시성을 ..

1. 일단 개선을 하긴 했는데.. 이전에 프로젝트 구조개선을 시도해보았다. 완성된 아키텍처는 아래와 같다.   주문 요청에 대한 요청 처리율도 향상되었고, 재고수량의 동시성 문제도 발생하지 않았다. 하지만 위의 개선된 구조는 내가 알고있는 지식 선에서 가능한 빠르게 구조를 잡아본 형태이고, 더 좋은 선택지가 있을 수 있기 때문에 어떠한 선택지가 있었는지 고민해보고, 새로 알게된 @Scheduling에 대해서도 학습해보면 좋을 것 같다.  2. Redis외에 다른 선택지? 1) 로컬 캐시우선 개선 구조에서 가장 중요하게 생각한 포인트는, 트래픽이 집중될것으로 예상되는 주문 서버의 주문 처리 로직을 MySQL 데이터베이스 I/O를 이용하지 않고 구현하는 것이었다. 그러기 위해서는 캐시 저장소를 활용하면 좋겠..

🌈 문제상황현재 프로젝트 진행 과정은 아래와 같다.1. 이슈/pr 생성2. 개발3. commit & push4. pr리뷰 및 병합 개발을 진행하면서 단위 테스트와 통합 테스트의 개수가 많아져 100개가 넘어가기 시작하였다.그래서 이슈/pr을 생성하고 개발이 완료된 후에 반드시 직접 테스트를 돌려볼 필요가 있었다.(만약 제대로 동작하지 않는 테스트가 있다면 개발 진행 중에 잘못된 코드가 있을 테니까!) 그러나 역시.. 사람이 직접 수동으로 테스트하려니까 까먹고(?) 테스트를 돌리지 않은 상태로 commit & push를 진행하기도 했고,심지어 테스트가 제대로 돌아가지 않는데도 pr후 병합을 해버리는 경우도 발생했다.(최신 pull 받고 테스트 돌렸는데 테스트가 실패해요...ㅠ) 그래서 이러한 수동 테스트..

이전 프로젝트에서는 동시간대에 많은 주문 요청이 들어올 때 동시성 문제를 해결하는데에 집중해서 프로젝트를 진행하였고 마무리 하였다. 이번에는 동시간대에 많은 주문 요청이 들어올 때 어떻게 성능을 개선해볼 수 있을지 고민해 보려고 한다. 기존 로직 성능 측정 & 문제 분석현재까지의 주문 요청 로직을 분석해보고, 어떻게 개선해볼 수 있을지 고민해보자.아래는 현재 주문 요청을 처리하는 컨트롤러, 서비스, 레포지토리 코드이다./** * 주문 생성 컨트롤러 */@PostMappingpublic Response create(@RequestBody final OrderCreate orderCreate) { final Long savedOrderId = orderService.create(orderCreate);..