스프링 배치를 사용하면서 겪은 것들

먼저 스프링 배치가 어떻게 동작하는지 간단하게 알아보자.

 

 

🍀 스프링 배치는 어떻게 동작할까요?

스프링 배치는 Job 단위로 실행됩니다. 하나의 Job은 여러 Step으로 나눌 수 있다.

 

실행하면서 Spring Batch 내부의 Job Repository를 통해 계속해서 Job과 Step의 정보를 아래의 순서대로 메타 테이블에 저장한다. 참고로 메타 정보는 배치 수행과 관련된 수치(시작/종료 시간, 상태, 횟수)와 Job, Step에서 공유해서 쓰는 컨텍스트등을 포함한다.

• BATCH_JOB_INSTANCE :  JOB 인스턴스 정보 - Job 이름, Job 고유 키
• BATCH_JOB_EXECUTION :  JOB 실행정보 - job_instance_id, 상태, 시작시간, 종료시간, job 에러정보 
• BATCH_JOB_EXECUTION_PARAM :  사용된 Job Parameter 정보
• BATCH_JOB_EXECUTION_CONTEXT :  사용된 Job Execution Context 객체  (직렬화되어 DB에도 저장) 
• BATCH_STEP_EXECUTION :  STEP 실행정보 - job_execution_id, 데이터 read, commit, filter, skip count, step 에러정보
• BATCH_STEP_EXECUTIOIN_CONTEXT : 사용된 Step Execution Context 객체 (직렬화되어 DB에도 저장)

 

 

 

 

🍀 스프링 배치의 트랜잭션은 어떻게 걸릴까요?

 

위 그림에서 트랜잭션 부분을 확대해보면 아래와 같다. 참고로 Reader에서 DB를 사용하지 않더라도 spring batch 메타 데이터를 갱신하면서 바로 DB 트랜잭션이 시작됨을 유의하자. 

Chunk 단위로 트랜잭션이 반복된다.

참고로 이는 ChunkOrientedTasklet 를 디버깅으로 추적해보면 코드로도 확인할 수 있다.

정확히는 TaskletStep 에서 작업할 때 마다 StepExecution이 업데이트 되고 이는 청크 단위로 JobRepository에 의해 DB에 저장됩니다.

 

 

 

🤔 스프링 배치는 왜 이렇게 트랜잭션을 길게 잡을까요?

물론 단순히 트랜잭션을 청크단위로 걸면 깔끔하니까 그런 것도 있겠지만

• SpringBatch는 청크가 실행 될 때 마다 StepExecution 객체 업데이트, 청크가 끝나는 시점에 DB에 저장한다. 이는 배치 작업의 추적과 오류 발생시 재시작을 위해 사용된다.
• 복잡한 배치 작업에 TransactionCallback을 사용 시 데드락이 걸리는 이슈가 있어서 청크단위로 트랜잭션을 잡은거기도 하다.

 

 

 

1️⃣ TransactionSystemException (Transaction Session Timeout)

사내에서 배치를 잘 사용하고 있었는데, 코드를 변경하지 않았는데도 특정 시점 이후부터 아래 에러가 종종 발생하였었다.

org.springframework.transaction.TransactionSystemException: Could not roll back JPA transaction; nested exception is org.hibernate.TransactionException: Unable to rollback against JDBC Connection
	at org.springframework.orm.jpa.JpaTransactionManager.doRollback(JpaTransactionManager.java:593)
	at org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:835)
	at org.springframework.transaction.support.AbstractPlatformTransactionManager.rollback(AbstractPlatformTransactionManager.java:809)
	at org.springframework.transaction.support.TransactionTemplate.rollbackOnException(TransactionTemplate.java:168)
	at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:144)
	...

 

데이터를 API로 받아와서 전처리하는 배치였는데 Reader와 Processor에서는 DB 를 사용하지 않는 코드였다.

Writer 또한 단순 전처리완료된 데이터를 Save하는 단순한 쿼리라 더더욱 이해가 안되는 상황이었다.

/** 예시입니다. **/
@Bean
fun JiwonCollectDataJob(
    jiwonStep: Step,
): Job {
    return jobBuilderFactory.get(JIWON_JOB_NAME)
        .start(jiwonStep)
        .incrementer(RunIdIncrementer())
        .listener(JobResultListener())
        .build()
}

@Bean
fun JiwonStep(
    jiwonItemReader: JiwonItemReader,
    jiwonItemProcessor: ItemProcessor<List<CollectData>, List<MyEntity>>,
    jiwonItemWriter: ItemWriter<List<MyEntity>>,
): Step {
    // Reader(웹사이트 API) - Processor(복잡한 데이터 전처리) - Writer(단순 DB 저장)
    return stepBuilderFactory[JIWON_STEP_NAME]
        .chunk<List<ParseData>, List<Entity>>(chunkSize)
        .reader(jiwonItemReader)
        .processor(jiwonItemProcessor)
        .writer(jiwonItemWriter)
        .transactionManager(mainDbTransactionManager)
        .build()
}

 

 

 

