들어가며 독립 큐 + 전용 워커 스레드를 사용하는 서비스에서 종료 신호가 워커 스레드에 전달되지 않는 문제가 발생했다. @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 ← 로컬 테이블 (실제 데이터 저장..

ClickHouse에서 잘못 적재된 데이터를 지워야 하는 상황이 생겼다. MySQL이라면 그냥 DELETE FROM ... WHERE ... 날리면 끝인데, ClickHouse 클러스터 환경에서는 그게 안 된다. DELETE FROM 문법 자체는 존재하지만, ON CLUSTER를 지원하지 않아 클러스터 전체에 적용되지 않는다. 클러스터 환경에서는 반드시 ALTER TABLE ... DELETE나 DROP PARTITION을 써야 한다. 이 글은 클러스터 환경을 전제로 데이터를 삭제하는 두 가지 방법인 ALTER DELETE와 DROP PARTITION을 비교하고, 각각 언제 쓰는 게 맞는지 정리한다. 방법 선택의 기준은 데이터 양이 아니라 삭제 패턴이다. 작은 양이라도 ALTER DELETE는 파트..

ClickHouse를 처음 접했을 때 가장 혼란스러웠던 건 용어였다. MySQL이나 MariaDB에서는 그냥 테이블 만들고 쿼리 날리면 됐는데, ClickHouse는 처음부터 "Shard", "Replica", "Distributed 테이블", "ZooKeeper"가 튀어나온다. 심지어 테이블도 두 종류가 있다고 한다. 이 글에서는 ClickHouse 클러스터가 어떤 구조로 이루어져 있는지, 각 개념이 무슨 역할을 하는지 한 눈에 이해할 수 있도록 정리해본다. ClickHouse는 왜 클러스터 구조를 쓸까? ClickHouse는 대용량 분석 쿼리에 최적화된 컬럼형 DB다. 수억 건의 데이터를 빠르게 집계하는 게 주 목적이다 보니, 데이터를 여러 서버에 나눠 저장하고 병렬로 처리하는 구조가 기본이 ..