Trouble Shooting (12) 썸네일형 리스트형 API 호출 성능 최적화 (feat. 사영 - Projection은 어디서나 보여요) 문제 상황클라이언트가 자주 사용하는 특정 API가 있는데, 이게 체감상 로딩이 느린것 같다라는 얘기를 들었다. 실제로 내가 사용해봐도, 부쩍 느려진 느낌이다.그래서 일단 AOP를 통해 @PerformanceCheck를 구현하고, API에서 걸리는 총 시간을 측정하기로 했다.아래의 코드 예시는 실제 코드가 아니라, 해당 상황을 재현하기 위해 사용된 코드이다. 문제 원인 파악정량적 상황 파악 파악을 위해 다음의 준비를 가진다.간편한 사용과 시간 체크라는 관심사 분리를 위해서 Spring AOP를 통한 어노테이션을 생성하고, 이를 통해 성능체크를 진행하려 한다. 자세한 내용은 이전에 관련 글을 써두었기에, 이를 참조하기 바란다.https://namucy.tistory.com/81 Aspect Oriented .. Refresh Token 회전(갱신) 시 발생하는 동시성 문제 문제 상황) access token이 만료되었을 때 frontend 쪽에서는 refresh token을 날리도록 하였다.만약, 한 페이지에 두 개의 api요청을 날린다고 한다고 가정하자.그리고 이 때 access token이 만료되었다면 어떤 일이 일어날까? 먼저 be는 두 개의 요청에 대해서 401을 날릴 것이다.그러면 자연스럽게 fe에서도 두 개의 요청에 대한 refresh token 요청을 날릴 것이다.즉 두 번의 refresh 요청이 들어온다. 문제는 이 때 발생한다.두 개의 refresh요청은 모두 같은 쿠키(같은 refresh token)를 통해서 들어온다. 첫 번째 요청이 들어올 경우, DB에 refresh token이 있는지를 확인 -> 있을 경우 refresh 토큰을 갱신하고, 기존의 것.. github action gradle cache 사용으로 빌드 시간 단축 (초안) gradle 매번 다운로드 후 설치했는데캐시 사용함.리포지토리당 5기가 제한깃허브 푸시 기본 시간 2000분이라고 하더라. + 예상되는 문제점 : 원래는 버전이 다를 경우 다른 gradle 사용할 가능성 있다.버전에 대한 값을 넣은 해시값 만들어서 관리하기에 문제는 없음.문제 상황 : gradle wrapper를 통한 JAR 빌드 과정에서 소요되는 시간이 매우 길었습니다.원인 파악 :Intellij에서 실험해본 결과, gradle 다운로드 및 설치하는 과정이 없었고, 빌드만으로 5초가 걸리는 반면,(물론 성능이 다른 것도 감안해야 할 것 같습니다.)github action상에서는 매번 새로운 가상 환경을 사용하기에,위의 로그처럼 다운로드 후 설치하는 방식을 사용하므로 시간이 오래 걸립니다.해결 방안 :어.. AOP : Dummy User 생성 + Id 기반 Entity 설정 아직 개발 초기 단계라 더미유저 생성의 필요성이 있다.그렇지만 각 Service별로 매번 user의 정보를 추가하는게 귀찮았다.만약 생성됐다면 알아서 hibernate에서 select를 통해서 user를 생성하고 끝내겠지만,생성이 되지 않을 경우를 대비해서 모든 로직마다 dummy를 추가해야 하기에이러한 귀찮음을 막고자 Custom Annotation을 만드는 과정도 소개한다. 1. DummyUserType Enum 생성 맨 처음 생각해 줄 것은 dummy 유저라도 role이 다르기 때문에,이 role별로 다르게 추가하는 것을 설정하기 위한 DummyUserType을 구현했다.@Getter@RequiredArgsConstructor@FieldDefaults(makeFinal = true, level =.. Tomcat의 일부 Thread가 놀고 있다?! TransactionSynchronizationManager(이하 TSM)를 통한 트랜잭션 동기화를 진행한 코드를 작성하는 중에다수의 요청을 보낼 시 connection이 어떻게 이뤄지는지, 멀티스레드를 통한 병렬처리가 가능한지 궁금해서 동시에 요청을 보내는 법을 알아보았다. postman의 collection에서 다음과 같이 여러개의 요청을 한번에 보내는 것이 가능했다. 문제는 16개의 요청을 동시에 보내는데, 보낼때마다 아래의 그림처럼 10개의 스레드만 형성이 되어서 사용이 되었다. 나머지 6개의 요청은 10개의 스레드중 먼저 작업이 끝난 스레드를 통해서 작업이 이루어졌다.왜 10개인가를 주목해서 봐야할 것 같아서 처음에 문제라고 생각한 부분은 tomcat 서버의 스레드풀 개수였다. 1. Tom.. Docker Compose with Github Action Troubleshooting name: Docker Compose CI/CD Pipeline# STEP1: Main Branch에 push 또는 pull request가 발생할 때 실행한다.on: push: branches: ['main'] pull_request: branches: ['main']jobs: # STEP2: SpringBoot_CI_CD_Pipeline이라는 Job을 실행한다. Docker_Compose_CI_CD_Pipeline: # 최신 버전의 Ubuntu에서 실행한다. # docker가 기본적으로 제공되는 환경 runs-on: ubuntu-latest steps: # STEP3: CI (1) 공식 Checkout Action을 사용해 저장소의 코드를 가져온다. .. 효율적인 Git Merge를 위한 전략 - Local에서 Merge 팀원들과 각자 작업을 하던 것을 github에서 원격으로 merge하는 과정에서 잦은 충돌이 일어나고 있다.처음부터 각자의 작업물을 합한 것이 아닌, 개별끼리 만들고 중간에 합치는 과정이라어느 정도 충돌은 예상되기는 했지만, merge하는 과정에서 문제가 되는 것은 다음과 같다. 문제 상황 )다른 branch로 merge하려고 할 때 발생하는 issue 모음merge 할 때, 더하고 빼는 과정에서 merge할 대상 브랜치의 작업자와 일일이 확인해야 하는 번거로움이 필요.중복된 메서드 정의와 서로 다른 변수 명명 규칙으로 인해 충돌이 발그 외의 다른 것도 있지만 위 두 개를 github의 인터페이스 상으로는 확인하는 것이 어려웠다. 그래서 이를 확인하기 위해서. IDE의 힘을 빌리고자 한다. 해결 방법 ).. Spring Boot - 406 Error, No acceptable representation 문제 상황 ) spring boot를 통해서 간단한 CRUD기능을 하는 API를 구축하고, 이를 테스트해보기 위해서Postman을 통해 간단한 POST 요청을 보냈는데 위와 같이 에러가 떴다. 검색을 해보면 문제의 원인이 되는 부분이 다양하게 나와있기에일단 먼저 내 코드의 어떤 부분이 문제가 되는지 로그의 stackTrace를 통해서 파악해 보았다. 문제점의 원인 파악)1. StackTrace를 통한 메소드 흐름 확인 일단 첫 번째 줄에서 AbstractMessageConverterMethodProcessor 클래스의writeWithMessageConverters 메서드를 보자.공식 document를 찾아보니 해당 클래스는 다음과 같이 요약되어 있었다. Extends AbstractMessageCo.. 이전 1 2 다음 목록 더보기
