DBA와 소통하기 위한 DB 모니터링 지표 기초

핵심 요약

DB 일일 점검 자동화 POC를 진행하면서 가장 먼저 막힌 부분은 알고리즘이 아니라 지표 그 자체였습니다. 저는 백엔드 개발자라 DBA가 매일 보는 지표(Active Session, Row Lock Waits, Redo, Vacuum 같은 것들)가 무엇을 뜻하는지, 어떤 값이 정상이고 어떤 값이 위험인지, 그리고 그 값이 이상하면 무엇을 들여다봐야 하는지를 몰랐습니다. 자동 점검 시스템을 만들려면 결국 이 지표들을 제가 이해하고 있어야 했습니다.

이 글은 그 과정에서 정리한 내용입니다. DB 모니터링에서 자주 보는 지표를 9개 묶음(CPU·세션·연결·락·장기쿼리·쓰기·IO·메모리·스토리지)으로 나누고, 각 지표가 무엇을 의미하는지, 일상적인 비유로 어떻게 이해하면 되는지, Oracle·MySQL·PostgreSQL에서 각각 어떤 SQL로 직접 확인하는지, 그리고 실제로 어떤 장애 상황에서 그 지표가 뜨는지를 사례와 함께 적었습니다. DBA와 대화할 때 최소한 같은 언어로 말하기 위한 기초 정리라고 보시면 됩니다.

1. 왜 지표부터 알아야 했나

점검 자동화의 목표는 단순합니다. 사람이 매일 아침 콘솔을 열어 "어제 이 DB에 이상한 일이 있었나"를 눈으로 확인하던 일을, 시스템이 대신 보고 이상하면 알려주는 것입니다. 그런데 "이상하다"를 코드로 판단하려면 먼저 무엇을 측정한 값인지를 알아야 합니다. 예를 들어 어떤 지표가 27이라는 값을 가졌을 때, 그게 평소 0~2이던 값이 튄 것인지 아니면 원래 수백까지도 가는 값인지 모르면 임계값조차 정할 수 없습니다.

비유하자면 건강검진 결과표를 처음 받아 든 상황과 같습니다. 혈압 120이라는 숫자가 정상인지 위험인지는 "정상 범위가 얼마인가"를 알아야 판단할 수 있습니다. DB 지표도 똑같습니다. 그래서 임계값 기준표를 받고, 한 달치 실제 데이터를 열어보고, DBA가 쓰는 확인 쿼리를 하나씩 따라 쳐보면서 각 지표의 정상 범위 감각을 익혔습니다. 아래는 그렇게 정리한 결과입니다.

2. 모니터링 리포트를 읽는 기본 틀

대부분의 점검 리포트는 지표를 표로 보여줍니다. 칸의 의미는 다음과 같습니다.

칸	의미
지표	무엇을 측정했는가 (예: 활성 세션 수)
대표값	그 시간대의 대표 측정값. 보통 1분 평균을 하루로 모았을 때의 최댓값 또는 대표 통계
임계	위험으로 판단하는 경계선. 이 값을 넘으면 경고
전일대비	어제 같은 값 대비 몇 배인가. 절대값은 정상이어도 급증이면 의심
상태	정상 / 주의 / 위험

핵심 판단은 두 가지입니다. 첫째, 대표값이 임계를 넘었는가(절대 기준). 둘째, 전일 대비 급증했는가(상대 기준). 좋은 점검은 이 둘을 같이 봅니다. 임계는 안 넘었지만 평소의 다섯 배로 뛰었다면 그것도 신호이기 때문입니다.

지표를 볼 때는 항상 "이 값의 평소 범위가 얼마인가"를 같이 기억해야 합니다. 같은 100이라도 어떤 지표는 정상이고 어떤 지표는 비상입니다.

3. 지표를 9개 묶음으로 나누기

지표는 수십 개지만, 결국 DB가 일하는 몇 가지 측면을 나눠 본 것입니다. 아래 9개 묶음으로 이해하면 처음 보는 지표도 "아, 이건 락 쪽이구나" 하고 분류할 수 있습니다.

