프로도의 개발 블로그

카프카, 레빗엠큐, 레디스 큐의 차이점

prodo-developer — Mon, 16 Oct 2023 13:53:04 +0900

Apache Kafka:
- 분산 환경에 최적화되어 고가용성(High Availability)이 뛰어납니다.
- **오프셋(Offset)**을 통해 소비자가 읽은 위치를 스스로 관리하므로, 여러 소비자가 각기 다른 시점의 데이터를 읽을 수 있습니다.
RabbitMQ:
- 라우팅 기능이 매우 강력합니다 (Exchange 개념). 복잡한 규칙에 따라 메시지를 분배해야 할 때 유리합니다.
- 메시지 전달 보장(Confirmation) 기능이 상세합니다.
Redis Queue (RQ/List):
- 메모리 기반이므로 속도가 매우 빠릅니다.
- 영속성(Persistence)보다는 가볍고 빠른 처리가 필요한 백그라운드 작업에 적합합니다.

[SPRING] 스프링의 트랜잭션 전파 속성(Transaction propagation)

prodo-developer — Mon, 4 Sep 2023 23:32:36 +0900

1. 트랜잭션의 시작과 종료 및 전파 속성(Transaction Propagation)

[트랜잭션 전파 속성(Transaction Propagation)이란? ]

"트랜잭션 전파 속성"을 이해하려면, 우리가 '트랜잭션'이라는 것이 무엇인지 알아야 합니다.

트랜잭션은 마치 '작업의 단위'와 같습니다.

예를 들어, 당신이 집에서 방 청소를 하는 것을 생각해봅시다.
방 청소는 크게 세 가지 작업으로 나눌 수 있습니다: 1) 먼지 제거, 2) 가구 정리, 그리고 3) 바닥 닦기.

이제 여기서 '트랜잭션 전파 속성'은 이런 작업들을 어떻게 조합할 것인가에 대한 규칙입니다.

예를 들어, "REQUIRED"라는 전파 속성은 이미 진행 중인 청소 작업(예: 먼지 제거)에 다른 작업(예: 가구 정리)을 추가하는 것입니다. 만약 아무도 청소를 하고 있지 않다면, 새로운 청소 작업을 시작합니다.

반면에 "REQUIRES_NEW"라는 전파 속성은 무조건 새로운 청소 작업을 시작하는 것입니다. 이미 진행 중인 다른 사람의 청소와 상관 없이 자신만의 새로운 청소(예: 바닥 닦기)를 시작합니다.

따라서 트랜잭션 전파 속성은 여러 개의 작업(트랜잭션)들이 어떻게 서로 관계를 맺고 진행될 지 결정하는 규칙입니다.

Spring이 제공하는 선언적 트랜잭션(트랜잭션 어노테이션, @Transactional)의 장점 중 하나는 여러 트랜잭션을 묶어서 커다란 하나의 트랜잭션 경계를 만들 수 있다는 점이다. 작업을 하다보면 기존에 트랜잭션이 진행중일 때 추가적인 트랜잭션을 진행해야 하는 경우가 있다. 이미 트랜잭션이 진행중일 때 추가 트랜잭션 진행을 어떻게 할지 결정하는 것이 전파 속성(Propagation)이다.

전파 속성에 따라 기존의 트랜잭션에 참여할 수도 있고, 별도의 트랜잭션으로 진행할 수도 있고, 에러를 발생시키는 등 여러 선택을 할 수 있다. 이렇게 하나의 트랜잭션이 다른 트랜잭션을 만나는 상황을 그림으로 나타내면 다음과 같다.

[ 물리 트랜잭션과 논리 트랜잭션 ]

물리 트랜잭션과 논리 트랜잭션의 차이는 "실제 일을 하는 사람들"과 "그 일들을 추적하고 관리하는 사람들" 사이의 차이

트랜잭션은 데이터베이스에서 제공하는 기술이므로 커넥션 객체를 통해 처리한다. 그래서 1개의 트랜잭션을 사용한다는 것은 하나의 커넥션 객체를 사용한다는 것이고, 실제 데이터베이스의 트랜잭션을 사용한다는 점에서 물리 트랜잭션이라고도 한다.

앞서 설명하였듯 트랜잭션 전파 속성에 따라서 외부 트랜잭션과 내부 트랜잭션이 동일한 트랜잭션을 사용할 수도 있다. 하지만 스프링의 입장에서는 트랜잭션 매니저를 통해 트랜잭션을 처리하는 곳이 2군데이다. 그래서 실제 데이터베이스 트랜잭션과 스프링이 처리하는 트랜잭션 영역을 구분하기 위해 스프링은 논리 트랜잭션이라는 개념을 추가하였다. 예를 들어 다음의 그림은 외부 트랜잭션과 내부 트랜잭션이 1개의 물리 트랜잭션(커넥션)을 사용하는 경우이다.

이 경우에는 2개의 트랜잭션 범위가 존재하기 때문에 개별 논리 트랜잭션이 존재하지만, 실제로는 1개의 물리 트랜잭션이 사용된다. 만약 트랜잭션 전파 없이 1개의 트랜잭션만 사용되면 물리 트랜잭션만 존재하고, 트랜잭션 전파가 사용될 때 논리 트랜잭션 개념이 사용된다. 이러한 물리 트랜잭션과 논리 트랜잭션을 정리하면 다음과 같다.

물리 트랜잭션: 실제 데이터베이스에 적용되는 트랜잭션으로, 커넥션을 통해 커밋/롤백하는 단위
논리 트랜잭션: 스프링이 트랜잭션 매니저를 통해 트랜잭션을 처리하는 단위

기존의 트랜잭션이 진행중일 때 또 다른 트랜잭션이 사용되면 복잡한 상황이 발생한다. 스프링은 논리 트랜잭션이라는 개념을 도입함으로써 상황에 대한 설명을 쉽게 만들고, 다음과 같은 단순한 원칙을 세울수 있었다.

모든 논리 트랜잭션이 커밋되어야 물리 트랜잭션이 커밋됨
하나의 논리 트랜잭션이라도 롤백되면 물리 트랜잭션은 롤백됨

더 이해하기 쉽게 청소를 한다고 생각했을때로 가정해보자.

먼저 '물리 트랜잭션'과 '논리 트랜잭션'의 개념을 명확히 이해해야 합니다.

물리 트랜잭션은 실제로 데이터베이스에 변화를 주는 작업 단위입니다. 예를 들어, 당신이 방 청소를 한다고 가정하면, 청소가 완전히 끝나고 방이 깨끗해진 상태가 '커밋'되는 것입니다. 만약 청소 도중에 문제가 생겨서 중단한다면, 그 전 상태로 돌아가는 것이 '롤백'입니다.

논리 트랜잭션은 스프링에서 관리하는 작업 단위입니다. 이것은 실제 데이터베이스에 변화를 주지 않지만, 어떤 작업들을 수행할 것인지 결정합니다. 예를 들어, 방 청소 프로젝트에서 누가 어떤 일을 할지, 어떻게 진행될지 등을 계획하는 것입니다.

그런데 여기서 복잡한 상황이 발생할 수 있습니다. 이미 진행 중인 청소(트랜잭션)에 다른 사람들도 참여하게 되면 어떻게 될까요? 이런 경우 스프링은 각각의 참여자(논리 트랜잭션)를 따로 관리합니다.

예를 들어 A와 B 두 사람이 함께 방 청소를 하는 경우라고 생각해보세요. A와 B 모두 자신의 업무가 완료되야만 (모든 논리 트랜잭션이 커밋되야만) 전체적으로 방 청소(물리 트랜잭션)가 완료됩니다. 하지만 A나 B 중 한 명이라도 문제가 생겨서 업무를 완료하지 못한다면 (하나의 논리 트랜잭션이 롤백된다면), 전체적으로 방 청소는 실패하고 처음부터 다시 시작해야 합니다 (물리 트랜잭션은 롤백됨).

이렇게 스프링은 논리 트랜잭션 개념을 도입함으로써 복잡한 상황을 쉽게 관리하고, 어떤 상황에서도 일관된 규칙을 적용할 수 있습니다.

논리 트랜잭션을 기반으로 단순한 원칙을 세움으로써 2개 이상의 트랜잭션을 다루는 경우에 대한 이해가 상당히 쉬워진다. 실제로 트랜잭션들이 마주하는 상황에서 어떠한 전파 속성들이 있는지 살펴보도록 하자.

2. 다양한 스프링의 트랜잭션 전파 속성

[ REQUIRED 속성과 REQUIRES_NEW 속성 ]

스프링에는 7가지 전파 속성이 존재하는데, REQUIRED와 REQUIRES_NEW를 바탕으로 어떻게 진행되는지 살펴보도록 하자. REQUIRED와 REQUIRES_NEW를 이해하면 나머지는 응용이 가능하므로, 두 케이스만 자세히 살펴보도록 하자.

두 가지를 알기전에 우리가 초등학생에게 설명한다면 어떻게 설명할 것인가??

chatGpt에게 도움을 얻어 정리하였는데 이해가 쏙쏙 되었다.

트랜잭션이라는 것을 생각해보면,

우리가 보드 게임(부루마불, 모놀로피)을 할 때의 차례(turn)와 비슷하다고 생각하면 됩니다.
"한 사람이 차례를 가질 때까지 다른 사람들은 기다려야 해요."
"REQUIRED" 당신의 차례가 왔고 아직 주사위를 굴리지 않았다면 (즉, 현재 진행중인 '차례' 또는 '트랜잭션'이 없다면),
당신은 주사위를 굴려 (새로운 '트랜잭션'을 생성해) 자신의 차례를 시작하게 됩니다.

"REQUIRES_NEW"는 이렇게 말합니다: 무조건 새로운 트랜잭션을 시작합니다.
부루마불에서 본다면, 현재 진행 중인 다른 사람의 차례와 상관없이 자신만의 새로운 차례(주사위를 굴림)를 시작하는 것과 같습니다.

그래서 REQUIRED와 REQUIRES_NEW의 주된 차이점은
'현재 진행 중인 트랜잭션(차례)에 어떻게 반응하느냐'입니다.
REQUIRED는 현재 트랜잭션에 합류하거나 필요한 경우 새로운 트랜잭션을 생성합니다. 반대로 REQUIRES_NEW는 항상 새로운 트랜잭션을 생성합니다.

이제 전문가 적으로 분석해 보겠습니다.

REQUIRED

REQUIRED는 스프링이 제공하는 기본적인(DEFAULT) 전파 속성으로, 기본적으로 2개의 논리 트랜잭션을 묶어 1개의 물리 트랜잭션을 사용하는 것이다. 앞선 예시로 살펴본 경우가 REQUIRED에 해당하며, 내부 트랜잭션은 기존에 존재하는 외부 트랜잭션에 참여하게 된다.

여기서 참여한다는 것은 외부 트랜잭션을 그대로 이어간다는 뜻이며, 외부 트랜잭션의 범위가 내부까자 확장되는 것이다. 그러므로 내부 트랜잭션은 새로운 물리 트랜잭션을 사용하지 않는다.

하지만 트랜잭션 매니저에 의해 관리되는 논리 트랜잭션이 존재하므로 커밋은 내부 1회, 외부 1회해서 총 2회 실행된다. 물론 내부 트랜잭션은 논리 트랜잭션이기 때문에 커밋을 호출해도 즉시 커밋되지는 않고, 외부 트랜잭션이 최종적으로 커밋될 때 실제로 커밋이 된다. 롤백 역시 비슷한데, 내부 트랜잭션에서 롤백을 하여도 즉시 롤백되지 않는다. 물리 트랜잭션이 롤백될 때 실제 롤백이 처리되는데, 논리 트랜잭션들 중에서 1개라도 롤백되었다면 롤백된다. 물리 트랜잭션은 실제 커넥션에 롤백/커밋을 호출하는 것이므로 해당 트랜잭션이 끝나는 것이다.

이러한 REQUIRED를 정리하면 다음과 같다.

REQUIRES_NEW

REQUIRES_NEW는 외부 트랜잭션과 내부 트랜잭션을 완전히 분리하는 전파 속성이다. 그래서 2개의 물리 트랜잭션이 사용되며, 각각 트랜잭션 별로 커밋과 롤백이 수행된다. 이를 그림을 표현하면 다음과 같다.

두 개는 서로 다른 물리 트랜잭션이므로, 내부 트랜잭션 롤백이 외부 트랜잭션 롤백에 영향을 주지 않는다. 그러므로 내부 트랜잭션이 롤백 호출은 실제 커넥션에 롤백을 호출하는 것이므로 트랜잭션이 끝나게 된다.

서로 다른 물리 트랜잭션을 별도로 가진다는 것은 각각의 디비 커넥션이 사용된다는 것이다. 즉, 1개의 HTTP 요청에 대해 2개의 커넥션이 사용되는 것이다. 내부 트랜잭션이 처리 중일때는 꺼내진 외부 트랜잭션이 대기하는데, 이는 데이터베이스 커넥션을 고갈시킬 수 있다. 그러므로 조심해서 사용해야 하며, 만약 REQURES_NEW 없이 해결 가능하다면 대안책(별도의 클래스를 두기 등)을 사용하는 것이 좋다.

REQUIRED와 REQUIRES_NEW를 이해했다면 나머지는 응용이므로, 간단히 어떻게 동작하는지 살펴보도록 하자.

[ 다양한 트랜잭션 전파 속성 ]

앞서 설명하였듯 스프링은 총 7가지 전파 속성을 제공한다. 각각에 대해 요약해서 정리하면 다음과 같다.

REQUIRED
SUPPORTS
MANDATORY
REQUIRES_NEW
NOT_SUPPORTED
NEVER
NESTED

이것 또한 바로 이해하기 어려울 수 있어 초등학생에게 설명하는것으로 정리하고 넘어가자.

REQUIRED (필요한 경우): 친구가 과자를 먹고 있는데, 당신도 그 친구와 함께 과자를 먹을 수 있습니다. 만약 아무도 과자를 먹고 있지 않다면, 당신은 새로운 팩의 과자를 열어서 먹을 수 있습니다.
SUPPORTS (지원하는 경우): 당신은 친구가 과자를 먹고 있다면 같이 먹을 수 있지만, 아무도 안 먹는다 해도 상관없습니다. 그냥 현재 상황에 맞춰서 행동합니다.
MANDATORY (필수적인 경우): 반드시 이미 누군가가 과자를 열어서 먹고 있어야 합니다. 아무도 안 먹는다면, 당신은 문제에 직면하게 됩니다(오류 발생).
REQUIRES_NEW (새로 필요한 경우): 답사는 다른 사람이 어떤 종류의 과자를 열어서 나눠주더라도, 반드시 자기만의 새로운 팩의 과자를 열어서 자기 혼자만의 시간을 가집니다.
NOT_SUPPORTED (지원하지 않음): 여러분은 절대로 다른 사람들과 함께 나눠진 과자를 함께 나눠갖거나 새롭게 팩을 꺼내어 서로 나눠갖지 않아야 합니다.
NEVER (절대 없음): 여러분은 점심시간에만 간식을 준비할 수 있는 규칙이 있는 학교에서 점심시간 외에 간식 시간을 가집니다(오류 발생).
NESTED (중첩된 경우): 답사는 이미 시작된 간식 시간에 참여하지만, 자신만의 작은 "부" 간식 시간(예: 트렌치 코트 안에서 스틱 과자를 먹음)을 가집니다. 만약 부 간식 시간이 문제가 생긴다면(예: 과자가 다 떨어짐), 그것은 자신의 작은 간식 시간에만 영향을 주고, 전체 간식 시간에는 영향을 주지 않습니다.

