꾸준하게, 차근차근

[트러블슈팅 회고] JPA 엔티티 단순 조회만 했는데 update 쿼리가 남발된 이유

jn4624 — Mon, 14 Jul 2025 23:17:24 +0900

(@DynamicUpdate, @Converter, dirty checking, equals/hashCode, Hibernate deep copy 내부 동작까지)

바쁜 주말을 보내고, 피로와 싸우며 출근을 짠! 했는데 출근과 동시에 이슈가 발생했다.

덕분에 피로고 나발이고 활기찬 오전을 보냈다...

1. 문제 상황: "조회만 했는데 update 쿼리가 나온다?"

금요일 운영에 반영한 Search API가 update 쿼리를 대량으로 쏟아내는 현상이 발생했다...

단순히 JPA로 엔티티를 여러 번 조회했을 뿐인데, 데이터베이스에 update 쿼리가 조회 횟수만큼 쏟아졌다.

코드 상황은 이랬다:

엔티티 클래스에 @DynamicUpdate 어노테이션이 선언되어 있었다.
필드 중 하나는 @Converter를 적용한 커스텀 클래스로 구성되어 있었다.
해당 커스텀 클래스에 equals/hashCode를 재정의하지 않았다.
Search API 로직상 데이터는 전혀 변경하지 않았고, 단순 조회 로직만 반복 실행되는 구조였다.

그런데도 로그에는 select뿐만 아니라 불필요한 update 쿼리가 계속 실행되어 데이터베이스에 부하를 주고 있었다.

2. 원인 추적

처음에는 코드를 수정하면서 어딘가에 데이터를 변경하는 로직이 잘못 들어갔나 싶어 흐름을 몇 번이고 따라갔지만 데이터 변경 로직은 전혀 보이지 않았다. 완전 멘붕...

그룹장님의 감사하고 죄송하고 감사한 도움으로 원인을 빠르게 파악하여 문제를 해결하게 되었지만 왜 의도한 대로 동작하지 않은건지 궁금해서 JPA의 내부 동작, Hibernate의 dirty checking까지 들여다보기 시작했다.

3. Hibernate의 스냅샷 생성 및 dirty checking 구조

우선 hydratedState, loadedState, dirty checking에 대해서 알아보자.

3.1. hydratedState의 역할

Hibernate가 데이터베이스에서 엔티티를 로드할 때 각 필드의 값을 일단 hydratedState라는 Object[] 배열에 임시로 저장한다.
이 hydratedState는 엔티티가 실제로 생성되기 전에 데이터베이스에서 가져온 "원시 값"의 임시 보관소다.
@Converter가 붙은 필드 역시, 변환된 커스텀 객체로 이 배열에 포함된다.
hydratedState 자체는 dirty checking에 직접 사용되지 않는다.

3.2. loadedState(스냅샷) 생성 이유과 과정

엔티티 객체가 생성되면, Hibernate는 hydratedState를 deep copy(깊은 복사)해서 loadedState라는 배열로 저장한다.
이 loadedState가 "처음 데이터베이스에서 엔티티를 로드했을 때의 값"이자 dirty checking의 기준(스냅샷)이 된다.
왜 deep copy가 필요할까?
- 뮤터블 객체(예: List, Map, 커스텀 객체)가 hydratedState와 엔티티 필드에서 동일한 객체(참조)를 공유하게 되면, 트랜잭션 중 엔티티를 변경하면 hydreatedState까지 같이 바뀌어 dirty checking이 무의미해지기 때문이다.
Hibernate는 이를 방지하기 위해 deep copy(=별도 객체 생성)로 loadedState를 만들어 변경감지 기준을 분리한다.

3.3. dirty checking의 기준

dirty checking은 flush(트랜잭션 커밋 전) 시점에 loadedState(스냅샷)와 엔티티 인스턴스의 현재 값을 equals()로 비교한다.
만약 값이 달라졌다면 dirty(변경)로 간주하여 update 쿼리를 실행한다.
hydratedState는 오직 loadedState 생성을 위한 중간 단계일 뿐, dirty checking의 비교 대상은 "loadedState(스냅샷)"와 "현재 엔티티 인스턴스"다.

3.4. 관련 Hibernate 내부 구조

deep copy는 내부적으로 각 타입별 전략이 적용된다.
- 이뮤터블(불변) 객체는 값만 복사(참조 유지)
- 뮤터블(가변) 객체는 복제 객체 생성
관련 클래스 체계
- AbstractStandardBasicType -> JavaTypeDesciptor -> MutabilityPlan

4. 트러블의 근본 원인 - @Converter + equals/hashCode 미구현

이제 현상과 Hibernate 내부 구조를 연결해보면, 문제의 진짜 원인은 아래와 같았다.

@Converter로 데이터베이스 값을 읽을 때마다 매번 새로운 커스텀 객체가 생성된다.
하지만 해당 커스텀 클래스에 equals/hashCode가 미구현이면 loadedState(스냅샷, 조회 시 객체)와 현재 엔티티(트랜잭션 중 새로 생성된 객체)의 참조값이 항상 다르게 되어버린다.
Hibernate의 dirty checking(=loadedState와 현재 객체의 equals() 비교)은 참조가 다르면 무조건 "dirty"로 판단한다.
그 결과, 실제로 값은 안 바뀌었는데도 불구하고 update 쿼리가 남발된다.

5. @DynamicUpdate의 역할

여기서 헷갈릴 수 있는 점 한가지!

@DynamicUpdate는 dirty checking의 수행 여부와는 관계 없다.

@DynamicUpdate는 "실제로 변경된 필드만 update 쿼리에 포함"되도록 쿼리를 최적화하는 기능이다.
dirty checking(변경 감지)은 @DynamicUpdate와 무관하게 트랜잭션이 readOnly가 아니라면 항상 실행된다.

6. 동작 흐름 용어 요약 및 flush 시 비교 순서

6.1. 용어 정리

hydratedState
- 데이터베이스에서 로딩한 엔티티의 "원시값"을 담은 임시 배열
- dirty checking에 직접 사용되지 않고, loadedState 생성용 원본
loadedState
- hydratedState를 deep copy해서 만든 "처음 로딩된 시점의 값"
- dirty checking의 기준
dirty checking(변경 감지)
- flush 시점에 loadedState(스냅샷)와 엔티티 인스턴스의 현재 값을 equals()로 비교해 변경 여부를 판단

6.2. flush(커밋) 시 비교 순서

트랜잭션 내 비즈니스 로직(조회/수정 등)
flush(트랜잭션 커밋 전)
loadedState(스냅샷)와 엔티티 인스턴스의 현재 값이 equals()로 비교됨
값이 다르면 dirty로 간주해 update 쿼리 발생

7. 해결 방법

커스텀 클래스에 equals/hashCode 반드시 구현

커스텀 객체의 실제 값이 같으면 동등하게 판단할 수 있도록 equals/hashCode를 구현해야 한다.

조회만 필요한 트랜잭션에는 readOnly 옵션 명시

@Transactional(readOnly = true)로 선언하면 Hibernate는 dirty checking 자체를 생략한다.

8. 여기서 문득 드는 궁금증?

hydratedState가 원시 데이터를 Object 배열에 임시 저장하고 이를 기반으로 loadedState를 생성한다고 했다