묶음	대표 지표	한 줄 의미
CPU	CPU 사용률	서버가 연산으로 얼마나 바쁜가
세션	Active Session / Active Backend	지금 실제로 일하는 접속이 몇 개인가
연결	Connections / Threads Connected	맺어진 커넥션이 몇 개인가
락(잠금)	Row Lock Waits / Locks Waiting	같은 데이터를 두고 줄 서서 기다리는가
장기쿼리	Long Active / Trx Time	오래 끝나지 않는 쿼리가 있는가
쓰기	Redo / Undo / Insert·Update	변경 작업이 얼마나 몰리는가
IO	IOPS / TPS / Reads	디스크 읽기·쓰기가 얼마나 많은가
메모리	Free Memory	여유 메모리가 충분한가
스토리지	Free Storage	디스크 공간이 충분한가

이제 각 묶음을 하나씩, 비유와 실제 사례, 확인 쿼리와 함께 보겠습니다. 쿼리는 Oracle / MySQL / PostgreSQL 순서로 적었고, 클라우드 관리형 DB(RDS 등)에서는 일부 지표를 SQL이 아니라 클라우드 모니터링(예: CloudWatch)에서 보는 경우도 함께 적었습니다.

4. CPU 사용률

뜻: 서버 CPU가 얼마나 바쁜지를 백분율로 나타냅니다. 80%를 꾸준히 넘으면 연산이 한계에 가까운 것입니다. 보통 무거운 쿼리, 비효율적인 실행계획, 트래픽 급증이 원인입니다.

비유: CPU 사용률은 주방장 한 명이 동시에 처리하는 주문량과 같습니다. 주문이 적당하면 여유 있게 돌아가지만, 한 번에 몰리면 모든 요리가 동시에 느려집니다. 중요한 점은 CPU가 높다는 건 "바쁘다"는 결과일 뿐, 왜 바쁜지는 따로 봐야 한다는 것입니다.

언제 보나: 응답이 전반적으로 느려질 때 가장 먼저 봅니다. 다만 CPU는 결과이지 원인이 아닌 경우가 많아서, CPU가 높으면 "무엇이 CPU를 쓰고 있나"(장기쿼리·세션)를 이어서 봐야 합니다.

실제 사례: 어느 오후 CPU가 50%대에서 90%로 올랐습니다. 처음에는 트래픽이 몰린 줄 알았지만, 접속 수는 평소와 같았습니다. 장기쿼리 지표를 같이 보니 통계용 집계 쿼리 하나가 인덱스를 타지 못하고 전체 테이블을 훑고 있었습니다. CPU는 증상이었고, 범인은 쿼리 하나였습니다.

확인: 관리형 DB에서는 CPU 사용률을 클라우드 모니터링 지표로 보는 게 가장 정확합니다. DB 내부에서 간접 확인은 다음과 같습니다.

-- Oracle: 최근 CPU 관련 시스템 지표
SELECT metric_name, value
FROM   v$sysmetric
WHERE  metric_name LIKE 'Host CPU%';

-- MySQL: CPU를 많이 쓰는 쿼리 후보(실행 시간 누적 상위)
SELECT digest_text, count_star, sum_timer_wait
FROM   performance_schema.events_statements_summary_by_digest
ORDER  BY sum_timer_wait DESC
LIMIT  10;

-- PostgreSQL: 활성 쿼리 중 오래 도는 것(CPU 소비 후보)
SELECT pid, now() - query_start AS run_time, query
FROM   pg_stat_activity
WHERE  state = 'active'
ORDER  BY run_time DESC;

5. 세션과 연결

이 둘은 자주 헷갈리는데 구분이 중요합니다.

• 연결(Connection): 애플리케이션이 DB에 맺어 둔 통로. 일을 하지 않아도 열려 있을 수 있습니다.
• 활성 세션(Active Session): 그 연결 중 지금 실제로 쿼리를 실행 중인 것.