REQUIRED

의미: 트랜잭션이 필요함(없으면 새로 만듬)
기존 트랜잭션 없음: 새로운 트랜잭션을 생성함
기존 트랜잭션이 있음: 기존 트랜잭션에 참여함

REQUIRED는 디폴트 속성으로써 모든 트랜잭션 매니저가 지원하는 속성이다. 별도의 설정이 없다면 REQUIRED로 트랜잭션이 진행된다.

SUPPORTS

의미: 트랜잭션이 있으면 지원함(트랜잭션이 없어도 됨)
기존 트랜잭션 없음: 트랜잭션 없이 진행함
기존 트랜잭션이 있음: 기존 트랜잭션에 참여함

MANDATORY

의미: 트랜잭션이 의무임(트랜잭션이 반드시 필요함)
기존 트랜잭션 없음: IllegalTransactionStateException 예외 발생
기존 트랜잭션이 있음: 기존 트랜잭션에 참여함

REQUIRES_NEW

의미: 항상 새로운 트랜잭션이 필요함
기존 트랜잭션 없음: 새로운 트랜잭션을 생성함
기존 트랜잭션이 있음: 기존 트랜잭션을 보류시키고 새로운 트랜잭션을 생성함

NOT_SUPPORTED

의미: 트랜잭션을 지원하지 않음(트랜잭션 없이 진행함)
기존 트랜잭션 없음: 트랜잭션 없이 진행함
기존 트랜잭션이 있음: 기존 트랜잭션을 보류시키고 트랜잭션 없이 진행함

NEVER

의미: 트랜잭션을 사용하지 않음(기존 트랜잭션도 허용하지 않음)
기존 트랜잭션 없음: 트랜잭션 없이 진행
기존 트랜잭션이 있음: IllegalTransactionStateException 예외 발생

NESTED

의미: 중첩(자식) 트랜잭션을 생성함
기존 트랜잭션 없음: 새로운 트랜잭션을 생성함
기존 트랜잭션이 있음: 중첩 트랜잭션을 만듬

NESTED는 이미 진행중인 트랜잭션에 중첩(자식) 트랜잭션을 만드는 것으로, 독립적인 트랜잭션을 만드는 REQUIRES_NEW와 다르다. NESTED에 의한 중첩 트랜잭션은 부모 트랜잭션의 영향(커밋과 롤백)을 받지만, 중첩 트랜잭션이 외부에 영향을 주지는 않는다.

즉, 중첩 트랜잭션이 롤백 되어도 외부 트랜잭션은 커밋이 가능하지만 외부 트랜잭션이 롤백되면 중첩 트랜잭션은 함께 롤백되는 것이다. NESTED는 JDBC의 savepoint 기능을 사용하는데, DB 드라이버가 이를 지원하는지 확인이 필요하며 JPA에서 사용이 불가능하다.

3. 트랜잭션의 전파 속성 요약

[ 트랜잭션의 전파 속성 요약 ]

참조 링크: https://mangkyu.tistory.com/269

[SPRING] 생성자 주입을 사용해야 하는 이유, 필드인젝션이 좋지 않은 이유

prodo-developer — Tue, 29 Aug 2023 00:12:51 +0900

개요

Dependency Injection (의존관계 주입) 이란
- Setter Based Injection (수정자를 통한 주입)
- Constructor based Injection (생성자를 통한 주입)
스프링에서 사용할 수 있는 DI 방법 세가지
생성자 주입을 이용한 순환참조 방지
생성자 주입이 테스트 코드 작성하기 좋은 이유

서론

의존관계 주입을 받을때는 아무생각없이 당연하게 @Autowired 를 사용한 필드주입 방식을 사용해왔다.

그런데 어느날 갑자기(?) 인텔리제이에서 경고메시지를 보여준다는 것을 보게 되었다. 항상 경고는 표시되고 있었겠지만 무시하다가 갑자기 궁금해졌다. 필드인젝션을 사용하고 있는 @Autowired 에 하이라이트 표시가 되면서 나오는 경고메시지는

Field injection is not recommended … Always use constructor based dependency injection in your beans

Why???? Always???

실제 회사에서 이런 사례를 겪기도 했었다. ㅠㅠ 따라서 이번에 이 참에 복습하는 차원으로 다시 정리하고자 한다.

기존에 의존관계 주입에 대한 정리한 내용은 아래를 참조하시면 종류별로 확인이 가능합니다.

다양한 의존관계 주입 방법

Dependency Injection (의존관계 주입)

이유를 알기 위해서는 DI 에 대한 이해가 필요하다. DI 는 스프링에서만 사용되는 용어가 아니라 객체지향 프로그래밍에서는 어디에서나 통용되는 개념이다.

강한 결합

객체 내부에서 다른 객체를 생성하는 것은 강한 결합도를 가지는 구조이다. A 클래스 내부에서 B 라는 객체를 직접 생성하고 있다면, B 객체를 C 객체로 바꾸고 싶은 경우에 A 클래스도 수정해야 하는 방식이기 때문에 강한 결합이다.

느슨한 결합

객체를 주입 받는다는 것은 외부에서 생성된 객체를 인터페이스를 통해서 넘겨받는 것이다. 이렇게 하면 결합도를 낮출 수 있고, 런타임시에 의존관계가 결정되기 때문에 유연한 구조를 가진다.

SOLID 원칙에서 O 에 해당하는 Open Closed Principle 을 지키기 위해서 디자인 패턴 중 전략패턴을 사용하게 되는데, 생성자 주입을 사용하게 되면 전략패턴을 사용하게 된다.

Setter Based Injection (수정자를 통한 주입)

의존관계 주입에는 크게 생성자 주입, 수정자 주입 두가지 방법이 있다.

코드를 한번 보자. 클래스나 인터페이스 이름만 Controller, Service, ServiceImpl 로 지정했지 스프링과는 상관이 없는 순수 자바로만 짜여진 코드이다.

먼저 수정자를 이용한 의존관계 주입을 보자.

public class Controller {
    private Service service;

    public void setService(Service service) {
        this.service = service;
    }

    public void callService() {
    	if(service == null) {
            throw new IllegalStateException("Service is null. Please set the Service instance using setService() method.");
        }
    
        service.doSomething();
    }
}

public interface Service {
    void doSomething();
}

public class ServiceImpl implements Service {
    @Override
    public void doSomething() {
        System.out.println("ServiceImpl is doing something");
    }
}

public class Main {
    public static void main(String[] args) {
        Controller controller = new Controller();

        // 어떤 구현체이든, 구현체가 어떤방법으로 구현되든 Service 인터페이스를 구현하기만 하면 된다.
        controller.setService(new ServiceImpl1());
        controller.setService(new ServiceImpl2());

        controller.setService(new Service() {
            @Override
            public void doSomething() {
                System.out.println("Anonymous class is doing something");
            }
        });

        controller.setService(
          () -> System.out.println("Lambda implementation is doing something")
        );

        // 어떻게든 구현체를 주입하고 호출하면 된다.
        controller.callService();
    }
}

(참고) 익명클래스나 람다로 구현할 수 있었던 것은 Service 인터페이스가 함수형 인터페이스이기 때문이다.

Controller 클래스의 callService() 메소드는 Service 타입의 객체에 의존하고 있다.
Service 는 인터페이스이고, 인터페이스는 인스턴스화 할 수 없으므로 인터페이스의 구현체가 필요하다.
Service 인터페이스를 구현하기만 했다면 어떤 타입의 객체라도 Controller 에서 사용할 수 있는데 (다형성) Controller 는 이 구현체의 내부 동작을 아무 것도 알지 못하고 알 필요도 없다.
main 함수에서 Controller 클래스를 사용하는 것을 보면, 수정자 메소드인 setService() 에 Service 인터페이스의 구현체만 넘겨주면 된다.

어떤 구현체이든, 구현체가 어떤방법으로 구현되든, Service 인터페이스를 구현하기만 하면 된다.

신박하다?

수정자 주입으로 의존관계 주입은 런타임시에 할 수 있도록 낮은 결합도를 가지게 구현되었다. 하지만 문제는 수정자를 통해서 Service 의 구현체를 주입해주지 않아도 Controller 객체는 생성가능하다. Controller 객체가 생성가능하다는 것은 내부에 있는 callService() 메소드도 호출 가능하다는 것인데, callService() 메소드는 service.doSomething() 을 호출하고 있으므로

NullPointerException 이 발생한다.

주입이 필요한 객체가 주입이 되지 않아도 얼마든지 객체를 생성할 수 있다는 것이 문제다.

위 코드에서 setService() 메소드는 수정자 주입 방식으로 Service 객체를 주입하는 메소드입니다. callService() 메소드에서는 service 객체의 null 여부를 검사하여 null이라면 IllegalStateException을 발생시키도록 합니다. 이렇게 예외처리를 함으로써, 런타임시에 NullPointerException이 발생하는 것을 막을 수 있습니다.

다른방법으로 이 문제를 해결 할 수 있는 방법이 생성자 주입이다.

Constructor based Injection (생성자를 통한 주입)

Controller 에 setter 를 없애고, 생성자를 이용해서 주입한다.

public class Controller {
    private Service service;

    public Controller(Service service) {
        this.service = service;
    }

    public void callService() {
        service.doSomething();
    }
}

이렇게 생성자 주입을 해주면 사용하는 쪽은 아래와 같이 바뀐다.

public class Main {
    public static void main(String[] args) {

        // Controller controller = new Controller(); // 컴파일 에러

        Controller controller1 = new Controller(new ServiceImpl());
        Controller controller2 = new Controller(
            () -> System.out.println("Lambda implementation is doing something")
        );
        Controller controller3 = new Controller(new Service() {
            @Override
            public void doSomething() {
                System.out.println("Anonymous class is doing something");
            }
        });

        controller1.callService();
        controller2.callService();
        controller3.callService();
    }
}

이를 통해 두가지 이득과 한가지 보너스 이득이 생긴다.

null 을 주입하지 않는 한 NullPointerException 은 발생하지 않는다.
의존관계 주입을 하지 않은 경우에는 Controller 객체를 생성할 수 없다. 즉, 의존관계에 대한 내용을 외부로 노출시킴으로써 컴파일 타임에 오류를 잡아낼 수 있다.

보너스 이득은 final 을 사용할 수 있다는 것이다. final 로 선언된 레퍼런스타입 변수는 반드시 선언과 함께 초기화가 되어야 하므로 setter 주입시에는 의존관계 주입을 받을 필드에 final 을 선언할 수 없다.

public class Controller {
    private final Service service; // final 추가

    public Controller(Service service) {
        this.service = service;
    }

    public void callService() {
        service.doSomething();
    }
}

final 의 장점은 누군가가 Controller 내부에서 service 객체를 바꿔치기 할 수 없다는 점이다.

스프링에서 필드주입은 수정자를 통한 주입과 유사한 방식으로 이루어진다. 이제 슬슬 생성자 주입의 장점이 보이기 시작한다.

스프링에서의 DI 방법 세가지

스프링에서는 수정자 주입, 생성자 주입과 더불어 필드 주입이란걸 할 수 있다. 필드 주입은 수정자를 통한 주입과 유사한 방식으로 이루어지기 때문에, 수정자를 통한 주입의 단점은 Field Injection 을 사용할 때의 단점을 그대로 가진다.

더불어, 수정자 주입은 스프링 컨테이너가 아닌 외부에서 수정자를 호출해서 주입할 수 있는 방법이라도 열려있지만, 필드주입은 스프링 컨테이너 말고는 외부에서 주입할 수 있는 방법이 없다.

아래는 각 DI 방법에 대한 간단한 예제다. 뒤에서도 쓰기 위해서 예제를 Student, Course 관련된 내용으로 변경했다.

Field Injection

@Service
public class StudentServiceImpl implements StudentService {

    @Autowired
    private CourseService courseService;

    @Override
    public void studentMethod() {
        courseService.courseMethod();
    }

}

Setter based Injection

@Service
public class StudentServiceImpl implements StudentService {

    private CourseService courseService;

    @Autowired
    public void setCourseService(CourseService courseService) {
        this.courseService = courseService;
    }

    @Override
    public void studentMethod() {
        courseService.courseMethod();
    }
}

Constructor based Injection

@Service
public class StudentServiceImpl implements StudentService {

    private final CourseService courseService;

    @Autowired
    public StudentServiceImpl(CourseService courseService) {
        this.courseService = courseService;
    }

    @Override
    public void studentMethod() {
        courseService.courseMethod();
    }
}

인텔리제이에서 보여주는 경고메시지는 위 두 예제 중 아래에 있는 Constructor based Injection 을 사용하라는 것이다.

지금까지 살펴본 생성자 주입의 장점은

1.NullPointerException 을 방지할 수 있다.

- 객체가 생성될 때 모든 필수 의존성이 주입되므로, NullPointerException과 같은 런타임 예외가 발생할 가능성이 줄어듭니다. 의존성이 null인 상태로 객체가 생성되는 것을 방지할 수 있습니다.

2. 주입받을 필드를 final 로 선언 가능하다. 불변(Immutable) 객체

- Constructor Injection을 사용하면 주입받을 필드를 final로 선언할 수 있습니다. 이렇게 하면 한 번 설정된 값을 변경할 수 없으므로, 객체의 상태를 보호하고 예기치 않은 변경을 방지하는 불변(Immutable) 객체를 만들 수 있습니다.

3. 의존성 추적 및 테스트 용이성

- Constructor Injection은 클래스의 생성자 시그니처를 통해 어떤 의존성이 필요한지 명확하게 드러나기 때문에 코드를 이해하고 디버깅하기 쉽습니다. 또한, 단위 테스트 작성 시에도 의존성을 쉽게 대체(Mocking 등)할 수 있어 테스트 용이성이 좋아집니다.

4. 의존성 순환 해결

- 생성자에서 모든 의존성을 한 번에 주입하기 때문에, 순환 참조로 인한 초기화 문제를 방지할 수 있습니다.

5. 강력한 컴파일 타임 검사

- Constructor Injection은 컴파일 타임에 많은 종류의 오류를 검출하는 강력한 타입 체크 기능을 제공합니다. 올바른 타입의 인스턴스만 주입될 수 있도록 보장됩니다.

정도인데 또 다른 장점을 소개하고자 한다. 이는 스프링에서만 유용한 방법인 것 같다.

생성자 주입을 이용한 순환참조 방지

개발하다보면 여러 서비스들 간에 의존관계가 생기게 되는 경우가 있다. 이 예제에서는 CourseService 에서 StudentService 에 의존하고, StudentService 가 CourseService 에 의존하는 경우를 볼 것이다.

(실무에서도 종종 볼수 있음)

Field Injection 의 경우

