사례5건
5건 중 1~5번째
- 증상
US East 1 운영 리전의 RDS PostgreSQL 을 14.7 에서 17.9 로 올리는 계획된 업그레이드가 점검 시간이 지나도 끝나지 않았다. 그동안 us2a 배포의 모든 고객이 Superset 에 접속하지 못했다.
- 촉발
Preset 이 US East 1 운영 리전의 모든 RDS 인스턴스에서 PostgreSQL 을 14.7 에서 17.9 로 올리는 계획된 메이저 버전 업그레이드를 시작했다. RDS 가 업그레이드 전에 찍는 전체 스냅샷이 약 4.5시간 이어지면서 주 데이터베이스 인스턴스의 남은 저장 공간을 다 썼다.
- 원인
- 구성 요소
- 기여 요인
- 감지
Preset 은 계획된 업그레이드를 지켜보던 중 05:28 EDT 에 스냅샷의 I/O 급증을 보았다. 06:00 에 상태 페이지에 사고를 올렸고, 07:26 에 AWS 지원 티켓을 열었다.
- 조치
- 업그레이드가 실패한 뒤 AWS 가 인스턴스를 업그레이드 전 상태로 자동으로 되돌렸고, 인스턴스가 10:13 EDT 에 PostgreSQL 14.15 로 다시 올라와 서비스가 돌아왔다. 수동 개입은 없었다.
- 후속 조치
- 다음 메이저 버전 업그레이드를 시도하기 전에 운영 규모의 전체 데이터로 업그레이드 과정을 미리 해 보고 저장 공간과 소요 시간 추정이 맞는지 확인한다.
- 교훈
RDS 는 메이저 버전 업그레이드 전에 기존 스냅샷과 상관없이 전체 스냅샷을 찍는다. 같은 인스턴스의 증분 스냅샷 시간이나 다른 환경의 업그레이드 시간으로는 이 스냅샷이 얼마나 걸릴지 알 수 없었고, 약 30~45MB/s 인 S3 스냅샷 처리량 상한은 드문 전체 스냅샷에서만 드러났다. 그래서 Preset 은 다음 메이저 버전 업그레이드 전에 운영 규모의 데이터로 저장 공간과 소요 시간을 먼저 확인한다.
- 증상
2026-03-10 15:57 UTC 에 알림 시스템이 Clerk API 전반의 지연 증가와 5xx 오류 증가를 알렸다. 모니터링에는 그보다 1분쯤 앞서 시작된 데이터베이스 락 경합 증가가 보였다.
- 촉발
Google Cloud SQL 이 Clerk 데이터베이스를 호스팅하는 가상 머신을 일상적으로 라이브 마이그레이션하다 실패했다. Clerk 는 라이브 마이그레이션 시점을 미리 통보받지 않는다.
- 원인
- 구성 요소
- 기여 요인
- 감지
15:57 UTC 에 알림 시스템이 API 전반의 지연 증가와 5xx 오류 증가를 알렸고, 이때 내부에서 사고를 선언했다.
- 조치
- 16:10 UTC 에 Origin Outage Mode 를 켜 세션 관리가 계속 돌아가게 했다.
- 읽기의 IO wait 만 오르는 것을 보고 인프라 문제를 의심해 GCP 에 티켓을 열었다.
- 16:23 UTC 에 문제가 스스로 풀리고 시스템이 안정된 것을 확인한 뒤 곧 Origin Outage Mode 를 껐다.
- 후속 조치
- 추가 라이브 마이그레이션을 막도록 Google 에 데이터베이스를 다시 고정해 달라고 요청했다. 글을 쓸 때까지 요청은 받아들여지지 않았다.
- 앞으로 모든 Postgres 데이터베이스 유지 보수는 기존 방식의 replica 승격으로 한다. Clerk 는 이미 안전하고 빠른 replica 승격 자동화를 갖고 있고, 2026-01-17 Postgres 메이저 버전 업그레이드에 문제없이 썼다.
- Google 이 라이브 마이그레이션을 영구히 끌 방법을 주지 않으면 다른 데이터베이스 제공업체로 옮기거나 Postgres 를 직접 운영한다. 지금 선택지를 조사하고 있다.
- 내부 서비스의 429 가 그대로 전달되지 않고 500 으로 바뀌게 고쳐, 애플리케이션이 오류 코드로 Clerk 시스템의 상태를 정확히 판단하게 한다.
- 엔지니어링 팀 대부분을 안정성 중심 프로젝트로 옮겼고, 당분간 시스템 안정성 회복을 가장 앞에 둔다.
- 교훈
2025년 9월 장애에서 Clerk 는 라이브 마이그레이션이 실패하면 작업이 끝날 때까지 서비스가 멈추고, 마이그레이션 도중 replica 장애 조치를 하는 것도 안전하지 않다는 것을 배웠다. 몇 달에 걸친 Google 과의 작업 뒤에도 이번 장애로 라이브 마이그레이션이 여전히 안전하지 않다는 것이 드러났다. 라이브 마이그레이션은 잘 되면 무중단이지만 안을 들여다볼 수 없어 Google 의 말을 믿는 수밖에 없다. 그래서 Clerk 는 준비가 더 들더라도 기존 방식의 replica 승격에 기대는 편이 더 안전하다고 보았다.
- 증상
2025-10-28 18:36 UTC 에 내부 모니터링 알림이 울려 엔지니어링 팀이 호출됐다. 대시보드가 열리지 않았고, railway up 처럼 API 를 쓰는 CLI 작업이 실패했으며, Public API 작업이 모두 멈췄다.
- 촉발
일상적인 Postgres 데이터베이스 변경으로 약 10억 행 테이블에 새 컬럼과 인덱스가 더해졌다. 인덱스 생성에 CONCURRENTLY 옵션을 쓰지 않아 테이블 전체에 배타적 잠금이 걸렸다.
- 원인
- 구성 요소
- 기여 요인
- 감지
변경이 운영에 반영되고 2분 뒤인 18:36 UTC 에 내부 모니터링 알림이 울려 엔지니어링 팀이 호출됐다.
- 조치
- 인덱스를 만드는 마이그레이션이 약 30분 만에 끝나 테이블 잠금이 스스로 풀렸고, 줄을 선 작업이 처리되며 커넥션 풀이 정상으로 돌아왔다.
- 후속 조치
- CI 에서 모든 인덱스 생성에 CONCURRENTLY 사용을 강제하고, 지키지 않은 풀 리퀘스트는 머지 전에 막는다.
- PgBouncer 커넥션 풀 한도를 조정해 뒤에 있는 Postgres 인스턴스의 용량을 넘지 않게 한다.
- 데이터베이스 사용자별 커넥션 한도를 설정해 장애 중에도 관리용 접속을 보장하고, 어떤 상황에서도 유지 보수 작업을 할 수 있게 한다.
- 증상
13:40 UTC 무렵 SourceHut 서비스 대부분을 사용할 수 없다는 경보가 한꺼번에 울렸다. 그 가운데 하나는 주 데이터베이스 서버인 물리 호스트 remilia.sr.ht 를 사용할 수 없다는 경보였다.
- 촉발
주 데이터베이스 서버 remilia.sr.ht 의 하드웨어가 고장 났다.
- 원인
- 구성 요소
- 기여 요인
- 감지
13:38 에 Prometheus 가 remilia 의 지표 수집에 실패했고, 13:40 무렵 대부분의 서비스와 remilia.sr.ht 를 사용할 수 없다는 경보가 울렸다.
- 조치
- 데이터센터 직원에게 연락이 닿지 않아 데이터센터 근처의 비상 연락 담당자를 불렀고, 담당자가 데이터센터로 출발했다.
- 현장에 도착한 비상 연락 담당자가 데이터센터 직원의 진단을 확인한 뒤 디스크를 cirno1.sr.ht 와 바꿔 끼우고 서버를 띄웠다.
- 후속 조치
- 오프사이트 데이터베이스 백업이 장애 조치용 데이터베이스 호스트로도 쓰일 수 있게 고친다. 이 일은 이미 끝났다.
- EU 이전 작업 전체의 우선순위를 다시 높인다.
- 새 데이터베이스 장애 조치 구성을 만든다.
- 빌드 용량을 메우려고 EU 에 새 빌드 워커를 둔다.
- 앞으로를 대비해 하드웨어 목록을 더 꼼꼼히 기록한다.
IL-0334RDS MySQL 의 bookmarks 테이블이 2TB 파일 크기 한도에 닿아 INSERT 가 실패하고 Instapaper 가 31시간 동안 멈췄다Instapaper2017- 증상
2월 9일 수요일 12:30PM PT 부터 Instapaper 사용자가 저장한 글을 담는 MySQL 의 bookmarks 테이블에 새 항목을 넣으면 오류가 나기 시작했다. Instapaper 서비스는 2월 10일 목요일 7:30pm PT 까지 멈췄다.
- 촉발
2월 9일 수요일 12:30PM PT 에 bookmarks 테이블이 2TB 파일 크기 한도를 넘었다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- Pinterest SRE 팀의 안내로 Instapaper 운영 데이터베이스를 i2.8xlarge 인스턴스의 5.5TB RAID-0 디스크에 덤프했다. 첫 시도는 24시간, 병렬로 돌린 두 번째 시도는 10시간이 걸렸다.
- 덤프가 너무 오래 걸리자 아카이브 접근을 제한한 채 동작하는 인스턴스를 약 6시간 만에 만들어, 31시간의 다운타임 끝에 운영에 올렸다.
- 옛 데이터베이스의 Aurora 읽기 복제본을 만들었다. Aurora 는 Instapaper 코드로 충분히 시험해 보지 않아 위험하다고 봤지만 만들기는 쉬웠다. 약 24시간 만에 끝났다.
- 새 MySQL RDS 인스턴스를 만들어 보조 인덱스 없이 데이터를 모두 넣었다. 8시간이 걸렸다. 그 뒤 보조 인덱스 세 개를 하나에 약 16시간씩 만들었다.
- Amazon 엔지니어가 실패한 운영 데이터베이스에 ext4 파일 시스템을 마운트하고 ext3 파일 시스템에서 ext4 파일 시스템으로 rsync 를 약 8시간 돌려, 데이터와 인덱스가 모두 있는 ext4 데이터베이스 인스턴스를 만들었다.
- RDS 엔지니어들이 임시 운영 데이터베이스의 바이너리 로그로 새 ext4 데이터베이스에 행 기반 복제를 걸어 목요일부터 월요일까지의 변경을 맞췄다. 약 3시간이 걸렸다.
- 새 데이터베이스를 마스터로 승격하고 애플리케이션 코드가 새 데이터베이스를 가리키도록 배포했다.
- 후속 조치
- Instapaper 전체 장애가 나면 Pinterest 의 SRE 팀에 바로 에스컬레이션하는 절차를 만든다.
- MySQL 백업 시험 주기를 석 달에 한 번에서 한 달에 한 번으로 늘린다.
- Pinterest 의 SRE 팀과 함께 이런 장애가 다시 나면 복구할 수 있는 절차를 마련한다.
- 교훈
팀이 알지 못했고 볼 수도 없었던 파일 시스템 한도 때문에 운영 데이터베이스뿐 아니라 모든 백업까지 쓸 수 없게 됐다. 호스팅된 인스턴스에는 MySQL 로만 접근할 수 있어서 rsync 같은 파일 시스템 수준의 해결책은 Amazon 엔지니어의 도움 없이는 쓸 수 없었다. 완벽하게 대응했어도 진단부터 데이터베이스 재구축까지 다운타임은 최소 10시간이었을 것이다. 이 문제는 미리 내다보고 막기 어려웠지만, 이런 장애를 위한 재해 복구 계획이 없어 다운타임과 복구 시간이 필요 이상으로 길어졌다. 데이터베이스를 다시 만드는 데 며칠이 걸린다는 것을 알았다면 곧바로 제한된 서비스 복구로 들어가 첫날의 다운타임을 크게 줄일 수 있었다. Pinterest 안에서, 그리고 AWS 팀과 더 잘 소통했다면 쓸 수 있는 자원을 더 잘 활용했을 것이다. 글쓴이는 다른 회사가 호스팅하는 기술이라도 매일 운영에 쓰는 기술의 한도를 이해하는 것이 자신의 책임이라고 밝혔다.
이 5건에서 가장 많이 나오는 구성 요소: 데이터베이스, 데이터베이스 백업과 스냅숏. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.