비유: 식당으로 비유하면 연결은 "예약해 둔 좌석"이고, 활성 세션은 "지금 주문해서 요리를 받고 있는 테이블"입니다. 좌석을 100개 예약해 둬도 실제 주문이 5개면 주방은 한가합니다. 반대로 예약 좌석이 가게 정원을 꽉 채우면, 새 손님은 자리가 없어 들어오지도 못합니다.

언제 보나: 연결 수가 한계(max_connections)에 가까우면 새 접속이 거부되어 장애로 이어집니다. 활성 세션이 평소보다 급증하면 쿼리가 빨리 안 끝나고 쌓이고 있다는 신호입니다.

실제 사례: 애플리케이션 배포 후 커넥션 풀이 연결을 제대로 반납하지 않는 설정 실수가 있었습니다. 일을 끝낸 연결이 닫히지 않고 계속 쌓여, Threads_connected가 천천히 올라 결국 max_connections에 도달했습니다. 그 순간부터 새 요청은 "too many connections" 오류로 전부 거부됐습니다. 활성 세션은 적은데 연결만 가득 찬, 전형적인 커넥션 누수였습니다.

-- Oracle: 전체 연결 / 활성 세션
SELECT status, COUNT(*) FROM v$session GROUP BY status;   -- ACTIVE / INACTIVE
SELECT resource_name, current_utilization, limit_value
FROM   v$resource_limit
WHERE  resource_name IN ('sessions','processes');

-- MySQL: 연결 수와 상한
SHOW STATUS LIKE 'Threads_connected';
SHOW VARIABLES LIKE 'max_connections';
SHOW PROCESSLIST;   -- 각 연결이 무엇을 하는지

-- PostgreSQL: 상태별 접속 수
SELECT state, COUNT(*) FROM pg_stat_activity GROUP BY state;
SHOW max_connections;

리포트에서 "Active Session"이 임계를 넘었다면, 위 쿼리로 지금 무슨 쿼리들이 active 상태인지 바로 확인할 수 있습니다.

6. 락(잠금)

뜻: DB는 같은 데이터를 동시에 고치면 데이터가 깨지므로, 한 작업이 데이터를 고치는 동안 다른 작업은 기다리게 합니다. 이 "기다림"이 늘어난 것이 락 대기 지표입니다. 우리 리포트의 Innodb Row Lock Waits(MySQL), Locks Waiting(PostgreSQL)이 여기 해당합니다.

비유: 한 칸짜리 공용 화장실과 같습니다. 한 사람이 들어가 문을 잠그면 다른 사람들은 밖에서 기다려야 합니다. 그 사람이 빨리 나오면 문제가 없지만, 안에서 한참 안 나오면 줄이 길어집니다. 락 대기 지표가 높다는 건 이 대기 줄이 길어졌다는 뜻입니다.

언제 보나: 특정 화면이나 기능만 "멈춘 것처럼" 느려질 때 전형적인 원인입니다. 한 트랜잭션이 데이터를 오래 붙잡고 커밋을 안 하면, 그 데이터를 건드리려는 다른 작업들이 줄줄이 대기합니다.

실제 사례: 한 운영자가 관리 도구에서 특정 주문 행을 수정하는 트랜잭션을 열어 둔 채 자리를 비웠습니다(커밋도 롤백도 하지 않은 상태). 그 사이 같은 주문을 갱신하려던 결제 처리들이 전부 그 행의 잠금이 풀리기를 기다리며 멈췄습니다. Row Lock Waits가 평소 2에서 수십으로 튀었고, 결제 화면이 "멈춘 것처럼" 느려졌습니다. 막고 있던 트랜잭션을 찾아 종료하자 즉시 풀렸습니다.

-- Oracle: 누가 누구를 막고 있는가(blocker / waiter)
SELECT blocking_session, sid, serial#, username, event
FROM   v$session
WHERE  blocking_session IS NOT NULL;