그럼 엔티티 인스턴스는 어떤 기준으로 생성되는거지??

엔티티 인스턴스는 어떻게 만들어지는가?

Hibernate가 데이터베이스에서 엔티티를 로드할 때,

각 컬럼(필드)의 값을 읽어서 hydratedState 배열에 저장한다.
이 hydratedState 배열에 들어 있는 값을 이용해서
- 엔티티 객체의 각 필드에 값을 주입해 실제 엔티티 인스턴스를 생성한다.
- 즉, hydratedState 배열에 있는 값이 엔티티의 생성자/필드/Setter 등에 그대로 할당된다.
그리고 hydratedState의 값을 deep copy하여 loadedState 배열(스냅샷)로 만들어 dirty checking의 기준을 만든다.

정리하면?

엔티티 인스턴스는 데이터베이스 -> hydratedState -> 엔티티 생성
loadedState(스냅샷)는 hydratedState -> deep copy -> loadedState(스냅샷)

으로 생성된다고 한다.

이번 이슈로 세상 혼자 난리났었지만, 그래도 너무 좋은 경험이었던 것 같다. (하지만 두번의 실수는 안돼 ‍♂️ ‍♂️ ‍♂️)

앞으로 사소한 걸 사용하게 되더라도 실무에서의 경험이 부족하다면 사이드 이펙트를 먼저 확인하고, JPA가 관련되었다면 실행되는 쿼리도 꼭 확인하는 습관을 가져야겠다.

늘 나를 의심하고, 내 코드를 의심하고, 두 번, 세 번 확인하고, 늘 겸손하자

혹시 잘못된 내용이 있다면 댓글 감사드리겠습니다.

END.

[Error] No matching tests found in any candidate test task.

jn4624 — Sat, 5 Jul 2025 00:06:39 +0900

회사 업무에 적응하기도 바쁘지만, 바쁘다고 자기계발에 소홀하면 안되지!

그 덕에 점점 일만 벌리고 있는 것 같지만

친한 동생과 내년 상반기를 목표로 토이 프로젝트를 진행하기로 했고, 퇴근 후 틈틈이 개발해서 테스트 코드 작성 단계까지 도달했다. (나는 TDD가 잘 안돼 )

하지만 뭐든 쉽게 넘어가는 법이 없는게 세상의 이치 는 테스트 코드를 실행하면서 발생했다.

1. 문제 상황

테스트 코드를 작성하고 실행하는데 아래와 같은 에러 로그가 찍히면서 테스트 코드가 정상 동작하지 않는 것!

자, 어디서 또 삽질하는 소리가 들리지 않는가...

2. 해결 방법

2.1. IntelliJ 설정 수정

GPT에게 물어보고(비록 헛소리로 하나도 도움이 되지 않았음 ), 구글링도 해보고 해서 찾은 첫번째 방법이 IntelliJ 설정을 변경하는 것이었다.

해당 설정값을 Gradle (Default) -> IntelliJ IDEA로 변경하는 것!

위와 같이 변경하니 에러는 사라졌고, 테스트 코드도 문제 없이 실행되었다.

현재 맡은 도메인 개발이 거의 마무리되어 오늘 PR까지 생성하고 마무리하는게 목표였는데 코드를 정리하는데 무언가 이상했다.

갑자기 잘 설정해둔 Q클래스가 외부 경로에 생성되어 있질 않나, QueryDSL의 Q클래스가 동일 경로에 두 번 이상 생성되어 중복 생성 시도로 인한 에러가 발생하질 않나 ‍

거기다 테스트 코드를 실행할 때마다 JUnit Run Configurations가 중복해서 생성되고 있는 것이었다.

원인을 정확하게 분석하지는 못했지만, 예상컨대 테스트 코드를 실행할 때마다 빌드와 실행이 누적된게 아닐까 싶다.

그러다보니 설정도 꼬이고 코드도 꼬이고 내 머리도 꼬이고

다른 방법이 필요했다.

2.2. build.gradle 설정

StackOverflow에 게시되어 있는 IntelliJ 2019.1 업데이트로 인해 JUnit 테스트가 중단되었다는 글을 보게 되었다.

첫번째 댓글은 IntelliJ 설정 변경 방법과 똑같은 내용이었고, 그 다음으로 눈에 띈 댓글이 현재 작성 중인 build.gradle 설정 방법이다.

build.gradle에 아래와 같이 설정을 추가한다.

test {
	useJUnitPlatform()
}

위와 같이 설정하니 JUnit Run Configurations도 중복 생성되지 않았고, 꼬이고 꼬였던 QueryDSL 이슈도 말끔히 사라졌다.

해당 게시글은 아래와 같다.

https://stackoverflow.com/questions/55405441/intelij-2019-1-update-breaks-junit-tests

해결하고 다시 게시글을 확인해보니 생각보다 오래된 게시글이었다??

3. 궁금증

3.1. 이전 설정을 적용하면?

갑자기 궁금해졌다.

2019.1 업데이트로 인해 JUnit 테스트가 중단되었는데 올해 상반기에 생성한 프로젝트는 이런 문제가 없었단 말이지?

상반기에 생성한 프로젝트에서 테스트 관련 설정을 옮겨와 적용해봤다.

tasks.named('test') {
	useJUnitPlatform()
}

잘 된다.

뭐야??

3.2. 에러가 맞을까?

지금 진행하고 있는 프로젝트의 초기 설정 담당이 아니라 어떻게 된건지 혼란스러웠다.

현재 시점의 초기 프로젝트 설정을 확인해야 했다.

Spring Initializr 홈페이지에 접속해서 프로젝트를 하나 생성해봤는데....

동생이 QueryDSL 설정하면서 테스트 관련 설정을 지웠나봐

너무 멀리 돌아왔다... 내 다크써클...

4. 참고

어차피 여기까지 돌아온 김에 내용을 정리해보자면,

2019.1 이전에는 Gradle이 JUnit 4 Runner로 테스트를 실행했다.

하지만 이후 버전부터는 Gradle이 JUnit Platform(5) 기반으로 테스트를 실행하는 것이 표준이 되면서, 명확하게 useJUnitPlatform()을 지정하지 않으면 Gradle이 JUnit 4/5 혼합 프로젝트에서 테스트를 찾지 못하거나 에러가 발생할 수 있었다.

IntelliJ의 Run/Debug도 "JUnit Platform"기반으로 동작하기 때문에 반드시 useJUnitPlatform()을 지정해야 프로젝트 전반에서 일관된 테스트 실행을 보장 받을 수 있었다.

따라서 이러한 이유로 Gradle이 모든 테스트를 JUnit 5(Platform) 기반으로 실행하도록 강제하는 설정이 IntelliJ 2019.1+의 테스트 정책 변화와 맞물려 반드시 필요한 설정이 된 것이다.

END.

[Spring] FeignClient의 재시도(Retry), 너란 녀석!

jn4624 — Thu, 19 Jun 2025 22:54:38 +0900

드디어 입사하고 첫 서비스가 운영에 배포되는 날이었다.

출근하자마자 각 서버의 인스턴스들을 모니터링하고, 모든 서비스가 배포된 후 운영 테스트가 진행되었다.

1. 문제 상황

한참 운영 테스트가 진행되고 있는 와중에 서비스에서 예외가 발생했다.

