고급 DB 장애와 한계
3줄 요약
- 고급 DB 장애는 평소에는 잘 보이지 않지만 트래픽, 데이터량, 배포, 장애 복구가 겹칠 때 갑자기 드러난다.
- Lock 경합, connection 고갈, replica lag, hot row, vacuum/bloat/WAL 문제는 백엔드 코드와 운영 환경이 함께 만든다.
- 전문 백엔드 개발자는 이런 문제를 “DB가 느리다”로 뭉개지 않고, 증상과 지표와 코드 패턴을 연결해 완화책과 구조 개선을 구분한다.
핵심 정리
- Lock 경합은 특정 행, 범위, 테이블, 메타데이터를 여러 트랜잭션이 동시에 필요로 할 때 발생한다. 인덱스 부재와 긴 트랜잭션은 잠금 범위를 키운다.
- Connection 고갈은 느린 쿼리, 락 대기, 외부 호출 포함 트랜잭션, 과도한 pool size, DB max connections 부족이 합쳐질 때 생긴다.
- Replica lag는 read replica가 primary 변경을 따라오지 못하는 현상이다. 방금 쓴 데이터를 replica에서 읽는 read-after-write 요구사항과 충돌한다.
- Hot row는 많은 요청이 같은 행을 업데이트할 때 생긴다. 좋아요 수, 조회수, 재고, 포인트 잔액, 전역 설정 row가 대표적이다.
- PostgreSQL의 MVCC 환경에서는 오래 열린 트랜잭션이 vacuum을 방해하고, bloat와 WAL 증가가 성능과 저장 공간 문제로 이어질 수 있다.
- MySQL InnoDB에서는 gap lock, next-key lock, metadata lock 같은 엔진 특성을 이해해야 “왜 이 쿼리가 저 쿼리를 막지?”라는 상황을 설명할 수 있다.
- 고급 장애는 대개 단일 지표만으로 보이지 않는다. active session, wait event, pool pending, replica lag, WAL/binlog 증가, long transaction, 배포/배치 타임라인을 함께 묶어야 한다.
- 완화는 구조 개선보다 먼저다. batch 중지, rate limit, retry 차단, primary read 전환, 문제 기능 feature flag 같은 조치로 압력을 낮춘 뒤 근본 원인을 고친다.
헷갈리는 지점
- 잘 일어나지 않는 문제는 몰라도 된다고 생각하기 쉽다. 대부분의 개발 기간에는 재현되지 않기 때문이다.
- 핵심은 드문 문제가 발생했을 때 영향 범위가 매우 크다는 점이다.
- 미리 증상과 지표를 알아두면 장애 중 판단 시간이 줄어든다.
- Replica를 붙이면 읽기 성능과 정합성이 모두 좋아진다고 오해하기 쉽다. 읽기 부하 분산이 직관적으로 좋아 보이기 때문이다.
- 핵심은 replica가 비동기 지연을 가질 수 있다는 점이다.
- 최신성이 중요한 읽기는 primary로 보내거나 세션 일관성 전략을 둬야 한다.
- Hot row 문제는 DB 스펙을 올리면 해결된다고 생각하기 쉽다. CPU나 IOPS 부족처럼 보이기 때문이다.
- 핵심은 같은 행을 직렬로 업데이트해야 하는 구조적 병목이라는 점이다.
- 샤딩된 카운터, 이벤트 적재 후 집계, 큐잉, 원자적 조건 업데이트를 검토한다.
- Vacuum, WAL, replica lag는 인프라만의 문제라고 생각하기 쉽다. 용어가 운영 내부처럼 보이기 때문이다.
- 핵심은 긴 트랜잭션, 대량 update/delete, hot row, backfill을 만드는 쪽이 백엔드 코드일 수 있다는 점이다.
- 작업 전 row 수, batch size, 실행 시간대, 중단 기준을 인프라와 맞춰야 한다.
확인 질문
- Replica lag가 사용자에게 어떤 버그로 보일 수 있는가?
- 저장 직후 조회했는데 방금 쓴 데이터가 보이지 않거나, 상태 변경 후 이전 상태가 다시 보이는 것처럼 보일 수 있다.
- Connection 고갈이 전체 장애로 번지는 이유는 무엇인가?
- DB 커넥션을 얻지 못한 요청 스레드가 쌓이고, 대기 시간이 늘며, 정상 API까지 같은 풀을 기다리게 되기 때문이다.
- Hot row를 의심해야 하는 대표 상황은 무엇인가?
- 많은 요청이 같은 상품 재고, 같은 게시글 카운터, 같은 사용자 잔액, 같은 전역 설정 행을 동시에 업데이트할 때다.
- 고급 DB 장애에서 타임라인을 함께 봐야 하는 이유는 무엇인가?
- 배포, batch, migration, 트래픽 증가, replica lag, pool pending, wait event가 서로 영향을 주며 장애를 증폭하기 때문이다.