-- MySQL: 잠금 대기 관계와 대기 중인 트랜잭션
SELECT * FROM performance_schema.data_lock_waits;
SELECT trx_id, trx_state, trx_started, trx_query
FROM   information_schema.innodb_trx
ORDER  BY trx_started;
-- 상세 진단: SHOW ENGINE INNODB STATUS;

-- PostgreSQL: 허가되지 않은(대기 중) 잠금과 막는 쪽
SELECT pid, relation::regclass, mode, granted
FROM   pg_locks
WHERE  NOT granted;
SELECT pid, pg_blocking_pids(pid) AS blocked_by, query
FROM   pg_stat_activity
WHERE  cardinality(pg_blocking_pids(pid)) > 0;

락은 거의 항상 "오래 커밋 안 한 트랜잭션 하나"가 범인입니다. 그래서 락 지표가 뜨면 그 막고 있는 세션(blocker)을 찾아 무슨 쿼리인지 보는 게 첫 단계입니다.

7. 장기 실행 쿼리

뜻: 보통 쿼리는 밀리초 단위로 끝납니다. 몇 분씩 도는 쿼리가 있다는 것은 인덱스를 안 탔거나, 대량 데이터를 훑거나, 잠금에 걸려 있다는 뜻입니다. 우리 리포트의 Long Active Threads(MySQL), Long Active Backend(PostgreSQL), Trx Time이 여기 해당합니다.

비유: 마트 계산대에서 앞 손님 한 명이 영수증 문제로 오래 붙잡으면, 뒤에 선 사람들이 전부 밀립니다. 장기 쿼리 하나가 딱 그 손님 역할을 합니다. 자기만 느린 게 아니라 뒤따르는 작업과 자원을 같이 묶어 버립니다.

언제 보나: 위의 CPU·락·세션 지표가 떴을 때 그 원인을 찾는 단계에서 봅니다. 장기 쿼리 하나가 CPU도 쓰고, 락도 잡고, 세션도 점유하는 경우가 많아서 사실상 출발점입니다.

실제 사례: 새로 추가된 관리자 통계 화면에서 WHERE 조건이 빠진 집계 쿼리가 들어갔습니다. 수백만 건 테이블을 통째로 스캔하느라 한 번 실행에 5분씩 걸렸고, 그 시간 동안 CPU와 디스크 읽기가 같이 올랐습니다. 장기쿼리 목록에서 그 쿼리를 발견해 조건과 인덱스를 추가하자, 실행 시간이 5분에서 0.2초로 줄었습니다.

-- Oracle: 60초 이상 실행 중인 활성 세션
SELECT sid, serial#, username, last_call_et AS sec_running, sql_id
FROM   v$session
WHERE  status = 'ACTIVE' AND last_call_et > 60
ORDER  BY last_call_et DESC;
-- sql_id 로 실제 쿼리 텍스트 조회: SELECT sql_text FROM v$sql WHERE sql_id = '...';

-- MySQL: 60초 이상 도는 쿼리
SELECT id, user, time, state, info
FROM   information_schema.processlist
WHERE  command = 'Query' AND time > 60
ORDER  BY time DESC;

-- PostgreSQL: 1분 이상 active 인 쿼리
SELECT pid, now() - query_start AS run_time, state, query
FROM   pg_stat_activity
WHERE  state = 'active' AND now() - query_start > interval '1 minute'
ORDER  BY run_time DESC;

8. 쓰기 부하 (Redo / Undo / Commit)

변경 작업(INSERT·UPDATE·DELETE)이 많을 때 오르는 지표들입니다. 용어가 낯설어서 짧게 정리합니다.

• Redo(Oracle): 변경 내용을 복구용으로 적어 두는 로그. 쓰기가 많으면 redo 생성량이 늘어납니다. (PostgreSQL의 WAL, MySQL의 InnoDB redo log가 같은 개념입니다.)
• Undo(Oracle): 변경을 되돌릴(롤백) 수 있도록 이전 값을 보관하는 영역. 큰 트랜잭션이 길게 돌면 undo가 커집니다.
• Commit / Insert·Update 카운트: 단위 시간당 변경·확정 작업 수. 배치가 돌면 급증합니다.

