Spring Batch Remote Partitioning

Overview

Remote Partitioning은 하나의 Manager가 전체 입력 범위를 여러 StepExecution으로 나누고, 원격 Worker가 각 범위를 독립적으로 처리하는 Spring Batch 확장 방식이다.

왜 필요한가

Local Partitioning은 한 JVM 안에서 Thread를 늘리므로 Heap, CPU, Disk I/O의 단일 Node 한계를 넘지 못한다. 처리 기한과 데이터 크기가 한 Node의 최대 처리량을 넘을 때 Worker JVM을 수평 확장하는 선택지가 된다.

내부 동작

1. Manager의 Partitioner가 실행 범위를 ExecutionContext로 나눈다.
2. MessageChannelPartitionHandler가 StepExecutionRequest를 Broker로 보낸다.
3. Worker가 요청을 받아 동일한 이름의 Worker Step을 실행한다.
4. 실행 상태는 Job Repository에 기록되고 Manager가 전체 완료를 판단한다.

flowchart LR; A[Manager Partitioner] --> B[StepExecutionRequest]; B --> C[Message Broker]; C --> D1[Worker 1]; C --> D2[Worker 2]; C --> D3[Worker N]; D1 --> E[Job Repository]; D2 --> E; D3 --> E

실무 설계 포인트

• Partition Key가 겹치지 않고 재실행해도 같은 범위를 만들도록 한다.
• Worker 처리 Logic은 Retry나 중복 전달에도 안전하도록 Idempotency를 설계한다.
• Broker Partition 수와 Worker 수, Batch Grid Size를 같은 값으로 가정하지 않는다.
• Manager, Broker, Job Repository가 새로운 병목과 장애 지점이 된다.
• Worker가 공유 Database를 사용하면 Connection Pool 총합이 DB 한도를 넘지 않게 계산한다.

대안

운영 복잡성이 이득보다 크다면 같은 Job을 서로 다른 범위 Parameter로 여러 번 실행하는 단순한 외부 분할도 고려한다. 메시지 흐름과 중앙 조정이 꼭 필요한지 먼저 판단한다.

Trade-off

수평 확장과 장애 격리를 얻지만 Broker 운영, 분산 상태 추적, 중복 처리, 배포 Version 호환, 재시작 전략이 필요하다.

Interview Questions

1. Local Partitioning과 Remote Partitioning의 Resource 경계 차이는 무엇인가?
2. Manager와 Worker 사이에서 중복 메시지가 전달되면 어떻게 처리할 것인가?
3. Partition 크기가 지나치게 작거나 크면 어떤 문제가 생기는가?
4. Remote Partitioning 대신 여러 독립 Job 실행을 선택할 조건은 무엇인가?

Related Topics

Kafka, 부하 테스트, DB Connection Pool을 함께 확인한다.