확인 결과, 데이터 취득을 위해 타 서비스로 API를 요청하는데 이 과정에서 400(Bad Request) 응답 코드를 받게 된 것이었다.

결론적으로 요청을 받는 서비스 측의 문제로 문제가 해결되기를 기다릴 수밖에 없었지만, 문득 의아한 생각이 들었다.

정책상 위 과정에서 예외가 발생할 경우 2회 재시도가 발생했어야 하는데? 로그상으로는 1회 요청으로 끝난 것이다.

그래서 어김 없이 오늘도 원인을 파악하기 위해 삽질이 시작되었다.

2. Feign의 기본 Retryer 설정

Feign으로 API 통신 중, 장애 상황이나 네트워크 불안정으로 재시도(Retry) 설정을 한다.

하지만, 이번 상황에서는 재시도(Retry)가 일어나지 않았다.

FeignClient에서는 재시도 횟수, 간격을 지정한 Retryer를 Bean으로 등록한 설정 클래스를 @FeignClinet 어노테이션의 configuration 속성에 설정해주면 예외가 발생했을 경우 재시도(Retry)를 시도한다.

@Bean
public Retryer retryer() {
    // (initialInterval, maxInterval, maxAttempts)
    return new Retryer.Default(100, 1000, 3); // 최대 3회 시도
}

나는 위 예제와 같이 설정해두면 API 요청이 실패할 경우 무조건 재시도를 할 줄 알았다.

3. Feign의 Retryer와 ErrorDecoder, 그리고 상태 코드

하지만 Feign의 재시도는

네트워크 예외(IOException 등)
RetryableException

이 두 가지가 발생할 때만 동작한다.

HTTP 상태 코드는 보통

ErrorDecoder에서 FeignException으로 변환
4xx, 5xx 둘 다 그냥 FeignException 발생
RetryableException이 아니라서, Retryer는 재시도 안함

즉, Retryer는 FeignException에는 반응하지 않고, RetryableException일 때만 재시도를 한다.

4. 공식 문서 Search-Search

Spring Cloud OpenFeign 공식 문서에도 아래처럼 명시되어 있다.

Spring Cloud OpenFeign 공식문서(2024.06. 기준)

Spring Cloud OpenFeign은 기본적으로 재시도가 꺼져 있고,

Retryer를 등록해야만 "네트워크 오류(IOException)"와 "RetryableException"에 대해 재시도가 동작한다.

4xx, 5xx는 커스텀 ErrorDecoder에서 RetryableException을 던지지 않는 한 기본적으로 재시도되지 않는다. 라는 의미!

5. 만약 특정 상태 코드에서만 재시도하려면?

이런 경우엔 ErrorDecoder를 커스터마이징해서 특정 상태 코드에서만 RetryableException을 직접 throw 해야 한다.

public class CustomErrorDecoder implements ErrorDecoder {
	private final ErrorDecoder defaultDecoder = new Default();

	@Override
	public Exception decode(String methodKey, Response response) {
		if (response.status() == 400) {
			System.out.println("### [ErrorDecoder] " + response.status() + "에서 RetryableException 발생");
			return new RetryableException(
				response.status(),
				"retry on " + response.status(),
				response.request().httpMethod(),
				(Long) null,
				response.request()
			);
		}
		return defaultDecoder.decode(methodKey, response);
	}
}

그리고 Config에 등록

@Configuration
public class FeignConfig {
	@Bean
	public Retryer retryer() {
		return new Retryer.Default(100, 1000, 3);
	}

	@Bean
	public ErrorDecoder errorDecoder() {
		return new CustomErrorDecoder();
	}
}

이렇게 하면 400에서만 재시도한다.

6. 그럼 테스트를 해봐야지!

테스트를 위한 나머지 코드를 작성해보자.

@FeignClient(
	name = "test-api",
	url = "http://localhost:8080",
	configuration = FeignConfig.class
)
public interface TestFeignClient {
	@GetMapping("/remote/test")
	String callRemote();
}

@RestController
@RequiredArgsConstructor
public class TestController {
	private int callCount = 0;

	@GetMapping("/remote/test")
	public ResponseEntity<String> testApi() {
		callCount++;
		System.out.println("#### [Server] 호출 횟수: " + callCount);
		return ResponseEntity.status(400).body("Bad Gateway");
	}

	private final TestFeignClient testFeignClient;

	@GetMapping("/feign/test")
	public String feignTest() {
		try {
			return testFeignClient.callRemote();
		} catch (Exception e) {
			System.out.println("### [FeignClient] 최종 예외 발생: " + e.getClass().getSimpleName() + " / " + e.getMessage());
			throw e;
		}
	}
}

위와 같이 코드를 작성하고 포스트맨으로 호출한 결과!

최초 1회 + 재시도 2회를 시도한 것을 확인할 수 있었다.

하지만 여기서 드는 궁금증

오늘 운영 테스트 중 발생한 예외에서 ErrorDecoder를 커스터마이징 + 등록하지 않아서 재시도가 정말 안된게 맞을까?

CustomErrorDecoder를 주석 처리하고 다시 요청을 시도해보자.

정말 Feign의 기본 Retryer는 4xx 응답코드에 대해선 재시도를 하지 않는다.

뿌듯한 삽질이었다.

END.

[Java] 람다/스트림에서 외부 변수 값 변경, Exception 누적 처리

jn4624 — Wed, 18 Jun 2025 23:37:01 +0900

오늘도 어김 없이 문제 상황에 부딪혔고 이를 해결하면서 알게 된 내용들을 정리하려고 한다.

개발은 매일 매일이 배움의 시간이라는걸 뼈저리게 느끼며 삽질 시작!

1. 문제 상황

Java로 배치 처리를 하다 보면 스트림(stream().forEach())나 람다식을 사용할 일이 참 많다.

이번 문제는 스케줄러 내부, 람다식 사용에서 발생했다.

기존에는 람다식을 통해 코어 로직을 호출하고 해당 로직에서 예외가 발생할 경우 예외와 함께 알림 처리를 진행했다.

하지만 모니터링을 통해 점진적으로 처리량을 늘려가야 할테지만, 현재 한번에 처리되는 데이터의 양은 200건으로 설정되어 있고, 그럴 일은 없겠지만 최악의 경우 200건 모두 예외가 발생하면 알림 또한 200개가 전송될 여지가 있기 때문에 예외를 누적하여 단건의 알림만 전송되도록 로직을 수정하게 됐다.

알림을 통해 모든 예외 내용을 한 눈에 파악하긴 힘들고, 어차피 로그나 DB를 확인해야 하니 예외는 최초 예외만 포함해서 알림 메시지를 구성하기로 했다.

예를 들어,

Exception firstErrorException = null;
list.forEach(item -> {
    try {
        process(item);
    } catch (Exception e) {
        firstErrorException = e; // 컴파일 에러!
    }
});

위와 같이 최초 예외를 보관하기 위해 외부에 Exception 변수를 선언하고, 람다 안에서 해당 변수의 초기화를 진행했다.

뚜둔! 역시나 뭐든 쉽게 가는 법이 없지

"변수는 final이거나 effectively final이어야 한다"는 친절한(?) 에러가 발생한다.

2. 잘못된 코드와 컴파일 에러 메시지

