[3회차] Spring Batch 스터디: 후기 및 추가 학습 내용

아래 글은 한국 스프링 사용자 모임(KSUG)에서 진행된 스프링 배치 스터디 내용을 정리한 게시글입니다.
DEVOCEAN에 연재 중인 KIDO님의 글을 메인 교안으로 진행되는 스터디입니다.   [메인 교안 바로 가기]

 

3회차는 SpringBatch ChunkModel과 TaskletModel을 주제로 스터디가 진행 되었습니다.

 

스터디 진행 전 교안을 공부하며 정리한 내용은 이곳에서 볼 수 있습니다.

[3회차] SpringBatch ChunkModel과 TaskletModel

 

 

스터디는 1시간 반 가량 진행 되었고, 스터디 동안 나눴던 얘기들을 조금 정리해 보겠습니다.

 

• Spring Batch Plus (네이버 라이브러리)
  • 코틀린 스타일로 스프링 배치를 사용할 수 있는 네이버에서 만든 라이브러리입니다.
• Tasklet 사용 시점 
  
  • Tasklet 방식은 메서드 개발하듯 하나의 프로세스를 작성하여 호출할 수 있으며, 기존 코드와 쉽게 연동할 수 있습니다.
  • Tasklet은 대용량 데이터 처리에 적합하지 않은데, 그 이유는 Tasklet이 하나의 작업을 처리하고 나면 바로 커밋이 이루어지기 때문입니다. 이로 인해 트랜잭션이 오래 지속될 수 있어 '롱 트랜잭션(long transaction)'이 발생할 수 있습니다. 때문에 현업에서는 대부분 청크 단위로 작업을 하고 Tasklet은 잘 채택하지 않는다고 합니다.
  • 현업에서 사용할 수 있는 곳에는 -- 예를 들어, 매일 데이터를 새로 만드는 작업에서 이전 데이터를 지울 필요가 있을 때 효율적으로 사용하신다고 하셨습니다.
• 롱 트랜잭션
  • 롱 트랜잭션이란, 트랜잭션이 오랫동안 유지되는 상황을 말합니다.
  • 예를 들어, 웹 애플리케이션이 DB에서 데이터를 조회(SELECT)할 때 트랜잭션을 오래 유지하면 사용자가 요청한 트랜잭션이 길어집니다. 이 경우 10개의 커넥션 풀만 사용해도 금방 가득 차고, 다른 요청이 들어오면 무기한 대기 상태가 될 수 있습니다. 그래서 트랜잭션을 짧게 유지하는 '숏 트랜잭션'을 권장합니다.
• 커밋 단위 선정 기준
  • 커밋 단위는 상황에 따라 달라질 수 있으며, 시스템 리소스와 데이터베이스 성능에 따라 결정됩니다. (현업자 분께서는) 일반적으로 DBA에게 문의하여 해당 커밋 단위를 시스템이 감당할 수 있는지 확인하고 진행하신다고 합니다. 서버의 사양에 따라 데이터베이스에 가는 부하도 달라지므로, 성능을 모니터링하며 커밋 단위를 유연하게 조정해 나가는 것이 중요합니다.
• 청크 처리와 롤백
  
  • 청크 단위로 데이터를 읽고 처리한 후, 설정된 commit interval에 따라 커밋이 발생하면 해당 청크는 롤백되지 않고 독립적으로 처리됩니다. 예를 들어, commit interval을 100건으로 설정하고 1000건의 데이터를 처리할 때, 100건씩 청크로 나누어 처리하게 됩니다. 만약 마지막 청크에서 오류가 발생하면, 마지막 청크에 대한 롤백만 이루어지고 이전에 커밋된 900건은 그대로 유지됩니다.
  • 만약 commit interval을 별도로 설정하지 않으면, 기본적으로 각 청크 단위로 커밋이 발생합니다. 이렇게 되면 한 번 커밋된 청크는 롤백되지 않기 때문에, 주의해서 설정하는 것이 중요합니다.

 

---

 

이번 주는 실무에서 어떻게 사용하고 계시는지에 대해 들을 수 있어서 더 흥미로웠습니다.

 

KIDO님께서 다음 주까지 해야할 실습 퀴즈를 준비해 주셨습니다.

문제를 듣자마자 약간 걱정이 되긴 했지만, 열심히 해보겠습니다. 👍