public interface CourseService {
    void courseMethod();
}

@Service
public class CourseServiceImpl implements CourseService {

    @Autowired
    private StudentService studentService;

    @Override
    public void courseMethod() {
        studentService.studentMethod();
    }
}

public interface StudentService {
    void studentMethod();
}

@Service
public class StudentServiceImpl implements StudentService {

    @Autowired
    private CourseService courseService;

    @Override
    public void studentMethod() {
        courseService.courseMethod();
    }
}

이 상황은 StudentServiceImple 의 studentMethod() 는 CourseServiceImpl 의 courseMethod() 를 호출하고, CourseServiceImpl 의 courseMethod() 는 StudentServiceImple 의 studentMethod() 를 호출하고 있는 상황이다. 서로서로 주거니 받거니 호출을 반복하면서 끊임없이 호출하다가 결국 StackOverflowError 를 발생시키고 죽는다.

2019-08-28 00:14:56.042 ERROR 46104 --- [nio-8080-exec-1] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Handler dispatch failed; nested exception is java.lang.StackOverflowError] with root cause


java.lang.StackOverflowError: null
    at com.yaboong.alterbridge.tmp.CourseServiceImpl.courseMethod(CourseServiceImpl.java:26) ~[classes/:na]
    at com.yaboong.alterbridge.tmp.StudentServiceImpl.studentMethod(StudentServiceImpl.java:25) ~[classes/:na]
    at com.yaboong.alterbridge.tmp.CourseServiceImpl.courseMethod(CourseServiceImpl.java:26) ~[classes/:na]
    at com.yaboong.alterbridge.tmp.StudentServiceImpl.studentMethod(StudentServiceImpl.java:25) ~[classes/:na]
    at com.yaboong.alterbridge.tmp.CourseServiceImpl.courseMethod(CourseServiceImpl.java:26) ~[classes/:na]
…

이게 순환참조의 문제인데, 실제 코드가 호출이 되기 전까지는 아무것도 알지 못한다. 스프링 애플리케이션 구동도 너무나 잘된다. 여기서 궁금했던게 하나 있다.

왜 빈 생성이 잘 되는거지…?

수정자 주입이나 필드 주입시에 스프링 ApplicationContext 를 통해서 현재 로딩된 빈 목록을 출력하면 사이클 호출 로직을 가진 두개의 빈이 모두 떠있는 것을 확인할 수 있었다. 아니 사이클 호출을 하고 있는데 빈이 어떻게 생성될 수 있는거지? 생성은 안하고 빈 목록만 가지고 있다가 lazy 로딩하는 방식인건가? 근데 따로 lazy init 옵션을 주지 않으면 lazy 로딩은 적용 되지 않는다던데…?

객체생성시점에서 순환참조가 일어나는 것과 객체생성 후 비즈니스 로직상에서 순환참조가 일어나는 것은 완전히 다른 이야기인데, 하나로 묶어서 생각하고 있었기 때문에 이런 이상한 질문에 빠졌던 것이다.

필드 주입이나, 수정자 주입은 객체 생성시점에는 순환참조가 일어나는지 아닌지 발견할 수 있는 방법이 없다.

Constructor based Injection 의 경우

@Service
public class CourseServiceImpl implements CourseService {

    private final StudentService studentService;

    @Autowired
    public CourseServiceImpl(StudentService studentService) {
        this.studentService = studentService;
    }

    @Override
    public void courseMethod() {
        studentService.studentMethod();
    }
}

@Service
public class StudentServiceImpl implements StudentService {

    private final CourseService courseService;

    @Autowired
    public StudentServiceImpl(CourseService courseService) {
        this.courseService = courseService;
    }

    @Override
    public void studentMethod() {
        courseService.courseMethod();
    }
}

이 경우에도 애플리케이션이 구동이 잘 될까? 실행해보면 아래와 같은 로그가 찍히면서 앱 구동이 실패한다

***************************
APPLICATION FAILED TO START
***************************

Description:

The dependencies of some of the beans in the application context form a cycle:

┌─────┐
|  courseServiceImpl defined in file [/Users/yaboong/.../CourseServiceImpl.class]
↑     ↓
|  studentServiceImpl defined in file [/Users/yaboong/.../StudentServiceImpl.class]
└─────┘

빈 생성시 아래와 같은 로직이 수행되면서 어떤 시점에 스프링이 그것을 캐치해서 순환참조라고 알려주는 것 같다.

new CourseServiceImpl(new StudentServiceImpl(new CourseServiceImpl(new ...)))

이처럼 생성자 주입을 사용하면 객체 간 순환참조를 하고 있는 경우에 스프링 애플리케이션이 구동되지 않는다.

컨테이너가 빈을 생성하는 시점에서 객체생성에 사이클관계가 생기기 때문이다!

개선 방안으로는 여러 가지가 있을 수 있는데, 그 중 한 가지 방법은 아래와 같습니다:

서비스 분리: 가능하다면 서비스의 책임을 재구성하여 순환 참조를 제거하는 것이 가장 바람직합니다. 현재 CourseService와 StudentService가 서로에게 의존하고 있는데, 이것은 각각의 서비스가 너무 많은 책임을 가지고 있음을 나타낼 수 있습니다. 역할과 책임에 따라 더 세분화된 서비스로 분리하여 순환 참조를 제거할 수도 있습니다.

@Service
public class CourseServiceImpl implements CourseService {

    private final StudentService studentService;

    @Autowired
    public CourseServiceImpl(StudentService studentService) {
        this.studentService = studentService;
    }

    @Override
    public void courseMethod() {
        //student service method call here...
    }
}

@Service
public class StudentServiceImpl implements StudentService {

    private CourseServiceImpl courseServiceImpl;

    @Autowired
    public void setCourseServiceImpl(CourseServiceImpl courseServiceImpl){
        this.courseServiceImpl = courseServiceImpl;
     }

     @Override
     public void studentMethod() {
         //course service method call here...
     }
}

위 예제에서 보듯이, 생성자 대신 setter 메소드를 사용하여 한 쪽의 의존성(CourseServiceImpl)을 주입하면 순환 참조 문제를 해결할 수 있습니다. 이 경우 CourseServiceImpl이 먼저 생성되고, 그 다음에 StudentServiceImpl이 생성되며, 마지막으로 StudentServiceImpl에 대한 참조를 가진 CourseServiceImpl의 setter 메소드가 호출됩니다.

이렇게 하면 두 서비스 사이의 순환 참조 문제를 해결할 수 있지만, 앞서 언급한 바와 같이 일부 단점들도 함께 고려해야 합니다. 특히 Setter Injection을 사용할 때는 객체가 일시적으로 불완전한 상태에 있을 수 있다는 점과 필드에 final 키워드를 사용하여 불변성을 보장할 수 없다는 점 등을 유의해야 합니다.

수정자 주입을 사용하면 아주 잘 구동되고 순환참조를 하고 있는 부분에 대한 호출이 이루어질 경우 StackOverflowError 를 뱉기 때문에, 오류를 뱉을 수 밖에 없는 로직을 품고 애플리케이션이 구동되는 것이다.

마지막으로, 생성자 주입을 사용하면 단위테스트 작성하기가 좋아진다.

Constructor Injection만으로는 해결할 수 없는 걸까?

순환 참조 문제는 생성자 주입(Constructor Injection)만으로는 해결하기 어렵습니다. 생성자 주입은 객체가 생성될 때 모든 의존성을 주입받아야 하기 때문에, 순환 참조가 발생하면 서로가 서로를 기다리게 되어 결국 애플리케이션이 구동되지 않게 됩니다.

이 문제를 해결하는 가장 바람직한 방법은 설계 단계에서 순환 참조를 피하는 것입니다. 이는 객체 지향 설계 원칙 중 하나인 단일 책임 원칙(Single Responsibility Principle)과 관련이 있습니다. 한 클래스 또는 모듈이 너무 많은 책임을 가지고 있다면, 그것들을 분리하여 각각의 클래스 또는 모듈이 자신의 책임만을 가지도록 하는 것이 좋습니다.

그러나 만약 이런 설계 변경이 어렵거나 불가능한 경우에는 필드 주입(Field Injection) 혹은 Setter Injection과 같은 다른 의존성 주입 방식을 사용하여 순환 참조 문제를 해결할 수 있습니다. 이러한 방식들은 순환 참조 문제를 회피할 수 있으나, 앞서 언급한 바와 같이 일부 단점들도 함께 고려해야 합니다.

테스트 코드 작성하기 좋다

아직 테스트 코드를 열심히 짜보거나 하지는 않았지만, 요즘 테스트 코드의 중요성을 깨닫고 공부를 하고 있는 중이다. (참 일찍도 깨달았다 미련한 것)

CourserServiceImpl 이 가진 메소드들에 대해서 단위테스트를 수행하고 싶은 경우, field injection 을 사용해서 작성된 클래스라면 단위테스트시 의존관계를 가지는 객체를 생성해서 주입할 수가 없다. 할 수 있는 방법이 없다! 스프링의 IoC 컨테이너가 다 생성해서 주입해 주는 방식이고 외부로 노출되어 있는 것이 하나도 없기 때문이다. 그래서 의존관계를 가지고 있는 메소드의 단위테스트를 작성하면 (courseMethod() 같은) NullPointerException 이 발생한다.

하지만, constructor based injection 을 사용해 작성된 클래스라면 CourseServiceImpl 객체를 생성할 때 원하는 구현체를 넘겨주면 되고, 구현체를 넘겨주지 않은 경우에는 객체생성 자체가 불가능하기 때문에 테스트하기도 편하다.

요약

생성자 주입방식은 아래와 같은 장점을 가진다

의존관계 설정이 되지 않으면 객체생성 불가 -> 컴파일 타임에 인지 가능, NPE 방지
의존성 주입이 필요한 필드를 final 로 선언가능 -> Immutable
(스프링에서) 순환참조 감지가능 -> 순환참조시 앱구동 실패
테스트 코드 작성 용이

필드 인젝션은 아래와 같은 장점을 가진다

편하다는 것 말고는 없다

요약

생성자 주입방식은 권장, 적극 권유한다.

참조사이트 : https://yaboong.github.io/spring/2019/08/29/why-field-injection-is-bad/

[SPRING] 스프링 배치에서 사용되는 Quartz 배치 스케줄링

prodo-developer — Sun, 6 Feb 2022 17:26:03 +0900

스프링 배치 실습을 하는 과정에서 무중단배포가 가능한 스케줄링 기능이 필요했다.

현업에서도 이미 적용중이고, 스프링 배치 내에서 커버할 수 있는것도 한계점이 있다.

예를들어 Job 실행 중에 오류가 발생할 경우 예외처리로 FaultTolerant(내결함성)를 통해 pass를 시킬수 있지만

이것은 어디까지 임시방편으로 처리하는것으로 밖에 안된다.

1. ItemReader, ItemProcess, ItemWriter 에서 설정된 Exception이 발생했을 경우 (Skip)

2. ItemProcess, ItemWriter 에서 설정된 Exception이 발생했을 경우 (Retry)

따라서 job이 실행될 때 여부와 상관없이 가장 먼저 스케줄링을 통해 제어하는 방식이 더 효율적이라 볼 수 있다.

쿼츠에 대해 알아보자.

쿼츠(Quartz)

오픈소스 실시간 스케줄링, 서버 간 클러스터 기능

자바 환경의 규모와 상관없이 사용이 가능하고 Job 실행에 유용한 Spring boot 지원과 같이 오래전부터 스프링 연동을 지원하고있다.

쿼츠는 아래 3가지 컴포넌트를 제공한다.

1. 스케줄러(Scheduler)

스케줄러는 SchedulerFactory 를 통해서 가져올 수 있으며 JobDetails 및 트리거의 저장소 기능을 한다.

예시코드

public JobDetail buildJobDetail(Class job, String name, String group, Map params) {
    JobDataMap jobDataMap = new JobDataMap();
    jobDataMap.putAll(params);

    return newJob(job).withIdentity(name, group)
            .usingJobData(jobDataMap)
            .build();
}

2. 잡(Job)

3. 트리거(Trigger)

작업 실행 시점을 정의한다.

트리거가 작동되어 쿼츠에게 잡을 실행하도록 지시하면, 잡의 개별 실행을 정의하는 JobDetails 객체가 생성된다.

예시코드

public Trigger buildJobTrigger(String scheduleExp) {
    return TriggerBuilder.newTrigger()
            .withSchedule(CronScheduleBuilder.cronSchedule(scheduleExp)).build();
}

스프링 배치 작업

* 해당 실습은 스케줄러 시간에 따라 파일을 읽어들이고, api 통신하는 시간을 각각 나누어 진행한다.

- 파일 읽어들이기 (FileSchJob)

package com.example.springbatch.project.scheduler;

import lombok.SneakyThrows;
import org.quartz.JobExecutionContext;
import org.quartz.JobExecutionException;
import org.springframework.batch.core.*;
import org.springframework.batch.core.explore.JobExplorer;
import org.springframework.batch.core.launch.JobLauncher;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.scheduling.quartz.QuartzJobBean;
import org.springframework.stereotype.Component;

import java.util.Date;
import java.util.List;
import java.util.stream.Collectors;

// QuartzJobBean 을 사용하여 스프링 배치 잡을 기동하는 쿼츠 잡 작성

@Component
public class FileSchJob extends QuartzJobBean {

    @Autowired
    private Job fileJob;

    @Autowired
    private JobLauncher jobLauncher;

    @Autowired
    private JobExplorer jobExplorer; // jobRepository의 read 기능만 가지고 있음

    /**
     * 배치를 실행시키는 구문 : 스케줄링된 이벤트가 발생할때마다 한번씩 호출된다.
     * @param context
     * @throws JobExecutionException
     */
    @SneakyThrows
    @Override
    protected void executeInternal(JobExecutionContext context) throws JobExecutionException {

        String requestDate = (String) context.getJobDetail().getJobDataMap().get("requestDate");

        JobParameters jobParameters = new JobParametersBuilder()
                .addLong("id", new Date().getTime())
                .addString("requestDate", requestDate)
                .toJobParameters();

        // 모든 job의 인스턴스 갯수를 가져올수 있음.
        int jobInstanceCount = jobExplorer.getJobInstanceCount(fileJob.getName());

        // 모든 job의 인스턴스 정보를 가져올수 있음. 0번째 부터 카운트 갯수까지
        List<JobInstance> jobInstances = jobExplorer.getJobInstances(fileJob.getName(), 0, jobInstanceCount);

        if(jobInstances.size() > 0) {
            for (JobInstance jobInstance : jobInstances) {
                // 여러개의 jobExecution을 가져온다.
                List<JobExecution> jobExecutions = jobExplorer.getJobExecutions(jobInstance);
                List<JobExecution> jobExecutionList = jobExecutions.stream()
                        .filter(jobExecution -> jobExecution.getJobParameters().getString("requestDate").equals(requestDate))
                        .collect(Collectors.toList());

                // 해당하는 날짜가 1개 이상인경우 배치를 실행하지 않는다.
                if(jobExecutionList.size() > 0) {
                    throw new JobExecutionException(requestDate + " already exists");
                }
            }

        }

        jobLauncher.run(fileJob, jobParameters);
    }

}