자바 컴파일러는 Local veriable firstErrorException defined in an enclosing scope must be final or effectively final 이라는 에러 메시지를 보여준다.

즉, 람다식 안에서는 외부의 일반 변수에 값을 다시 할당할 수 없다는 것!!!!!!!

3. 람다/스트림에서 외부 변수 값 변경이 불가능한 이유

자바의 람다 캡처(closure) 원칙

자바 람다는 외부(감싸고 있는) 메서드의 지역 변수를 "캡처"해서 내부에서 쓸 수 있게 해준다.

하지만 그 변수는 "final" 혹은 "effectively final(사실상 최종값)"만 허용! 즉, 값이 변하지 않는 것만 접근 가능하다.

왜?

람다식이 실행되는 시점에는, 외부 변수의 라이프사이클(생명 주기)이 이미 끝났을 수도 있기 때문이다.

쉽게 비유하자면, 람다는 "외부 변수의 복사본"을 안고 들어가기 때문이다.

만약 값이 계속 바뀔 수 있다면,

동시성 문제
예측 불가능한 결과
의도치 않은 Side Effect

가 발생할 수 있다.

그래서 변경이 불가능한(final, effectively final) 변수만 허용하는거다.

"final" 혹은 "effectively final"이란?

final: 선언 시점에 "한 번만 값이 할당"되고, 바뀌지 않는 변수
effectively final: final 키워드는 안 붙었지만, 실제로 값이 한 번도 바뀌지 않는 변수

람다/스트림에서는 final 또는 effectively final 변수만 읽기 가능, 값 변경은 불가다.

4. 가능한 해결방법과 각각의 장단점

해당 문제를 해결하는 방법은 여러 가지가 있었다.

final 배열(혹은 컬렉션) 활용

final Exception[] firstException = {null};
list.forEach(item -> {
    try {
        process(item);
    } catch (Exception e) {
        firstException[0] = e;
    }
});

장점: 쉽게 적용 가능하다.
단점: 배열 인덱스로 값을 넣고 빼는 코드가 다소 직관적이지 않다.

AtomicReference 활용

AtomicReference<Exception> firstException = new AtomicReference<>(null);
list.forEach(item -> {
    try {
        process(item);
    } catch (Exception e) {
        firstException.compareAndSet(null, e);
    }
});

장점: 람다/스트림에서도 가독성 좋게 값을 변경 가능하고, 동시성에도 안전하다.
단점: AtomicReference를 처음 보는 사람에게는 생소할 수 있다.

for-each(전통적 반복문)로 대체

Exception firstException = null;
for (Item item : list) {
    try {
        process(item);
    } catch (Exception e) {
        firstException = e;
    }
}

장점: 가장 단순하고 누구나 이해하기 쉽다.
단점: 람다식의 장점(함수형 스타일, 메서드 체이닝 등)을 쓸 수 없다.

5. 그래서 나의 선택은?

고민 끝에 AtomicReference를 활용하는 방식을 택했다.

코어 로직의 성공/실패 카운트도 누적해야 하고 최초 발생한 예외도 처리해야 했으며 가독성을 포기할 수 없었다.

최초 이외의 나머지 예외를 건너뛰려면 조건문도 들어가야 하니까 메서드 호출 한줄이면 될 코드를 3줄로 만들 필요가 있을까 싶었다.

Atomic은 겸사겸사 동시성에도 안전하니까

enum ProcessStatus { SUCCESS, FAIL }

Map<ProcessStatus, Integer> resultCount = new EnumMap<>(ProcessStatus.class);
AtomicReference<Exception> firstException = new AtomicReference<>(null);

list.forEach(item -> {
    try {
        process(item);
        resultCount.merge(ProcessStatus.SUCCESS, 1, Integer::sum);
    } catch (Exception e) {
        resultCount.merge(ProcessStatus.FAIL, 1, Integer::sum);
        firstException.compareAndSet(null, e);
    }
});

따라서 성공/실패 카운트는 EnumMap과 merge로 관리하고, 예외는 AtomicReference로 관리하는 패턴을 적용했다(추후 EnumMap과 HashMap의 차이에 대한 내용도 정리도 필요할 것 같... ).

아참!

해결하면서 궁금했던 점!

AtomicReference<Exception> firstException = new AtomicReference<>(null);

AtomicReference<Exception>을 생성할 때 null로 초기화하는 이유가 궁금해서 찾아봤다!

초기값이 없음을 명시

AtomicReference<Exception>은 Exception 객체(혹은 아무 객체나)를 저장하는 참조형 래퍼다.

배치, 반복문, 람다 등에서 "예외가 발생하지 않았다"는 상태를 "null(아직 예외가 없다)"로 표현한 것이다.

위의 나의 선택에서 사용한 것처럼 최초 한 번만 예외를 저장하고 싶어 compareAndSet을 사용하게 된다면,

처음에 firstException은 null로 초기화
처음 예외가 발생하면 null에서 e로 바뀜
그 이후 발생하는 예외는 이미 값이 있으므로 저장되지 않음

compareAndSet(expectedValue, newValue)의 의미

첫 번째 인자(expectedValue): 현재 값이 이것과 같다면...
두 번째 인자(newValue): "해당 값으로 바꿔라"

의 의미로 firstException의 현재 값이 null이면 e(예외 객체)로 값을 변경하기 때문에 생성할 때 null로 초기화하는 것이다.

따라서 AtomicReference<Exception>의 초기값을 null로 두는건 "아직 예외가 발생하지 않았다"는 상태를 표현하고, 최초로 예외가 생겼을 때만 값을 저장하기 위함으로 이해하면 된다!

오늘의 삽질은 어제의 삽질보다 짧았다 괜히 뿌듯하군

END.

[Spring] 스케줄러에서 ShedLock 실행 누락, ThreadPoolTaskScheduler, 그리고 millisecond의 함정

jn4624 — Tue, 17 Jun 2025 23:30:36 +0900

최근 도메인 서비스를 개발하면서 데이터 처리, 재처리 등을 위한 스케줄러를 구현하게 되었다.

스케줄러는 이전 직장에서도 자주 구현해왔던지라 익숙했지만, 다중 인스턴스 환경에서의 구현은 처음이고 ThreadPoolTaskScheduler, ShedLock 활용도 처음이라 의도한대로 동작하는지 출근하면 로그를 모니터링하는 습관이 생길 정도였다.

하지만 왜 슬픈 예감은 틀린 적이 없는지...

특정 주기의 스케줄러 로그가 누락되는 현상을 두 눈으로 확인한 후에 내 머릿속은 바빠지기 시작했다.

왜 1개의 로그가 안찍혔지? 왜 2개만 로그가 찍힌거지? 내가 잘못 본건가?

1. 시스템 구성 및 문제 상황

먼저 시스템의 구성을 간단히 소개하자면,

ThreadPoolTaskScheduler를 활용해 스케줄러를 관리했고,
스케줄러 작업마다 @SchedulerLock(ShedLock, DB 기반 분산 락)을 적용했다.
1분마다 실행되어야 하는 스케줄러가 3개, 3초마다 실행되는 스케줄러가 2개 있었다.
ThreadPoolTaskScheduler의 pool size는 4로 설정되어 있었다(사내 템플릿 프로젝트의 기본 설정).

