EVO

문제 사항 테스트코드가 40개를 넘어가면서 갑자기 그 이후로 간헐적으로 깨짐이 발생했다. 처음 생겼던 에러는 다음과 같았다. org.hibernate.exception.JDBCConnectionException: Unable to release JDBC Connection [The database has been closed [90098-224]] [n/a] 문제해결 시도 해당 에러를 검색해보니 원인은 다양했다. 1. H2 데이터베이스 설정 확인 H2 데이터베이스가 테스트 하나 실행하고 닫지 않도록 DB_CLOSE_DELAY=-1; 을 추가했다. 테스트가 독립적으로 실행하니깐 H2에 필요로 하는 커넥션이 많아진것으로 예상이 되어 HikariCP maximum pool size을 100개로 늘렸다. dat..

문제 상황 같은 키를 가진 프로젝트를 생성하면 UNIQUE 제약조건에 의해 예외(DataIntegrityViolationException)가 발생한다. 4가지 방법 1. 서비스계층에서 flush + try catch 엔티티를 저장하고 unique key에 의해 중복이 감지되면, try catch를 통해 예외 변화를 하면 된다. flush를 해야하는 이유는 @Transactional 이 붙은 메서드에서 사용되는 CrudRepository의 save()와 saveAll()은 메서드를 호출할 때 바로 쿼리를 실행하지 않고 1차캐시에 우선적으로 저장했다가 메서드가 정상적으로 종료되면 커밋이 되어 실제 DB에 반영된다. try-catch 블럭 내부에서는 쿼리가 실행되지 않으니 잡아낼 DataIntegrityVio..

문제 배경 로컬에서 정상적으로 API를 만들고 POSTMAN으로 테스트까지 해보고 배포를 했다. 하지만 정상적으로 요청이 오질 않아(404 error) NGINX 로그를 살피던 도중 의도치 않게 다른 문제를 발견하게 되었다. (위 문제는 Reverse Proxy 설정을 잘못한거라 해결했다) 에러로그가 굉장히 많이 쌓여 있었고 그중 수상하게 용량이 매우 크고 에러로그(error.log.6.gz)가 있길래 한번 살펴봤다. 가장 첫번째 줄에 client: 124.156.187.113의 위치를 한번 검색해봤다. 무슨 홍콩 지역이 나온다. 그리고 request: "HEAD /Core/Skin/Login.aspx 이라는 요청을 보낸다. Login.aspx 이란, https://dotnet.microsoft.com/..

처음 인스턴스를 시작할 때 스토리지 구성을 건들지 않았다. 스토리지 유형은 EFS, Amazon EC2 Instance Store, EBS, S3가 있다. 아마존 EBS는 인스턴스 중지나 종료에 상관없이 데이터가 유지되어 있는 영구 스토리지 이며, EC2 인스턴스를 생성할 때 프리티어로 사용할 경우 root 디바이스 유형이 기본적으로 EBS로 되어있다. 최대 30GB까지 EBS 범용 SSD를 사용할 수 있는데 난 8GiB로 설정을 해버려서 다음과 같이 프로젝트를 시작한지 몇 주만에 30%의 가용량 밖에 남아있지 않았다. 늘리는 방법은 굉장히 쉽다. 먼저 해당 인스턴스에 들어가서 스토리지의 볼륨 ID로 들어가서 볼륨 수정을 눌른 후 원하는 만큼의 크기로 늘리면 시간이 지난 뒤 할당 된다. 하지만 이로서 끝..

신규 Repo 생성 > Actions 탭 > set up a workflow yourself 클릭합니다. CI 테스트 워크 플로우 작성 backend_ci.yml name: 애자일허브 백엔드 CI 테스트 자동화 on: pull_request: branches: - main - develop permissions: write-all jobs: build: runs-on: ubuntu-latest steps: - name: 레포지토리를 가져옵니다 uses: actions/checkout@v3 - name: JDK 17를 설치합니다 uses: actions/setup-java@v3 with: java-version: '17' distribution: 'temurin' - name: 그래들 캐시 uses: ac..