- api 통신 (ApiSchJob)

package com.example.springbatch.project.scheduler;

import lombok.SneakyThrows;
import org.quartz.JobExecutionContext;
import org.quartz.JobExecutionException;
import org.springframework.batch.core.Job;
import org.springframework.batch.core.JobParameters;
import org.springframework.batch.core.JobParametersBuilder;
import org.springframework.batch.core.launch.JobLauncher;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.scheduling.quartz.QuartzJobBean;
import org.springframework.stereotype.Component;

import java.util.Date;

@Component
public class ApiSchJob extends QuartzJobBean {

    @Autowired
    private Job apiJob;

    @Autowired
    private JobLauncher jobLauncher;

    /**
     * 배치를 실행시키는 구문 : 스케줄링된 이벤트가 발생할때마다 한번씩 호출된다.
     * @param context
     * @throws JobExecutionException
     */
    @SneakyThrows
    @Override
    protected void executeInternal(JobExecutionContext context) throws JobExecutionException {

        JobParameters jobParameters = new JobParametersBuilder()
                .addLong("id", new Date().getTime())
                .toJobParameters();

        jobLauncher.run(apiJob, jobParameters);
    }
}

* api 스케줄러 작성

package com.example.springbatch.project.scheduler;

import org.quartz.*;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.stereotype.Component;

import java.util.HashMap;
import java.util.Map;

import static org.quartz.JobBuilder.newJob;

/**
 * 스케줄러 설정
 */
@Component
public class ApiJobRunner extends JobRunner {

    @Autowired
    private Scheduler scheduler;

    @Override
    protected void doRun(ApplicationArguments args) {

        JobDetail jobDetail = buildJobDetail(ApiSchJob.class, "apiJob", "batch", new HashMap());
        Trigger trigger = buildJobTrigger("0/10 * * * * ?"); // 10초마다 실행

        try{
            scheduler.scheduleJob(jobDetail, trigger);
        } catch (SchedulerException e) {
            e.printStackTrace();
        }
    }

}

* file 스케줄러 작성

package com.example.springbatch.project.scheduler;

import org.quartz.JobDetail;
import org.quartz.Scheduler;
import org.quartz.SchedulerException;
import org.quartz.Trigger;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.ApplicationArguments;
import org.springframework.stereotype.Component;

import java.util.HashMap;

/**
 * 스케줄러 설정
 */
@Component
public class FileJobRunner extends JobRunner {

    @Autowired
    private Scheduler scheduler;

    @Override
    protected void doRun(ApplicationArguments args) {

        String[] sourceArgs = args.getSourceArgs();

        JobDetail jobDetail = buildJobDetail(FileSchJob.class, "fileJob", "batch", new HashMap());
        Trigger trigger = buildJobTrigger("0/30 * * * * ?"); // 30초마다 실행
        jobDetail.getJobDataMap().put("requestDate", sourceArgs[0]);

        try{
            scheduler.scheduleJob(jobDetail, trigger);
        } catch (SchedulerException e) {
            e.printStackTrace();
        }
    }

}

* 공통 스케줄러를 통해 상속받아 사용한다.

package com.example.springbatch.project.scheduler;

import org.quartz.*;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.stereotype.Component;

import java.util.HashMap;
import java.util.Map;

import static org.quartz.JobBuilder.newJob;

/**
 * 공통 스케줄러 설정
 */
public abstract class JobRunner implements ApplicationRunner {

    @Override
    public void run(ApplicationArguments args) throws Exception {

        doRun(args);
    }

    public Trigger buildJobTrigger(String scheduleExp) {
        return TriggerBuilder.newTrigger()
                .withSchedule(CronScheduleBuilder.cronSchedule(scheduleExp)).build();
    }

    public JobDetail buildJobDetail(Class job, String name, String group, Map params) {
        JobDataMap jobDataMap = new JobDataMap();
        jobDataMap.putAll(params);

        return newJob(job).withIdentity(name, group)
                .usingJobData(jobDataMap)
                .build();
    }

    protected abstract void doRun(ApplicationArguments args);

}

왼쪽사진 file 스케줄러를 통해 파일이 생성되는 결과

가운데사진 db적재된 결과

오른쪽사진 api통신을 통해 적재된 결과

해당 프로젝트는 인프런의 있는 스프링배치 실습을 통해 진행되었다.

해당 결과물은 git을 통해 확인 가능합니다.

https://github.com/prodo-developer/spring-batch

2021년을 돌아 보며 회고록

prodo-developer — Fri, 31 Dec 2021 00:22:38 +0900

생애 처음 쓰는 일기같은 회고록.

그 동안은 단순하게 해왔던 이력을 적었더라면, 한해를 돌아보는 회고록은

싸이월드 일기장 이후 길게 써본적은 처음인거 같다.

올해는 정말 다산다난했던 한해였다.

그만큼 열심히 살았다는 증거고 1년동안 있었던 일들을 몰아서 회고해본다.

1. 내 자신을 돌아보기

어느덧 연차는 만 5년차, 나는 늘 고민이 있었다.

SI회사를 다니면서 그리고 마지막으로 그토록 하고 싶었던 프리랜서까지 12월까지 마무리짓고,

휴식기 없이 지내온 나는, 알수 없는 갈증을 이제서야 느꼈다.

내가 진짜 원하는 개발이 뭔지, 앞으로 나는 성장하려면 어디서 무엇을 해야 할지..

그 공백기가 생각보다 길어질진 몰랐으나, 쉬는기간 동안 내가 하고 싶었던것들을 시작해보았다.

부업으로 게임서버도 운영해보니 그동안 SI에서 끌려다녔던 느낌과 달리 직접 유저들과 소통을 하면서 유지보수를 하는과정에서 더 책임감과 애착심이 생기고, 잠을 설쳐도 피곤한줄 모르고 그렇게 2~3달은 지냈던거 같다. ⛱

그러다 사업이라는것은 안정적이지 못하고, 그 동안 기술스택을 쌓았던 나로써 다시한번 돌아보게 되었다.

파견업체에 다니면서 SI과 SM을 하면서 느꼈던점은 풀스택 같은 개념으로 프론트도 다루고, 백엔드도 다루지만

가끔 정체성을 못느낄 때 마다 나에게 계속 혼란이 왔었고, 하나를 깊게 아는데도 시간이 부족한데..

좀 더 편하게 개발할수 있는건 없을까?? 라는 생각에 UI솔루션 업체에서도 근무를 해보았으나, 결국 그 경험을 통해

프론트는 뭔가 나랑 안맞는게 갈수록 느껴졌었고, 솔루션의 장단점은 확실히 편하게 개발하는건 좋으나, 트렌드를 쫓아가기엔 점점 거리감이 느껴지고, 이직을 하게 될 경우 개발자에겐 도태 되는 길로 몸소 느낄 수 있었다.

그렇다고 특출나게 백엔드를 잘했던것도 아니다.

그 동안 내가 정말 성실하게 살았는가?? 내 자신을 돌아보니 쉬고 싶은거 다쉬고, 개발은 단지 컴공을 나왔으니까,

하던일이 이거였니까.. 그렇게 흐름대로 살아왔던걸 백수라는 기간동안 뼈저리게 느꼈고, 반환점이 없으면

난 그대로 계속 이 바닥에서 그냥 그렇게 하다가 도태되는 개발자가 되겠구나. 지난 시간들을 반성하게 되었다.

2. 이직 준비

무엇부터 준비를 해야 할까, 그렇다면 누가들어도 알수있는 서비스회사로 한번 1년동안 준비해보고, 안되면 생계를 위해서라도 돌아가야지 라는 마음으로 올해 1월부터 결심하게 되었다.

서비스회사는 SI회사와 달리 보통 코딩테스트 또는 과제형식으로 진행된다.

그 동안 코딩테스트를 항상 기피했던 나는 그 동안 준비 안했던 것들이 후회처럼 몰려오고, 늦었지만 지금이라도 차근차근 준비하자는 마음으로 시작했다.

가장 먼저 시작한것은 혼자하는것보단 스터디가 좋다고 생각하여 그 동안 자기계발에 투자하지 않았던 것을

온전히 이곳에 투자하기로 마음 먹었다.

1. 프로그래머스 : 코딩테스트와 실무 역량 모두 잡는 스터디: Java반 8기

기수당 약 40명으로 이루어져 있으며, 지금은 오래되어 내역을 자세하게 볼 순 없지만, 주차별 미션이 주어지면 과제는 깃으로 공유하며 코드리뷰도 꼼꼼하게 확인할 수 있다.

주 1회 온라인세션이 열리며, 담당자와 주차별 설명과 직접 소통할 수 있는 좋은 시간도 주어진다.

코테를 처음 준비하시는 분들에게 가성비는 다소 아쉬울수 있으나 추천하는 스터디이다.

현재는 12기 진행중이며 모집중이다.

https://programmers.co.kr/learn/courses/13210

2. 인프런 :

코딩테스트 전 꼭 알아야 할 개념과 문제(with 자바)

정말 쉽게 풀어보는 코딩테스트 top 기본문제

1번으로만 준비하기에는 사실 부족한 부분이 있었다. 실시간 피드백이 다소 아쉬운부분이있어, 그런 부분은 내가 직접 채워 나가는수 밖에 없었다.

병행으로 준비할 수 있는건 없을까.. 라는 생각에 정말 이런 문제는 공식처럼 외워서 풀면 접근이 쉬워지는 노하우를

갖춘 강의며, 인프런의 최고 장점은 역시 강의마다 질의응답이 가능하다는거!

문제는 릿코드기반으로 진행되며, 기본개념도 잡아주고, 기본 문제를 미리 풀어보는것도 좋다고 생각한다.

3. 백엔드의 길

1,2번은 기본적으로 갖춰야 할 소양이라면, 이제 내가 어디방향으로 갈지 방향을 잡아야 할 찰나에,

우연히 인프런을 통해 김영한님의 JPA를 보게되고, 무료강의 및 미리보기를 보았는데,

그동안 인강을 기피했던 편견이 깨졌으며, 돈이 아깝지 않다는 생각에 아래와 같이 한번에 플렉스를 하게되었고,

지금은 팬이 되어버린 난 신작이 나올때 마다 선구매 후감상으로 진행하고 있다.

이번 강의에 투자한 돈만 대략 100만원은 넘는것같다. 내 인생에 이렇게 투자를 하게 될줄이야...

정말 백엔드의 길로 가고 싶다면 스프링, JPA 영한님 강의만 믿고 따라가도 면접,실무에서 막힘없이

나아갈수 있다고 장담한다.

이렇게 나는 인강을 모으는 재미와, 기술면접에 필요한 스터디를 열게 되어 부족했던 CS 지식들을 다시한번 정리하면서

점점 백엔드 개발자의 필요한 정보들을 줍줍하게 되었다.

하지만 이걸로만 부족하다고 느껴, 사이드 프로젝트를 진행하게 되었고, 약 8개월동안 현재까지 많은 우여곡절이 있었으나, 이제 어느정도 정예멤버가 갖추어져 조금씩 진전해 나가고 있다.

유아도서 쇼핑몰 스터디 : https://github.com/ecommerce-site-study

ecommerce-site-study

ecommerce-site-study has one repository available. Follow their code on GitHub.

github.com

3. 취업성공 그리고 도전해야 될 큰 산

취업이 쉽지만은 않았다. 보는 눈을 애시당초에 높게 잡았기 때문에, 서류탈락은 다반사였고,

각종 테스트를 통해 떨어지는 회사들도 많았으며, 시간이 지나갈수록 우울증이 몰려오게 되고

하고 싶었던 운동도 접게 되어, 몸과 마음이 약해지고 있는걸 느꼈다.

그 간절함이 운좋게도, 6개월만에 기회가 오게되어 현재는 인터파크에 입사하게되어,

그토록 가고싶었던 서비스회사에, 백엔드 개발자로 입사하게 되었다.

최종합격과 동시에 준비하고 있었던 넥스트스텝의 우아한 테크캠프 2기까지 선발되어,

운이 좋게 입사와 함께 동시에 준비할 수 있었다.

그러나, 이게 두가지를 병행하기엔 정말 높은 산이었다.

회사업무는 회사업무대로... 우테캠 과제는 결코 호락호락 하지않은 과제였기 때문에, 혼자서 이것들을 해결하기엔

감당하기 힘들다고 생각하여, 오프라인 스터디를 개설하게 되었고, 함께했던 동기들과 지금까지 소통하면서 개발자다운

이야기를 들으며, 더욱 더 성장하게 되는거 같아 만족한다.

우아한테크캠프는 마무리할때쯤 이거에 대한 회고록을 쓰려고 했으나 본업에 다시 집중해야되는 시기가 찾아오다보니

이제서야 그 후기를 간략하게 정리하고자 한다.

캡틴 포비님께서도 말씀해주셨지만 캠프기간 2달동안은 나 자신과의 약속을 지켜야만 이 진도를 따라갈수 있다고하셨다.

1. 주변 친구들과 잠시 안녕

2. 전자매체 안녕

3. 퇴근 후, 주말에도 온전히 이곳에 집중하기

정말 이 세가지를 지켜야만 진도를 쫓아갈 수 있었다. 그 만큼 8주과정 동안 과제가 수없이 쏟아지며, 고생하는 만큼

얻어가는 지식들이 풍부하다.

우테캠을 해보면서 새롭게 보고 느꼈던점을 간략하게 정리하자면

1. TDD를 통한 리팩토링

2. 동기들과 함께 페어프로그래밍

3. JPA 실습

4. ATDD, DDD 경험

5. AWS를 통한 인프라 실습

6. 도커 컨테이너를 이용한 실습

7. 부하테스트

8. 레거시 코드 리팩토링

9. Redis와 mysql를 통한 최적화 만들기

이외에도 많았지만 기억에 남았던 내용들을 간략하게 추려 보았다.

자세한 썰들은 회고록 목록에 주차별 느낀점을 따로 정리해 두었다.

우테캠을 희망하는 사람이 있다면, 이 많은것들을 소화하기 위해 2달동안은 정말 각오하고 들어올것...

그렇게 쏜살같이 상반기가 지나갔다.

4. 본업에 집중

회사에 입사한지 어느덧 8개월차가 되었다.

투어플랫폼개발팀에 입사하여, 처음에는 내가 어떤 업무를 할 수 있을까? 라는 의구심에 정체성을 찾는데 시간이 많이 걸렸다.

기술적으로 어렵다기 보다, 투어서비스를 처음 접하게 되다보니 모든것들이 낯설고 어렵게 느껴졌었다.

지금은 국내 숙박 상품을 담당하고 있으며, 인터파크 투어와 협업 하고 있는 업체들에게 서비스를 제공해주는

연동제휴 플랫폼을 개발 및 운영 하고 있다.

각 거래처마다 요구사항이 다르고, 거기에 맞게 대응을 하다보니, 처음부터 개발한것이 아닌 이 모든걸 혼자 파악하기엔 시간이 오래걸렸다. 아쉬운점이 있다면, 히스토리를 아는분이 많이 계시질 않아, 맨땅의 헤딩만이 답이었다.