문제는, 1분마다 실행되어야 하는 스케줄러 3개가 문제였다.

스케줄러가 "매번 정확히 3개가 동시에 실행되어야 하는데, 어떤 시점에는 2개만 실행되고 어떤 시점에는 1개만 실행되는 등 실행 누락이 반복적으로 나타나는 것"이었다.

로그로 보면 아래와 같은 상황이 자주 보였다.

00:15:00.057 scheduler-1 실행
00:15:00.058 scheduler-2 실행
00:15:00.064 scheduler-3 실행

00:16:00.079 scheduler-2 실행
00:16:00.079 scheduler-3 실행
// scheduler-1 누락

00:22:00.035 scheduler-1 실행
00:22:00.035 scheduler-3 실행
00:22:00.035 scheduler-2 실행

00:23:00.055 scheduler-1 실행
// scheduler-3 누락
// scheduler-2 누락

즉, 3개의 스케줄러가 1분마다 반드시 실행되어야 하는데, 간헐적으로 한두개가 누락되는 현상이 계속 반복되었다.

2. 첫 번째 시도: ThreadPoolTaskScheduler의 pool size 증가

처음에는 단순히 ThreadPoolTaskScheduler의 pool size가 부족해서 동시에 여러 스케줄러가 실행될 때 스레드 할당이 안되어 누락되는건 아닐까 의심했다.

pool size가 4로 설정되어 있었고, 1분마다 실행되는 스케줄러가 3개, 3초마다 실행되는 스케줄러가 2개이니 최대 5개가 동시에 겹치는 경우 pool size가 부족할 수도 있다고 판단했다.

그래서 pool size를 5로 늘려서 배포해봤지만, 문제는 여전히 해결되지 않았다.

로그 패턴이 그대로 반복되었고, 여전히 스케줄러가 누락되는 일이 사라지지 않았다.

이 과정에서

ThreadPoolTaskScheduler는 pool size만큼의 스레드를 미리 생성해두고,
동시에 여러 예약 작업을 실행할 때 각 작업에 빈 스레드를 할당해준다.
pool size가 넉넉하면, 단순 스레드 경쟁 때문에 스케줄러가 누락되는 일은 없다.

실제로 작업 자체가 아주 짧게 끝나고 있어서 pool size 부족 문제가 아니라는 점을 다시 한 번 확인하게 되었다.

3. 원인 분석: ShedLock(@SchedulerLock) 설정과 실행 타이밍

ThreadPoolTaskScheduler의 설정에는 문제가 없다는 결론에 도달하면서 자연스럽게 @SchedulerLock(ShedLock)의 설정을 다시 들여다보게 되었다.

@SchedulerLock의 기본 원리

각 스케줄러마다 name을 지정해서 DB에 락을 건다.
락을 잡은 인스턴스만 해당 작업을 수행하고, 락이 풀릴 때까지는 같은 name의 다른 작업(심지어 같은 인스턴스라도)은 실행되지 않는다.

lockAtLeastFor가 핵심

문제 상황에서는 각 스케줄러의 @SchedulerLock에 lockAtLeastFor = "PT1M", lockAtMostFor = "PT2M"을 설정했었다.

이 설정의 의미는

작업이 아무리 빨리 끝나도 락은 최소 1분 동안 유지된다는 것이다.
즉, 스케줄러가 1분마다 실행된다고 하더라도, 락이 1분간 유지되고 있는 동안에는 ShedLock이 락을 잡지 못해 작업이 스킵(누락)된다.

4. 실행 누락의 진짜 원인: 밀리초(millisecond) 오차와 락 해제 타이밍

그런데, 실제 로그를 보면 "정확히 1분이 지난 시점"에 다음 작업이 실행을 시도하는데도 락을 못 잡는 경우가 있다.

예를 들어,

00:15:00.057에 작업이 실행되고 락이 걸림 (lock_until = 00:16:00.057)
00:16:00.079에 다음 작업이 락을 잡으려고 시도 -> 분명 1분이 지난 시점인데, 락을 못 잡고 실행이 누락된다.

이유는 무엇일까?

실제 락 만료 타이밍과 트리거 오차

락 해제 타이밍(lock_until)과, 실제 @Scheduled가 트리거되는 타이밍 사이에는 서버/DB 시스템간 millisecond 단위의 clock drift(시계 오차), 또는 DB write/read 지연, JVM GC/스레드 스케줄링 오차 등 다양한 현실적 요소로 인해 정확히 1분이 보장되지 않는다.
예를 들어 DB lock_until 값이 00:16:00.057인데, 애플리케이션의 시스템 시계가 DB보다 10~20ms 느리거나, DB와 네트워크 전송/처리 지연 등으로 실제 lock_until보다 미묘하게 오차가 발생할 수 있다.
이럴 경우, 00:16:00.079에 락을 잡으러 왔지만 DB에서는 lock_until보다 아직 current_time이 작거나 같다고 판단, 락 획득에 실패하게 된다.

ShedLock의 락 체크 로직

ShedLock은 락을 잡으려 할 때 현재 시간(current_time)이 lock_until보다 "확실히 큰 경우"에만 락을 획득한다.
1ms라도 current_time이 lock_until보다 작거나 같으면 락을 잡지 못하고 바로 실행이 누락된다.

이렇게 아주 미세한 차이(0.01초, 0.02초)가 실제 스케줄러의 실행 누락으로 이어질 수 있다.

실제로 ShedLock 테이블의 갱신되는 정보를 확인하기 위해 새로고침을 여러번 해본 결과 누락된 스케줄러의 시간만 갱신이 되지 않고 있었다.

5. 최종 해결: lockAtLeastFor 설정값 조정

문제의 진짜 원인을 파악한 뒤에는 해결은 명확했다.

lockAtLeastFor 설정값을 스케줄러 주기(1분)보다 더 짧게, 스케줄러 데이터 처리 예상 시간을 고려하여 PT2S로 조정하여 락이 항상 다음 실행 트리거 전에 미리 해제될 수 있도록 했다.
실제로 lockAtLeastFor를 2초로 조정한 뒤에는 스케줄러가 빠짐없이 1분마다 모두 정상적으로 실행되는 것을 로그로 확인할 수 있었다. ‍

lockAtLeastFor는 "실제 작업 소요 시간 + 1~2초 여유" 정도로만 설정하고, lockAtMostFor는 장애 복구를 고려해 넉넉하게 설정하는 것이 효율적인 듯하다....

6. 이번 삽질을 통해 배운 점을 정리해보자!

ThreadPoolTaskScheduler의 pool size는 단순히 스레드 경쟁 문제만을 해결할 뿐, lockAtLeastFor 등 스케줄러 락 설정 이슈까지 해결해주지 않는다.
@SchedulerLock의 lockAtLeastFor 설정값이 실행 주기와 같거나 더 길면 DB/서버의 millisecond 단위 오차, 네트워크 지연 등 여러 현실적 변수로 인해 스케줄러 실행이 주기적으로 누락될 수 있다.
정확히 "1분" 같은 딱 맞는 수치는 항상 위험하며, lockAtLeastFor를 스케줄러 주기보다 몇 초 이상 충분히 작게 잡는 것이 안전하다.
ShedLock/분산 락 기반 스케줄러를 사용할 때는 시스템간 시계 동기화(NTP 등), DB/서버 간 시간차, 네트워크 상황 등 현실적인 인프라 환경을 반드시 고려해야 한다.

