TIL-20220203~04

2022. 02. 04.

02.03

인턴1

배치

테스트

배치 테스트 어떻게 하는게 좋을까. SpringBatchTest 어노테이션이 있지만 사용하기가 쉽지 않다. 의존성이 꼬이는데 방법을 찾기 힘들다. 가장 큰 문제는 exclude가 제대로 동작하지 않는 다는 것... 여유가 있다면 이것 저것 하면서 세팅을 잡아가겠지만 일단은 스프링 부트 테스트로 잡아가기로 했다.

가장 애 먹었던 부분은 스케줄러를 어떻게 중지시킬지였는데, 테스트를 실행하면서 빈 등록을 해제하거나 할 수 있지만 컨텍스트가 시작된 이후이기 때문에 최초 한 번은 실행이 된다. 만약 안 된다면 운이 좋은 케이스인 것이다. 목업 객체를 이용해볼 수도 있겠지만, 좋아보이진 않는다. 빈을 모킹해야 하기 때문에 매번 등록을 해줘야 할거니까.

결국 프로필을 이용해 해결했다. 지금은 가장 좋아보인다. 향후에도 계속 사용될테고

여러개 읽고 쓰기?

ItemReader 하나에 여러번의 Writer가 필요한 상황이다. 책에서 CompositeWriter를 찾았지만 결국 매핑이 달라져야 하기 때문에 문제가 있다.

다른 팀원분께 조언을 구했는데, 일정이 빡빡하니 우선 안전하고 쉬운 방법으로 갈 것 같다. 그리고 데이터가 그리 많지 않으면 크게 고려하지 않아도 될 것 같다는 것이 결론이었다. 만약 직접 개발한다면 배치보다는 이벤트를 사용할 것 같다는데, 앞으로는 MSA와 이벤트를 중심으로 공부해봐야겠다.

내일은 여러개를 Read해와야 하는 상황이다. 잘 헤쳐나가보자

02.04

인턴2

배치2

쿼리보관

쿼리 보관에 대한 고민이 있었다. 따로 클래스를 파서 상수로 만들었는데, 쿼리 테스트하기가 어려워서였다. 처음에는 ItemReader를 따로 불러보려고 했는데, 설정할 것도 많고 Job 인스턴스가 존재해야 한다. 쿼리를 따로 보관해두면 단위테스트하기가 편하다. 확장성을 고려하면 메소드를 만드는게 좋겠지만 지금은 쿼리 저장에만 의의를 두기로 했다. 메소드로 빼는 것 보다 그루비나 코틀린으로 보관하는게 좋을 것 같다. 아니면 15이상으로 버전업을 하는 방법도 ㅎㅎ..

JpaPagingItemReader 읽었던 테이블에 다시 쓰기

읽었던 테이블에 다시 쓰면 인덱스가 달라져서 제대로 읽어지지가 않는다. 청크 사이즈가 10이라고 했을 때, 1에서 10까지 읽어와서 업데이트를 하면 다음 참조에서 11~20까지 읽어야 하지만 업데이트된 것을 다시 읽어버린다. 아마 밀려나는 식으로 동작이 되는 것 같다. 그래서 절반만 읽어진다. 데이터가 1000개고 청크 100에 fetch200으로 두면 600까지만 읽어진다.

0~200(업데이트) -> 0~200(이전 쿼리와 같아서 업데이트 일어나지 않음) -> 200~400 -> 200~400 -> 400~600

이렇게 되는 것 같다. 200개씩 총 1000번을 읽었지만, 600까지 도달한 것이다. JPA뿐만 아니라 JDBC도 동일한 문제가 생기는 것 같은데 이유를 다시 찾아봐야겠다.

해결법으로 페이징을 오버라이딩 하거나 커서를 사용하는 방법이 있는데, 스프링 배치 4.3부터 JPA도 Cursor 방식을 사용할 수 있다.

정대화
DaeHwa_Jeong@outlook.com

Powered with by Gatsby 2.0