웹 애플리케이션을 개발하다보면 통합 테스트 보다, 단위 테스트가 훨씬 더 많이 작성됩니다. 단위 테스트로 많은 코드를 검증 후, 통합 테스트 코드를 통해 각 단위가 합쳐졌을때 잘 작동 되는지 검증하곤 하는데요. 스프링 배치를 이용한 배치 애플리케이션에서는 많은 분들이 통합 테스트만 작성할때가 많습니다. 전편에서 말씀드린것처럼 스프링 배치의 단위 테스트 작성이 통합 테스트 보다 복잡하기 때문입니다. 그래서 이번 챕터에서는 다음의 질문들에 대해 이야기해볼까 합니다. Reader의 쿼리가 잘 작동되었는지는 어떻게 확인하지? StepScope를 통한 JobParameter가 잘 할당 된다는 것은 어떻게 확인하지? 부분 부분을 잘개 쪼개서 테스트할 수 있는 방법들을 소개드리겠습니다Reader의 단위 테스트는 다음..

배치 애플리케이션이 웹 애플리케이션 보다 어려운 점을 꼽자면 QA를 많이들 얘기합니다. 일반적으로 웹 애플리케이션의 경우 전문 테스터 분들 혹은 QA 분들이 전체 기능을 검증을 해주시는 반면, 배치 애플리케이션의 경우 DB의 최종상태라던가 메세징큐의 발행내역 등 개발자들이 직접 확인해주는 것 외에는 검증 하기가 쉽진 않습니다. (별도의 어드민을 제공하는것도 포함입니다.) 더군다나 개발자가 로컬 환경에서 배치 애플리케이션을 수행하는 것도 많은 수작업이 필요합니다. 수정/삭제 등의 배치 애플리케이션이라면 한번 수행할때마다 로컬 DB의 데이터를 원복하고 다시 수행하는 작업을 반복해야 합니다. 이러다보니 당연하게 테스트 코드의 필요성이 많이 강조됩니다. 다행이라면 배치 애플리케이션은 웹 애플리케이션 보다 테스트..

프로그래밍에서 자주 사용되는 단어 중에 멱등성 이 있습니다. 이 멱등성을 한마디로 정의 하면 연산을 여러번 적용하더라도 결과가 달라지지 않는 성질 입니다. 참고: idempotent-rest-apis Spring Batch에서도 역시 이런 멱등성이 필요한 경우가 있습니다. 예를 들어 Spring Batch를 사용하다보면 동적으로 변하는 날짜가 필요한 경우가 있습니다. 대표적으로 다음과 같은 경우들 입니다. 매일 한번 어제 매출 데이터를 집계해야할 때 현재 시간을 기준으로 유효기간이 만료된 포인트를 정리할 때 매일 한번 오늘을 기준으로 휴면회원 처리를 할 때 등등 실행되는 시간을 기준으로 데이터를 조회하고 처리해야할 경우들입니다. 이럴때 가장 흔하게 사용되는 방법이 LocalDate.now() 혹은 Loc..

젠킨스의 경우 스프링 배치의 스케줄러로 많이 사용 됩니다. 다만, 공통 설정을 어떻게 해야할지 고민될 때가 많습니다. 이럴 경우 젠킨스의 Environment variables (환경 변수) 가 아주 유용합니다. 이번 시간에는 젠킨스의 Environment variables를 통해 스프링 배치의 공통 설정들을 관리해보겠습니다. 본문을 보시고 좀 더 좋은 방법이 있으시면 댓글 부탁드리겠습니다! 1. 기존 상황 젠킨스에서 스프링 배치를 사용하다보면 다음과 같은 상황을 자주 목격합니다. java -jar \ -XX:+UseG1GC \ -Dspring.profiles.active=real \ 배치jar \ --job.name=스프링배치Job이름 \ 파라미터1=파라미터값1 \ 파라미터2=파라미터값2 -XX:+Us..

