🏹 예치금 차액 비교 Spring Batch 리펙토링 부록

#프로젝트 #개발 #SPRING #Batch #Partitioning #Chunk

output (9).png

parallelStream vs CompletableFuture 서비스의 api호출 로직을 더 효율적으로 관리할 수는 없을까?

현재 예치금 차액 배치의 서비스로직은, 각 파티션에서 실행되며,
이렇게 실행된 코드는 parallelStream을 사용하여 내부적인 병렬처리를 진행한다.
해당 로직의 특징은 cpu에 부하를 주는 계산식이 아닌, 단순 I/O (api호출 대기)의 소요시간이 크다.

작업 시나리오

API 호출 작업 10,000건 처리
각 호출 응답 시간 200ms

`parallelStream`의 성능:

기본 스레드 풀 크기: CPU 코어 수 - 1 (예: 7개의 코어)
처리 시간 ≈ 작업 개수/스레드 수×응답 시간\text{작업 개수} / \text{스레드 수} \times \text{응답 시간}작업 개수/스레드 수×응답 시간
≈10,000/7×200ms\approx 10,000 / 7 \times 200ms≈10,000/7×200ms
≈286초\approx 286초≈286초

CompletableFuture + FixedThreadPool(100)**의 성능:

스레드 풀 크기: 100
처리 시간 ≈ 작업 개수/스레드 수×응답 시간\text{작업 개수} / \text{스레드 수} \times \text{응답 시간}작업 개수/스레드 수×응답 시간
≈10,000/100×200ms\approx 10,000 / 100 \times 200ms≈10,000/100×200ms
≈20초\approx 20초≈20초

a. 작업의 성격

CPU 바운드 작업:
- CPU를 많이 사용하는 작업(예: 복잡한 계산)이면, 코어 수 이상의 스레드를 실행할 경우 컨텍스트 스위칭(스레드 간 전환) 비용이 증가해 성능이 오히려 떨어질 수 있습니다.
- 예: 7개의 코어로 100개의 CPU 작업 스레드를 처리하려 하면 병목이 발생.
I/O 바운드 작업(API 호출 포함):
- 네트워크 I/O 작업은 대기 시간이 길고, 대기 중에는 CPU를 거의 사용하지 않습니다.
- 이 경우 스레드 수 > 코어 수가 유리하며, 100개의 스레드를 실행해도 대부분의 스레드는 대기 상태에 있으므로 CPU 사용량이 낮습니다.

2차 검증로직 삭제 전

기존로직

69961 ms 70048 ms 70396 ms

2차 검증로직 삭제 후

기존 로직

55180 ms 55036 ms 55285 ms 55442 ms

(계산로직 + API호출 로직) - 스레드 고정(20)

71139 ms 72220 ms