비유: 은행 장부를 떠올리면 됩니다. redo는 "무슨 거래를 했는지 그대로 적어 두는 기록"이라 나중에 사고가 나도 장부를 보고 복구할 수 있습니다. undo는 "취소를 대비해 보관하는 거래 전 잔액"입니다. 거래가 많은 날일수록 두 기록 모두 두꺼워집니다.

언제 보나: 야간 배치, 대량 적재(bulk load), 대량 삭제 같은 작업이 돌 때 오릅니다. 이 지표들의 급증 자체는 정상일 수 있지만, "평소 이 시간대에는 없던 쓰기"가 보이면 예정에 없던 작업을 의심합니다.

실제 사례: 평소 새벽에만 오르던 redo 생성량이 한낮에 평소의 두 배로 튀었습니다. 확인해 보니 누군가 운영 DB에서 대량 UPDATE를 수동으로 실행하고 있었습니다. 장애는 아니었지만, "이 시간대에 없어야 할 쓰기"라는 신호 덕분에 예정에 없던 작업을 빨리 파악할 수 있었습니다.

-- Oracle: redo 생성량 / 활성 트랜잭션의 undo 사용
SELECT name, value FROM v$sysstat
WHERE  name IN ('redo size','redo entries','user commits');
SELECT s.sid, t.used_ublk AS undo_blocks, t.status
FROM   v$transaction t JOIN v$session s ON t.addr = s.taddr;

-- MySQL: 변경 작업 카운터 / redo 쓰기량
SHOW GLOBAL STATUS WHERE Variable_name IN
  ('Com_insert','Com_update','Com_delete','Innodb_os_log_written');

-- PostgreSQL: 커밋/롤백 추이와 WAL 위치
SELECT datname, xact_commit, xact_rollback
FROM   pg_stat_database
WHERE  datname = current_database();
SELECT pg_current_wal_lsn();   -- WAL 진행 지점(증가 속도로 쓰기량 가늠)

9. IO (IOPS / TPS / Reads)

뜻: 디스크나 스토리지에 대한 읽기·쓰기 요청량입니다. IOPS는 초당 입출력 횟수, TPS는 초당 트랜잭션 수, physical reads / blks read는 메모리에 없어서 디스크에서 직접 읽어 온 양입니다.

비유: 도서관에서 일하는 모습과 같습니다. 자주 보는 책을 책상 위(메모리)에 두면 손만 뻗으면 됩니다. 그런데 필요한 책이 책상에 없어 매번 서가(디스크)까지 걸어가 가져와야 한다면, 같은 일을 해도 훨씬 느려집니다. physical reads가 늘었다는 건 "서가까지 걸어가는 횟수"가 늘었다는 뜻입니다.

언제 보나: 디스크에서 직접 읽는 양(physical reads)이 갑자기 늘면, 캐시(버퍼)에 없는 데이터를 자꾸 읽는다는 뜻이라 비효율적인 쿼리나 대량 스캔을 의심합니다. 관리형 DB에서는 IOPS 한도를 넘으면 throttling(속도 제한)이 걸려 전체가 느려집니다.

실제 사례: 캐시 적중률이 평소 99%대에서 85%로 떨어진 적이 있습니다. 새 배치가 인덱스 없는 컬럼으로 대량 조회를 하면서, 캐시에 없는 데이터를 디스크에서 계속 읽어 온 것입니다. physical reads가 급증했고, 관리형 DB의 IOPS 한도에 가까워지면서 그 시간대 전체 쿼리가 느려졌습니다. 배치에 인덱스를 추가하자 적중률이 회복됐습니다.

-- Oracle: 물리 읽기/쓰기 통계
SELECT name, value FROM v$sysstat
WHERE  name IN ('physical reads','physical writes','session logical reads');

