배치 애플리케이션이란?
- 일정 주기로 실행해야 할 때
- 실시간 처리가 어려운 다량의 데이터를 처리해야 할 때
→ 이런 작업을 하나의 애플리케이션에서 수행하면 성능 저하를 유발할 수 있으니 배치 애플리케이션을 구현한다.
배치 애플리케이션의 조건
- 대용량 데이터 : 배치 어플리에키션은 대량의 데이터를 가져오거나, 전달하거나, 계산하는 등의 처리를 할 수 있어야 한다.
- 자동화 : 배치 애플리케이션은 심각한 문제 해결을 제외하고는 사용자 개입없이 실행되어야 한다.
- 견고성 : 배치 애플리케이션은 잘못된 데이털르 충돌/중단 없이 처리할 수 있어야 한다.
- 신뢰성 : 배치 애플리케이션은 무엇이 잘못되었는지를 추적할 수 있어야한다. (로깅, 알림)
- 성능 : 배치 애플리케이션은 지정한 시간 안에 처리를 완료하거나 동시에 실행되는 다른 애플리케이션을 방해하지 않도록 수행되어야한다.
배치와 스케쥴러의 차이
스케쥴링이란?
매시간 혹은 지정한 시간에 지정한 동작을 수행하는 것
Spring Batch vs Quartz
- 배치 애플리케이션의 절대적인 목적은 대용량 데이터 처리.
- 배치 프레임워크에서 스케쥴링 기능을 제공하지 않는다.
- 스케쥴링 프레임워크는 배치를 도와주는 보완제 역할.
Spring Batch와 Spring JPA Querydsl의 bulk 연산차이
Spring Batch의 bulk 연산
- chunk지향 처리방식을 사용하며, 데이터를 여러 개의 작은 chunk로 분할하고, 각 chunk를 병렬로 처리한다.
- 이를 통해 대규모 데이터를 빠르게 처리하고, 자원 사용을 최적화할 수 있다.
Spring JPA Querydsl의 bulk연산
- Spring JPA Querydsl에서는 원래 JPA에서 bulk 연산을 할 때, JPQL이나 Criteria API를 사용하여 일괄 업데이트 및 삭제 작업을 수행하는데, 이를 type-safe하게 작성할 수 있도록 도와준다.
- 그러나 Spring Batch만큼 확장성과 성능에 뛰어나지 않다.
그래서 뭘 사용하라구?
그래서 결론적으로 대규모 데이터 처리에는 Spring Batch의 bulk연산이 더 적합하며, type-safe한 동적쿼리를 통해 데이터베이스와 상호작용해야할 경우 Spring JPA Querydsl가 적합하다.
배치 도메인 용어
Job
Job은 배치처리 과정을 하나의 단위로 만들어 놓은 객체다.
또한 배치처리 과정에 있어 전체 계층 최상단에 위치하고 있다.
JobExecution Properties
- Batch Status : 실행 상태를 나타낸다. 실행중이면 started, 실패하면 failed, 성공하면 completed
- Exit Status : 실행 결과를 나타낸다. ExitCode를 포함하고 있다.
Step
- 배치 작업의 독립적이고 순차적인 단계를 캡슐화하는 도메인 객체.
- 모든 Job은 하나 또는 그 이상의 Step으로 구성
- Step의 내용은 개발자의 재량이므로 복잡하거나 단순하게 구현 가능.
StepExecution
- Status : 실행 상태
- ExitStatus : 실행 결과를 나타냄.
- ReadCount , Write Count, CommitCount, Rollback Count, Filter Coutn등 실행에 대한 다양한 정보를 담고 있다.
JobRepository
Job, Step 구현을 위한 CRUD 작업을 제공
JobLauncher
Job을 시작하기 위한 간단한 인터페이스, 구현 시 JobRepository에서 유효한 JobExecution을 획득하고 Job을 실행한다.
Item
작업에 사용하는 데이터
ItemReader
Step에서 한 항목씩 검색한다. 모든 항목이 소진된 경우 null을 반환한다.
ItemWriter
여러 출력 항목을 나타낸다
ItemProcessor
비즈니스 처리를 담당한다. 항목이 유효하지 않다고 판단되는 경우 null을 반환한다.
스프링 배치 활용하기
Chunk기반 방식
Spring Batch에서의 Chunk란 처리 되는 커밋 row 수를 의미한다. Batch 처리에서 커밋 되는 row 수는 chunk 단위로 Transaction을 수행하기 때문에 실패시 Chunk 단위 만큼 rollback이 되게 된다.
Chunk 지향 처리에서는 다음과 같은 3가지 시나리오로 실행 된다.
- 읽기(Read) — Database에서 배치처리를 할 Data를 읽어온다
- 처리(Processing) — 읽어온 Data를 가공,처리를 한다 (optional)
- 쓰기(Write) — 가공,처리한 데이터를 Database에 저장한다.
ItemReader에서 Cursor/Paging 기능
Cursor
데이터베이스와 connection을 계속 유지한 채 아이템을 1개씩 뽑아오는 작업
Paging
데이터베이스와 한번 connection을 할 때, 정해진 사이즈 만큼의 아이템을 가져오는 것
page size vs chunk size
Paging Size가 5이며 Chunk Size가 10일 경우 2번의 Read가 이루어진 후에 1번의 Transaction이 수행된다. 이는 한번의 Transaction을 위해 2번의 쿼리 수행이 발생하게 된다.
따라서, 한번의 Read 쿼리 수행시 1번의 Transaction을 위해 두 설정의 값을 일치를 시키는게 가장 좋은 성능 향상 방법이며 특별한 이유가 없는 한 Page Size 와 Chunk Size를 동일하게 설정하는 것을 추천!!
PagingReader 사용 시 주의할 점
페이징 처리 시 각 쿼리에 Offset 과 , Limit를 지정해 주어야 하는데 이는 PageSize를 지정하면 Batch에서 Offset과 Limit를 지정해준다. 하지만 페이징 처리를 할 때 마다 새로운 쿼리를 실행하기 때문에 데이터 순서가 보장 될 수 있도록 반드시 Order By를 사용하여야 한다.
ItemProcessor
- 청크기반 Tasklet을 구성할 때 선택 요소
- 데이터를 가공/필터링 하는 역할을 한다.
→ writer에서도 구현 가능함
→ 그러나 비즈니스 코드가 섞이는 것을 방지 - Step에 여러 로직이 필요할 때, 도입을 고려해 유지보수성을 증가시킨다.
- 데이터 처리를 실패했을 때 null을 반환해 writer에 전달되지 않는다.
관리도구
Cron
리눅스 작업 스케쥴러
Spring MVC + API Call
→ 권장하지 않음
Quartz + Admin
스케쥴러 프레임워크 + 관리자 페이지 구현
CI Tool(Jenkins)
- 슬랙이나 email등과 연동해서 실행결과 받을 수 있음
- 실행 이력/ 로그관리 가능
- 파이프라인을 활용해 Batch Job을 순차적으로 실행시킬 수 있음
( Job 내부에 Step을 여러개 설계하는 것보다 Job을 파이프라인으로 만들어 실행시키는 것이 권장됨. )
