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

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

문제 상황 특정 사용자의 데이터를 일괄 삭제하는 배치에서 두 종류의 타임아웃이 발생했다.Lock wait timeout exceeded; try restarting transaction ← 서브쿼리 DELETE 단계Query execution was interrupted (max_statement_time exceeded) ← PK 기반 SELECT+DELETE 단계 두 에러는 동시에 발생한 것이 아니다. 서브쿼리 DELETE를 사용할 때 Lock wait timeout이 발생했고, PK 기반 SELECT+DELETE로 전환한 뒤 max_statement_time exceeded가 발생했다. 타임아웃 종류가 바뀐 것 자체가 분석 포인트다. 초기 코드는 서브쿼리 DELETE 구조였다.DELET..

문제 상황 스프링 배치 서비스에서 여러 작업 대상을 스레드 풀로 병렬 처리하고, 각 스레드가 완료 후 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..

노션과 함께한 시간들 이전에 취업 준비를 시작하면서 노션을 처음 썼다. 자기소개서, 지원 현황 트래킹, 면접 기록까지. 이후에는 사이드 프로젝트 기획서, 회사 업무 메모, 일상 기록까지 노션 하나로 다 해결했다. 그만큼 노션은 쓰기 편하고 예쁘다. 페이지 공유도 링크 하나면 끝이고, 팀원과 협업하기도 좋다. 처음 접하는 사람도 금방 적응할 수 있는 낮은 진입장벽이 가장 큰 장점이었다. 그러다 한 번 옵시디언을 시도해봤다. 결론은 포기. 플러그인 설치에 볼트 구조 잡는 것도 낯설었고, 노션처럼 블록 드래그로 바로 레이아웃을 잡을 수 없다는 것도 불편했다. 나는 개발자라 마크다운에 익숙하지만 마크다운으로만 작성해야 한다는 것도 당시엔 번거롭게 느껴졌다. 갈아탄 이유노션 무료 플랜의 블록 제한 노션 무료..

ClickHouse 클러스터를 처음 사용하다 보면 당황스럽다. 분명히 특정 날짜 데이터를 삭제했는데, 조회해보면 데이터가 여전히 남아있다. 분명 DROP PARTITION을 실행했는데. 알고 보면 삭제된 건 클러스터 전체가 아니라 일부 Shard의 데이터뿐이다. 이 글에서는 왜 이런 일이 생기는지, 그리고 어떻게 해야 클러스터 전체에 올바르게 적용할 수 있는지 정리한다. 배경: Distributed 테이블은 라우터다앞선 글에서 다뤘지만 다시 짚고 넘어가자.ClickHouse 클러스터에서 테이블은 두 벌이다.default.user_events ← Distributed 테이블 (라우터, 데이터 없음)local.user_events_local ← 로컬 테이블 (실제 데이터 저장..