이미 개발이 어느정도 되어있고, 되어있는 서비스를 운영하는것이 쉬운것만은 아니었다. 그래서 더욱 더 작업을 할 때마다 더 조심스럽고, 더 꼼꼼해지려고 한다.

SI처럼 만들고 철수하는것이 아닌 직접 서비스를 운영하는 입장에서 퇴근하고 나서도, 주말에서도 계속 생각나는것이

서비스회사만의 특징인것 같다. 그러면서 투어의 도메인이라는 깊이를 알게 되고, 그렇게 점차 쌓아가다보면

먼 훗날에 훌륭한 투어쪽의 달인이 되지 않을까라는 기대감으로 지금도 열심히 노력하고 있다.

일과 시간 이후에도 꾸준히 인강을 통해 학습중이며, 주말에도 답답하면 카페에 가서 즐기는 마음으로 코딩하면서 시간을 보낸다.

5. 2022 목표

올해 해왔던것들을 조금 더 정비할 필요가 있는 한해가 될것 같다.

- 본업에 더 충실하기

현재 내가 맡은 업무만큼은 충분히 소화할 수 있는 개발자가 되어, 어딜가도 인정받는 일잘러가 되고 싶다.

- 인강 정주행하기

위에 언급한 강의들 아직 많이 보질 못했다. 내년엔 꼭 정주행하리라.. 물론 강의는 계속 구매할 예정

- 전공 독서하기

주변에서 유명하다고 언급한 책들은 사놓긴 했으나, 막상 읽질 못했다.

이것 또한 읽기 도전!! 구매한 책들은 아래와 같다.

* 스프링부트와 AWS로 혼자 구현하는 웹 서비스

* 코드로 배우는 스프링부트 웹 프로젝트

* 리팩토링

* Real Mysql

* 가상 면접 사례로 배우는 대규모 시스템 설계 기초

* 웹 개발자를 위한 대규모 서비스를 지탱하는 기술

* 모던 자바 인 액션

* 이펙티브 자바

- 사이드 프로젝트

2021년도에는 마음맞는 팀원들과 알아가는 기간이 였다면, 올해는 조금 더 퀄리티 좋은 코드와, 꾸준한 관심의 결과물로

표현하자.

- 건강유지 (운동 생활화)

항상 모든일엔 건강이 최우선이다.

체력이 뒷받침 되어야 어떠한 상황을 겪어도 버틸 수 있게 해주는 원동력인거 같다.

운동을 통해 느낀점은 부정적으로 생각하던 것들도 긍정적으로 바뀌는 멘탈케어에도 좋으며,

몸도 건강해짐을 느끼고 있다.

평일, 주말 가리지 않고 웨이트 운동을 통해 특별한 일이 없으면 헬스장으로 출근하자.

못가는 날에는 집에서 홈트라도 진행할 것.

6. 마무리

12월 31일. 한해를 마무리 하면서 꼭 작성하고 싶었던 회고록을 작성하게 되어 기쁘고,

올 한해 열심히 살았던 나에게 칭찬해주고 싶다. 내년에는 더 멋있고, 알차고 목표를 이룰수 있는 내가 되길.

살면서 가장 중요한것은 건강과 멘탈인것 같다.

사이드 프로젝트와, 개인공부를 통한 Git에 1일 1커밋을 통해 성실함을 계속 보여주고 앞으로도 그렇게 되길

응원한다!

[SPRING] 스프링 배치 테이블 초기화 방법

prodo-developer — Wed, 15 Dec 2021 00:55:05 +0900

아래와 같이 초기화를 돌리고 다음과 같은 이슈를 발생하였다.

@Configuration
@RequiredArgsConstructor
public class jobBatchResetTest {
    private final JobBuilderFactory jobBuilderFactory;
    private final StepBuilderFactory stepBuilderFactory;

    @Bean
    public Job job() {
        return jobBuilderFactory.get("batchJob1")
                .incrementer(new RunIdIncrementer()) // 동일 파라미터인데 다시 실행하고 싶을때 사용하라는 의미로 RunIdIncrementer를 제공
                .start(step1())
                .next(step2())
                .build();
    }

    @Bean
    public Step step1() {
        return stepBuilderFactory.get("step1")
                .tasklet(new Tasklet() {
                    @Override
                    public RepeatStatus execute(StepContribution contribution, ChunkContext chunkContext) throws Exception {
                        System.out.println("step1 was executed");
                        return RepeatStatus.FINISHED;
                    }
                })
                .build();
    }

    @Bean
    public Step step2() {
        return stepBuilderFactory.get("step2")
                .tasklet(new Tasklet() {
                    @Override
                    public RepeatStatus execute(StepContribution contribution, ChunkContext chunkContext) throws Exception {
                        System.out.println("step2 was executed");
                        return RepeatStatus.FINISHED;
                    }
                })
                .build();
    }
}

org.springframework.dao.DuplicateKeyException: PreparedStatementCallback; SQL [INSERT into BATCH_STEP_EXECUTION(STEP_EXECUTION_ID, VERSION, STEP_NAME, JOB_EXECUTION_ID, START_TIME, END_TIME, STATUS, COMMIT_COUNT, READ_COUNT, FILTER_COUNT, WRITE_COUNT, EXIT_CODE, EXIT_MESSAGE, READ_SKIP_COUNT, WRITE_SKIP_COUNT, PROCESS_SKIP_COUNT, ROLLBACK_COUNT, LAST_UPDATED) values(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)]; Duplicate entry '0' for key 'BATCH_STEP_EXECUTION.PRIMARY'; nested exception is java.sql.SQLIntegrityConstraintViolationException: Duplicate entry '0' for key 'BATCH_STEP_EXECUTION.PRIMARY'

Caused by: java.sql.SQLIntegrityConstraintViolationException: Duplicate entry '0' for key 'BATCH_STEP_EXECUTION.PRIMARY'

개선책으로는 아래와 같이 해봤는데도 실패....

1. @SpringBootApplication 주석 후 아래와 같이 진행

@EnableAutoConfiguration(exclude={BatchAutoConfiguration.class})

2. @SpringBootApplication(exclude={BatchAutoConfiguration.class})

결국은 테이블만 날리는것이 아닌 시퀀스들도 초기화를 해주고나서 가능해졌다.

delete from BATCH_JOB_EXECUTION_CONTEXT;
delete from BATCH_JOB_EXECUTION_PARAMS;
delete from BATCH_JOB_EXECUTION_SEQ;
delete from BATCH_JOB_SEQ;
delete from BATCH_STEP_EXECUTION_CONTEXT;
delete from BATCH_STEP_EXECUTION_SEQ;
delete from BATCH_STEP_EXECUTION;
delete from BATCH_JOB_EXECUTION;
delete from BATCH_JOB_INSTANCE;

INSERT INTO BATCH_STEP_EXECUTION_SEQ values(0, '0');
INSERT INTO BATCH_JOB_EXECUTION_SEQ values(0, '0');
INSERT INTO BATCH_JOB_SEQ values(0, '0');

※ 시퀀스를 수동으로 넣어야 하는 DB 일 경우 위와 같이 삭제했을 경우 다시 입력해 주어야 합니다.

Postgresql 같은 경우 위와 같은 처리가 필요하지 않습니다.

깃허브(github) 잔디심기 안될 때

prodo-developer — Thu, 16 Sep 2021 21:43:30 +0900

최근에 노트북을 변경하고, 환경셋팅을 하고 여전히 1일 1커밋을 진행 하면 잔디가 심어져야 하는데

계속 되지않아서 브랜치를 지웠다가 해보기도하고, 권한도 바꿔보고 별의 별짓을 약 1주일간 했던거같다.

무식하게, 브랜치를 새롭게 받아서 하는방식... 이건 아니다 싶어, 나와 같은 고민하는 분들이 많았다.

원인은 git을 공유할 때 이메일주소를 이상하게 적었다. (오타 )

그 이외에 다른케이스들도 있다고하여 아래에 공유 하겠습니다.

1) 깃허브 계정의 이메일 주소 확인하기

깃허브 프로필 클릭 -> settings -> 이메일 주소 확인

2) 명령어로 config list 확인하기

git config --global --list

config 에 이메일주소가 저장이 안되어있거나, 오타 또는 {중괄호가 씌워진 값이면 당장 지울것}

//이메일변경
git config --global user.email "aaa@a.com"

//유저이름 변경
git config --global user.name "USER_NAME"

위와 같이 변경 후 새로운 commit 거리를 만들고 push 하면 정상적으로 잔디심기 성공!

[SPRING] 주문금액 집계 프로젝트 실습 part3 (성능개선과 성능비교)

prodo-developer — Sat, 7 Aug 2021 18:46:48 +0900

이전 실습에서 진행한 배치 속도를 다양한 방법으로 개선해보고 성능측정을 하려고 합니다.

배치 측정 요구 사항은 아래와 같습니다.

● SaveUserTasklet에서 User 30,000건 저장, Chunk Size는 1,000

● 성능 개선 대상 Step은 userLevelUpStep

● 아래 표 순서대로 실행

예제를 만들고 성능 측정 후 비교
3번 씩 실행
PC 환경에 따라 성능이 다를 수 있음 (해당 개인PC는 강의에 나온 PC보다 느렸음 )

	1회	2회	3회
Simple Step	15557mills	15081mills	14628mills
Async Step	15074mills	15511mills	14940mills
Multi-Thread Step(가장빠름)	9038mills	8943mills	9909mills
Partition Step	9659mills	10890mills	10629mills
Async + Partition Step	10795mills	10919mills	11186mills
Parallel Step	14236mills	14433mills	14377mills
Partition + Parallel Step	10512mills	10294mills	10252mills

* 4차부터는 큰 속도의 변화를 찾아볼 수 없었다. 15403mills, 15024mils, 이후에도... 그래서 3번씩만 진행하기로 했다.

Async Step을 적용하기 위해서는 Async 관련된 라이브러리를 추가해야 합니다.

1. java.util.concurrent에서 제공되는 Future 기반 asynchronous Async를 사용하기 위해 spring-batch-integration 필요.

2. build.gradle 파일에서 implementation 'org.springframework.batch:spring-batch-integration' 추가

3. ItemProcessor와 ItemWriter를 Async로 실행하도록 수정합니다.

4. Async Step은 ItemProcessor와 ItemWriter 기준으로 비동기 처리 합니다.

Single Thread에서 asynchronous Async로 변경

AsyncStep 기능 작업

@Configuration
@Slf4j
public class AsyncUserConfiguration {

    private final String JOB_NAME = "asyncUserJob";
    public static final int CHUNK_SIZE = 1000;
    private final JobBuilderFactory jobBuilderFactory;
    private final StepBuilderFactory stepBuilderFactory;
    private final UserRepository userRepository;
    private final EntityManagerFactory entityManagerFactory;
    private final DataSource dataSource;
    private final TaskExecutor taskExecutor;

    public AsyncUserConfiguration(JobBuilderFactory jobBuilderFactory, StepBuilderFactory stepBuilderFactory, UserRepository userRepository, EntityManagerFactory entityManagerFactory, DataSource dataSource, TaskExecutor taskExecutor) {
        this.jobBuilderFactory = jobBuilderFactory;
        this.stepBuilderFactory = stepBuilderFactory;
        this.userRepository = userRepository;
        this.entityManagerFactory = entityManagerFactory;
        this.dataSource = dataSource;
        this.taskExecutor = taskExecutor;
    }

    @Bean(JOB_NAME)
    public Job userJob() throws Exception {
        return this.jobBuilderFactory.get(JOB_NAME)
                .incrementer(new RunIdIncrementer())
                .start(this.saveUserStep())
                .next(this.userLevelUpStep())
                .listener(new LevelUpJobExecutionListener(userRepository))
                .next(new JobParameterDecide("date")) // 가져온값이 아래의 CONTINUE인지 체크
                .on(JobParameterDecide.CONTINUE.getName()) // CONTINUE이면 아래의 to메서드 실행
                .to(this.orderStatisticsStep(null))
                .build()
                .build();
    }

    @Bean(JOB_NAME + "_orderStatisticsStep")
    @JobScope
    public Step orderStatisticsStep(@Value("#{jobParameters[date]}") String date) throws Exception {
        return this.stepBuilderFactory.get(JOB_NAME + "_orderStatisticsStep")
                .<OrderStatistics, OrderStatistics>chunk(CHUNK_SIZE)
                .reader(orderStatisticsItemReader(date))
                .writer(orderStatisticsItemWriter(date))
                .build();
    }

    private ItemReader<? extends OrderStatistics> orderStatisticsItemReader(String date) throws Exception {
        YearMonth yearMonth = YearMonth.parse(date);

        Map<String, Object> parameters = new HashMap<>();
        parameters.put("startDate", yearMonth.atDay(1)); // 2021년 8월 1일
        parameters.put("endDate", yearMonth.atEndOfMonth()); // 8월의 마지막 날

        Map<String, Order> sortKey = new HashMap<>();
        sortKey.put("created_date", Order.ASCENDING);

        JdbcPagingItemReader<OrderStatistics> itemReader = new JdbcPagingItemReaderBuilder<OrderStatistics>()
                .dataSource(this.dataSource)
                .rowMapper((resultSet, i) -> OrderStatistics.builder()
                        .amount(resultSet.getString(1))
                        .date(LocalDate.parse(resultSet.getString(2), DateTimeFormatter.ISO_DATE))
                        .build())
                .pageSize(CHUNK_SIZE) // 페이징 설정
                .name(JOB_NAME + "_orderStatisticsItemReader")
                .selectClause("sum(amount), created_date")
                .fromClause("orders")
                .whereClause("created_date >= :startDate and created_date <= :endDate")
                .groupClause("created_date")
                .parameterValues(parameters)
                .sortKeys(sortKey)
                .build();

        itemReader.afterPropertiesSet();

        return itemReader;
    }

    private ItemWriter<? super OrderStatistics> orderStatisticsItemWriter(String date) throws Exception {
        YearMonth yearMonth = YearMonth.parse(date);

        String fileName = yearMonth.getYear() + "년_" + yearMonth.getMonthValue() + "월_일별_주문_금액.csv";

        BeanWrapperFieldExtractor<OrderStatistics> fieldExtractor = new BeanWrapperFieldExtractor<>();
        fieldExtractor.setNames(new String[]{"amount", "date"});

        DelimitedLineAggregator<OrderStatistics> lineAggregator = new DelimitedLineAggregator<>();
        lineAggregator.setDelimiter(",");
        lineAggregator.setFieldExtractor(fieldExtractor);

        FlatFileItemWriter<OrderStatistics> itemWriter = new FlatFileItemWriterBuilder<OrderStatistics>()
                .resource(new FileSystemResource("output/" + fileName))
                .lineAggregator(lineAggregator)
                .name(JOB_NAME + "_orderStatisticsItemWriter")
                .encoding("UTF-8")
                .headerCallback(writer -> writer.write("total_amount,date"))
                .build();

        itemWriter.afterPropertiesSet();

        return itemWriter;
    }

    @Bean(JOB_NAME + "_saveUserStep")
    public Step saveUserStep() {
        return this.stepBuilderFactory.get(JOB_NAME + "_saveUserStep")
                .tasklet(new SaveUserTasklet(userRepository))
                .build();
    }

