Incident Library

IL-0334 Instapaper · 2017-02-09databaseaws

RDS MySQL 의 bookmarks 테이블이 2TB 파일 크기 한도에 닿아 INSERT 가 실패하고 Instapaper 가 31시간 동안 멈췄다

Instapaper 는 MySQL 데이터베이스를 Amazon RDS 에서 운영했다. 2013년 6월에 만든 원래 인스턴스는 2015년 초 백업 시간대에 성능 문제를 겪었고, AWS 지원은 MySQL v5.6.19 이상으로 올리면 풀린다고 했다. 2015년 3월 팀은 원래 인스턴스의 읽기 복제본을 만들어 MySQL 을 올리고 약 5분의 다운타임으로 전환했다. 새 인스턴스는 2014년 4월 뒤에 만들었지만 2013년 6월 인스턴스의 읽기 복제본이라 ext3 파일 시스템과 2TB 파일 크기 한도를 물려받았다. 2014년 4월 전에 만든 MySQL RDS 인스턴스는 ext3 를 써서 한도가 2TB 이고, 그 뒤에 만든 인스턴스는 ext4 를 써서 한도가 6TB 다. 이 한도를 알았던 사람이 있었다면, 2013년 Softlayer 에서 AWS 로 옮길 때 일한 betaworks 외부 계약자였을 것이다. RDS 콘솔에도 이를 알려 주는 것이 없었다.

2월 9일 수요일 12:30PM PT 에 bookmarks 테이블이 2TB 를 넘어 INSERT 가 실패하기 시작했다. 10일치 자동 백업도 파일 시스템 스냅샷이라 같은 한도에 묶였다. 이런 장애를 위한 재해 복구 계획도 없었다. 팀은 AWS 지원, Pinterest 의 SRE 와 논의한 끝에 2.5TB 데이터베이스를 전체 덤프와 복원으로 다시 만들기로 했다. Pinterest SRE 팀의 안내로 i2.8xlarge 인스턴스의 5.5TB RAID-0 디스크에 덤프했지만 첫 시도는 24시간, 병렬로 돌린 두 번째 시도는 10시간이 걸렸다. 그래서 팀은 아카이브 접근을 제한한 임시 인스턴스를 약 6시간 만에 만들어, 31시간의 다운타임 끝에 2월 10일 목요일 7:30pm PT 에 운영에 올렸다.

주말 동안 RDS 엔지니어들과 두 갈래로 복원을 진행했다. 하나는 옛 데이터베이스의 Aurora 읽기 복제본으로 약 24시간 만에 끝났다. 다른 하나는 새 MySQL RDS 인스턴스에 보조 인덱스 없이 데이터를 8시간 동안 넣은 뒤 보조 인덱스 세 개를 하나에 약 16시간씩 만드는 것이었다. 인덱스 생성이 너무 오래 걸리자 Amazon 엔지니어가 실패한 운영 데이터베이스에 ext4 파일 시스템을 마운트하고 ext3 에서 ext4 로 rsync 를 약 8시간 돌려, 데이터와 인덱스가 모두 있는 ext4 데이터베이스를 얻었다. 임시 운영 데이터베이스의 바이너리 로그로 행 기반 복제를 약 3시간 돌려 목요일부터 월요일까지의 변경을 맞췄다. 그다음 새 데이터베이스를 마스터로 승격하고 애플리케이션이 이를 가리키도록 배포했다. 2월 14일에 전체 복구를 마쳤고, 사용자의 글은 하나도 잃지 않았다.

심각도
–
영향 범위
Instapaper service down for 31 hours, then five days of limited access to archives until full recovery on February 14; no user articles were lost
영향 사용자
Instapaper users
지역
–
감지까지
–
복구까지
31h

증상

2월 9일 수요일 12:30PM PT 부터 Instapaper 사용자가 저장한 글을 담는 MySQL 의 bookmarks 테이블에 새 항목을 넣으면 오류가 나기 시작했다. Instapaper 서비스는 2월 10일 목요일 7:30pm PT 까지 멈췄다.

bookmarks 테이블은 2TB 파일 크기 한도를 넘었다. 2014년 4월 전에 만든 MySQL RDS 인스턴스는 파일 크기 한도가 2TB 인 ext3 파일 시스템을 쓴다. 그 뒤에 만든 인스턴스는 ext4 파일 시스템을 쓰고 한도가 6TB 다. Instapaper 의 인스턴스는 2015년 3월에 만들었지만 2013년 6월 인스턴스의 읽기 복제본으로 만들었기 때문에 같은 파일 시스템과 2TB 한도를 물려받았다.

RDS 콘솔에는 2TB 한도에 다가가고 있다거나 애초에 그 한도가 적용된다는 것을 알려 주는 모니터링, 알림, 로그가 없었다. 글을 쓴 시점에도 데이터베이스에 심각한 문제가 있다는 표시는 없었다.

10일치 자동 백업도 모두 파일 시스템 스냅샷이라 같은 2TB 한도에 묶여 있었다. 팀은 처음에 행 수를 보고 데이터베이스 덤프에 6~8시간이 걸린다고 어림했다. 하지만 첫 시도는 24시간, 병렬로 돌린 두 번째 시도는 10시간이 걸렸다. bookmarks 의 앞쪽 25 퍼센트 행이 전체 데이터의 10 퍼센트밖에 되지 않았기 때문이다.

증상 쓰기 거부서비스 중단

원인

원인 용량 한계

구성 요소 데이터베이스데이터베이스 백업과 스냅숏데이터베이스 복제
기여 요인 한계 미인지모니터링 사각지대미검증 백업런북 부재디버그 접근 제한
촉발
2월 9일 수요일 12:30PM PT 에 bookmarks 테이블이 2TB 파일 크기 한도를 넘었다.

감지

–

조치

후속 조치

교훈

팀이 알지 못했고 볼 수도 없었던 파일 시스템 한도 때문에 운영 데이터베이스뿐 아니라 모든 백업까지 쓸 수 없게 됐다. 호스팅된 인스턴스에는 MySQL 로만 접근할 수 있어서 rsync 같은 파일 시스템 수준의 해결책은 Amazon 엔지니어의 도움 없이는 쓸 수 없었다. 완벽하게 대응했어도 진단부터 데이터베이스 재구축까지 다운타임은 최소 10시간이었을 것이다. 이 문제는 미리 내다보고 막기 어려웠지만, 이런 장애를 위한 재해 복구 계획이 없어 다운타임과 복구 시간이 필요 이상으로 길어졌다. 데이터베이스를 다시 만드는 데 며칠이 걸린다는 것을 알았다면 곧바로 제한된 서비스 복구로 들어가 첫날의 다운타임을 크게 줄일 수 있었다. Pinterest 안에서, 그리고 AWS 팀과 더 잘 소통했다면 쓸 수 있는 자원을 더 잘 활용했을 것이다. 글쓴이는 다른 회사가 호스팅하는 기술이라도 매일 운영에 쓰는 기술의 한도를 이해하는 것이 자신의 책임이라고 밝혔다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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