🤦‍♂️ "당연한 걸 지키는 게 이렇게 어려운가" E

개발 ・ 2026.01.25

🤦‍♂️ "당연한 걸 지키는 게 이렇게 어려운가" EC2 환경에서 DuckDB를 사용하는 서비스에서 Collector writer가 간헐적으로 락 획득에 실패했다. 에러는 이거였다. Could not set lock on file "analytics.db": Conflicting lock is held in PID 0 “리소스는 쓰고 나면 닫아야 한다.” 너무 당연한 얘기라 한 군데에서 놓쳤을 거라고는 처음엔 생각도 못 했다. 그런데 결국 😅 🧱 "이미 다 하고 있다고 생각했는데" 구조는 처음부터 단순하게 잡았다. Writer 1명, Reader N명. Collector 하나만 DuckDB에 쓰고, Detector와 API는 read_only=True로만 접근했다. 대시보드는 React + Vite고, 데이터는 API를 통해서만 내려주기 때문에 DuckDB에 직접 붙는 컴포넌트는 아니었다. Collector와 API는 DuckDB 연결을 열고 나면 항상 닫도록 구현해 둔 상태였다. 그래서 이론상으로는 다 막아 둔 구조라고 생각했다. 🔍 "어디서 락이 걸린 건지" 에러 메시지에 찍힌 PID 0 때문에 처음엔 “이미 죽은 프로세스가 남긴 stale lock” 쪽으로만 생각했다. 그래서 초반에는 close() 문제일 거라고 바로 연결하지 못했다. 가능성을 세 가지로 나눴다. 하나는 stale lock, 하나는 연결 누수, 하나는 reader와 writer 접근 타이밍 문제. 그래서 하나씩 확인했다. 먼저 Detector 코드부터 봤다. detect_spikes()에서 DuckDB read_only 연결을 연 뒤, 데이터가 부족하면 early return 하는 경로가 있었고 그 경로에서는 close()가 호출되지 않았다. 그다음 로그 타임라인을 다시 봤다. 재시작 직후에는 실패하고, 시간이 지나면 성공하는 패턴이었다. 일시적인 락이거나, 연결이 시간이 지나며 정리되는 상황과 맞아떨어졌다. 마지막으로 재시작 순서를 바꿔봤다. detector와 api를 먼저 내리고, collector를 나중에 올리자 바로 해결됐다. 기존 reader 연결을 먼저 정리해야 writer가 락을 잡을 수 있다는 게 명확해졌다. 🧩 결론 힘 빠지게도 원인은 복잡하지 않았다. 닫히지 않은 reader 연결, 이전 프로세스가 남긴 stale lock, 여러 reader가 같은 파일을 동시에 붙들고 있던 상황. 이 세 가지가 겹쳤다. 🔧 1차 해결 detector와 api를 먼저 재시작하고, dashboard는 잠시 내려두고, collector를 재시작한 뒤 다시 dashboard를 올렸다. DB에 붙어 있던 연결을 전부 끊고 writer만 깨끗한 상태에서 다시 붙인다. 이게 끝이었다. 🛠 근본 해결 Detector 쪽 DuckDB 접근을 전부 try/finally로 감쌌다. early return이나 쿼리 도중 예외가 나도 reader가 DB를 오래 붙들고 있지 않게 하기 위해서다. Collector 쪽에는 락 관련 예외만 골라 exponential backoff를 3회까지만 두었다. 솔직히 락 예외를 직접 다뤄본 건 이번이 처음이었다. 순간적인 경합이나 stale lock은 재시도로 흡수할 필요가 있었다. 그리고 runbook.md에 DuckDB 락 충돌 시 조치 절차를 따로 정리해 두었다. OLAP 용으로 DuckDB, OLTP 용으로 Postgres를 쓰고 있어서 문제가 난다면 DB 간 충돌이거나 Postgres 쪽일 거라고 생각했었다. 정작 발목을 잡은 건 파일 기반 DB 쪽이었다. 🎯 정리 기본이라고 생각한 것부터 다시 보게 됐다. 원인은 하나라고 단정 지으면 안 된다는 것도. 그리고 구조상 자연스럽게 발생하는 에러는 분명히 존재한다는 것. 중요한 건, 그 에러를 “어쩔 수 없는 것”으로 넘기지 않고 운영에서 관리 가능한 상태로 만드는 장치를 두는 것. 💢

콘텐츠를 더 읽고 싶다면?

원티드에 가입해 주세요.
로그인 후 모든 글을 볼 수 있습니다.

・댓글 1