Spring Batch Guide 시리즈는 이동욱 개발자님의 Spring Batch 가이드를 보고 학습한 내용을 정리한 글입니다.
많은 내용이 원 글과 유사할 수 있습니다. 이 점 양해바랍니다 🙏🏻
배치(Batch)는 일괄처리 란 뜻을 갖고 있습니다.
전 날의 데이터를 집계한다고 합시다. 어떻게 할 수 있을까요?
웹 어플리케이션의 환경을 떠올려보면 tomcat + SpringMVC가 있을 수 있습니다. 그래서 모든 데이터를 집계하는 API를 만들어서 실행하면 어떨까요?
위 상황처럼 큰 데이터를 읽고, 가공하고, 저장하는 작업의 경우 많은 양의 CPU와 I/O 리소스를 점유하게 됩니다. 그러면 이후에 들어오는 요청들을 처리하기 힘들 것입니다!
그리고 하루에 1번 실행하기 위해서 API를 만든다면? 너무 비효율적이지 않을까요? 만약 API를 만들었다고 가정해보겠습니다. 이를 실행하다가 중간에 오류가 발생하면? 그럼 지금까지 집계한 모든 데이터가 날아가는 걸까요?
만약 복구를 했다고 하더라도 API가 저장된 데이터부터 다시 실행이 가능할까요?
또는 누군가가 내가 이미 집계한 작업을 다시 실행시킨다면 어떡할까요? 데이터가 2배가 되는 걸까요? 내가 이미 실행하면 그 이후에는 실행을 못하도록 막는건 어떨까요? 같은 파라미터로 같은 함수를 실행하는 상황 말입니다.
이와 같은 상황에서 단발성으로 대용량의 데이터를 처리하는 어플리케이션을 배치 어플리케이션이라고 합니다.
배치 어플리케이션의 경우 아래와 같은 조건을 만족해야 합니다.
대용량 데이터 : 배치 어플리케이션은 대량의 데이터를 가져오거나, 전달하거나, 계산하는 등의 처리를 할 수 있어야 합니다.
자동화 : 배치 어플리케이션은 심각한 문제 해결을 제외하고는 사용자 개입 없이 실행되어야 합니다.
견고성 : 배치 어플리케이션은 잘못된 데이터를 충돌/중단 없이 처리할 수 있어야 합니다.
신뢰성 : 배치 어플리케이션은 무엇이 잘못되었는지를 추적할 수 있어야 합니다(로깅, 알림).
성능 : 배치 어플리케이션은 지정한 시간 안에 처리를 완료하거나 동시에 실행되는 다른 어플리케이션을 방해하지 않도록 수행되어야 합니다.
이와 같은 조건을 만족하는 어플리케이션을 배치 어플리케이션이라고 합니다.
여기서 한 가지, 우리는 웹 어플리케이션을 개발할 때 비지니스 로직에만 집중할 수 있는데 그 이유는 Spring과 같은 프레임워크가 도와주기 때문입니다.
그렇다면 배치 어플리케이션에는? Spring Batch가 바로 그런 역할을 제공해줍니다.
Spring Batch 프로젝트는 배치 프레임워크를 만든 경험이 있는 Accenture와 Spring Source의 공동 작업으로 2007년에 탄생하였습니다. Accenture의 배치 노하우 & 기술력와 Spring 프레임워크가 합쳐져 만들어진 것이 Spring Batch입니다.
Spring Batch는 Spring의 특성을 그대로 가져왔습니다. DI, AOP, 서비스 추상화 등 Spring 프레임워크의 3대 요소를 모두 사용할 수 있습니다. 거기다 플러스 Accenture의 Batch 아키텍쳐를 함께 사용할 수 있습니다.
Spring Batch 4.0(Spring Boot 2.0)에서 지원하는 Reader & Writer는 아래와 같습니다.
DataSource | 기술 | 설명 |
---|---|---|
Database | JDBC | 페이징, 커서, 일괄 업데이트 등 사용 가능 |
Database | Hibernate | 페이징, 커서 사용 가능 |
Database | JPA | 페이징 사용 가능 (현재 버전에선 커서 없음) |
File | Flat file | 지정한 구분자로 파싱 지원 |
File | XML | XML 파싱 지원 |
iBatis 모듈은 현재 삭제되었습니다.
Quartz는 스케줄러의 역할, 대용량 데이터 배치 처리에 대한 기능은 제공하지 않습니다. 물론 Batch 또한 스케줄 기능을 지원하지 않습니다.
그래서 Quartz + Batch로 주로 사용합니다. Quartz가 Batch를 실행시키는 구조로 말입니다.
거래가 하루에 50만건 이상 이뤄지는 커머스 사이트의 경우, 데이터는 최소 100만 ~ 200만 레코드 정도가 발생합니다. 이는 한 달이면 5000만 ~ 1억 레코드일 수도 있습니다.
이런 상황에서 실시간 집계 쿼리를 사용하면? 조회 시간이나 서버의 부하가 심할 것이 분명합니다.
그래서 매일 새벽 5시에 전날의 매출 집계 데이터를 만들어두고 조회가 필요할 경우 여기서 조회를 한다면?
성능도 굿! 부하도 감소!
대부분의 서비스에서는 ERP를 사용합니다.
ERP는 자원 관리 시스템입니다. 사내 구성원을 비롯해서 매출, 지출 등을 모두 관리하는 소프트웨어 시스템을 얘기합니다.
ERP 솔루션으로 유명한 것은 SAP가 있습니다.
재무팀에서 매일 매출 현황을 ERP로 전달해달라고 요구한다면? 이런 경우에 Spring Batch가 많이 사용됩니다. 매일 아침 8시에 ERP에 전달해야 할 매출 데이터를 전송해야 한다면 아래와 같은 구조일 것입니다.
지금까지 살펴본 상황들 처럼 정해진 시간마다 데이터 가공이 필요한 경우에는 어떻게 해결할 수 있을까요?
바로 Spring Batch를 사용하면 됩니다!
대용량 데이터를 처리해야 할 경우 웹 어플리케이션을 통해서 처리하기에는 너무 많은 리소스를 사용하게 됩니다.
이런 상황에서 배치 어플리케이션을 활용하여 대용량 데이터를 가공, 처리하면 다른 어플리케이션, 요청에 영향을 미치지 않으면서 성능을 챙기고 부하도 줄일 수 있다.
Spring 진영에서 Spring Batch를 사용하면 이런 효과를 얻으면서 Spring의 주요 기능들을 함께 사용할 수 있다.