(API호출 로직만 스레드 고정(20)

64473 ms 65609 ms

미리 파티션 되어있는 데이터의 특성상 한번에 처리되는 양이 많지 않다.
또한, stream().parallel()은 forkJoinPool에서 효율적으로 관리되며,
데이터의 동기화 병목을 줄이고, 컨텍스트 전환 횟수를 줄여 더 효율적인 것으로 보임.

결과

stream().parallel() 기능이 효율적이다.

QuerydslPagingItemReader를 적용함으로 인하여, 일정한 데이터의 크기를 자동으로 페이징 하기 때문에(Reader는 각 Partition별 1번 작동) 스케줄링이 동작할 수 없다.

그럼에도 속도가 더 개선된 이유를 분석해보면 좋을것으로 보인다.

아마도 Where절이 추가되면서 reader의 속도가 크게 올라갓으며, 1번의 호출만을 하기 때문에 더 개선되었을것이다.

292Column

기존 :

chunk-size:20 55969 ms

변경후 :

chunk-size:20 54679 ms 54416 ms

2차 검증 삭제시 최종 차액 인원이 다른 이유

기존 : reader에서 넘어온녀석들의(옛날기준 날짜범위 내의 가장최신Point)차액 -> 차액이있는녀석들의 (모든날짜 범위내의 최신 Point)의 차액 현재 : reader에서 가져온녀석들의(모든날짜범위내의 최신 Point)의 차액

현재:281 / 기존:141

현재차액에 기존차액이 모두 포함되어있음

=> 옛날기준 날짜범위 내의 가장최신포인트와 실시간 포인트는 다를 경우가 많음. 거기 내에

전날의 최신포인트 vs 현재 최신포인트(신한) -> 여기엔 안걸리지만 현재 최신포인트 vs 현재 최신포인트(신한) -> 여기에는 걸린다.

시행착오

Limit을 사용하지 않고 JpaPagingReader를 사용했을 때, 프로세서가 모아서 처리할 수 있는 방법이 있는가?

이게 무슨소리인지?

보통의 Batch 서비스라면 I/O 작업에 부하가 걸려있겠지만, 현재 예치금 차액 배치는 processor 즉, 예치금 비교 연산에서 큰 리소스를 소모하고있다.
이에 해당하는 시간 소모를 줄이기 위해 processor(서비스로직) 을 병렬처리 함으로 최종 처리시간 단축을 꾀할 수 있을지에 대한 고민이다.
이후 설명하겠지만, 내부 병렬처리 로직은 청크의 트렌젝션을 무너뜨릴 가능성이 크므로 지양해야함.

- processor는 reader의 return결과로만 트리거 되기 때문에 방법이 없다.

Pasted image 20241206113120.png

필수가 아니라면, processor의 로직을 writer에 할당하여 청크사이즈로 컨트롤 할수 있지 않을까?

reader(dto) -> processor -> writer(dtoList)

- 구현 결과 reader의 return인 dto값을 chunk사이즈 만큼 List dto로 합쳐 일괄 처리가 가능하다.

소요시간 : 1분 9초

-> 기존 limit절을 이용한 로직보다 속도가 더빠르며, JpaPagingReader를 적용한다면 중복 select횟수를 줄여 더 빨라질 것으로 예상된다.

우려되는 점은 writer가 데이터 가공의 역할까지 맡는게, 설계 목적에 부합한지 생각해보아야 한다.

결론 : 둘 중 하나

1. 리더,프로세서 각각 dto 1개 씩 처리 (역할 분담)

2. 프로세서 로직을 제거하여 스레드는 유지하돼, 서비스로직에서 dto list로 내부 병렬처리 로직으로 구현하기

#### 292 컬럼
## Processor 삭제(병렬처리)로직
#### grid-size:6 / chunk-size:20
54679 ms
54416 ms
## Processor 순차처리(writer만 병렬처리) 로직

#### grid-size:6 / chunk-size:20
60440 ms
62271 ms
#### grid-size:10 / chunk-size:20
58129 ms
56723 ms
#### grid-size:16 / chunk-size:20
58595 ms
56314 ms

#### grid-size:32 / chunk-size:20
- SQLTransientConnectionException
- 스레드풀 점유갯수 초과

데이터 상으로는 내부 병렬처리의 승리

하지만, 이후 청크 방식 Batch의 확장성과 유지보수성을 고려하여 리더,프로세서,라이터 방식으로 구현하기로 정했다.

🏹 예치금 차액 비교 Spring Batch 리펙토링 부록

parallelStream vs CompletableFuture 서비스의 api호출 로직을 더 효율적으로 관리할 수는 없을까?

작업 시나리오

parallelStream의 성능:

CompletableFuture + FixedThreadPool(100)**의 성능:

a. 작업의 성격

2차 검증로직 삭제 전

기존로직

2차 검증로직 삭제 후

기존 로직

(계산로직 + API호출 로직) - 스레드 고정(20)

(API호출 로직만 스레드 고정(20)

결과

QuerydslPagingItemReader를 적용함으로 인하여, 일정한 데이터의 크기를 자동으로 페이징 하기 때문에(Reader는 각 Partition별 1번 작동) 스케줄링이 동작할 수 없다.

그럼에도 속도가 더 개선된 이유를 분석해보면 좋을것으로 보인다.

292Column

기존 :

변경후 :

2차 검증 삭제시 최종 차액 인원이 다른 이유

현재:281 / 기존:141

현재차액에 기존차액이 모두 포함되어있음

시행착오

Limit을 사용하지 않고 JpaPagingReader를 사용했을 때, 프로세서가 모아서 처리할 수 있는 방법이 있는가?

- processor는 reader의 return결과로만 트리거 되기 때문에 방법이 없다.

필수가 아니라면, processor의 로직을 writer에 할당하여 청크사이즈로 컨트롤 할수 있지 않을까?

reader(dto) -> processor -> writer(dtoList)

- 구현 결과 reader의 return인 dto값을 chunk사이즈 만큼 List dto로 합쳐 일괄 처리가 가능하다.

우려되는 점은 writer가 데이터 가공의 역할까지 맡는게, 설계 목적에 부합한지 생각해보아야 한다.

1. 리더,프로세서 각각 dto 1개 씩 처리 (역할 분담)

2. 프로세서 로직을 제거하여 스레드는 유지하돼, 서비스로직에서 dto list로 내부 병렬처리 로직으로 구현하기

데이터 상으로는 내부 병렬처리의 승리

`parallelStream`의 성능: