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

ClickHouse를 처음 쓰다 보면 한 번쯤 이런 경험을 한다. MySQL에서는 아무 문제 없이 돌아가던 JOIN 쿼리가 ClickHouse에서는 유독 느리거나, WHERE 조건을 다 걸었는데도 풀스캔 수준의 시간이 걸리는 것이다. 이 글에서는 그 이유를 ClickHouse의 내부 동작 방식에서 찾고, 실제로 쓸 수 있는 최적화 전략을 정리한다. 어떤 상황인가 수억 건의 유저 행동 로그(page_view_log)와 주문 데이터(order_log)를 JOIN해서 페이지를 본 특정 기간, 특정 유저의 구매 건수를 집계한다고 해보자. 아래처럼 쓰는 것이 자연스럽다.SELECT count(*)FROM default.page_view_log p JOIN default.order_log o ON ..

AWS Summit Seoul 2026에 다녀왔다. 5월 20일, 1일차다. 뒤늦은 후기이다. 백엔드 개발자로서 SSAFY와 사이드 프로젝트를 거치며 AWS를 써왔는데, 취업은 온프레미스 환경의 회사로 했다. 현재 회사에서 인프라를 거의 다루지 않다 보니 클라우드와 점점 멀어지고 있던 차에 AWS Summit 소식을 듣고, 소중한 연차 하루를 써서 다녀왔다. 다녀오길 잘했다. 지금 하는 개발이 클라우드나 AI와 직접적인 연관은 없지만, 개발자로서 영감을 얻을 수 있는 내용이 많았다.역시 AI 시대답게 거의 모든 세션이 AI 활용에 관한 내용이었다. 얼마 전까지만 해도 대용량 아키텍처나 인프라 설계가 주를 이뤘던 것 같은데, AI 시대가 도래하면서 주제도 달라졌다. AWS Events 앱을 설치해서,..

배경 멀티스레드 배치 시스템에서 벌크 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..