    @Bean(JOB_NAME + "_userLevelUpStep")
    public Step userLevelUpStep() throws Exception {
        return this.stepBuilderFactory.get(JOB_NAME + "_userLevelUpStep")
                .<User, Future<User>>chunk(CHUNK_SIZE) // Future로 감싸야 컴파일 해결 됨.
                .reader(itemReader())
                .processor(itemProcessor())
                .writer(itemWriter())
                .build();
    }

    private AsyncItemWriter<User> itemWriter() {
        ItemWriter<User> itemWriter = users -> users.forEach(x -> {
                x.levelUp();
                userRepository.save(x);
        });

        AsyncItemWriter<User> asyncItemWriter = new AsyncItemWriter<>();
        asyncItemWriter.setDelegate(itemWriter);

        return asyncItemWriter;
    }

    private AsyncItemProcessor<User, User> itemProcessor() {
        ItemProcessor<User, User> itemProcessor = user -> {
            if (user.availableLeveUp()) {
                return user;
            }

            return null;
        };

        AsyncItemProcessor<User, User> asyncItemProcessor = new AsyncItemProcessor<>();
        asyncItemProcessor.setDelegate(itemProcessor);
        asyncItemProcessor.setTaskExecutor(this.taskExecutor);

        return asyncItemProcessor;
    }

    private ItemReader<? extends User> itemReader() throws Exception {
        JpaPagingItemReader<User> itemReader = new JpaPagingItemReaderBuilder<User>()
                .queryString("select u from User u")
                .entityManagerFactory(entityManagerFactory)
                .pageSize(CHUNK_SIZE)
                .name(JOB_NAME + "_userItemReader")
                .build();

        itemReader.afterPropertiesSet();

        return itemReader;
    }
}

※ Async Step은 Simple Step보다 속도가 조금 더 개선되는 줄 알고 기대했다가 큰 차이가 없었다.. ㅠㅠ

다음은 가장 빨랐던 Multi-Thread Step를 적용해보자.

● Multi-Thread Step은 Chunk 단위로 멀티 스레딩 처리

● Thread-Safe 한 ItemReader 필수

SpringBatchExampleApplication.java (메인메서드 자동 종료 및 TaskExecutor기반 쓰레드 설정)

@SpringBootApplication
@EnableBatchProcessing
public class SpringBatchExampleApplication {

	public static void main(String[] args) {
		// 스프링 배치가 정상적으로 종료될 수 있도록 System.exit(SpringApplication.exit();
		System.exit(SpringApplication.exit(SpringApplication.run(SpringBatchExampleApplication.class, args)));
	}

	/**
	 * // TaskExecutor가 기본적으로 Bean으로 생성되어 있기 때문에 기본 @Bean으로 사용하기 위함을 표시
	 */
	@Bean
	@Primary
	TaskExecutor taskExecutor() {
		ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
		taskExecutor.setCorePoolSize(10); // 쓰레드 기본 사이즈 10
		taskExecutor.setMaxPoolSize(20); // 최대 쓰레드 사이즈 20
		taskExecutor.setThreadNamePrefix("batch-thread-"); // 배치 쓰레드 Prefix 이름이 찍히게 됨.
		taskExecutor.initialize();
		return taskExecutor;
	}
}

User.java 수정 (FetchType.EAGER 변경)

Multi-Thread Step 기능 작업

@Configuration
@Slf4j
public class MultiThreadUserConfiguration {

    private final String JOB_NAME = "multiThreadUserJob";
    public static final int CHUNK_SIZE = 1000;
    private final JobBuilderFactory jobBuilderFactory;
    private final StepBuilderFactory stepBuilderFactory;
    private final UserRepository userRepository;
    private final EntityManagerFactory entityManagerFactory;
    private final DataSource dataSource;
    private final TaskExecutor taskExecutor;

    public MultiThreadUserConfiguration(JobBuilderFactory jobBuilderFactory, StepBuilderFactory stepBuilderFactory, UserRepository userRepository, EntityManagerFactory entityManagerFactory, DataSource dataSource, TaskExecutor taskExecutor) {
        this.jobBuilderFactory = jobBuilderFactory;
        this.stepBuilderFactory = stepBuilderFactory;
        this.userRepository = userRepository;
        this.entityManagerFactory = entityManagerFactory;
        this.dataSource = dataSource;
        this.taskExecutor = taskExecutor;
    }

    @Bean(JOB_NAME)
    public Job userJob() throws Exception {
        return this.jobBuilderFactory.get(JOB_NAME)
                .incrementer(new RunIdIncrementer())
                .start(this.saveUserStep())
                .next(this.userLevelUpStep())
                .listener(new LevelUpJobExecutionListener(userRepository))
                .next(new JobParameterDecide("date")) // 가져온값이 아래의 CONTINUE인지 체크
                .on(JobParameterDecide.CONTINUE.getName()) // CONTINUE이면 아래의 to메서드 실행
                .to(this.orderStatisticsStep(null))
                .build()
                .build();
    }

    @Bean(JOB_NAME + "_orderStatisticsStep")
    @JobScope
    public Step orderStatisticsStep(@Value("#{jobParameters[date]}") String date) throws Exception {
        return this.stepBuilderFactory.get(JOB_NAME + "_orderStatisticsStep")
                .<OrderStatistics, OrderStatistics>chunk(CHUNK_SIZE)
                .reader(orderStatisticsItemReader(date))
                .writer(orderStatisticsItemWriter(date))
                .build();
    }

    private ItemReader<? extends OrderStatistics> orderStatisticsItemReader(String date) throws Exception {
        YearMonth yearMonth = YearMonth.parse(date);

        Map<String, Object> parameters = new HashMap<>();
        parameters.put("startDate", yearMonth.atDay(1)); // 2021년 8월 1일
        parameters.put("endDate", yearMonth.atEndOfMonth()); // 8월의 마지막 날

        Map<String, Order> sortKey = new HashMap<>();
        sortKey.put("created_date", Order.ASCENDING);

        JdbcPagingItemReader<OrderStatistics> itemReader = new JdbcPagingItemReaderBuilder<OrderStatistics>()
                .dataSource(this.dataSource)
                .rowMapper((resultSet, i) -> OrderStatistics.builder()
                        .amount(resultSet.getString(1))
                        .date(LocalDate.parse(resultSet.getString(2), DateTimeFormatter.ISO_DATE))
                        .build())
                .pageSize(CHUNK_SIZE) // 페이징 설정
                .name(JOB_NAME + "_orderStatisticsItemReader")
                .selectClause("sum(amount), created_date")
                .fromClause("orders")
                .whereClause("created_date >= :startDate and created_date <= :endDate")
                .groupClause("created_date")
                .parameterValues(parameters)
                .sortKeys(sortKey)
                .build();

        itemReader.afterPropertiesSet();

        return itemReader;
    }

    private ItemWriter<? super OrderStatistics> orderStatisticsItemWriter(String date) throws Exception {
        YearMonth yearMonth = YearMonth.parse(date);

        String fileName = yearMonth.getYear() + "년_" + yearMonth.getMonthValue() + "월_일별_주문_금액.csv";

        BeanWrapperFieldExtractor<OrderStatistics> fieldExtractor = new BeanWrapperFieldExtractor<>();
        fieldExtractor.setNames(new String[]{"amount", "date"});

        DelimitedLineAggregator<OrderStatistics> lineAggregator = new DelimitedLineAggregator<>();
        lineAggregator.setDelimiter(",");
        lineAggregator.setFieldExtractor(fieldExtractor);

        FlatFileItemWriter<OrderStatistics> itemWriter = new FlatFileItemWriterBuilder<OrderStatistics>()
                .resource(new FileSystemResource("output/" + fileName))
                .lineAggregator(lineAggregator)
                .name(JOB_NAME + "_orderStatisticsItemWriter")
                .encoding("UTF-8")
                .headerCallback(writer -> writer.write("total_amount,date"))
                .build();

        itemWriter.afterPropertiesSet();

        return itemWriter;
    }

    @Bean(JOB_NAME + "_saveUserStep")
    public Step saveUserStep() {
        return this.stepBuilderFactory.get(JOB_NAME + "_saveUserStep")
                .tasklet(new SaveUserTasklet(userRepository))
                .build();
    }

    @Bean(JOB_NAME + "_userLevelUpStep")
    public Step userLevelUpStep() throws Exception {
        return this.stepBuilderFactory.get(JOB_NAME + "_userLevelUpStep")
                .<User, User>chunk(CHUNK_SIZE)
                .reader(itemReader())
                .processor(itemProcessor())
                .writer(itemWriter())
                .taskExecutor(this.taskExecutor) // 생성자로 주입받은 taskExecutor 사용
                .throttleLimit(8) // 몇개의 쓰레드로 처리할것인지 (기본 4개)
                .build();
    }

    private ItemWriter<? super User> itemWriter() {
        return users -> users.forEach(x -> {
                x.levelUp();
                userRepository.save(x);
        });
    }

    private ItemProcessor<? super User, ? extends User> itemProcessor() {
        return user -> {
            if (user.availableLeveUp()) {
                return user;
            }

            return null;
        };
    }

    private ItemReader<? extends User> itemReader() throws Exception {
        JpaPagingItemReader<User> itemReader = new JpaPagingItemReaderBuilder<User>()
                .queryString("select u from User u")
                .entityManagerFactory(entityManagerFactory)
                .pageSize(CHUNK_SIZE)
                .name(JOB_NAME + "_userItemReader")
                .build();

        itemReader.afterPropertiesSet();

        return itemReader;
    }
}

Partition Step은 어떨까?

● 하나의 Master 기준으로 여러 Slave Step을 생성해 Step 기준으로 Multi-Thread 처리

● 예를 들어

item이 40,000개, Slave Step이 8개면
40000 / 8 = 5000 이므로 하나의 Slave Step 당 5,000건 씩 나눠서 처리

● Slave Step은 각각 하나의 Step으로 동작

Partitioner 기능 추가

@Configuration
@Slf4j
public class PartitionUserConfiguration {

    private final String JOB_NAME = "partitionUserJob";
    public static final int CHUNK_SIZE = 1000;
    private final JobBuilderFactory jobBuilderFactory;
    private final StepBuilderFactory stepBuilderFactory;
    private final UserRepository userRepository;
    private final EntityManagerFactory entityManagerFactory;
    private final DataSource dataSource;
    private final TaskExecutor taskExecutor;

    public PartitionUserConfiguration(JobBuilderFactory jobBuilderFactory, StepBuilderFactory stepBuilderFactory, UserRepository userRepository, EntityManagerFactory entityManagerFactory, DataSource dataSource, TaskExecutor taskExecutor) {
        this.jobBuilderFactory = jobBuilderFactory;
        this.stepBuilderFactory = stepBuilderFactory;
        this.userRepository = userRepository;
        this.entityManagerFactory = entityManagerFactory;
        this.dataSource = dataSource;
        this.taskExecutor = taskExecutor;
    }

    @Bean(JOB_NAME)
    public Job userJob() throws Exception {
        return this.jobBuilderFactory.get(JOB_NAME)
                .incrementer(new RunIdIncrementer())
                .start(this.saveUserStep())
                .next(this.userLevelUpManagerStep())
                .listener(new LevelUpJobExecutionListener(userRepository))
                .next(new JobParameterDecide("date")) // 가져온값이 아래의 CONTINUE인지 체크
                .on(JobParameterDecide.CONTINUE.getName()) // CONTINUE이면 아래의 to메서드 실행
                .to(this.orderStatisticsStep(null))
                .build()
                .build();
    }

    @Bean(JOB_NAME + "_orderStatisticsStep")
    @JobScope
    public Step orderStatisticsStep(@Value("#{jobParameters[date]}") String date) throws Exception {
        return this.stepBuilderFactory.get(JOB_NAME + "_orderStatisticsStep")
                .<OrderStatistics, OrderStatistics>chunk(CHUNK_SIZE)
                .reader(orderStatisticsItemReader(date))
                .writer(orderStatisticsItemWriter(date))
                .build();
    }

    private ItemReader<? extends OrderStatistics> orderStatisticsItemReader(String date) throws Exception {
        YearMonth yearMonth = YearMonth.parse(date);

        Map<String, Object> parameters = new HashMap<>();
        parameters.put("startDate", yearMonth.atDay(1)); // 2021년 8월 1일
        parameters.put("endDate", yearMonth.atEndOfMonth()); // 8월의 마지막 날

        Map<String, Order> sortKey = new HashMap<>();
        sortKey.put("created_date", Order.ASCENDING);

        JdbcPagingItemReader<OrderStatistics> itemReader = new JdbcPagingItemReaderBuilder<OrderStatistics>()
                .dataSource(this.dataSource)
                .rowMapper((resultSet, i) -> OrderStatistics.builder()
                        .amount(resultSet.getString(1))
                        .date(LocalDate.parse(resultSet.getString(2), DateTimeFormatter.ISO_DATE))
                        .build())
                .pageSize(CHUNK_SIZE) // 페이징 설정
                .name(JOB_NAME + "_orderStatisticsItemReader")
                .selectClause("sum(amount), created_date")
                .fromClause("orders")
                .whereClause("created_date >= :startDate and created_date <= :endDate")
                .groupClause("created_date")
                .parameterValues(parameters)
                .sortKeys(sortKey)
                .build();

        itemReader.afterPropertiesSet();

        return itemReader;
    }

    private ItemWriter<? super OrderStatistics> orderStatisticsItemWriter(String date) throws Exception {
        YearMonth yearMonth = YearMonth.parse(date);

        String fileName = yearMonth.getYear() + "년_" + yearMonth.getMonthValue() + "월_일별_주문_금액.csv";

        BeanWrapperFieldExtractor<OrderStatistics> fieldExtractor = new BeanWrapperFieldExtractor<>();
        fieldExtractor.setNames(new String[]{"amount", "date"});

        DelimitedLineAggregator<OrderStatistics> lineAggregator = new DelimitedLineAggregator<>();
        lineAggregator.setDelimiter(",");
        lineAggregator.setFieldExtractor(fieldExtractor);

        FlatFileItemWriter<OrderStatistics> itemWriter = new FlatFileItemWriterBuilder<OrderStatistics>()
                .resource(new FileSystemResource("output/" + fileName))
                .lineAggregator(lineAggregator)
                .name(JOB_NAME + "_orderStatisticsItemWriter")
                .encoding("UTF-8")
                .headerCallback(writer -> writer.write("total_amount,date"))
                .build();

        itemWriter.afterPropertiesSet();

        return itemWriter;
    }

    @Bean(JOB_NAME + "_saveUserStep")
    public Step saveUserStep() {
        return this.stepBuilderFactory.get(JOB_NAME + "_saveUserStep")
                .tasklet(new SaveUserTasklet(userRepository))
                .build();
    }

    @Bean(JOB_NAME + "_userLevelUpStep")
    public Step userLevelUpStep() throws Exception {
        return this.stepBuilderFactory.get(JOB_NAME + "_userLevelUpStep")
                .<User, User>chunk(CHUNK_SIZE)
                .reader(itemReader(null, null))
                .processor(itemProcessor())
                .writer(itemWriter())
                .build();
    }

