Incident Library

IL-0309 Preset · 2026-04-13databaseaws

RDS PostgreSQL 메이저 버전 업그레이드가 점검 시간을 훨씬 넘겨 실패하면서 us2a 배포가 약 6시간 멈췄다

04:12 EDT 에 Preset 은 US East 1 운영 리전의 RDS 인스턴스를 PostgreSQL 14.7 에서 17.9 로 올리는 업그레이드를 시작했다. 주 데이터베이스 인스턴스는 38분 동안 사전 검사를 마친 뒤 04:51 에 내려가 스냅샷을 찍기 시작했다. 이 인스턴스의 볼륨은 500GB 였고 약 440GB 를 쓰고 있어 여유 공간은 약 64GB 였다. 스냅샷이 약 4.5시간 이어지는 동안 전체 스냅샷의 임시 파일과 메타데이터, pg_upgrade 작업 파일과 출력 로그, 길어진 스냅샷 동안 쌓인 WAL 이 남은 약 60GB 를 다 썼다. 여유 공간이 0이 되자 09:37 에 업그레이드가 실패했다.

스냅샷이 오래 걸린 이유는 RDS 가 메이저 버전 업그레이드 전에는 기존 스냅샷이 있어도 증분이 아닌 전체 스냅샷을 찍기 때문이었다. 이 인스턴스의 일일 자동 스냅샷은 증분이라 10~15분에 끝났고, 다른 리전의 업그레이드도 비슷한 시간에 스냅샷을 마쳤다. S3 스냅샷 처리량은 AWS 쪽 제약 때문에 EBS 볼륨에 프로비저닝한 처리량과 상관없이 약 30~45MB/s 를 넘지 못한다. 440GB 를 약 40MB/s 로 찍으면 전체 스냅샷에 최소 약 3시간이 걸린다. 그러나 이 상한은 평소에 드물게 찍는 전체 스냅샷에서만 드러났다. Preset 은 운영 이력과 AWS 문서 어디에도 이 인스턴스의 업그레이드 전 스냅샷이 약 4.5시간 걸린다는 분명한 단서가 없었다고 했다.

업그레이드가 실패하자 AWS 가 인스턴스를 업그레이드 전 상태로 자동으로 되돌렸다. 업그레이드 전 스냅샷은 10:10 EDT 에 끝났고, 인스턴스는 10:13 EDT 에 PostgreSQL 14.15 로 다시 올라와 서비스가 돌아왔다. 스냅샷에서 복원하지 않고 원래 데이터베이스 엔진을 되살렸기 때문에 데이터 손실이나 손상은 없었고, 수동 개입도 필요 없었다. 롤백 뒤 스냅샷은 자동으로 찍혀 11:29 EDT 에 끝났다. us2a 배포의 고객은 약 6시간 동안 Superset 을 쓰지 못했다.

심각도
–
영향 범위
Superset was unavailable for about 6 hours for all customers on the us2a production deployment; no data was lost or corrupted
영향 사용자
All customers on the us2a production deployment
지역
US East 1
감지까지
–
복구까지
6h

증상

US East 1 운영 리전의 RDS PostgreSQL 을 14.7 에서 17.9 로 올리는 계획된 업그레이드가 점검 시간이 지나도 끝나지 않았다. 그동안 us2a 배포의 모든 고객이 Superset 에 접속하지 못했다.

04:12 EDT 에 ModifyDBInstance 호출로 업그레이드를 시작했다. API Gateway 와 Examples 인스턴스는 04:18 에 업그레이드를 마쳤지만, 주 데이터베이스 인스턴스는 사전 호환성 검사에만 38분이 걸렸다. 04:51 에 인스턴스가 내려가고 스냅샷이 시작됐다.

스냅샷은 몇 시간 동안 이어졌다. 05:28 에는 순차 읽기가 약 45MB/s 였고 쓰기는 거의 0이었다. 08:00 에는 I/O 처리량이 약 55MB/s 로 오르고 CPU 가 약 70% 로 뛰어 단계가 바뀌는 것처럼 보였다. 09:22 에는 읽기가 거의 0으로 떨어지고 쓰기가 130MB/s 로 치솟아 인스턴스가 회복하는 것처럼 보였다.

09:37 에 업그레이드가 "Postgres cluster is in a state where pg_upgrade cannot be completed successfully." 오류로 실패했다. 500GB 볼륨에서 시작 때 약 64GB 남아 있던 여유 공간이 0이 된 뒤였다.

스냅샷이 약 2.5시간째 진행 중이던 07:26 에 AWS 지원 티켓을 열었다. 08:36 에 AWS 는 업그레이드가 정상으로 진행 중이고, 개입할 방법이 없으며, 예상 완료 시각도 알 수 없다고 답했다.

이 업그레이드는 샌드박스, 스테이징, 여러 운영 리전에서 15분 안에 끝났다. 같은 인스턴스의 일일 자동 스냅샷도 늘 10~15분에 끝났기 때문에, 업그레이드 전 스냅샷이 약 5시간 걸리리라고 볼 근거가 없었다.

증상 서비스 중단업그레이드 정체

원인

원인 용량 한계

구성 요소 데이터베이스데이터베이스 백업과 스냅숏
기여 요인 스테이징 불일치미검증 가정한계 미인지디버그 접근 제한
촉발
Preset 이 US East 1 운영 리전의 모든 RDS 인스턴스에서 PostgreSQL 을 14.7 에서 17.9 로 올리는 계획된 메이저 버전 업그레이드를 시작했다. RDS 가 업그레이드 전에 찍는 전체 스냅샷이 약 4.5시간 이어지면서 주 데이터베이스 인스턴스의 남은 저장 공간을 다 썼다.

감지

Preset 은 계획된 업그레이드를 지켜보던 중 05:28 EDT 에 스냅샷의 I/O 급증을 보았다. 06:00 에 상태 페이지에 사고를 올렸고, 07:26 에 AWS 지원 티켓을 열었다.

조치

후속 조치

교훈

RDS 는 메이저 버전 업그레이드 전에 기존 스냅샷과 상관없이 전체 스냅샷을 찍는다. 같은 인스턴스의 증분 스냅샷 시간이나 다른 환경의 업그레이드 시간으로는 이 스냅샷이 얼마나 걸릴지 알 수 없었고, 약 30~45MB/s 인 S3 스냅샷 처리량 상한은 드문 전체 스냅샷에서만 드러났다. 그래서 Preset 은 다음 메이저 버전 업그레이드 전에 운영 규모의 데이터로 저장 공간과 소요 시간을 먼저 확인한다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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