회사에서 데이터를 생성하는 배치를 만들었다.
생성해야 하는 데이터 도메인을 주문이라고 하자.
스프링 배치를 사용한다.
사수 분과 함께 작업했다.
단계(step)을 나누는 방법
처음에 생각했던 스텝는 하나였다.
하나의 스텝에서,
1) csv에서 주문들을(새롭게 생성될 주문) 읽고(reader),
2) 조건에 맞지 않은 주문들을 거르며(processor)
3) 조건에 맞는 주문들을 새롭게 생성한다.(writer)
하지만 이런 구조를 사용하지 않았다.
몇 가지 고려할 점 때문에 사용하지 않았다.
chunk 단위의 롤백 기능을 자유롭게 쓸 상황이 아님
chunk 단위의 롤백 기능을 자유롭게 쓸 수가 없었다.
주문 데이터를 생성하는 부분의 경우, 외부 api 호출을 통한 검증이 통과되어야 생성이 가능했다.
그리고, 주문 데이터 검증이 통과한다면 검증 통과 내역이 외부 시스템 db에 그대로 쌓였다.
따라서 주문 데이터 생성의 트랜잭션의 범위는 외부 시스템을 포함한다.
하지만 스프링 배치의 chunk 트랜잭션은 문제가 생겼을 때 내부 시스템의 롤백만 보장한다. 외부 시스템의 데이터는 스프링 배치가 롤백할 수가 없다.
그렇기에 주문 데이터 생성에 있어서는 chunk단위의 롤백 기능을 활용할 수 없었다.
그러면 스텝 구조를 바꾼다.
단계(step)을 나누는 방법2
스텝을 두 개로 나눈다.
첫 번째 스텝:
1) csv에서 주문들을(새롭게 생성될 주문) 읽고(reader),
2) 조건에 맞지 않은 주문들을 거르며(processor)
3) 조건에 맞는 주문 dto(주문 정보를 담는 객체)들을 새롭게 생성한다.(writer)
두 번째 스텝:
tasklet으로 작성한다.
첫 번째 스텝에서 만든 dto에 담긴 정보들을 바탕으로 주문 데이터들을 생성한다.
여기서 또 한 번 바뀌었다.
기존에 csv를 parsing해 주는 tasklet이 있어서 그걸 사용하기로 했다.
결국 스텝은 세 개가 됐다.
최종적으로 만든 스텝 구조
첫 번째 스텝:
tasklet으로 작성한다.
csv에서 정보들을 읽고 그 정보들을 container라는 객체에 담는다.
두 번째 스텝:
chunk를 사용한다.
1) 첫 번째 컨테이너에서 발 읽고(reader),
2) 조건에 맞지 않은 주문들을 거르며(processor)
3) 조건에 맞는 주문 dto(주문 정보를 담는 객체)들을 새롭게 생성한다.(writer)
세 번째 스텝:
tasklet으로 작성한다.
두 번째 스텝에서 만든 dto에 담긴 정보들을 바탕으로 주문 데이터들을 생성한다.
--
위와 같이 스텝을 먼저 만들어서, 필요한 세부 사항을 구현했다.
테스트도 작성했다.
직접 csv를 만들어 수동 테스트를 진행했다.
데이터 수가 크지 않지만, 몇 건의 데이터로 실험한 결과 배치는 의도대로 작동했다.
더 잘하려면
-
외부 시스템과 데이터가 연동해서 트랜잭션을 적용하는 경우, spring batch의 chunk 기능을 쓸 수 없다는 점을 외운다.
-
꼭 chunk 기능을 사용해야 한다면, 롤백 기능을 끄고 사용한다.