-- MySQL: InnoDB 디스크 읽기와 버퍼풀 요청(캐시 효율 비교)
SHOW GLOBAL STATUS WHERE Variable_name IN
  ('Innodb_data_reads','Innodb_buffer_pool_reads','Innodb_buffer_pool_read_requests');

-- PostgreSQL: 디스크 읽기 vs 캐시 적중
SELECT datname, blks_read, blks_hit,
       round(blks_hit*100.0 / nullif(blks_hit + blks_read,0), 2) AS cache_hit_pct
FROM   pg_stat_database
WHERE  datname = current_database();

여기서 캐시 적중률(cache hit ratio)은 중요한 감각입니다. 보통 99% 이상이 건강한 상태이고, 이 값이 떨어지면 디스크 읽기가 늘어 성능이 나빠집니다.

10. 메모리

뜻: DB는 데이터를 메모리(버퍼/캐시)에 올려 두고 일합니다. 여유 메모리가 부족하면 캐시가 줄어 디스크 읽기가 늘고, 심하면 작업이 실패합니다.

비유: 메모리는 작업 책상의 넓이입니다. 책상이 넓으면 자주 쓰는 자료를 펼쳐 두고 바로 꺼내 쓰지만, 책상이 좁으면 매번 서랍(디스크)을 여닫아야 합니다. 9번의 IO 문제와 메모리 부족이 자주 같이 나타나는 이유입니다.

언제 보나: 여유 메모리가 지속적으로 줄어드는 추세이면 메모리 누수나 과도한 연결을 의심합니다. 관리형 DB에서는 FreeableMemory 지표를 추세로 봅니다.

-- Oracle: SGA / PGA 메모리 구성
SELECT name, round(value/1024/1024) AS mb FROM v$sga;
SELECT name, value FROM v$pgastat WHERE name = 'total PGA allocated';

-- MySQL: InnoDB 버퍼풀 크기와 사용
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW STATUS LIKE 'Innodb_buffer_pool_pages_free';

-- PostgreSQL: 공유 버퍼 설정(여유 메모리 자체는 OS/클라우드 지표로)
SHOW shared_buffers;

11. 스토리지

뜻: 데이터가 쌓이는 디스크 공간입니다. 가득 차면 더 이상 쓰기를 못 해 DB가 멈춥니다. 가장 단순하지만 한 번 터지면 치명적입니다.

비유: 창고와 같습니다. 물건이 계속 들어오는데 비우지 않으면 언젠가 가득 차고, 그 순간부터는 아무것도 더 넣을 수 없습니다. 중요한 건 "지금 얼마나 찼나"보다 "이 속도면 며칠 뒤 가득 차나"입니다.

언제 보나: 여유 공간이 빠르게 줄어드는 추세를 봅니다. 절대 사용률(예: 85%)보다도 "며칠이면 가득 차는가"라는 속도가 중요합니다.

실제 사례: 로그 테이블을 정리하는 배치가 어느 날 조용히 실패했습니다. 매일 쌓이기만 하고 비워지지 않으니 여유 공간이 일정한 속도로 줄었습니다. 절대 사용률은 아직 70%대라 임계 경고는 안 떴지만, "줄어드는 추세"를 보고 며칠 뒤 가득 찰 것을 미리 알 수 있었습니다. 추세를 보는 것이 절대값만 보는 것보다 나았던 사례입니다.

-- Oracle: 테이블스페이스 사용률
SELECT tablespace_name, used_percent
FROM   dba_tablespace_usage_metrics
ORDER  BY used_percent DESC;

-- MySQL: 스키마별 데이터 크기
SELECT table_schema, round(SUM(data_length+index_length)/1024/1024) AS mb
FROM   information_schema.tables
GROUP  BY table_schema
ORDER  BY mb DESC;

-- PostgreSQL: 데이터베이스 크기
SELECT datname, pg_size_pretty(pg_database_size(datname)) AS size
FROM   pg_database
ORDER  BY pg_database_size(datname) DESC;

관리형 DB의 전체 여유 공간은 보통 클라우드 모니터링의 FreeStorageSpace 지표로 봅니다.

12. DB별 특화 지표