사실 설계와 개발도 아직 경험이 많이 부족하지만, 이런 수치를 결정하는 것에 대한 경험은 전무하다 보니 이런 결과를 초래하게 된 것 같다.

그래도 이런 시행착오를 겪으며 성장해나가리라 믿는다!!!!!!!

그럼 오늘의 삽질 일기는 여기서 이만

END.

[Error] java.lang.ClassCastException: com.google.gson.internal.LinkedTreeMap cannot be cast to...

jn4624 — Thu, 8 May 2025 23:45:48 +0900

Spring에서는 공통 인터페이스에 제네릭을 사용해 도메인마다 다른 타입을 주입받는 구조를 자주 활용한다.

구조도 깔끔하고 재사용성도 높아서 자주 쓰이는 방식인데, 문제는 FeignClient에 이 구조를 적용하려고 할 때 발생한다.

실무로는 처음 다뤄보는 FeignClient, 하루하루를 고군분투하는 이제 막 입사한 한달차 새내기 개발자는 이 구조가 적용되어 있다는 사실을 인지하지 못한채 로컬 테스트 도중 예외를 만나게 되었고, 디버깅과 구글링으로 삽질을 하다 깨달음에 도달했다.

따라서 이번 글에서는 삽질의 깨달음을 잊지 않기 위해서 FeignClient에서 제네릭 타입이 유지되지 않는 이유, 그로 인해 만났던 예외, 이를 해결하기 위한 방법에 대해 정리하려 한다.

1. 문제 상황: ResponseEntity<Page> 응답에서 캐스팅 예외 발생

ResponseEntity<Page<ResponseDTO>> response = feignClient.getPagedData();

FeignClient에서 위와 같이 응답을 받아 사용했다.

java.lang.ClassCastException: com.google.gson.internal.LinkedTreeMap cannot be cast to com.example.dto.ResponseDTO...

그리고 응답 바디를 꺼내서 Page.getContent()로 아이템을 순회하려고 했더니 위와 같은 예외가 발생했다.

문제의 핵심은 ResponseDTO로 역직렬화되길 기대했던 객체가 실제로는 Gson의 기본 Map 타입인 LinkedTreeMap으로 반환되었다는 점이었다. 이건 Java의 제네릭 타입 소거(Type Erasure)와 Gson의 동작 방식이 맞물리면서 생긴 런타임 문제였다.

2. 왜 이런 시련이 생긴건데?

Java는 제네릭 타입을 컴파일 타임까지만 유지하고, 런타임에는 모두 소거된다. 즉, Page<ResponseDTO>는 런타임에 단순한 Page로만 인식된다는 의미이다.

FeignClient는 내부적으로 JSON을 역직렬화할 때 Gson(혹은 Jackson)을 사용하는데, 이 과정에서 제네릭 타입 정보가 사라졌기 때문에 내부의 ResponseDTO는 역직렬화되지 않고 기본 타입인 LinkedTreeMap으로 변환된 것이다.

따라서 아래와 같은 구조로 데이터를 직접 꺼내고 캐스팅하려고 하면 예외가 발생한다.

final Page<ResponseDTO> responsePage = response.getBody();
responsePage.getContent().forEach(item -> "비즈니스 로직 처리 중");

3. 문제 해결 전략: Page<?> -> ObjectMapper 수동 변환

이 문제를 해결하기 위해 응답을 받을 때 명확한 제네릭 타입을 지정하지 않고, 먼저 Page<?>로 응답을 받고 수동으로 역직렬화를 시도하는 전략을 사용했다.

1단계: Page<?>로 바디 받기

final ResponseEntity<Page<ResponseDTO>> response = feignClient.getPagedData();
final Page<?> rawPage = response.getBody();

이 시점에서 rawPage.getContent()에 있는 요소들은 모두 LinkedTreeMap이다.

2단계: ObjectMapper로 content 리스트를 수동 변환

List<ResponseDTO> content = rawPage.stream()
    .map(item -> objectMapper.convertValue(item, ResponseDTO.class))
    .collect(Collectors.toList());

이렇게 하면 LinkedTreeMap을 기대한 ResponseDTO 타입으로 안전하게 변환할 수 있다. 핵심은 ObjectMapper의 convertValue를 이용해 수동 역직렬화를 수행하는 것이다.

4. 제네릭 타입을 그대로 믿지 말자!

FeignClient와 제네릭을 함께 사용하면 겉보기에는 타입이 잘 유지될 것 같지만, 실제로 IDE에서도 유지되는 것으로 보여줬다구

실제로는 런타임 타입 소거로 인해 역직렬화 문제가 발생할 수 있다.

Page<T>, List<T> 같은 제네릭 컬렉션을 직접 응답으로 받을 때
FeignClient 내부에서 Gson 또는 Jackson이 사용하는 디폴트 역직렬화 타입이 Map일 때
Gson 사용시 기본적으로 LinkedTreeMap, Jackson 사용시 LinkedHashMap으로 매핑

이럴 땐, 제네릭을 포기하고, Object로 받은 다음, 명시적으로 타입을 변환해주는 접근이 훨씬 안전하려나

END.

[Redis] AWS ElasticCache를 활용하자! (2)

jn4624 — Sat, 26 Oct 2024 02:48:49 +0900

자, 드디어 Redis의 마지막 챕터에 도달했다.

3일을 Redis를 위해 달려왔다!

이번 계기로 나도 Redis를 활용해서 조회 성능을 개선할 수 있는 개발자로 성장하자!

1. ElasticCache 잘 생성된거 맞아?

우선 대시보드에 들어가서 상태를 확인해보자.

상태가 Avaliable로 변경된 걸 보니 잘 생성된 것 같다.

생각보다 엄청 오래 걸려서 한참 기다렸다.

2. EC2에서 ElastiCache 접속해보자!

기본 엔드포인트에서 Port만 빼고 복사하자.

참고

기본 엔드포인트: 모든 권한을 가지고 있는 주소
리더 엔드포인트: 읽기 전용 주소

# EC2에서 ElastiCache 접속하는 명령어
redis-cli -h instagram-cache-server.iaxvmk.ng.0001.apn2.cache.amazonaws.com

# ElastiCache 통신 확인 명령어
ping

참고

다른 주소의 Redis에 접속하기 위해서는 -h 옵션을 붙여줘야 한다.

3. 로컬에서도 접속이 될까?

아무런 응답이 없네.

로컬에서는 EC2 ElastiCache에 접속되지 않는다.

이유

ElastiCache는 같은 VPC에서만 접속이 가능하기 때문이다.

4. 그럼 EC2랑 ElastiCache랑 VPC가 같아?

EC2의 VPC

ElastiCache의 VPC

VPC가 같았군

5. Spring Boot랑 연결하자!

application.yml 수정

# prod 환경
spring:
  config:
    activate:
      on-profile: prod
  datasource:
    url: jdbc:mysql://instagram-db.cfqanhnkrusz.ap-northeast-2.rds.amazonaws.com:3306/mydb
    username: admin
    password: password
  data:
    redis:
      host: instagram-cache-server.iaxvmk.ng.0001.apn2.cache.amazonaws.com
      port: 6379

