Incident Library

IL-0326 MailPace · 2023-08-11database

MailPace 의 관리형 Postgres 데이터베이스 디스크가 가득 차 데이터베이스가 두 시간 넘게 내려갔다

MailPace 는 매일 도는 Rake cron 작업으로 보존 기간 30일이 지난 데이터를 지웠다. 이 작업이 조용히 실패하면서 데이터가 쌓이고 있었다. 팀은 2023-08-11 13:00 BST 정기 점검에서 데이터베이스가 있어야 할 크기의 약 1.5배인 것을 보고, 정리 작업이 killed 메시지로 끝나는 것을 찾았다. 13:15 에 cron 인스턴스 메모리를 1gb 에서 8gb 로 늘리자 작업은 돌았다. 그러나 destroy_all 은 10개가 넘는 테이블에 걸친 응답과 첨부 파일 같은 연결 레코드까지 지웠다. 계정 하나가 하루에 메일을 수천 통 보낼 수 있었으므로 destroy_all 호출 하나하나가 매우 컸다. 데이터베이스가 빠르게 찼고 13:36 에 모든 데이터베이스 트랜잭션이 실패했다. MailPace 는 Write Ahead Log 때문일 것으로 추정했고, 업스트림 제공자가 정확한 경위를 확인해 주기를 기다리고 있다고 적었다. 데이터베이스 요금제도 처음부터 성장 여유가 모자랐다.

Postgres 가 관리형 서비스였으므로 팀은 13:37 에 업스트림 제공자 지원팀에 연락했다. 13:45 에 6시간 전 오프사이트 백업을 새 데이터베이스 인스턴스에 준비하는 복원 절차를 시작했다. 이 절차는 여러 번 시험해 본 것이었고 약 1시간이 걸렸다. 다만 데이터 일부를 잃고 그동안 장애가 이어지는 방법이었다. 14:30 에 새 데이터베이스로 옮기려던 참에, 제공자가 저장 공간이 99% 찼을 때 자동 알림을 받았고 더 큰 데이터베이스로 옮기는 중이라고 알려 왔다. 제공자 쪽 소통 착오로 지원 엔지니어 두 명이 동시에 작업해 이전이 늦어졌다. 15:25 에 이전 중인 데이터베이스가 읽기 전용이 돼 로그인은 됐지만 메일은 보낼 수 없었다. 15:50 에 더 큰 인스턴스로 옮겨 완전히 복구됐다. 상태 페이지 두 개는 장애를 잡지 못했다.

그 뒤 MailPace 는 백업으로 만든 별도 데이터베이스 인스턴스에서 문제를 재현해 메모리 사용량을 보고 수정안을 시험했다. 운영에서는 고친 쿼리로 오래된 데이터를 하루 단위로 직접 지웠다.

심각도
–
영향 범위
All database transactions failed across MailPace's services and emails were not sent; during the migration users could log in but not send emails
영향 사용자
–
지역
–
감지까지
–
복구까지
2h 14m

증상

2023-08-11 13:36 BST 에 여러 서비스에서 모든 데이터베이스 트랜잭션이 실패한다는 알림이 들어왔다. 데이터베이스를 다시 시작하려 했지만 공간이 없다며 올라오지 않았다. 메일도 나가지 않았다.

그날 13:00 정기 점검에서 보니, 보낸 메일과 API 정보를 저장하는 데이터베이스가 있어야 할 크기의 약 1.5배였고 용량의 약 80% 를 쓰고 있었다. 30일 보존 기간보다 오래된 데이터가 남아 있었다. 로그를 보니 매일 도는 정리 cron 작업이 끝나지 못하고 killed 메시지를 남기며 종료되고 있었다.

killed 는 보통 메모리 부족을 뜻하므로 13:15 에 cron 인스턴스 메모리를 1gb 에서 8gb 로 늘렸다. 작업은 몇 분 동안 돌다가 갑자기 끝났고, 그 직후 장애가 시작됐다. 데이터를 지우는 중이었고 70% 정도만 쓰던 데이터베이스였기 때문에 공간이 바닥났다는 것을 처음에는 믿기 어려웠다.

상태 페이지 두 개 모두 장애를 잡지 못했다. 데이터베이스가 내려갔는데도 https://app.mailpace.com 이 여전히 200 으로 응답하고 있었기 때문으로 추정했다.

15:25 에 이전 중인 데이터베이스가 읽기 전용 모드가 되자 사용자는 로그인할 수 있었지만 메일은 보낼 수 없었다. 팀은 처음에 완전히 복구됐다고 생각했다가 곧 잘못을 알고 Twitter 에 다시 알렸다.

증상 노드 디스크 가득 참서비스 중단쓰기 거부

원인

원인 용량 한계

구성 요소 데이터베이스
기여 요인 비효율적인 쿼리모니터링 사각지대여유 용량 부재
촉발
13:15 BST 에 cron 인스턴스 메모리를 1gb 에서 8gb 로 늘려 밀려 있던 보존 기간 정리 작업을 돌렸다. destroy_all 이 연결된 레코드까지 한꺼번에 많이 지우면서 데이터베이스 디스크가 빠르게 찼다.

감지

13:00 BST 정기 점검에서 데이터베이스가 평소보다 큰 것을 먼저 봤다. 13:36 에는 여러 서비스에서 모든 데이터베이스 트랜잭션이 실패한다는 알림이 곧바로 들어왔다. 상태 페이지 두 개는 장애를 잡지 못했다. 업스트림 제공자는 저장 공간이 99% 찼을 때 자동으로 알림을 받았다.

조치

후속 조치

교훈

장애는 여러 원인이 겹쳐 났다. 오래된 데이터를 지우는 cron 작업이 조용히 실패해 데이터가 쌓였다. 이 작업은 평소 하루치 양이었다면 문제없었겠지만 지나치게 단순하게 짜여 있었다. 데이터베이스 요금제는 처음부터 성장 여유가 부족했다. 상태 페이지는 장애를 잡지 못했다. MailPace 는 중요한 서비스마다 제공자를 여럿 두라고 권했다. 또 장애를 감지해 메일을 예비 제공자로 보내는 오픈 소스 아웃바운드 SMTP 프록시 Outgoer 를 만들고 있다고 밝혔다.

출처

참고 문서

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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