아침에 EC2에 Prometheus랑 Spring Actuator를 연결해보려고 했더니, Actuator Prometheus 엔드포인트가 잡히지 않는 문제를 겪었다. 어떻게 해결했는지 내 TIL을 정리해본다.로컬에서는 Prometheus가 localhost:8080/a

CI/CD 설정하면서 ./gradlew test만 유독 GitHub Actions에서 계속 실패했다.CI 파이프라인은 다음 순서로 짜놨음:Redis 설치테스트 실행Gradle 빌드EC2 배포테스트는 로컬에선 -Dspring.profiles.active=test 옵션 주

초기에는 간단하게 Spring Boot에서 구글 SMTP를 사용하여 메일을 보내고 있었다.메일 전송은 성공적으로 되었지만, 중요한 문제가 있었다.❌ 메일이 전부 스팸함으로 분류됨운영 서비스에서는 치명적인 문제라 판단했고,도메인 기반 인증이 가능한 AWS SES(Simp

프론트엔드에서 SSE(Server-Sent Events)를 이용해 알림을 구독하려 할 때, 다음과 같은 에러가 발생했다.또한 연결이 되자마자 readyState는 2(closed)로 바뀌며, onerror 콜백이 실행되었다.HTTP 응답 코드는 200이었기 때문에, 일

이메일 인증 기능을 구현하기 위해 Gmail SMTP 설정을 application-secret.yml에 저장했다. 스프링 프로파일도 정상적으로 지정한 상태였다. ✅ 실행 시 출력도 분명히 두 개의 profile이 활성화된 것으로 확인됨:그런데도 메일 발송 기능은 항

클럽 가입 신청을 관리자가 승인하는 기능을 만들던 중, 관리자가 본인의 클럽에 대해 승인하려 했는데, "유효하지 않은 클럽 관리자입니다" 라는 오류가 발생했다. 분명히 로그인한 사용자는 해당 클럽의 관리자였는데도 말이다.아래는 클럽 관리자인지 검증하는 로직이다:로그를

문제 상황 처음에는 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 예시:디렉토리 구조