스프링 배치를 통한 대용량 처리에 대해 알아봅시다!
🚀 들어가기
본 포스트에서는 배치 처리의 개념과 사용 시나리오를 중심으로, 일괄 생성, 일괄 수정, 통계 처리에 대해 알아보고 대량 데이터 처리 시 발생하는 일반적인 문제점까지 살펴보도록 하겠습니다.
배치 처리의 개념과 사용 시나리오
배치(batch) 처리는 특정 시간에 많은 데이터를 일괄적으로 처리하는 프로세스를 의미합니다. 예를 들어, e-커머스 플랫폼에서 오후 4시에 상품 배송 정보를 고객들에게 문자로 일괄 전송하는 경우가 이에 해당합니다. 서버 개발자들은 특정 시간에 일괄 처리해야 하는 작업이 필요할 때 이를 배치 프로세스로 구현하는 것이 일반적입니다.
일괄 생성, 일괄 수정, 통계 처리 개념
배치 처리는 크게 세 가지 형태로 구분할 수 있습니다.
1. 일괄 생성(Read-Create-Write)
기존 저장된 정보를 조합해 새로운 정보를 만듭니다. 예를 들어, 주문 정보를 읽어 사용자 정보와 합친 후 문자 정보를 생성하는 경우가 이에 해당합니다.
2. 일괄 수정(Read-Update-Write)
A 데이터를 읽고 B 데이터를 참고하여 A 데이터를 수정 합니다. 예를 들어, 주문 정보를 읽고 배송 정보를 참고해 주문 정보를 수정합니다.
3. 통계 처리(Read-Sum-Write)
데이터를 집계하여 통계 형식의 데이터를 만듭니다. 예를 들어, 주문 정보를 GROUP BY 형태로 질의해온 다음 상품별 주문 금액 합산 데이터를 만들 수 있습니다.
사이드 프로젝트 소개
스프링 배치의 성능을 최적화하는 사이드 프로젝트를 진행했습니다. 이 프로젝트에서는 e-커머스 플랫폼에서 상품을 등록한 판매자에게 일일 정산을 제공하기 위해, 하루 동안 발생한 구매 확정 데이터를 기반으로 매일 특정 시각에 판매자별 일일 정산을 수행하는 배치 프로세스를 구현했습니다.
다음 이미지는 일일 정산 배치를 수행하는 각 단계별 상태를 나타낸 다이어그램입니다.
주문-상품 구매 확정 처리: 특정 조건을 만족시키는 주문-상품 건에 대하여 구매 확정 상태로 일괄 수정 합니다.클레임 처리 완료: 클레임(취소/환불/반품)이 끝난 건에 대하여 클레임 완료 처리 상태로 일괄 수정 합니다.판매자별 일일 정산 생성: 금일 판매건이 존재하는 판매자에 대하여 일일 정산을 일괄 생성 합니다.주문-상품 정산 Detail 생성: 구매 확정 상태의 주문-상품 건에 대하여 (+) 정산 처리한 데이터를 일괄 생성합니다.클레임-환불 정산 Detail 생성: 클레임 처리 완료 건 중 환불건에 대하여 (-) 정산 처리한 데이터를 일괄 생성합니다.판매자별 정산 Detail 집계: 판매자별로 (+)정산과 (-)정산을 집계하여 통계 데이터를 생성합니다.판매자별 일일 정산 업데이트: 이전 단계에서 생성해두었던 일일 정산에 집계 데이터를 업데이트합니다.
대량 데이터 처리 시 발생하는 일반적인 문제점
개발자들은 종종 배치 성능에 상대적으로 무관심한 경향이 있습니다. 이는 배치 작업이 주로 트래픽이 적은 시간대인 새벽에 자동으로 스케줄링되어 실행되기 때문에, 배치 처리 시간이 오래 걸리더라도 큰 문제로 인식되지 않는 경우가 많기 때문입니다. 또한 배치를 개발한 뒤 배포 후 초기에만 로그를 모니터링하다가, 문제가 없다고 확인된 후에는 실제 문제가 발생하기 전까지 잘 살펴보지 않는 관리 소홀로 이어지기도 합니다. 특히 배치 모니터링 환경이 제대로 구축되어 있지 않다면, 문제를 파악하고 해결하는 데 상당한 시간이 소요될 수 있습니다.
대량 데이터 처리 시 흔히 발생하는 문제점들은 다음과 같습니다:
- 처리 시간이 예상보다 크게 길어지는 현상
- 메모리 부족(OOM, Out Of Memory) 오류 발생
- 데이터베이스 부하 증가 및 성능 저하
- 동시에 실행되는 배치 작업 간 자원 경쟁으로 인한 성능 저하
- 배치 처리 이력 관리 및 모니터링의 어려움
사이드 프로젝트를 진행하면서 위 문제들을 어떻게 개선해나갔는지 다음 포스트들에서 하나씩 자세히 살펴보도록 하겠습니다.