배경 멀티스레드 배치 시스템에서 벌크 INSERT가 간헐적으로 타임아웃으로 실패했다. 기존 코드는 예외를 로그로만 남겼기 때문에 실패한 수천 건이 그대로 유실됐다. 게다가 타임아웃이 발생하는 시점은 DB 부하가 높은 구간이다. 실패가 연달아 수 천건씩 N번 발생했다. 시도했던 방식 단순히 예외를 잡아 재시도하는 방식은 배치 스레드를 지연시키고, 실패가 연달아 발생하면 재시도 로직도 함께 실패한다. 타임아웃이 발생하는 시점은 DB 부하가 높은 구간이다. 재시도를 즉시 실행하면 같은 부하 구간에서 다시 실패할 가능성이 높고, 그 사이 다른 배치도 같은 스레드풀을 기다린다. 실패가 연달아 수 천건씩 N번 발생하는 패턴에서 인라인 재시도는 수십 번 연속으로 쌓여 배치 전체를 마비시킬 수 있다. 대신..

들어가며 독립 큐 + 전용 워커 스레드를 사용하는 서비스에서 종료 신호가 워커 스레드에 전달되지 않는 문제가 발생했다. @PreDestroy에서 running = false를 분명히 썼는데도 워커 스레드는 루프를 계속 돌고 있었다. private volatile boolean running = true; 해결책은 volatile 한 키워드였지만, 왜 없으면 안 되는지는 설명하기 어려웠다. 이 글은 문제의 원인을 파악하고 올바른 구현에 이르기까지의 과정을 담았다. 1. 문제 발생 - volatile 없이 어떤 일이 벌어지는가 volatile 없이 종료 플래그를 구현하면 어떤 일이 생기는지 코드로 먼저 보자.// volatile 없음private boolean running = true;// 워커 ..

문제 상황 스프링 배치 서비스에서 여러 작업 대상을 스레드 풀로 병렬 처리하고, 각 스레드가 완료 후 Telegram으로 배치 결과를 알림하는 기능이 있다. 평소에는 문제가 없었는데, 단기간(1~2초)에 끝나는 배치 대상이 많은 특정 시간대의 배치에서만 아래와 같은 에러가 반복 발생했다. 14:30:00에 46건을 대상으로 배치 시작 후, 순차적으로 Telegram 알림을 발송했다.(비즈니스 로직 수행부터 알림 발송까지 배치 대상 당 1~2초 안에 끝난다.) 그러다가 14:30:33부터 Telegram 알림 발송 에러가 발생했다. 14:30:33 429 Too Many Requests retry_after: 2714:30:34 429 Too Many Requests retry_after: 2..

배경얼마 전 업무에서 캐시를 적용했는데도 성능이 나아지지 않는 이상한 상황을 겪었다.캐시 히트는 정상이었다. 근데 느렸다. 문제는 8500개짜리 Map을 캐시에서 꺼내는 로직에 있었다. getDataMap()은 분명 캐시에서 응답하고 있었는데, 요청이 몰릴 때마다 성능 저하가 반복됐다.@Cacheable(value = "dataCache", key = "'dataMap'")public Map getDataMap() { return dataRepository.findAll();} 원인을 파고들다 보니 내가 캐시 설정 파일에서 무심코 을 쓰고 있었다는 걸 알게 됐다. 50 그리고 그때 처음으로 제대로 이해했다. Heap 캐시와 Offheap 캐시는 동작 방식 자체가 다르다는..

⚠️ 문제 상황 Spring Boot에서 Gradle에 있는 Dependency의 버전을 정리하던 중에 Redis 사용을 위한 Lettuce 의존성을 수정하던 중 문제가 발생했다. 기존에는 사용하는 Lettuce 라이브러리의 버전을 다음과 같이 명시적으로 적어줬었다.implementation 'io.lettuce:lettuce-core:6.0.0.RELEASE' 하지만 현재 Spring Boot 버전에 맞게 사용하도록 라이브러리의 버전을 때도록 수정해줬다.implementation 'io.lettuce:lettuce-core' 빌드는 제대로 되지만 런타임 중에 에러가 발생하는 문제가 발생했다. ❗️에러 메시지Caused by: io.lettuce.core.RedisCommandExecuti..

자바에서 프로그래밍할 때 언제나 조심해야 하는 것은 NullPointerException이다.실제로 최근 실무에서 null 체크를 꼼꼼히 안했다가 운영에서 에러가 찍히는 사태가 발생했다😱 그리고 List가 null 인지와 비었는지를 모두 확인해줘야 할 일이 생겼는데, Spring에서 제공하는 CollectionUtils을 쓰면 한 번에 체크할 수 있다는 것을 알게 되었다. 그래서 그 내용을 정리하고자 한다. 1. null vs empty우선 null과 empty의 차이에 대해 정리해보자.아래 그림은 null과 empty의 차이를 아주 잘 설명해주는 짤이다. 왼쪽 칸을 보면 휴지의 주요 내용물인 흰 부분(데이터)가 없고, 휴지를 담고 있던 휴지심(객체)는 있는 상태이다.오른쪽 칸을..