안녕하세요? 이번 시간엔 Spring batch에서 N+1 문제 해결을 진행해보려고 합니다. 모든 코드는 Github에 있기 때문에 함께 보시면 더 이해하기 쉬우실 것 같습니다. (공부한 내용을 정리하는 Github와 세미나+책 후기를 정리하는 Github, 이 모든 내용을 담고 있는 블로그가 있습니다. ) 1. 테스트 환경 프로젝트는 SpringBoot Batch + Lombok + Spock으로 구성됩니다. 스프링부트의 버전은 2.1.3 입니다. 해당 기술들이 처음이셔도 기존에 사용되던 기술과 크게 다르지 않기 때문에 보시는데 어려움이 없으실 것 같습니다. 다음은 기본적인 Entity와 Repository를 생성하겠습니다. 엔티티는 총 4개로 구성됩니다. 3개의 엔티티의 코드는 다음과 같습니다. (굳..

7,8 장에서는 Chunk 지향 처리에서의 데이터 읽기와 쓰기 부분을 소개 드렸습니다. 이번 챕터에서는 읽기와 쓰기가 아닌, 가공 (혹은 처리) 단계를 소개드리겠습니다. 바로 ItemProcessor입니다. 여기서 한가지 드리고 싶은 말씀은 ItemProcessor는 필수가 아니라는 점입니다. ItemProcessor는 데이터를 가공하거나 필터링하는 역할을 합니다. 이는 Writer 부분에서도 충분히 구현 가능합니다. 그럼에도 ItemProcessor를 쓰는 것은 Reader, Writer 와는 별도의 단계로 분리되었기 때문에 비지니스 코드가 섞이는 것을 방지해주기 때문입니다. 그래서 일반적으로 배치 어플리케이션에서 비즈니스 로직을 추가할때는 가장 먼저 Processor를 고려해보시는 것을 추천드립니다...

앞 시간에 Reader에 대해서 배웠습니다. Writer는 Reader, Prcessor와 함께 ChunkOrientedTasklet을 구성하는 3 요소입니다. 여기서 Processor가 아닌 Writer를 우선 선택한 이유는 Processor는 선택이기 때문입니다. Processor는 없어도 ChunkOrientedTasklet는 구성할 수 있습니다. 반면 Reader와 Writer는 ChunkOrientedTasklet에서 필수 요소입니다. 그래서 Writer를 먼저 다뤄보겠습니다. 8-1. ItemWriter 소개 ItemWriter는 Spring Batch에서 사용하는 출력 기능입니다. Spring Batch가 처음 나왔을 때, ItemWriter는 ItemReader와 마찬가지로 item을 하나..

안녕하세요. 이번 시간에는 Spring Batch를 사용하시는 분들이 자주 묻는 질문 중 하나인 같은 조건의 데이터를 읽고 수정할때 어떻게 해야하는지 에 대해서 소개드리려고 합니다. 모든 코드는 Github에 있으니 참고하시면 됩니다. 문제 상황 예를 들어 아래와 같은 문제가 있다고 가정하겠습니다. pay라는 테이블에 successStatus가 false인 데이터를 모두 가져와 true로 변환해야 한다고 보겠습니다. 샘플로 사용할 Pay Entity는 다음과 같습니다. import lombok.AccessLevel; import lombok.Getter; import lombok.NoArgsConstructor; import javax.persistence.Entity; import javax.persi..

앞의 과정들을 통해 Spring Batch가 Chunk 지향 처리를 하고 있으며 이를 Job과 Step으로 구성되어 있음을 배웠습니다. Step은 Tasklet 단위로 처리되고, Tasklet 중에서 ChunkOrientedTasklet을 통해 Chunk를 처리하며 이를 구성하는 3 요소로 ItemReader, ItemWriter, ItemProcessor가 있음을 배웠습니다. 즉, ItemReader & ItemWriter & ItemProcessor의 묶음 역시 Tasklet이란 이야기입니다. 이들의 묶음을 ChunkOrientedTasklet에서 관리하기 때문이죠. 이번 시간부터 이 3 요소를 차근차근 배워보겠습니다. 7-1. ItemReader 소개 Spring Batch의 Chunk Taskle..

Spring Batch의 큰 장점 중 하나로 Chunk 지향 처리를 얘기합니다. 이번 시간에는 Chunk 지향 처리가 무엇인지 한번 살펴보겠습니다. 6-1. Chunk? Spring Batch에서의 Chunk란 데이터 덩어리로 작업 할 때 각 커밋 사이에 처리되는 row 수를 얘기합니다. 즉, Chunk 지향 처리란 한 번에 하나씩 데이터를 읽어 Chunk라는 덩어리를 만든 뒤, Chunk 단위로 트랜잭션을 다루는 것을 의미합니다. 여기서 트랜잭션이라는게 중요한데요. Chunk 단위로 트랜잭션을 수행하기 때문에 실패할 경우엔 해당 Chunk 만큼만 롤백이 되고, 이전에 커밋된 트랜잭션 범위까지는 반영이 된다는 것입니다. Chunk 지향 처리가 결국 Chunk 단위로 데이터를 처리한다는 의미이기 때문에 그..