Incident Library

IL-0570 CrowdWorks · 2026-09-07 (게시일)database

안 쓰는 테이블을 지우는 마이그레이션 직후 MySQL 쿼리가 막혀 crowdworks.jp에 1분쯤 접속하기 어려웠다

2026년 8월 CrowdWorks의 엔지니어가 더 이상 쓰지 않는 테이블을 지우는 drop_table 마이그레이션을 배포했다. 지울 테이블에는 트래픽이 매우 많은 테이블을 가리키는 외래 키가 걸려 있었다. MySQL은 외래 키 정합성을 지키려고 자식 테이블을 지울 때도 부모 테이블의 배타적 메타데이터 락, 곧 MDL을 요구한다. 마이그레이션이 이 배타적 MDL을 얻으려고 기다리는 동안 부모 테이블로 가는 쿼리가 그 뒤에 쌓인 것이 직접적인 원인으로 보인다. 서비스의 lock_wait_timeout 기본값은 50초였고, 마이그레이션이 타임아웃으로 실패하면서 1분쯤 뒤 서비스는 저절로 복구됐다. 팀은 재발 방지책으로 대상 마이그레이션에 세션 단위로 lock_wait_timeout = 3 을 설정해 3초 안에 락을 얻지 못하면 실패하게 하기로 했다. 위험한 마이그레이션을 찾는 strong_migrations gem이나 모든 마이그레이션에 타임아웃 단축을 강제하는 몽키 패치도 검토했지만, 이런 DDL이 드물어 의존성과 유지보수 부담을 늘릴 만하지 않다고 보고 미뤘다. 대신 규칙을 문서로 정하고 AI 코딩 에이전트 지시 파일과 PR 자동 코멘트로 알리는 방식을 택했다. 팀은 이 결정을 Architecture Decision Record, 곧 ADR로 정리해 합의했다.

심각도
–
영향 범위
crowdworks.jp was hard to reach for about a minute
영향 사용자
–
지역
–
감지까지
–
복구까지
1m

증상

drop_table 마이그레이션을 실행한 직후부터 데이터베이스 쿼리가 막히기 시작했고, crowdworks.jp에는 1분쯤 접속이 잘 되지 않았다. 마이그레이션은 끝내 타임아웃으로 실패했고 서비스는 저절로 복구됐다.

증상 잠금 경합과 교착간헐적 연결 실패

원인

원인 배포 결함

구성 요소 데이터베이스스키마 마이그레이션
기여 요인 –
촉발
이미 쓰지 않는 테이블을 지우려고 drop_table 마이그레이션을 실행했다. 이 테이블에는 트래픽이 매우 많은 테이블을 가리키는 외래 키 제약이 걸려 있었다.

감지

–

조치

–

후속 조치

교훈

–

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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