위 9개 묶음은 공통이고, DB마다 따로 챙기는 대표 지표가 있습니다.

Oracle 테이블스페이스

Oracle은 데이터를 테이블스페이스 단위로 관리합니다. 비유하면 큰 창고를 용도별 칸으로 나눠 둔 것입니다. 전체 창고에 공간이 남아도 특정 칸이 가득 차면 그 칸에 넣어야 할 물건만 못 넣습니다. 그래서 전체 디스크와 별개로 테이블스페이스별 사용률을 따로 챙깁니다. 확인은 위 11번의 dba_tablespace_usage_metrics를 씁니다.

MySQL 복제 지연 (Replication Lag)

읽기 부하를 분산하려고 복제본(replica)을 두는데, 원본의 변경이 복제본에 늦게 도착하면 그만큼 오래된 데이터를 읽게 됩니다. 비유하면 신문 본사(원본)와 지방 배송본(복제본)의 관계입니다. 배송이 늦으면 지방에서는 어제 뉴스를 오늘 읽는 셈입니다.

실제 사례: 사용자가 방금 저장한 글이 새로고침하면 사라졌다 나타났다 하는 문제가 있었습니다. 쓰기는 원본에, 읽기는 복제본에서 했는데 복제 지연이 몇 초 있어서, 방금 쓴 데이터가 아직 복제본에 도착하지 않은 것이었습니다. 복제 지연 지표가 0에서 멀어지면 이런 현상을 의심합니다.

-- MySQL: 복제 지연(초). 0에 가까워야 정상
SHOW REPLICA STATUS;   -- Seconds_Behind_Source 열 확인
-- (관리형 Aurora 등에서는 ReplicaLag 모니터링 지표로 봄)

PostgreSQL Dead Tuple와 Vacuum

PostgreSQL은 행을 UPDATE·DELETE해도 즉시 지우지 않고 "죽은 행(dead tuple)"으로 표시만 해 둡니다. 이게 쌓이면 테이블이 비대해지고 조회가 느려집니다. 이를 청소하는 작업이 VACUUM이며, 보통 autovacuum이 자동으로 돌지만 변경이 많으면 못 따라갈 수 있습니다.

비유: 사무실에서 버린 서류를 그때그때 갖다 버리지 않고 책상 옆에 쌓아 두는 것과 같습니다. 처음엔 괜찮지만 쌓일수록 필요한 서류를 찾기가 느려집니다. VACUUM은 이 쌓인 폐지를 치우는 청소부이고, 청소부가 일이 밀리면 책상이 점점 지저분해집니다.

실제 사례: 대량 UPDATE 배치를 돌린 뒤 특정 테이블의 조회가 점점 느려졌습니다. dead tuple이 급증했는데 autovacuum이 그 속도를 못 따라가 청소가 밀린 상태였습니다. 수동으로 VACUUM을 돌리고 autovacuum 설정을 그 테이블에 맞게 조정하자 조회 속도가 회복됐습니다.

-- PostgreSQL: 죽은 행이 많은 테이블과 마지막 vacuum 시각
SELECT relname, n_live_tup, n_dead_tup, last_autovacuum
FROM   pg_stat_user_tables
ORDER  BY n_dead_tup DESC
LIMIT  10;

죽은 행 비율이 높고 last_autovacuum이 오래전이면, vacuum이 밀리고 있다는 신호입니다.

13. 실제 사례로 리포트 한 줄 읽어보기

점검 리포트에 다음과 같은 한 줄이 떴다고 합시다.

지표: Innodb Row Lock Waits   대표값: 27   임계: 2   상태: 위험

이걸 읽는 순서는 이렇습니다.

• 분류: "Lock"이 들어갔으니 락(잠금) 묶음. 같은 데이터를 두고 기다린 상황.
• 심각도: 평소 0~2이던 값이 27. 임계 2를 한참 넘었으니 경합이 분명히 있었다.
• 확인: MySQL에 붙어 6번의 쿼리를 실행한다.