🤔 왜 Transaction Timeout이 발생했는가?

결론부터 말하자면 Hikari Connection 객체는 살아있는데 db session timeout 을 초과했기 때문이다. 

// 관련된 로그 (Spring, db, HikariCP)
org.springframework.transaction.TransactionSystemException: Could not roll back JPA transaction; nested exception is org.hibernate.TransactionException: Unable to rollback against JDBC Connection
FATAL: terminating connection due to idle-in-transaction timeout
HikariCP-Writer - Connection org.postgresql.jdbc.PgConnection@2d0ea3a9 marked as broken because of SQLSTATE(08006), ErrorCode(0) // 08006은 커넥션 풀이 사용하고있는 커넥션이 중단되었거나 문제임을 나타냄.

PostgreSql, MySql 에서 각각 timeout 시간을 위와 같이 확인할 수 있다. // aws rds를 사용중이라면 파라미터 그룹에서도 확인할 수 있다.

 

Reader에서 DB를 사용하지 않았다고하더라도, 청크가 시작되는 시점에 step_execution을 업데이트하면서 db를 사용한다. 그리고 Writer가 동작하기전까지 DB를 사용하지않는데, 그 시간이 위 timeout (60초)를 초과했을 때만 간헐적으로 발생했던 것이었다.

1. chunk 단위 작업 시작 시, 트랜잭션 생성으로 인해 HikariCP 에서 커넥션을 획득합니다.
2. 커넥션을 이미 받았더라도 쿼리를 실행하지 않으면 DB에 요청을 보내지 않습니다.
3. 즉 DB 입장에서는 connection이 유후 상태입니다. idle_in_transaction_session_timeout (60초)가 지나면 커넥션이 끊깁니다.
4. 신나게 Reader와 Processor가 동작합니다. 처리할 데이터가 많아서 60초를 지나버립니다. 이 때 HikariCP 커넥션은 살아있지만, DB 커넥션은 이미 끊긴상태입니다.
5. 이후 writer에서 작업을 하든, spring batch에서 stepExecution을 저장하려고 하든 커넥션이 끊겨버렸기 때문에 아무것도 안됩니다.



 

🫠 어떻게 해결하지? - ResourcelessTransactionManager

• 단순하게 idle-transaction-session-timeout을 무작정 늘리는 방법도 있겠지만 이는 DB에 부담을 줄 수 있다.
• session이 끊기지 않도록 계속해서 쿼리를 날려주는 방법도 있겠지만 불필요한 쿼리를 생성해야하고 세션 자체의 누수 위험이 있다.
  -> 왜 HikariCP는 커넥션(세션) 갱신 기능을 절대 만들어주지 않을까?

 

다행히도 이런 경우를 위해 Spring Batch에선 ResourcelessTransactionManager 라는걸 따로 제공한다.

@Bean
public Step step() throws Exception {
    return stepBuilderFactory.get("myStep")
            .<ParseData, Item>chunk(chunkSize)
            .reader(reader())
            .processor(processor())
            .writer(writer())
            .transactionManager(new ResourcelessTransactionManager()) // No Transaction
            .build();
}

 

쉽게말하면 SpringBatch에서 필요없는 트랜잭션을 걸지않고 StepExceution과 같은 메타 정보를 테이블에 저장하지 않는다.
(수정) JobRepository로 메타정보는 저장한다. 청크단위로 트랜잭션만 걸지 않을 뿐이다. ResourceLessTxManager 코드를 열어보면 이해가 쉬울텐데, 그냥 동작하는 척하는 간단한 코드로 구성되어있다.

즉 동작에는 변함이 없는데 단지 [청크단위 트랜잭션]이 없을 뿐이다. 배치가 아닌 일반코드에서 Repository를 사용하는 것과 동일

물론 만능은 아니고 아래와 같은 상황에서 유용하게 사용할 수 있다. 당연한거지만 Reader에서 내 코드로 커넥션을 직접 열고 안쓰다가 Writer에서 재사용하면 처음과 동일하게 timeout이 발생할 수 있다.

• Reader 에서만 DB를 사용하고 Writer에서 사용하지 않는 경우 (세션이 닫혀도 직접 쿼리를 날리지 않으니 아무 문제 없다.)
• Writer 에서만 DB를 사용하고 Reader에서 사용하지 않는 경우 (세션 자체가 writer 시점에 열린다.)

https://kwonnam.pe.kr/wiki/springframework/batch

 

 

 

 

 

2️⃣ 가능하면 JPA 영속성 컨텍스트를 사용하지 말자.

