Incident Library

IL-0300 37signals · 2018-11-09database

Basecamp 3 의 events 테이블이 데이터베이스 한도에 닿아 서비스가 다섯 시간 가까이 읽기 전용이 되었다

2018년 11월 9일 Basecamp 3 가 CST 기준 오전 7시 21분부터 낮 12시 11분까지 다섯 시간 가까이 읽기 전용 상태였다. 사용자는 기존 메시지, 할 일 목록, 파일을 볼 수 있었지만 아무것도 새로 넣거나 고칠 수 없었다. 근본 원인은 사용량이 아주 많은 events 테이블이 데이터베이스의 한도인 2,147,483,647 에 닿은 것이었다. Basecamp 의 거의 모든 활동이 이 테이블에 기록되므로, 새 이벤트를 쓰지 못하게 되자 거의 모든 동작이 멈췄다.

37signals 는 장애 며칠 전부터 events 테이블의 용량을 늘리는 작업을 하고 있었지만, 남은 여유가 얼마나 빨리 줄고 있는지 제대로 계산하지 못했다. Basecamp 가 쓰는 Ruby on Rails 는 2017년에 나온 5.1 버전에서 데이터베이스 테이블의 기본값을 바꿔, 모든 테이블의 레코드 한도를 2,147,483,647 에서 9,223,372,036,854,775,807 로 올렸다. 37signals 가 이번에 Basecamp 의 테이블에 적용한 근본 해결책도 이와 같은 변경이었다. 이 장애로 Basecamp 3 출시 이후 99.998% 였던 가동률이 99.978% 로 내려갔다. 37signals 는 이 장애가 Basecamp 에서 아마 10년 사이 가장 큰 장애였다고 밝혔다.

심각도
–
영향 범위
Basecamp 3 was read-only: existing messages, to-do lists and files could be read, but nothing could be added or changed
영향 사용자
Basecamp 3 users
지역
–
감지까지
–
복구까지
4h 50m

증상

Basecamp 3 가 읽기 전용 상태가 되었다. 사용자는 기존 메시지, 할 일 목록, 파일을 볼 수 있었지만 새 내용을 넣을 수 없었고 기존 내용도 고칠 수 없었다.

Basecamp 의 거의 모든 활동은 events 테이블에 기록된다. 메시지를 올리거나 할 일 목록을 고치거나 댓글에 박수를 보내는 일이 모두 이 테이블에 쓰인다. 이 테이블에 새 이벤트를 쓸 수 없게 되자 Basecamp 에서 하려는 거의 모든 동작이 멈췄다.

읽기 전용 상태는 CST 기준 오전 7시 21분에 시작해 낮 12시 11분에 끝났다. 그동안 모든 내용이 그대로 멈춰 있었다.

증상 쓰기 거부

원인

원인 용량 한계

구성 요소 데이터베이스
기여 요인 용량 계획 부재
촉발
사용량이 아주 많은 events 테이블이 데이터베이스의 한도인 2,147,483,647 에 닿아, 이 테이블에 새 이벤트를 쓸 수 없게 되었다.

감지

–

조치

후속 조치

–

교훈

37signals 는 이 장애를 피할 수 있었다고 밝혔다. 장애 전 며칠 동안 events 테이블의 용량을 늘리는 작업을 하면서도 여유가 줄어드는 속도를 제대로 따지지 않았다. 37signals 의 CTO 는 Rails 5.1 이 새 기본값을 발표했을 때 회사의 데이터베이스 스키마를 더 주의 깊게 살폈어야 했다고 썼다. 해결 작업을 시작한 뒤에도 끝까지 챙기며 꼭 필요한 질문을 했어야 했다고 덧붙였다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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