-- 1) 지금 대기 관계가 있나
SELECT * FROM performance_schema.data_lock_waits;
-- 2) 오래된(=막고 있을 가능성) 트랜잭션 찾기
SELECT trx_id, trx_state, trx_started, trx_query
FROM   information_schema.innodb_trx
ORDER  BY trx_started ASC
LIMIT  5;

가장 오래된 트랜잭션의 trx_query를 보면 무엇이 데이터를 붙잡고 있었는지 드러납니다. 보통 커밋을 빠뜨린 배치나, 사람이 열어 둔 트랜잭션이 범인입니다. 자동 점검 시스템은 여기까지(어떤 지표가 언제 얼마나 튀었는지 + 어디를 보면 되는지)를 메일로 알려 주고, 실제 조치는 사람이 위 쿼리로 확인한 뒤 판단합니다.

14. 지표는 혼자 움직이지 않는다

지금까지 지표를 묶음별로 나눠 봤지만, 실제 장애에서는 여러 지표가 한꺼번에 움직입니다. 앞의 사례들을 모아 보면 하나의 연쇄가 보입니다.

장기 쿼리 하나가 들어온다 → 그 쿼리가 CPU를 쓰고(CPU 상승) → 데이터를 오래 붙잡아 다른 작업을 막고(락 대기 상승) → 기다리는 작업이 쌓이며(활성 세션 상승) → 끝나지 않은 연결이 누적된다(연결 수 상승).

그래서 여러 지표가 동시에 떴을 때, 각각을 따로 보는 것보다 "무엇이 이 연쇄의 출발점인가"를 찾는 게 빠릅니다. 대부분의 경우 그 출발점은 장기 실행 쿼리 하나입니다. 어제 만든 패턴 탐지(여러 지표의 조합이 평소와 다른지를 보는 방식)가 의미 있는 이유도 여기 있습니다. 지표 하나가 아니라 "같이 움직이는 모양"을 보면 이런 연쇄를 더 빨리 잡을 수 있기 때문입니다.

15. DBA와 대화할 때

지표를 알고 나면 대화가 구체적이 됩니다. "DB가 느려요" 대신 이렇게 말할 수 있습니다.

• "어제 오후 2시쯤 Row Lock Waits가 평소 2에서 27로 튀었는데, 그 시간대에 막고 있던 트랜잭션이 있었을까요?"
• "physical reads가 늘고 캐시 적중률이 떨어졌는데, 인덱스 안 타는 쿼리가 새로 들어왔을 가능성이 있을까요?"
• "PostgreSQL dead tuple이 쌓이는데 autovacuum 주기를 조정해야 할까요?"

지표의 이름과 평소 범위, 그리고 그 지표가 뜨면 무엇을 보는지를 알면, DBA의 판단을 이해하고 자동 점검 시스템에 그 판단 기준을 옮길 수 있습니다. 결국 점검 자동화는 이 도메인 지식을 코드로 옮기는 작업이었습니다.

16. 핵심 정리

• 지표는 9개 묶음(CPU·세션·연결·락·장기쿼리·쓰기·IO·메모리·스토리지)으로 나누면 처음 보는 것도 분류된다.
• 판단은 임계 초과와 전일 대비 급증 두 축으로 본다. 절대값과 추세를 같이 본다.
• 지표마다 평소 범위 감각이 있어야 한다. 같은 숫자라도 지표에 따라 정상과 비상이 갈린다.
• 락·CPU·세션이 뜨면 거의 항상 장기 실행 쿼리가 출발점이다. 그것부터 찾는다.
• 지표는 혼자 움직이지 않는다. 동시에 여러 개가 뜨면 연쇄의 출발점을 찾는다.
• DB별 특화 지표(Oracle 테이블스페이스, MySQL 복제 지연, PostgreSQL dead tuple)는 따로 챙긴다.

다음 글에서는 이 지표들을 실제 점검 자동화 코드에서 어떻게 임계값과 패턴 판정으로 옮겼는지 이어서 정리하겠습니다.