Incident Library

IL-0487 Autumn · 2026-03-15database

Postgres 테이블 두 개의 콜레이션을 바꾼 뒤 데이터베이스 CPU가 치솟아 Autumn API 요청의 약 10%가 실패했다

Autumn은 가장 자주 도는 질의를 최적화하다가 부모 테이블과 자식 테이블의 콜레이션이 달라 인덱스가 쓰이지 않는 것을 찾았다. customers.internal_id는 KSUID 정렬을 위해 COLLATE "C"를 쓰는데, customer_entitlements.internal_customer_id 같은 외래 키 열은 기본 콜레이션을 썼다. Postgres는 콜레이션이 다른 열 사이에서 인덱스를 쓰지 못해, 10ms 안에 끝나야 할 이 질의가 약 150ms 걸렸다. customer_entitlements의 콜레이션을 바꾸자 CPU가 30% 줄고 질의가 훨씬 빨라졌다. 팀은 customer_entitlements, customer_products, entities, customers 네 테이블의 콜레이션을 이 순서로 맞추기로 했다.

2026-03-15 15:00 GMT 무렵 앞의 두 테이블을 바꾸자 주 질의가 인덱스를 잃어 성능이 크게 떨어졌고, 데이터베이스 CPU가 치솟으며 질의가 실패했다. ALTER TABLE로 되돌리려 했지만 배타 잠금이 필요했고, 잠금을 잡은 활성 질의가 늘 있어 교착 상태가 되풀이됐다. 질의 SQL에서 콜레이션을 맞추는 코드 수정도 부하 속에서 빨리 효과를 내지 못했다. 15:48에 PlanetScale 지원팀의 도움을 받아 모든 애플리케이션 연결을 끊고, 콜레이션 변경을 되돌리고, ANALYZE로 플래너 통계를 다시 만든 뒤 재시작했다. 질의는 바로 정상으로 돌아왔고, 16:15에 두 리전 모두에서 API와 대시보드가 정상임을 확인했다.

심각도
–
영향 범위
Autumn API: about 10% of requests failed from 15:00 to 16:15 GMT
영향 사용자
–
지역
both regions
감지까지
5m
복구까지
1h 15m

증상

2026-03-15 15:00 GMT 무렵 운영 데이터베이스의 두 테이블에 콜레이션 변경을 적용하자 데이터베이스 CPU가 치솟고 질의가 실패하기 시작했다. 16:15 GMT까지 Autumn API 요청의 약 10%가 실패했다.

고객 정보를 읽는 주 질의가 인덱스를 쓰지 못하게 되면서 성능이 크게 떨어졌다. 이 질의가 데이터베이스 CPU를 끌어올렸다.

15:05에 문제를 찾고 ALTER TABLE로 변경을 되돌리려 했다. ALTER TABLE은 테이블에 배타 잠금이 필요했는데 잠금을 잡은 활성 질의가 늘 있어서 교착 상태가 되풀이됐다.

15:20에는 스키마를 되돌리지 않고 인덱스를 쓰게 하려고 고객 정보를 읽는 주 질의에서 콜레이션을 명시적으로 캐스트하는 코드 수정을 배포했다. 데이터베이스 부하가 높아 이 수정은 충분히 빨리 효과를 내지 못했다.

증상 데이터베이스 과부하오류율 상승잠금 경합과 교착

원인

원인 설정 변경

구성 요소 데이터베이스
기여 요인 롤백 무효
촉발
가장 자주 도는 질의를 최적화하던 중 관련 테이블 네 개의 콜레이션을 맞추기로 하고, 운영 데이터베이스에서 customer_entitlements와 customer_products의 콜레이션을 바꿨다.

감지

–

조치

후속 조치

교훈

–

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.