Incident Library

IL-0524 Open Collective · 2023-04-04database

인덱스를 다시 만드는 마이그레이션이 운영에서 Transactions 테이블을 잠가 Open Collective 서비스가 느려짐

Open Collective 는 2023년 4월 4일 성능을 높이려고, 소프트 삭제된 행을 빼고 Transactions 테이블의 인덱스를 다시 만드는 마이그레이션을 배포했다. 마이그레이션은 로컬에서 시험했고 staging 에서도 성공했다. 운영에서는 이 마이그레이션이 Transactions 테이블 전체를 잠가 서비스가 느려졌다. 인덱스 생성은 `CONCURRENTLY` 로 돌렸지만, Transactions 테이블에 끊임없이 들어오는 많은 쿼리가 마이그레이션과 부딪쳐 테이블이 잠긴 것으로 보였다. 옛 인덱스를 먼저 지우고 새 인덱스를 만드는 방식이었기 때문에, 그 사이에 들어온 쿼리는 인덱스를 전혀 쓰지 못했고 이것이 성능 저하를 크게 키웠다.

엔지니어들은 마이그레이션을 죽였지만 테이블은 잠긴 채로 남았다. 쿼리를 줄이려고 프런트엔드를 점검 모드로 돌리고 데이터베이스의 다른 연결을 닫은 뒤, 새 인덱스 생성을 취소하고 10:00 UTC 부터 옛 인덱스를 되살렸다. 복원은 10:05 UTC 에 끝났고, 10:08 UTC 에 프런트엔드를 되살리고 문제가 해결됐다고 공식으로 확인했다.

심각도
–
영향 범위
Open Collective's service was degraded while the Transactions table was locked, and the frontend was in maintenance mode for part of that time, from 09:20 to 10:08 UTC
영향 사용자
–
지역
–
감지까지
7m
복구까지
55m

증상

2023년 4월 4일 09:13 UTC 에 배포를 시작하고 7분 뒤인 09:20 UTC 에 서비스 성능 저하가 보였다. 운영에서 실행한 마이그레이션이 Transactions 테이블 전체를 잠근 상태였다.

엔지니어들이 마이그레이션을 죽였지만 테이블은 계속 잠겨 있었다. 프런트엔드를 점검 모드로 돌리고 데이터베이스의 다른 연결을 닫은 뒤 옛 인덱스를 되살렸다.

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

원인

촉발
2023년 4월 4일 09:13 UTC 에 성능을 높이려고, 소프트 삭제된 행을 빼고 Transactions 테이블의 인덱스를 다시 만드는 마이그레이션을 배포했다.

감지

배포를 시작하고 7분 뒤인 09:20 UTC 에 서비스 성능 저하를 알아챘다.

조치

후속 조치

교훈

옛 인덱스를 지우고 새 인덱스를 만드는 방식은 쿼리가 끊임없이 들어오는 테이블에서 너무 낙관적이었다. 로컬과 staging 에서 시험해도 부하가 걸린 환경에서 마이그레이션을 돌려 볼 도구가 없으면 이런 문제를 미리 잡지 못한다. 문제를 빨리 알아채고 엔지니어 두 명이 함께 조사한 것과, 사용자에게 분명한 안내를 보이면서 영향을 줄인 프런트엔드 점검 모드는 도움이 됐다.

출처

참고 문서

관련 사례

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

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

AI 도구와 스크립트용

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