문제 상황 처음에는 Redis getFairLock을 사용하여 처리 순서를 보장하려 했으나, 테스트 로그를 통해 순서가 보장되지 않는다고 잘못 판단했다. 이로 인해 FairLock은 성능만 저하시킨다고 생각해 사용을 배제했다. 그러나 서비스 로그를 통해 Redis Fa

쿠폰 발급 API에서 다수의 요청이 동시에 들어왔을 때, 동시성 문제와 요청 순서 처리 문제가 발생했다. 초기 코드는 Redis의 RLock을 사용하여 동시성 문제를 해결했으나, 요청을 순서대로 처리하는 데 실패했다. 이를 해결하기 위해 다양한 방법을 시도했으나, 동시

테스트 도구: nGrinder 테스트 스크립트: 로그인 후 쿠폰 발급 API 호출 (동일한 API 테스트) Vuser 수: 99명 → 99명의 가상 사용자가 동시에 부하를 발생시킴 Processes/Threads: 3 프로세스, 각 프로세스당 33 쓰레드 Dur

낙관적 락(Optimistic Lock)을 적용하여 동시성 제어를 시도했지만, 버전 충돌이 발생했을 때 재시도 로직이 제대로 작동하지 않음. 재시도가 실행되어야 하는 상황에서 기타 예외가 발생하며 스레드가 종료되는 현상을 겪음.기타 예외 로그 분석로그에 출력된 메시지:

테스트 도구: nGrinder 테스트 스크립트: 로그인 후 쿠폰 발급 API 호출 (동일한 API 테스트) Vuser 수: 99명 → 99명의 가상 사용자가 동시에 부하를 발생시킴Processes/Threads: 3 프로세스, 각 프로세스당 33 쓰레드 Dura

쿠폰 발급 기능에서 Redisson RedLock을 활용해 동시성 제어를 구현했다. 락 해제 시 중복 해제를 방지하기 위해 isHeldByCurrentThread()를 사용했지만, RedissonMultiLock에서 UnsupportedOperationException

쿠폰 발급 기능에서 Redis 분산 락을 활용하여 동시성 문제를 해결하려고 했지만, 레이스 컨디션으로 인해 남은 쿠폰 수량과 발급된 쿠폰 수량이 불일치하는 문제가 발생했습니다.증상:락이 해제된 시점에 트랜잭션이 아직 커밋되지 않아 다른 스레드가 동일한 리소스에 접근하게

목표: 쿠폰 발급 기능에서 동시성 제어를 테스트하기 위해 비관적 락 (Pessimistic Lock)을 적용.증상: 테스트 코드 실행 결과:쿠폰 수량: 100발급된 쿠폰 수량: 0동시성 문제가 해결되지 않았으며, 비관적 락이 제대로 동작하지 않음.비관적 락은 트랜잭션

Spring Boot 테스트에서 @Transactional을 사용할 때 동시성 테스트에서 예상치 못한 문제가 발생할 수 있다. 이러한 문제는 트랜잭션 격리 수준과 롤백 동작으로 인해 발생하며, 동시성 테스트를 정확히 진행하기 위해선 @Transactional의 동작을

테스트 코드는 프로젝트의 품질을 보장하는 핵심 도구입니다. 특히 데이터베이스와 연동된 코드를 테스트할 때, 테스트 환경이 실제 데이터베이스와 유사한지 여부는 매우 중요한 요소입니다. 이 글에서는 H2 임베디드 데이터베이스와 Mockito를 사용하는 방식의 차이를 비교하

이 코드는 Optional, 빌더 패턴, 람다 표현식을 활용하여 객체 조회와 생성 로직을 간결하게 처리하는 매우 유용한 예제입니다. 이 코드에서 배운 점과 주요 개념들을 정리했습니다.Optional:데이터가 있을 수도, 없을 수도 있는 상황을 처리하는 Java의 클래스

허용 가능한 중복은 도메인별 요구사항이나 특수성 때문에 모듈 간 유사한 코드가 반복되지만, 이를 완전히 제거하지 않고 설계의 유연성을 위해 일부 중복을 허용하는 접근 방식이다. 도메인별 요구사항의 차이 각 API(User, Boss, Admin)의 비즈니스 로직이 다

루트 프로젝트 생성:Gradle 기반의 프로젝트를 생성한다.프로젝트 이름은 팀 프로젝트 이름에 맞게 설정한다.Gradle 설정 파일 생성:settings.gradle 파일에서 멀티 모듈을 정의한다.하위 모듈의 경로를 지정.settings.gradle 예시:디렉토리 구조

책임 분리:역할(Role)과 기능에 따라 모듈을 나눠 각자 책임을 명확히 한다.코어(Core)의 경량화:공통 기능만 포함하며, 불필요하게 많은 로직이 몰리지 않도록 제한.의존성 관리:각 모듈이 필요 최소한의 의존성만 가지며 독립성을 유지.확장성과 유지보수성:새로운 기능

결과를 보면, 공연 목록을 10,000개로 늘렸을 때의 테스트 결과가 다음과 같습니다:로그인 (POST)Total requests: 626Response time (Avg): 380ms90th percentile: 749ms공연 조회 (GET, V1)Total requ

QueryDSL을 사용하다 보면 Predicate와 BooleanExpression 두 가지 타입을 자주 마주치게 됩니다. 둘 다 쿼리의 조건을 표현하는 데 사용되지만, 사용 목적과 특징이 조금 다릅니다. 이번 TIL에서는 이 두 타입의 차이를 정리하고, 언제 어떤 것

쿠키에서 JWT를 검증할 때 Bearer 처리가 문제되는 이유는 헤더와 쿠키가 데이터를 다루는 방식이 다르기 때문입니다. 이를 더 구체적으로 설명하겠습니다.헤더는 문자열 형태로 데이터를 전송하며, 클라이언트와 서버 간의 데이터 교환을 위해 사용됩니다.보통 Authori

Lazy Loading은 실제로 필요한 시점까지 데이터를 "지연"하여 조회하는 방식으로, 데이터베이스와 연결된 Entity 객체들을 필요할 때만 가져와 성능을 최적화하려는 기법입니다.예를 들어, Comment가 Todo와 관계가 있는 상황에서 FetchType.LAZY

이번 작업에서는 JPQL로 작성된 쿼리를 QueryDSL로 변경하여 동적 쿼리 작성과 N+1 문제 해결을 목표로 했습니다. QueryDSL은 직관적인 메서드 체인을 통해 동적 쿼리를 작성할 수 있는 라이브러리로, 엔티티 간의 조인을 명확하게 설정하여 JPA를 활용한 쿼

N+1 문제는 데이터베이스 성능을 저하시키는 대표적인 문제입니다. 특히 연관된 엔티티를 조회할 때 발생하며, 한 번의 기본 쿼리(N) 이후, 연관 엔티티를 조회하기 위한 추가 쿼리(+1)가 반복적으로 발생합니다.예를 들어, Comment 엔티티 목록을 조회하면서 각 댓