    @Bean(JOB_NAME + "_userLevelUpStep.manager")
    public Step userLevelUpManagerStep() throws Exception {
        return this.stepBuilderFactory.get(JOB_NAME + "_userLevelUpStep.manager")
                .partitioner(JOB_NAME + "_userLevelUpStep", new UserLevelUpPartitioner(userRepository))
                .step(userLevelUpStep())
                .partitionHandler(taskExecutorPartitionHandler())
                .build();
    }

    @Bean(JOB_NAME + "taskExecutorPartitionHandler")
    PartitionHandler taskExecutorPartitionHandler() throws Exception {
        TaskExecutorPartitionHandler handler = new TaskExecutorPartitionHandler();
        handler.setStep(userLevelUpStep());
        handler.setTaskExecutor(this.taskExecutor);
        handler.setGridSize(8);

        return handler;
    }

    private ItemWriter<? super User> itemWriter() {
        return users -> users.forEach(x -> {
                x.levelUp();
                userRepository.save(x);
        });
    }

    private ItemProcessor<? super User, ? extends User> itemProcessor() {
        return user -> {
            if (user.availableLeveUp()) {
                return user;
            }

            return null;
        };
    }

    @Bean
    @StepScope //StepScope가 proxy로 설정되어있기 때문에 어떤 클래스를 리턴해줘야되는지 명확해야 한다.
    JpaPagingItemReader<? extends User> itemReader(@Value("#{stepExecutionContext[minId]}") Long minId,
                                          @Value("#{stepExecutionContext[maxId]}") Long maxId) throws Exception {

        Map<String, Object> parameters = new HashMap<>();
        parameters.put("minId", minId);
        parameters.put("maxId", maxId);

        JpaPagingItemReader<User> itemReader = new JpaPagingItemReaderBuilder<User>()
                .queryString("select u from User u where u.id between :minId and :maxId")
                .parameterValues(parameters)
                .entityManagerFactory(entityManagerFactory)
                .pageSize(CHUNK_SIZE)
                .name(JOB_NAME + "_userItemReader")
                .build();

        itemReader.afterPropertiesSet();

        return itemReader;
    }
}

작은 값과 큰 값을 구하기 위해 Partitioner를 활용한 UserLevelUpPartitioner를 생성합니다.

public class UserLevelUpPartitioner implements Partitioner {
    private final UserRepository userRepository;

    public UserLevelUpPartitioner(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Override
    public Map<String, ExecutionContext> partition(int gridSize) {
        long minId = userRepository.findMinId(); /* 가장 작은 Id값 (1번) */
        long maxId = userRepository.findMaxId(); /* 가장 큰 Id값 (40,000번) */

        /* 예시 : (40000-1) / 8 + 1 = 5000 */
        long targetSize = (maxId - minId) / gridSize + 1;

        /**
         * 값이 ExecutionContext에 저장
         * partion0 : 1, 5,000
         * partion1 : 5001, 10,000
         * ...
         * partion7 : 35001, 40,000
         */
        Map<String, ExecutionContext> result = new HashMap<>();

        long number = 0;
        long start = minId;
        long end = start + targetSize -1;

        while(start <= maxId) {
            ExecutionContext value = new ExecutionContext();

            result.put("partition" + number, value);

            if (end >= maxId) {
                end = maxId;
            }

            value.putLong("minId", start);
            value.putLong("maxId", end);

            start += targetSize;
            end += targetSize;
            number++;
        }

        return result;
    }
}

Async Step 보다는 빠르지만 Multi-Thread Step 보다 느렸다.

그렇다면 비동기방식과 콜라보로 한 Async + Partition Step는 어떨까?

기존 Partition Step 에서 부분 수정한다.

Async + Partition Step이 Partition Step 보다 느린 성능이 나왔다...

이번엔 ParallelStep로 성능 측정을 알아보자.

@Configuration
@Slf4j
public class ParallelUserConfiguration {

    private final String JOB_NAME = "parallelUserJob";
    public static final int CHUNK_SIZE = 1000;
    private final JobBuilderFactory jobBuilderFactory;
    private final StepBuilderFactory stepBuilderFactory;
    private final UserRepository userRepository;
    private final EntityManagerFactory entityManagerFactory;
    private final DataSource dataSource;
    private final TaskExecutor taskExecutor;

    public ParallelUserConfiguration(JobBuilderFactory jobBuilderFactory, StepBuilderFactory stepBuilderFactory, UserRepository userRepository, EntityManagerFactory entityManagerFactory, DataSource dataSource, TaskExecutor taskExecutor) {
        this.jobBuilderFactory = jobBuilderFactory;
        this.stepBuilderFactory = stepBuilderFactory;
        this.userRepository = userRepository;
        this.entityManagerFactory = entityManagerFactory;
        this.dataSource = dataSource;
        this.taskExecutor = taskExecutor;
    }

    @Bean(JOB_NAME)
    public Job userJob() throws Exception {
        return this.jobBuilderFactory.get(JOB_NAME)
                .incrementer(new RunIdIncrementer())
                .listener(new LevelUpJobExecutionListener(userRepository))
                .start(this.saveUserFlow())
                .next(this.splitFlow(null))
                .build()
                .build();
    }

    @Bean(JOB_NAME + "_saveUserFlow")
    public Flow saveUserFlow() {
        TaskletStep saveUserStep = this.stepBuilderFactory.get(JOB_NAME + "_saveUserStep")
                .tasklet(new SaveUserTasklet(userRepository))
                .build();

        return new FlowBuilder<SimpleFlow>(JOB_NAME + "_saveUserSlow")
                .start(saveUserStep)
                .build();
    }

    @Bean(JOB_NAME + "_splitFlow")
    @JobScope
    public Flow splitFlow(@Value("#{jobParameters[date]}") String date) throws Exception {
        Flow userLevelUpFlow = new FlowBuilder<SimpleFlow>(JOB_NAME + "_userLevelUpFlow")
                .start(userLevelUpStep())
                .build();

        // orderStatisticsFlow을 사용함으로써 아래의 Bean 객체에 등록 할 필요가 없다.
        // step 2개를 하나로 만들기 위해 splitFlow가 userLevelUpFlow와 orderStatisticsFlow를 병렬로 처리함.
        return new FlowBuilder<SimpleFlow>(JOB_NAME + "_splitFlow")
                .split(this.taskExecutor)
                .add(userLevelUpFlow, orderStatisticsFlow(date))
                .build();
    }

    /**
     * @param date
     * @return
     *
     * userJob에 있는 step을 분리하여 Flow에 구현한다.
     */
    private Flow orderStatisticsFlow(String date) throws Exception {
        return new FlowBuilder<SimpleFlow>(JOB_NAME + "_orderStatisticsFlow")
                .start(new JobParameterDecide("date")) // 가져온값이 아래의 CONTINUE인지 체크
                .on(JobParameterDecide.CONTINUE.getName()) // CONTINUE이면 아래의 to메서드 실행
                .to(this.orderStatisticsStep(date))
                .build();
    }

    public Step orderStatisticsStep(@Value("#{jobParameters[date]}") String date) throws Exception {
        return this.stepBuilderFactory.get(JOB_NAME + "_orderStatisticsStep")
                .<OrderStatistics, OrderStatistics>chunk(CHUNK_SIZE)
                .reader(orderStatisticsItemReader(date))
                .writer(orderStatisticsItemWriter(date))
                .build();
    }

    private ItemReader<? extends OrderStatistics> orderStatisticsItemReader(String date) throws Exception {
        YearMonth yearMonth = YearMonth.parse(date);

        Map<String, Object> parameters = new HashMap<>();
        parameters.put("startDate", yearMonth.atDay(1)); // 2021년 8월 1일
        parameters.put("endDate", yearMonth.atEndOfMonth()); // 8월의 마지막 날

        Map<String, Order> sortKey = new HashMap<>();
        sortKey.put("created_date", Order.ASCENDING);

        JdbcPagingItemReader<OrderStatistics> itemReader = new JdbcPagingItemReaderBuilder<OrderStatistics>()
                .dataSource(this.dataSource)
                .rowMapper((resultSet, i) -> OrderStatistics.builder()
                        .amount(resultSet.getString(1))
                        .date(LocalDate.parse(resultSet.getString(2), DateTimeFormatter.ISO_DATE))
                        .build())
                .pageSize(CHUNK_SIZE) // 페이징 설정
                .name(JOB_NAME + "_orderStatisticsItemReader")
                .selectClause("sum(amount), created_date")
                .fromClause("orders")
                .whereClause("created_date >= :startDate and created_date <= :endDate")
                .groupClause("created_date")
                .parameterValues(parameters)
                .sortKeys(sortKey)
                .build();

        itemReader.afterPropertiesSet();

        return itemReader;
    }

    private ItemWriter<? super OrderStatistics> orderStatisticsItemWriter(String date) throws Exception {
        YearMonth yearMonth = YearMonth.parse(date);

        String fileName = yearMonth.getYear() + "년_" + yearMonth.getMonthValue() + "월_일별_주문_금액.csv";

        BeanWrapperFieldExtractor<OrderStatistics> fieldExtractor = new BeanWrapperFieldExtractor<>();
        fieldExtractor.setNames(new String[]{"amount", "date"});

        DelimitedLineAggregator<OrderStatistics> lineAggregator = new DelimitedLineAggregator<>();
        lineAggregator.setDelimiter(",");
        lineAggregator.setFieldExtractor(fieldExtractor);

        FlatFileItemWriter<OrderStatistics> itemWriter = new FlatFileItemWriterBuilder<OrderStatistics>()
                .resource(new FileSystemResource("output/" + fileName))
                .lineAggregator(lineAggregator)
                .name(JOB_NAME + "_orderStatisticsItemWriter")
                .encoding("UTF-8")
                .headerCallback(writer -> writer.write("total_amount,date"))
                .build();

        itemWriter.afterPropertiesSet();

        return itemWriter;
    }

    @Bean(JOB_NAME + "_userLevelUpStep")
    public Step userLevelUpStep() throws Exception {
        return this.stepBuilderFactory.get(JOB_NAME + "_userLevelUpStep")
                .<User, User>chunk(CHUNK_SIZE)
                .reader(itemReader())
                .processor(itemProcessor())
                .writer(itemWriter())
                .build();
    }

    private ItemWriter<? super User> itemWriter() {
        return users -> users.forEach(x -> {
                x.levelUp();
                userRepository.save(x);
        });
    }

    private ItemProcessor<? super User, ? extends User> itemProcessor() {
        return user -> {
            if (user.availableLeveUp()) {
                return user;
            }

            return null;
        };
    }

    private ItemReader<? extends User> itemReader() throws Exception {
        JpaPagingItemReader<User> itemReader = new JpaPagingItemReaderBuilder<User>()
                .queryString("select u from User u")
                .entityManagerFactory(entityManagerFactory)
                .pageSize(CHUNK_SIZE)
                .name(JOB_NAME + "_userItemReader")
                .build();

        itemReader.afterPropertiesSet();

        return itemReader;
    }
}

Parallel Step은 오히려 현저하게 느려짐을 발견했다.

끝으로 Partition + Parallel Step 테스트를 진행해 본다.

Parallel Step 에서 부분 수정 (비동기 개선, JpaPagingItemReader 리턴)

위와같이 진행하지않고 ItemReader로만 선언하게되면 아래와 같은 에러를 발견할 수 있다.

ItemReader -> JpaPagingItemReader로 리턴하면 문제 되지 않는다.

Parallel Step보다 Partition + Parallel Step가 훨씬 속도가 개선되었다. 전체 순위에서 2위.

하지만 멀티쓰레드 스텝을 쫓아갈 순 없었다.

* PC마다, 요구사항 환경마다 속도는 각각 다를 수 있다.

여러가지 경험을 해봐야 다양한 케이스로 생각을 해볼 수 있어서 좋은 경험이었다.

[SPRING] 주문금액 집계 프로젝트 실습 part2

prodo-developer — Wed, 4 Aug 2021 22:40:24 +0900

part1에서 진행했던 내용을 기반으로 이어서 진행한다.

● User의 totalAmount를 Orders Entity로 변경

하나의 User는 N개의 Orders를 포함

● 주문 총 금액은 Orders Entity를 기준으로 합산

● `-date=2021-08` JobParameters 사용

주문 금액 집계는 orderStatisticsStep으로 생성

■ `2021년_08월_주문_금액.csv` 파일은 2021년 8월1일~8월31일 주문 통계 내역

`date` 파라미터가 없는 경우, orderStatisticsStep은 실행하지 않는다.

user 한명이 orders의 여러개를 만들 수 있도록 일대다 구조로 만들 수 있게 엔티티를 수정한다.

1. Orders 추가

@Entity
@Getter
@NoArgsConstructor
public class Orders {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String itemName;

    private int amount;

    private LocalDate createdDate;

    @Builder
    public Orders(String itemName, int amount, LocalDate createdDate) {
        this.itemName = itemName;
        this.amount = amount;
        this.createdDate = createdDate;
    }
}

2. User 일대다 구조로 수정

@Getter
@Entity
@NoArgsConstructor
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String username;

    @Enumerated(EnumType.STRING)
    private Level level = Level.NORMAL;

//    private int totalAmount;
    /**
     * 1:N 관계
     * user는 n개의 Orders를 가질 수 있다.
     * user가 저장되면서 Orders를 같이 저장할 수 있도록 영속성 전이(PERSIST)를 적용한다.
    **/
    @OneToMany(cascade = CascadeType.PERSIST)
    @JoinColumn(name = "user_id")
    private List<Orders> orders;

    private LocalDate updatedDate;

    @Builder
    private User(String username, List<Orders> orders) {
        this.username = username;
        this.orders = orders;
    }

    public boolean availableLeveUp() {
        return Level.availableLevelUp(this.getLevel(), this.getTotalAmount());
    }

    private int getTotalAmount() {
        return this.orders.stream()
                .mapToInt(Orders::getAmount)
                .sum();
    }

    public Level levelUp() {
        Level nextLevel = Level.getNextLevel(this.getTotalAmount());
        this.level = nextLevel;
        this.updatedDate = LocalDate.now();

        return nextLevel;
    }
}

3. OrderStatistics (주문금액) 객체를 따로 분리한다.

@Getter
public class OrderStatistics {

    private String amount;

    private LocalDate date;

    @Builder
    public OrderStatistics(String amount, LocalDate date) {
        this.amount = amount;
        this.date = date;
    }
}

4. UserConfiguration에 orderStatisticsStep(주문금액집계)를 추가하여 월 단위 주문 통계 내역을 조회하고 csv파일을 생성한다.

@Configuration
@Slf4j
public class UserConfiguration {

    public static final int CHUNK_SIZE = 100;
    private final JobBuilderFactory jobBuilderFactory;
    private final StepBuilderFactory stepBuilderFactory;
    private final UserRepository userRepository;
    private final EntityManagerFactory entityManagerFactory;
    private final DataSource dataSource;