배포 환경에 redis 연동 정보를 추가하고 ElastiCache의 기본 엔드포인트 정보를(Port 제거) 작성해준다.

EC2에 배포하기 위해서 Github Repository에 Push하고 EC2에서 Pull 받자.

6. Spring Boot 프로젝트 실행

ElastiCache는 Docker로 띄우지 않을거기 때문에 기존 방식으로 실행한다.

# 테스트 생략하고 Spring Boot 빌드하는 명령어
./gradlew clean build -x test

# 빌드 파일이 있는 곳으로 디렉토리 이동하는 명령어
cd build/libs

# Spring Boot 실행하는 명령어
java -jar -Dspring.profiles.active=prod redis-in-spring-0.0.1-SNAPSHOT.jar

7. API 테스트가 빠질 수 없지

데이터 응답은 이번에도 정상이다.

최초 요청에 대한 로그

최초 요청시 Redis에 데이터가 없어 데이터베이스를 통해 데이터를 취득하고 Redis에 해당 데이터를 저장한 것을 확인할 수 있다.

두번째 요청에 대한 로그

두번째 요청시 기존에 저장되어 있는 데이터가 Redis에 존재해 데이터베이스 SQL이 찍히지 않은 것을 알 수 있다.

이로써 ElastiCache 도 Cache Aside 전략의 흐름대로 동작하는 것을 알 수 있게 되었다.

이제 프로젝트에 활용해보러 가야지

Reference.

https://www.inflearn.com/course/%EB%B9%84%EC%A0%84%EA%B3%B5%EC%9E%90-redis-%EC%9E%85%EB%AC%B8-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94

비전공자도 이해할 수 있는 Redis 입문/실전 (조회 성능 최적화편) 강의 | JSCODE 박재성 - 인프런

JSCODE 박재성 | 비전공자 입장에서도 쉽게 이해할 수 있고, 실전에서 바로 적용 가능한 'Redis 입문/실전 (조회 성능 최적화편)' 강의를 만들어봤습니다!, 에라이, 못 해먹겠네!비전공자로 개발

www.inflearn.com

[Redis] AWS ElasticCache를 활용하자! (1)

jn4624 — Sat, 26 Oct 2024 01:55:50 +0900

현업에서는 EC2에 Redis를 직접 설치해서 사용하지 않고,

데이터베이스를 RDS를 활용하는 것처럼 Redis도 AWS의 ElastiCache를 활용해서 사용하고 있다고 한다.

설정이 쉽고 부가적인 기능도 많고 안정성이 높은 이유 때문이다.

따라서 AWS ElasticCache를 마지막으로 활용해보자!

1. 아키텍처 구성

이전 아키텍처

기존의 아키텍처 구조는 취준생 레벨 또는 비용을 극단적으로 관리해야 하는 초기 스타트업에 적합한 구성이다.

실제로 규모가 조금이라도 커지면 서비스를 이렇게 구성하는 경우는 드물다.

ElasticCache 도입 아키텍처

따라서 이런 식으로 구성하는게 실제 서비스 현업에 가까운 아키텍처 구조라 할 수 있다.

우리는 현업에 가까운 배포 환경을 경험해야 하지 않겠는가?

지금부터 AWS 인프라 구성을 변경해서 ElastiCache를 도입해보자!

2. ElastiCache 생성

홈페이지에서 ElastiCache를 검색해서 사이트를 이동하자.

지금 시작을 클릭하고 Redis OSS를 선택하자.

클러스터 설정 단계에서 구성은 자체 캐시 설계와 클러스터 캐시를 선택한다.

클러스터가 뭔데?

클러스터는 여러 개의 Cache 서버들을 묶고 있는 하나의 그룹을 뜻한다.

여기서 하나의 Cache 서버를 노드(Node)라고 부른다.

출처: AWS 공식 문서

클러스터 정보에서 이름을 입력해준다.

나는 이번에도 강사님 정하신 instagram-cache-server로 정했다.

위치는 AWS 클라우드를 선택하고 다중 AZ는 체크를 해제, 자동 장애 조치는 사용하는 것으로 선택한다.

참고

다중 AZ와 자동 장애 조치에 대해서 알고 넘어가자

다중 AZ: 리전에 재난이 발생해 서비스가 중단될 수 있는 상황을 미연에 방지하고나 여러 리전에 Cache 서버를 분산해 세팅해두는 것을 의미한다.
자동 장애 조치: failover라고도 하는데 클러스터 내부에서 특정 노드에 장애가 발생하면 정상 노드로 교체해주는 기능으로, 자동으로 장애를 처리해주는 기능이다.

클러스터 설정 부분에서 노드 유형을 t3.micro로 설정해준다. 프리티어이기 때문에!

복제본 개수는 클러스터 내 Cache 서버의 개수를 의미하는데 0으로 지정할 경우 failover 처리가 불가능하다.

참고

ElastiCache는 노드(Node)당 가격을 책정한다.

또한 failover는 1개 이상의 복제본 개수를 선택해야 처리가 가능하다.

최소한의 비용으로 테스트를 진행하기 위해 복제본 개수를 0으로 지정했지만, 실제로는 1개 이상 만드는 경우가 많다.

연결 부분에서 서브넷 그룹의 이름을 작성해준다.

이 부분도 나는 강사님이 정하신 instagram-subnet-group으로 정했다.

클러스터 설정은 다 했으니 이제 다음 단계로 넘어가자.

ElastiCache에 접근할 수 있도록 보안 그룹을 설정해줘야 해서 EC2로 이동해서 보안 그룹을 생성하자.

오른쪽 상단에 있는 보안 그룹 생성을 클릭한다.

보안 그룹은 위와 같이 설정하고 보안 그룹 생성을 진행한다.

참고로 인바운드 규칙 소스 부분은 Anywhere-IPv4를 선택한 것이다.

다시 ElastiCache로 돌아와서 위에 생성한 보안 그룹을 선택해준다.

데이터를 영구적으로 보존하기 위해서 사용하는 것이 아니기 때문에 자동 백업 사용은 체크 해제한 후 나머지는 그대로 유지한채 다음 단계로 넘어간다.

마지막 단계는 검토 및 생성하는 단계로 바로 ElastiCache를 생성한다.

상태를 보니 열심히 생성하고 있다

Reference.

https://www.inflearn.com/course/%EB%B9%84%EC%A0%84%EA%B3%B5%EC%9E%90-redis-%EC%9E%85%EB%AC%B8-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94

비전공자도 이해할 수 있는 Redis 입문/실전 (조회 성능 최적화편) 강의 | JSCODE 박재성 - 인프런

www.inflearn.com

[Redis] Docker Compose로 Redis + Spring Boot 띄우기 (AWS)

jn4624 — Sat, 26 Oct 2024 00:56:39 +0900

배포 환경의 인프라를 구성했으니 AWS EC2에서 Docker Compose로 Redis + Spring Boot를 한 번에 띄워봐야하지 않겠는가!

1. Dockerfile 만들기

EC2 내에서 사용할 Dockerfile을 생성한다.

로컬 환경에서 사용할 파일과 배포 환경에서 사용할 파일을 구분하기 위해 이번엔 Dockerfile-prod로 생성하자.

