
배치 최적화 이후 실행 시간이 지나치게 단축되어 장애가 발생할 수도 있겠다는 우려가 있었습니다.
그렇기에 장애를 사전에 예방하고자 Retry와 Backoff 전략을 설계하고 적용하였습니다.
장애는 여러 가지 원인으로 발생할 수 있지만, 데이터베이스 관련 일시적인 장애가 발생한 경우를 제외하고는 재시도가 성공할 가능성이 낮다고 판단했습니다. 이에 따라, SQLRecoverableException과 TransientDataAccessException을 재시도 대상으로 지정했습니다.
SQLRecoverableException
데이터베이스 연결 손실과 같은 복구 가능한 오류
TransientDataAccessException
커넥션풀 고갈, 트랜잭션 충돌, 데이터 접근 일시적 문제로 발생하는 오류
과도한 재시도는 시스템 부하를 유발할 수 있다고 판단해 재시도 횟수는 최대 2회로 제한했습니다.
또한, Backoff 전략을 통해 재시도 간격을 10초(10,000ms)로 설정하여 서버 부하를 최소화하며 안정적으로 처리될 수 있도록 구성했습니다.
@Bean
public FixedBackOffPolicy fixedBackOffPolicy() {
FixedBackOffPolicy fixedBackOffPolicy = new FixedBackOffPolicy();
// 10초간 대기
fixedBackOffPolicy.setBackOffPeriod(10000);
return fixedBackOffPolicy;
}
@Bean
public SimpleRetryPolicy simpleRetryPolicy() {
Map<Class<? extends Throwable>, Boolean> retryableExceptions = new HashMap<>();
// 복구 가능한 데이터베이스 오류 발생 시 재시도
retryableExceptions.put(SQLRecoverableException.class, true);
// 커넥션풀 고갈, 트랜잭션 충돌, 데이터 접근 일시적 문제 발생 시 재시도
retryableExceptions.put(TransientDataAccessException.class, true);
return new SimpleRetryPolicy(2, retryableExceptions);
}
이후 Listener를 설정해 실패한 Job이나 Step에 대한 알림(ex. Slack)을 보내는 것이 가능하다는 것을 알게 되어서 추가로 학습 후 적용해보았습니다.
Spring Batch 장애 알림 _ 슬랙