긴급 상황! 데이터베이스가 멈췄을 때의 식은땀, 저도 잘 압니다
개발자로 일하면서 가장 심장이 철렁 내려앉는 순간이 언제일까요? 아마도 잘 돌아가던 서비스가 갑자기 멈추고, 고객들의 불만 전화가 빗발치는데 정작 로그에는 아무런 에러도 찍히지 않는 그 순간일 겁니다. 15년 전, 제가 주니어 개발자였을 때 처음 겪었던 '데드락(Deadlock, 교착 상태)' 사건이 아직도 생생합니다. 금요일 오후 5시, 퇴근을 앞두고 배포한 작은 패치가 거대한 쇼핑몰의 주문 시스템을 마비시켰죠. 데이터베이스 CPU 사용률은 평온한데, 주문 버튼을 누르면 무한 로딩만 도는 상황. 그 공포감은 겪어보지 않은 사람은 모릅니다. ☕ 커피를 10잔 마셔도 정신이 번쩍 들지 않더군요.
혹시 지금 이 글을 읽고 계신 여러분도 비슷한 상황이신가요? 아니면 언제 터질지 모르는 시한폭탄 같은 DB 잠금 문제를 예방하고 싶으신가요? 걱정 마세요. PostgreSQL은 매우 훌륭한 데이터베이스이지만, 동시성 제어(MVCC)를 위해 정교한 잠금(Lock) 메커니즘을 사용합니다. 이 메커니즘이 꼬이면 데드락이나 무한 대기 상태가 발생하는데, 다행히도 우리에게는 pg_stat_activity라는 아주 강력한 탐지 도구가 있습니다. 이것만 잘 활용해도 장애 시간의 90%를 줄일 수 있습니다.
오늘은 제가 수많은 밤샘 작업을 통해 얻은 노하우를 바탕으로, PostgreSQL에서 데드락이 발생했을 때 당황하지 않고 '범인(Blocking Query)'을 찾아내어 우아하게 해결하는 방법을 A부터 Z까지 상세하게 알려드리겠습니다. 단순한 명령어 복사-붙여넣기가 아니라, 왜 이런 일이 발생하는지 근본 원리를 이해하고, 다시는 같은 문제가 발생하지 않도록 시스템을 견고하게 만드는 방법까지 깊이 있게 다뤄보겠습니다. 마치 옆자리 15년 차 선배가 모니터를 같이 보며 하나하나 설명해 주는 것처럼 말이죠. 자, 심호흡 한번 크게 하시고 시작해 볼까요? 🚀
도대체 왜 멈춘 걸까? 데드락과 락 대기의 메커니즘 이해하기
보이지 않는 신호등 전쟁, 락(Lock)의 세계
먼저 우리가 해결하려는 문제의 본질을 꿰뚫어 봐야 합니다. 데이터베이스는 기본적으로 '데이터 무결성'을 생명처럼 여깁니다. A라는 사람이 은행 계좌에서 돈을 인출하는 동시에 B라는 사람이 입금을 한다면, 이 두 작업이 꼬여서 잔액이 틀어지면 안 되니까요. 그래서 PostgreSQL은 데이터를 수정하려는 트랜잭션에게 잠시 '줄을 서시오'라고 말합니다. 이것이 바로 락(Lock)입니다. 마치 화장실이 하나뿐인 집에 5명의 가족이 사는 것과 비슷합니다. 누군가 들어가서 문을 잠그면(Lock), 밖에서는 아무리 급해도 기다려야(Wait) 합니다.
보통의 경우 이 대기 시간은 밀리초(ms) 단위로 매우 짧습니다. 사용자는 눈치채지도 못하죠. 하지만 특정 상황에서는 이 대기 줄이 꼬여버립니다. 가장 흔한 시나리오는 '교착 상태(Deadlock)'입니다. 트랜잭션 A가 자원 1을 잡고 자원 2를 기다리는데, 트랜잭션 B는 자원 2를 잡고 자원 1을 기다리는 상황입니다. 좁은 골목길에서 서로 마주 본 자동차 두 대가 "네가 먼저 비켜"라고 신경전을 벌이며 영원히 멈춰 있는 것과 완벽히 동일합니다. PostgreSQL은 이런 데드락을 감지하면 일정 시간(기본 1초) 후 하나를 강제로 에러 처리하지만, 복잡한 상황에서는 감지가 늦어질 수 있습니다.
제 경험상, 실제 운영 환경에서 발생하는 락 이슈의 약 70%는 순수한 데드락보다는 '장기 실행 트랜잭션에 의한 블로킹(Blocking)'인 경우가 더 많습니다. 누군가가 데이터를 수정하려고 락을 걸어놓고는(예: UPDATE 문 실행), 커밋(COMMIT)도 롤백(ROLLBACK)도 하지 않은 채 네트워크 이슈로 연결이 끊기거나 로직 오류로 멈춰버린 상황입니다. 이를 'Idle in transaction' 상태라고 부르는데, 뒤이어 들어온 수백 개의 요청들이 이 하나 때문에 줄줄이 대기 상태에 빠지게 됩니다. 이것이 서버가 멈춘 것처럼 보이는 주원인입니다.
MVCC와 락의 관계, 그리고 오해
많은 분들이 오해하는 것 중 하나가 "PostgreSQL은 MVCC(다중 버전 동시성 제어)를 쓰니까 락이 안 걸리는 거 아니에요?"라는 질문입니다. 반은 맞고 반은 틀립니다. MVCC 덕분에 '읽기(SELECT)' 작업은 '쓰기(UPDATE/INSERT)' 작업을 방해하지 않습니다. 즉, 누군가 데이터를 고치고 있어도 다른 사람은 그 전 버전의 스냅샷 데이터를 읽을 수 있습니다. 이는 엄청난 성능 이점이며, 오라클 같은 다른 DB와 차별화되는 점이기도 합니다.
하지만 '쓰기'와 '쓰기'가 만날 때는 이야기가 다릅니다. 같은 행(Row)을 동시에 수정하려고 하면, 반드시 한쪽은 기다려야 합니다. 이를 'Row Exclusive Lock'이라고 합니다. 더 무서운 것은 DDL(테이블 구조 변경) 작업입니다. `ALTER TABLE`이나 `CREATE INDEX` 같은 명령어는 테이블 전체에 락을 걸기도 하는데, 트래픽이 많은 운영 시간에 이런 명령어를 무심코 날렸다가 전체 서비스가 30분간 중단된 사례도 목격했습니다. 락은 데이터 보호를 위한 필수 불가결한 존재이지만, 잘못 다루면 서비스의 목을 조르는 양날의 검이 됩니다.
탐정의 도구: pg_stat_activity 뷰 완벽 해부
PostgreSQL의 CCTV, pg_stat_activity
문제가 생겼을 때 가장 먼저 봐야 할 곳은 바로 `pg_stat_activity` 시스템 뷰입니다. 이것은 현재 데이터베이스에 접속해 있는 모든 세션의 상태를 실시간으로 보여주는 고해상도 CCTV와 같습니다. 누가 접속해 있는지, 어떤 쿼리를 날리고 있는지, 현재 쉬고 있는지 일하고 있는지, 그리고 가장 중요한 '누구를 기다리고 있는지'를 적나라하게 보여줍니다. 이 뷰를 조회하지 않고 DB 문제를 해결하려는 것은 눈을 감고 운전하는 것과 같습니다.
이 뷰를 조회했을 때 수많은 컬럼이 나와서 당황스러울 수 있습니다. 하지만 트러블슈팅을 위해 꼭 봐야 할 핵심 컬럼은 6개 정도로 압축됩니다. `pid`(프로세스 ID), `usename`(사용자명), `state`(현재 상태), `query`(실행 중인 SQL), `wait_event_type`(대기 종류), `wait_event`(대기 세부 내용)가 그것입니다.
댓글
댓글 쓰기