FROM openjdk:17-jdk

COPY build/libs/*SNAPSHOT.jar app.jar

# 배포 환경 profiles를 지정해줘야 하기 때문에 명령어가 추가되었다
ENTRYPOINT ["java", "-jar", "-Dspring.profiles.active=prod", "/app.jar"]

2. compose.yml 파일 만들기

compose.yml 파일도 로컬 환경과 배포 환경을 구분하기 위해 compose-prod.yml로 생성하자.

services:
  api-server:
    build:
      # Dockerfile이 위치한 경로 특정
      context: .
      # Dockerfile을 임의로 지정하였기 때문에 파일명을 명시
      dockerfile: ./Dockerfile-prod
    ports:
      - 8080:8080
    depends_on:
      cache-server:
        condition: service_healthy
  cache-server:
    image: redis
    ports:
      - 6379:6379
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      retries: 10

3. Github Repository에 Push

프로젝트 내 변경 사항을 Github Repository에 올려야 EC2에서 내려 받을 수 있기 때문에 Repository에 변경 사항을 Push 한다.

4. EC2에서 Git Pull 받기

push한 설정 파일들을 EC2에 내려 받아 적용해야 하기 때문에 인스턴스에 접속해서 변경 사항을 Pull 받는다.

5. EC2에 Docker 설치

EC2에서 Docker를 실행시켜야 하기 때문에 Docker 설치를 진행한다.

Docker 설치

# EC2에 Docker 설치하는 명령어
sudo apt-get update && \
	sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common && \
	curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - && \
	sudo apt-key fingerprint 0EBFCD88 && \
	sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" && \
	sudo apt-get update && \
	sudo apt-get install -y docker-ce && \
	sudo usermod -aG docker ubuntu && \
	newgrp docker && \
	sudo curl -L "https://github.com/docker/compose/releases/download/2.27.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose && \
	sudo chmod +x /usr/local/bin/docker-compose && \
	sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

Docker 및 Docker compose 설치 확인

# Docker 버전 확인 명령어
docker -v

# Docker compose 버전 확인 명령어
docker compose version

6. 기존에 실행되고 있는 Redis 종료

# EC2에서 Redis 중지하는 명령어
sudo systemctl stop redis

# EC2에서 Redis 상태 확인하는 명령어
sudo systemctl status redis

7. Docker 컨테이너로 띄워보자!

Spring Boot 다시 빌드

# 테스트 생략하고 Spring Boot 빌드하는 명령어
./gradlew clean build -x test

Docker 컨테이너로 띄우기

# 배포 환경 파일을 명시해서 Docker 컨테이너로 띄우는 명령어
docker compose -f compose-prod.yml --build -d

잘 떴을까?

8. 마지막으로 API 확인해야지!

이것도 다행이 정상이군

Reference.

https://www.inflearn.com/course/%EB%B9%84%EC%A0%84%EA%B3%B5%EC%9E%90-redis-%EC%9E%85%EB%AC%B8-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94

비전공자도 이해할 수 있는 Redis 입문/실전 (조회 성능 최적화편) 강의 | JSCODE 박재성 - 인프런

www.inflearn.com

[Redis] Docker Compose로 Redis + Spring Boot 띄우기 (로컬)

jn4624 — Sat, 26 Oct 2024 00:00:19 +0900

백엔드 개발을 하다 보면 Docker를 자주 활용하는 것을 알 수 있다.

따라서 이번엔 Docker Compose로 Redis와 Spring Boot를 한 번에 띄울 수 있게 구성을 진행해보려 한다.

1. Dockerfile 만들기

Spring Boot 프로젝트 root 디렉토리에 Dockerfile을 생성한다.

# JDK17을 사용해서
FROM openjdk:17-jdk

# 빌드한 파일을 복사해와서
COPY build/libs/*SNAPSHOT.jar app.jar

# 복사한 파일을 기반으로 실행
ENTRYPOINT ["java", "-jar", "/app.jar"]

2. compose.yml 파일 만들기

이 파일도 Spring Boot 프로젝트 root 디렉토리에 생성하면 된다.

services: 
  api-server:
    # Dockerfile을 기준으로 빌드를 할거라 Dockerfile의 경로 설정
    build: .
    ports:
      - 8080:8080
    depends_on:
      cache-server:
        # Redis가 정상적으로 구동한 뒤에 api 서버를 구동한다는 설정
        condition: service_healthy
  cache-server:
    image: redis
    ports:
      - 6379:6379
    # Redis가 정상적으로 구동되었음을 확인하는 설정
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      retries: 10

Redis가 정상적으로 구동한 뒤에 api 서버를 구동해야 하는 이유

api서버가 구동되면서 Redis와의 연결을 시도하는데 이때, Redis가 구동되기 전이라면 Error가 발생해 정상적인 서버 구동이 어렵기 때문이다.

3. 기존에 실행되고 있는 Redis 종료

포트 충돌이 일어나기 때문에 기존에 실행해두었던 Redis를 종료해야 한다.

# 로컬에서 실행되고 있는 Redis 종료 명령어
brew services stop redis

# 정상 종료되었는지 확인하는 명령어
brew services info redis

4. application.yml 수정

# local 환경
spring:
  profiles:
    default: local
  datasource:
    url: jdbc:mysql://host.docker.internal:3306/mydb # 호스트 컴퓨터의 주소로 변경
    username: root
    password: [password]
    driver-class-name: com.mysql.cj.jdbc.Driver
  jpa:
    hibernate:
      ddl-auto: update
    show-sql: true
  data:
    redis:
      host: cache-server # compose에 명시한 이름으로 변경
      port: 6379

5. Docker 컨테이너로 띄워보자!

Spring Boot 다시 빌드

# 테스트 생략하고 Spring Boot 빌드하는 명령어
./gradlew clean build -x test

Docker 컨테이너로 띄우기

# Docker 컨테이너로 띄우는 명령어
docker-compose up --build -d

참고

Docker 컨테이너로 띄우기 전에 Docker 데몬이 실행되고 있는지 확인을 하자.

그렇지 않으면 이런 메세지를 만나게 될 것이다.

해결 방법은

Docker Desktop을 실행하여 Docker 데몬을 활성화하기
docker 서비스 시작하기

잘 떴을까?

# Docker 상태 확인을 위한 명령어
docker ps

Docker Desktop을 실행해 Docker 데몬을 활성화했다면 Docker Desktop에서도 확인이 가능하다!

6. API 확인까지 해야지?

서버가 잘 띄워졌다고 해도 API가 정상 동작하는지까지 확인해봐야 한다!

정상이군

참고

Docker의 실시간 로그를 확인하는 방법을 알아두자!

백엔드 개발자에게 로그란 중요한 것이니까!

# Docker의 실시간 로그 확인하는 명령어
docker compose logs -f

최초 요청을 처리한 로그를 찾아봤는데 실시간으로 문제 없이 확인되는 것을 알 수 있다!

Reference.

https://www.inflearn.com/course/%EB%B9%84%EC%A0%84%EA%B3%B5%EC%9E%90-redis-%EC%9E%85%EB%AC%B8-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94

비전공자도 이해할 수 있는 Redis 입문/실전 (조회 성능 최적화편) 강의 | JSCODE 박재성 - 인프런