인덱스 하나 잘못 지워서
4시간 멈춘 이야기

6월 9일 화요일 오전 10시 4분, 저희는 프로덕션 데이터베이스에서 복합 인덱스 하나를 제거했습니다. 지난 90일간 쿼리 통계에 한 번도 잡히지 않은 인덱스였고, 쓰기 지연을 줄이려는 정기 정리 작업의 일부였습니다. 변경은 사전에 리뷰를 거쳤고 스테이징에서 이틀간 문제없이 돌아갔습니다.

10시 38분, 조회 API의 p99 응답이 320ms에서 8.4초로 뛰었습니다. 알림은 정상적으로 울렸지만 처음 20분 동안 저희는 인덱스를 의심하지 않았습니다. 같은 시각 배포된 다른 변경이 두 건 있었기 때문입니다.

왜 통계에 안 잡혔나

문제의 인덱스는 created_at과 status를 묶은 것이었는데, 평소에는 옵티마이저가 다른 단일 인덱스를 골랐습니다. 그런데 특정 조건 — 상태값이 편중되고 기간이 90일을 넘는 조회 — 에서만 이 복합 인덱스로 실행 계획이 바뀝니다. 그 조건은 월별 정산 배치가 도는 화요일 오전에만 발생했습니다.

쿼리 통계 수집 주기가 주 단위 롤업이었던 것도 겹쳤습니다. 주당 몇 시간만 쓰이는 인덱스는 반올림 과정에서 사용률 0으로 표시됐습니다.

-- 문제가 된 조회. status 편중 + 90일 초과 구간에서만
-- 복합 인덱스로 실행 계획이 바뀐다.
SELECT id, status, created_at
  FROM orders
 WHERE status IN ('settled', 'partial')
   AND created_at >= now() - interval '120 days'
 ORDER BY created_at DESC
 LIMIT 500;

롤백이 왜 90분이나 걸렸나

인덱스를 다시 만드는 데 걸린 시간은 22분이었습니다. 나머지 68분은 실행 계획 캐시 때문이었습니다. 인덱스가 복구된 뒤에도 커넥션 풀에 남아 있던 준비된 구문이 예전 계획을 그대로 쓰고 있었습니다. 결국 애플리케이션을 순차 재시작해야 했습니다.

인덱스를 지우는 변경은 되돌리기 쉽다고 생각했습니다. 되돌리기 쉬운 것과 빠르게 복구되는 것은 다른 문제였습니다.

바꾼 것

첫째, 인덱스 사용 통계를 시간 단위로 수집하도록 바꿨습니다. 둘째, 인덱스 제거는 바로 지우지 않고 INVISIBLE 상태로 2주를 두는 절차를 만들었습니다. 셋째, 스테이징 데이터셋에 정산 배치 시나리오를 포함시켰습니다.

바꾸지 않은 것도 있습니다. 배포 창을 오전에서 옮기자는 제안은 받아들이지 않았습니다. 사람이 깨어 있는 시간에 배포하는 편이 낫다고 판단했습니다.