배치작업을 하면서 별 생각없이 이미 만들어진 Domain 코드의 JpaRepository를 이용하거나 삭제 작업등에는 JpaCursorItemReader등을 활용하곤 했었다. 처음에는 아무 문제 없었지만 작업량이 커지니 사용자가 많이 없는데도 DB CPU 사용률이 높다는 알람을 받게 된다.

 

 

배치작업의 특성상 ChunkSize 만큼 I/O가 발생하게된다. JPA는 더티체킹으로 업데이트를 진행하기 때문에 단건으로조회해서 Writer가 진행된다. 즉 갯수만큼 select 요청을 db에 날리게 된다는 말

 

이를 해결하는건 간단했었다. JdbcReader를 사용하거나 Projections 을 이용해서 JPA 영속성 컨텍스트를 거치지않고 바로 업데이트하도록 코드를 변경하니 쉽게 해결되었다. 또 JPA를 사용하지 않으니 쿼리로 update .. where in (ids) 와 같이 최적화 할 수 있는 부분이 있는건 덤

• update 작업 자체가 많아서 변경이 힘들다면 DB I/O 작업을 묶어서 처리하는 jdbc executeBatch를 활용할 수도 있다.
• 그 외 https://tech.kakaopay.com/post/ifkakao2022-batch-performance-read/ 같은 배치 성능 튜닝을 같이 참고하자.

https://tech.kakaopay.com/post/spring-batch-performance/

 

 

 

 

3️⃣ Domain 로직이나 변하는 값(time, option)은 배치에서 분리하자.

예를 들어 매달 1일에 실행하도록 만드는 배치라서 LocalDateTime.now() 같이 코드에 박아서 사용할 수 있는데, 그러지 않는걸 권장한다.

• 서버시간이나 실행환경에 따라 값이 달라질 수 있다.
• 당장은 매달 1일만 실행할 것 같지만, 상황에 따라 (혹은 배치가 실패해서) 다른 날짜에 실행할 수도 있다.
• 옵션값이 변경되면 배치를 새로 배포해야한다.

코드에서 바로 구할 수 있더라도 위와 같은걸 고려해서 JobParameters 으로 받아서 사용하자.

@Value("#{jobParameters[batchDate]}") batchDate: String,
@Value("#{jobParameters[apiKey]}") apiKey: String

 

같은 맥락으로 굳이 필요하지 않다면 Batch에서 가능하면 Domain에 구현된 코드를 사용하지 않고 별도의 모듈로 분리하기를 권장한다.  두 개의 변경 시점이 다른데 배포를 같이해야해서 애매해지기도 하고 도메인에서 분리함으로서 불필요한 과정을 줄이고 쿼리를 직접 최적화 할 수 있다.

https://techblog.woowahan.com/2637/

 

 

 

 

4️⃣ Update, Delete 배치작업시 데이터가 누락되지 않게 주의하자

정말 간단한건데 Update, Delete 배치 작업의 경우 페이징이 깨진다는 걸 절대 잊지말자. 별거 아닌데 막상 돌려보면 잘 돌아가는 것 같이 보이기 때문에 모르고 있으면 정말 찾기 힘들다 🥲

• pagingReader로 10개를 읽어옴
• read 10개 -> writer 10 개
• writer 10개를 했기 때문에 중간에 몇 개를 건너뛰고 다음 페이지가 반환됨



제일 편한 해결 방법은 CursorReader로 읽어들이거나, 그게 어렵다면 아래와 같이 pageSize=0으로 고정해서 읽으면 된다.

단 pageSize 를 고정한 경우 모든 아이템이 완료되지 않는다면 배치가 끊나지 않는 다는걸 명심하자.

@Bean
@StepScope
public ItemReader<Order> itemReader() {
    MyBatisPagingItemReader<Order> itemReader = new MyBatisPagingItemReader<Order>() {
        @Override
        public int getPage() {
            return 0;
        }
    };
    itemReader.setQueryId("query-name");
    itemReader.setPageSize(PAGE_SIZE);
    itemReader.setSqlSessionFactory(sqlSessionFactory);
    return itemReader;
}

// Kotlin이면 이렇게.
val reader: JpaPagingItemReader<Group> = object : JpaPagingItemReader<Group>() {
    override fun getPage(): Int {
        return 0
    }
}.apply {
    pageSize = batchPageSize
    setName("reader")
    setEntityManagerFactory(entityManagerFactory)
    setQueryString( "SELECT * FROM Group")
}

 

 

 

 

📚 레퍼런스

https://jojoldu.tistory.com/526

https://kwonnam.pe.kr/wiki/springframework/batch

https://pkgonan.github.io/2018/04/HikariCP-test-while-idle

https://kakaocommerce.tistory.com/45

https://devocean.sk.com/blog/techBoardDetail.do?ID=164123

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%EB%B0%B0%EC%B9%98/dashboard

스프링 배치 강의 - 인프런