Github API의 느린 응답 이슈 개선을 위한 스케줄링을 통한 DB 업데이트
문제 상황 & 접근매우 느린 Github API를 사용해야 했으며 바로 데이터를 response 해야 함Github Repository의 기여자들의 기여도(커밋, addition, deletion)와 기여자 정보를 가져오는 API Github Repository -> Insights -> Contributors 탭에 브라우저를 통해 들어가면 매번 분석을 위해 어느정도 Delay 이후 정보를 확인할 수 있다. 사용하고자 하는 Github API가 해당 정보들을 가져오기 때문에 느린 것으로 예상된다. 문제가 생긴 Github API 의 특징맨 처음 호출시 202 상태코드 response 및 계산 시작계산이 끝나면 그 다음 호출시 데이터 반환하며 비동기 호출 방법을 제공하지 않음평균 7초 이상 소요되며 최대 ..
Redis Sorted Set으로 기존 DB 페이징 기반 랭킹 시스템 개선
문제 상황 & 접근DB 페이징 쿼리 기반으로 랭킹을 조회하는데 있어 성능이 좋지 못함오프셋 기반 페이징이라 데이터가 많아질 수록 느려지기에 Redis를 통해 랭킹 시스템을 구축하고자 결정 적용기존 쿼리Pageable 를 통해 데이터베이스의 데이터를 정렬하여 오프셋 기반 페이징을 수행한다.where 절의 조건은 랭킹에 포함할 멤버인지 확인하는 정도의 조건이다.DB에서 순위를 매겨야 하기에 정렬은 불가피 했고, 서비스 요구사항에 의해 페이징도 필요했다. (요구사항이 아니더라도 많은 데이터가 있는 경우 페이징이 없다면 전체조회는 위험하다.) Redis의 자료구조 중 하나인 Sorted Set은 member를 score 기반으로 정렬하여 저장한다.순위를 매겨 조회해야하는 경우 효과적이다.페이징과 같이 부분만 ..
문제 상황동시에 여러 번 호출할 경우 DB 데이터가 중복 저장되는 현상 빈번히 발생한 번의 요청에 종류가 다른 4가지 멤버의 기여도를 가져와 하나의 같은 테이블을 업데이트, 다른 한 테이블에는 insertDB Lock 적용DB Lock을 통해 데이터의 중복 저장을 막을 수 있을 것이라 기대시도 1 : @Version 기반 낙관적 락성능을 생각해 낙관적 락을 먼저 걸어보기로 했다.Jpa 엔티티에 @Version 필드를 추가해 락을 적용한다.다중 요청시 version 필드의 충돌로 인해 롤백이 자주 발생했다.쓰기 작업에 더 높은 수준의 락이 필요하다고 느꼈다.시도 2: 공유락읽기 작업에는 락이 걸리지 않아도 되었기에 공유락을 선택했다. (이전의 데이터를 읽어도 큰 상관은 없었다.)사용할 JpaReposito..