    public UserConfiguration(JobBuilderFactory jobBuilderFactory, StepBuilderFactory stepBuilderFactory, UserRepository userRepository, EntityManagerFactory entityManagerFactory, DataSource dataSource) {
        this.jobBuilderFactory = jobBuilderFactory;
        this.stepBuilderFactory = stepBuilderFactory;
        this.userRepository = userRepository;
        this.entityManagerFactory = entityManagerFactory;
        this.dataSource = dataSource;
    }

    @Bean
    public Job userJob() throws Exception {
        return this.jobBuilderFactory.get("userJob")
                .incrementer(new RunIdIncrementer())
                .start(this.saveUserStep())
                .next(this.userLevelUpStep())
                .next(this.orderStatisticsStep(null))
                .listener(new LevelUpJobExecutionListener(userRepository))
                .build();
    }

    @Bean
    @JobScope
    public Step orderStatisticsStep(@Value("#{jobParameters[date]}") String date) throws Exception {
        return this.stepBuilderFactory.get("orderStatisticsStep")
                .<OrderStatistics, OrderStatistics>chunk(CHUNK_SIZE)
                .reader(orderStatisticsItemReader(date))
                .writer(orderStatisticsItemWriter(date))
                .build();
    }

    private ItemReader<? extends OrderStatistics> orderStatisticsItemReader(String date) throws Exception {
        YearMonth yearMonth = YearMonth.parse(date);

        Map<String, Object> parameters = new HashMap<>();
        parameters.put("startDate", yearMonth.atDay(1)); // 2021년 8월 1일
        parameters.put("endDate", yearMonth.atEndOfMonth()); // 8월의 마지막 날

        Map<String, Order> sortKey = new HashMap<>();
        sortKey.put("created_date", Order.ASCENDING);

        JdbcPagingItemReader<OrderStatistics> itemReader = new JdbcPagingItemReaderBuilder<OrderStatistics>()
                .dataSource(this.dataSource)
                .rowMapper((resultSet, i) -> OrderStatistics.builder()
                        .amount(resultSet.getString(1))
                        .date(LocalDate.parse(resultSet.getString(2), DateTimeFormatter.ISO_DATE))
                        .build())
                .pageSize(CHUNK_SIZE) // 페이징 설정
                .name("orderStatisticsItemReader")
                .selectClause("sum(amount), created_date")
                .fromClause("orders")
                .whereClause("created_date >= :startDate and created_date <= :endDate")
                .groupClause("created_date")
                .parameterValues(parameters)
                .sortKeys(sortKey)
                .build();

        itemReader.afterPropertiesSet();

        return itemReader;
    }

    private ItemWriter<? super OrderStatistics> orderStatisticsItemWriter(String date) throws Exception {
        YearMonth yearMonth = YearMonth.parse(date);

        String fileName = yearMonth.getYear() + "년_" + yearMonth.getMonthValue() + "월_일별_주문_금액.csv";

        BeanWrapperFieldExtractor<OrderStatistics> fieldExtractor = new BeanWrapperFieldExtractor<>();
        fieldExtractor.setNames(new String[]{"amount", "date"});

        DelimitedLineAggregator<OrderStatistics> lineAggregator = new DelimitedLineAggregator<>();
        lineAggregator.setDelimiter(",");
        lineAggregator.setFieldExtractor(fieldExtractor);

        FlatFileItemWriter<OrderStatistics> itemWriter = new FlatFileItemWriterBuilder<OrderStatistics>()
                .resource(new FileSystemResource("output/" + fileName))
                .lineAggregator(lineAggregator)
                .name("orderStatisticsItemWriter")
                .encoding("UTF-8")
                .headerCallback(writer -> writer.write("total_amount,date"))
                .build();

        itemWriter.afterPropertiesSet();

        return itemWriter;
    }

    @Bean
    public Step saveUserStep() {
        return this.stepBuilderFactory.get("saveUserStep")
                .tasklet(new SaveUserTasklet(userRepository))
                .build();
    }

    @Bean
    public Step userLevelUpStep() throws Exception {
        return this.stepBuilderFactory.get("userLevelUpStep")
                .<User, User>chunk(CHUNK_SIZE)
                .reader(itemReader())
                .processor(itemProcessor())
                .writer(itemWriter())
                .build();
    }

    private ItemWriter<? super User> itemWriter() {
        return users -> users.forEach(x -> {
                x.levelUp();
                userRepository.save(x);
        });
    }

    private ItemProcessor<? super User, ? extends User> itemProcessor() {
        return user -> {
            if (user.availableLeveUp()) {
                return user;
            }

            return null;
        };
    }

    private ItemReader<? extends User> itemReader() throws Exception {
        JpaPagingItemReader<User> itemReader = new JpaPagingItemReaderBuilder<User>()
                .queryString("select u from User u")
                .entityManagerFactory(entityManagerFactory)
                .pageSize(CHUNK_SIZE)
                .name("userItemReader")
                .build();

        itemReader.afterPropertiesSet();

        return itemReader;
    }
}

5. JobExecutionDecider에서 제공하는 주문 금액 집계 step 실행 여부 벨리데이션을 구현한다.

public class JobParameterDecide implements JobExecutionDecider {

    public static final FlowExecutionStatus CONTINUE = new FlowExecutionStatus("CONTINUE");

    private final String key;

    public JobParameterDecide(String key) {
        this.key = key;
    }

    @Override
    public FlowExecutionStatus decide(JobExecution jobExecution, StepExecution stepExecution) {
        String value = jobExecution.getJobParameters().getString(key);

        // key가 없으면
        if(StringUtils.isEmpty(value)) {
            return FlowExecutionStatus.COMPLETED;
        }

        return CONTINUE;
    }
}

* JobExecutionDecider의 인터페이스는 flow결정과_배치실행여부를 결정한다.

6. 5번에서 만든 JobExecutionDecide를 기반으로 step 기능을 추가한다.

* UserConfiguration.java 의 userJob() 영역 step 추가

@Bean
public Job userJob() throws Exception {
	return this.jobBuilderFactory.get("userJob")
		.incrementer(new RunIdIncrementer())
        .start(this.saveUserStep())
        .next(this.userLevelUpStep())
        .listener(new LevelUpJobExecutionListener(userRepository))
        .next(new JobParameterDecide("date")) // 가져온값이 아래의 CONTINUE인지 체크
        .on(JobParameterDecide.CONTINUE.getName()) // CONTINUE이면 아래의 to메서드 실행
        .to(this.orderStatisticsStep(null))
        .build()
        .build();
}

* 결과 값

느낀점 :

1. user가 저장되면서 Orders를 같이 저장할 수 있도록 영속성 전이(PERSIST)를 적용 함으로 써 JPA의 이해를 한번 더 상기 시켰다.

(잊을만 하면 기존에 기록했던 영속성 전이를 다시 보면서 리마인딩 하자)

2. JobExecutionDecider를 통해 배치실행여부를 좀 더 쉽게 확인이 가능한점을 배움.

3. FlatFileItemWriter로 데이터 CSV 파일 쓰기를 통해 보다 편하게 생성할 수 있었다.

학습사이트 : 패스트 캠퍼스 (스프링 배치편)

[SPRING] 주문금액 집계 프로젝트 실습 part1

prodo-developer — Wed, 4 Aug 2021 21:56:08 +0900

JPA를 통한 스프링 배치 실습 프로젝트를 진행하면서 아래의 요구사항이 있다.

● User 등급을 4개로 구분

일반(NORMAL), 실버(SILVER), 골드(GOLD), VIP

● User 등급 상향 조건은 총 주문 금액 기준으로 등급 상향

200,000원 이상인 경우 실버로 상향
300,000원 이상인 경우 골드로 상향
500,000원 이상인 경우 VIP로 상향
등급 하향은 없음

● 총 2개의 Step으로 회원 등급 Job 생성

saveUserStep : User 데이터 저장
userLevelUpStep : User 등급 상향

● JobExecutionListener.afterJob 메소드에서 “총 데이터 처리 {}건, 처리 시간 : {}millis” 와 같은 로그 출력

1. 요구사항에 필요한 User와 Level별 엔티티를 아래와 같이 만든다.

User.java

@Getter
@Entity
@NoArgsConstructor
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String username;

    @Enumerated(EnumType.STRING)
    private Level level = Level.NORMAL;

    private int totalAmount;

    private LocalDateTime updateDate;

    @Builder
    private User(String username, int totalAmount) {
        this.username = username;
        this.totalAmount = totalAmount;
    }

    public boolean availabelLevelUp() {
        return Level.availabelLevelUp(this.getLevel(), this.getTotalAmount());
    }

    public Level levelUp() {
        Level nextLevel = Level.getNextLevel(this.getTotalAmount());
        this.level = nextLevel;
        this.updateDate = LocalDateTime.now();

        return nextLevel;
    }
}

Level.java

public enum Level {
    VIP(500_000, null),
    GOLD(500_000, VIP),
    SILVER(300_000, GOLD),
    NORMAL(200_000, SILVER);

    private final int nextAmount;
    private final Level nextLevel;

    Level(int nextAmount, Level nextLevel) {
        this.nextAmount = nextAmount;
        this.nextLevel = nextLevel;
    }

    public static boolean availabelLevelUp(Level level, int totalAmount) {
        if(Objects.isNull(level)) {
            return false;
        }

        if(Objects.isNull(level.nextLevel)) {
            return false;
        }

        return totalAmount >= level.nextAmount;
    }

    static Level getNextLevel(int totalAmount) {
        if(totalAmount >= Level.VIP.nextAmount) {
            return VIP;
        }

        // GOLD.nextLevel == VIP
        if(totalAmount >= Level.GOLD.nextAmount) {
            return GOLD.nextLevel;
        }

        // SILVER.nextLevel == GOLD
        if(totalAmount >= Level.SILVER.nextAmount) {
            return SILVER.nextLevel;
        }

        // NORMAL.nextLevel == SILVER
        if(totalAmount >= Level.NORMAL.nextAmount) {
            return NORMAL.nextLevel;
        }

        return NORMAL;
    }
}

2. 100건당 등급 상향조건에 맞는 Tasklet 생성

public class SaveUserTasklet implements Tasklet {

    private final int ZERO = 0;
    private final int SIZE = 100;
    private final UserRepository userRepository;

    public SaveUserTasklet(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Override
    public RepeatStatus execute(StepContribution contribution, ChunkContext chunkContext) throws Exception {
        List<User> users = createUsers();

        Collections.shuffle(users);

        userRepository.saveAll(users);

        return RepeatStatus.FINISHED;
    }

    private List<User> createUsers() {
        List<User> users = new ArrayList<>();

        for (int i = ZERO; i < SIZE; i++) {
            users.add(User.builder()
                    .orders(Collections.singletonList(Orders.builder()
                            .amount(1_000)
                            .createdDate(LocalDate.of(2021,8,1))
                            .itemName("item" +i)
                            .build()))
                    .username("test username" + i)
                    .build());
        }

        // SILVER 등급
       for (int i = ZERO; i < SIZE; i++) {
            users.add(User.builder()
                    .orders(Collections.singletonList(Orders.builder()
                            .amount(200_000)
                            .createdDate(LocalDate.of(2021,9,2))
                            .itemName("item" +i)
                            .build()))
                    .username("test username" + i)
                    .build());
        }

        // GOLD 등급
        for (int i = ZERO; i < SIZE; i++) {
            users.add(User.builder()
                    .orders(Collections.singletonList(Orders.builder()
                            .amount(300_000)
                            .createdDate(LocalDate.of(2021,8,3))
                            .itemName("item" +i)
                            .build()))
                    .username("test username" + i)
                    .build());
        }

        // VIP 등급
        for (int i = ZERO; i < SIZE; i++) {
            users.add(User.builder()
                    .orders(Collections.singletonList(Orders.builder()
                            .amount(500_000)
                            .createdDate(LocalDate.of(2021,8,4))
                            .itemName("item" +i)
                            .build()))
                    .username("test username" + i)
                    .build());
        }

        return users;
    }
}

3. 배치 작업에 필요한 Configuration를 생성합니다.

@Configuration
@Slf4j
public class UserConfiguration {

    private final JobBuilderFactory jobBuilderFactory;
    private final StepBuilderFactory stepBuilderFactory;
    private final UserRepository userRepository;
    private final EntityManagerFactory entityManagerFactory;

    public UserConfiguration(JobBuilderFactory jobBuilderFactory, StepBuilderFactory stepBuilderFactory, UserRepository userRepository, EntityManagerFactory entityManagerFactory) {
        this.jobBuilderFactory = jobBuilderFactory;
        this.stepBuilderFactory = stepBuilderFactory;
        this.userRepository = userRepository;
        this.entityManagerFactory = entityManagerFactory;
    }

    @Bean
    public Job userJob() throws Exception {
        return this.jobBuilderFactory.get("userJob")
                .incrementer(new RunIdIncrementer())
                .start(this.saveUserStep())
                .next(this.userLevelUpStep())
                .listener(new LevelUpJobExecutionListener(userRepository))
                .build();
    }

    @Bean
    public Step saveUserStep() {
        return this.stepBuilderFactory.get("saveUserStep")
                .tasklet(new SaveUserTasklet(userRepository))
                .build();
    }

    @Bean
    public Step userLevelUpStep() throws Exception {
        return this.stepBuilderFactory.get("userLevelUpStep")
                .<User, User>chunk(100)
                .reader(itemReader())
                .processor(itemProcessor())
                .writer(itemWriter())
                .build();
    }

    private ItemWriter<? super User> itemWriter() {
        return users -> users.forEach(x -> {
                x.levelUp();
                userRepository.save(x);
        });
    }

    private ItemProcessor<? super User, ? extends User> itemProcessor() {
        return user -> {
            if (user.availableLeveUp()) {
                return user;
            }

            return null;
        };
    }

    private ItemReader<? extends User> itemReader() throws Exception {
        JpaPagingItemReader<User> itemReader = new JpaPagingItemReaderBuilder<User>()
                .queryString("select u from User u")
                .entityManagerFactory(entityManagerFactory)
                .pageSize(100)
                .name("userItemReader")
                .build();

        itemReader.afterPropertiesSet();

        return itemReader;
    }
}

1. Junit4 실습 위주의 단위 테스트 였으나 요즘 대세인 Junit5기반으로 셋팅을 해보았다.

* 메인메서드 셋팅은 아래와 같이 진행합니다.

* 등급별 자세한 로그를 확인하기 위해 아래와 같이 구현합니다.

@Slf4j
public class LevelUpJobExecutionListener implements JobExecutionListener {

    private final UserRepository userRepository;

    public LevelUpJobExecutionListener(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Override
    public void beforeJob(JobExecution jobExecution) {

    }

    @Override
    public void afterJob(JobExecution jobExecution) {
        Collection<User> users = userRepository.findAllByUpdatedDate(LocalDate.now());

        long time = jobExecution.getEndTime().getTime() - jobExecution.getStartTime().getTime();

        log.info("회원등급 업데이트 배치 프로그램");
        log.info("--------------------------");
        log.info("총 데이터 처리 {}건, 처리 시간 {}mills", users.size(), time);
    }
}

* 결과

느낀점 : step별 배치를 돌리면서 처리되는시간을 통해 좀 더 최적화 할수 있는 방법에 대해 고민하게 된다.