IL-0329 incident.io · 2025-04-09database

Postgres 17 업그레이드 뒤 다시 켠 PGAudit 가 마이그레이션 중 락을 쥔 채 멈춰, 서비스 전반이 느려지고 데이터베이스가 2분 동안 내려갔다

incident.io 는 2025년 4월 9일 직전 주말에 데이터베이스를 Postgres 17 로 업그레이드했다. 업그레이드하는 동안 PGAudit 를 잠시 껐다. PGAudit 는 데이터베이스 활동과 데이터베이스 구조, 사용자 권한의 변경을 표준 Postgres 로그보다 자세히 남기는 확장이다. 업그레이드가 끝난 뒤 스테이징에서 시험이 통과하자 운영에서도 PGAudit 를 다시 켰고, 정상 동작을 확인했다.

4월 9일 14:16 UTC 에 빈 테이블을 만들고 인덱스를 더하는 평범한 마이그레이션이 PGAudit 와 예상하지 못한 방식으로 얽혔다. PGAudit 는 중요한 데이터베이스 락을 쥔 채 응답하지 않게 됐다. 엔지니어들은 PGAudit 프로세스를 죽이려 했지만 프로세스가 타임아웃 시그널에 반응하지 않았다. 락이 풀리지 않아 다른 데이터베이스 작업이 막혔다. 대시보드, 모바일 앱, Slack 앱, API 가 간헐적으로 느려졌다.

타임아웃이 계속 늘자 팀은 데이터베이스를 재시작하기로 했다. 재시작하면 멈춘 프로세스가 강제로 끝나지만 데이터베이스도 잠깐 완전히 내려간다. 팀은 혼란이 더 이어지는 위험보다 먼저 손을 쓰는 쪽을 골랐다. 주 데이터베이스는 14:25 부터 14:27 UTC 까지 2분이 조금 안 되게 내려갔다. 인프라의 핵심 부분이 이런 상황을 견디도록 설계돼 있어 그동안에도 온콜 알림과 에스컬레이션은 빠지지 않았다. 복구 뒤 팀은 PGAudit 를 껐다가 완전히 지웠다.

심각도: –
영향 범위: Intermittent slowness and timeouts across the dashboard, mobile app, Slack app and API from 14:16 to 14:27 UTC, including a primary database outage of just under 2 minutes; on-call alerts and escalations kept working
영향 사용자: –
지역: –
감지까지: –
복구까지: 11m

증상

2025년 4월 9일 14:16 UTC 부터 대시보드, 모바일 앱, Slack 앱, API 가 간헐적으로 느려졌고, 모니터링이 곧 문제를 알렸다. 14:25 부터 14:27 UTC 까지 2분 동안은 데이터베이스가 완전히 내려가 제품 전체가 영향을 받았다.

빈 테이블을 만들고 인덱스를 더하는 평범한 마이그레이션이 돌던 중 PGAudit 프로세스가 응답하지 않게 됐다. 이 프로세스는 중요한 데이터베이스 락을 쥐고 놓지 않았다. 락이 걸린 자원 때문에 다른 데이터베이스 작업이 줄줄이 막혔다.

타임아웃은 시간이 갈수록 늘었다. 엔지니어들은 처음에 문제의 PGAudit 프로세스를 죽이려 했지만, 프로세스가 타임아웃 시그널에 반응하지 않아 락이 풀리지 않았다. 몇 번을 더 시도해도 프로세스는 끝나지 않았다.

이 기간에도 온콜 알림과 에스컬레이션은 하나도 빠지지 않고 동작했다.

증상 잠금 경합과 교착 간헐적 타임아웃 지연 시간 증가 서비스 중단

원인

원인 소프트웨어 결함

구성 요소 데이터베이스

기여 요인 –

촉발: PGAudit 를 다시 켠 운영 데이터베이스에서 빈 테이블을 만들고 인덱스를 더하는 평범한 마이그레이션을 14:16 UTC 에 실행했다.

감지

모니터링이 문제를 빠르게 알렸다.

조치

PGAudit 프로세스를 죽이는 시도가 계속 실패하자 데이터베이스를 재시작해 멈춘 프로세스를 강제로 끝냈다. 이 때문에 주 데이터베이스가 14:25 부터 14:27 UTC 까지 2분이 조금 안 되게 내려갔다.
서비스를 되살린 뒤 PGAudit 확장을 잠시 껐다가 완전히 지웠다.

후속 조치

PGAudit 가 안전하다고 보장할 수 있을 때까지 확장을 지운 상태로 두어, 실수로 다시 켜질 위험을 없앤다.
원인 조사를 계속한다.
내부 회고를 한다.
비슷한 상황을 더 잘 감지하고 막고 대응하도록 절차와 모니터링을 보강한다.

교훈

–

출처

https://status.incident.io/incidents/01JRDFKAGE07YYDY0KZR137BX3/write-up · official-status · 보관본

관련 사례

IL-0451 Aurora MySQL 에서 인덱스를 INVISIBLE 로 바꿀 때마다 Reader 3대의 버퍼풀이 무효화돼 CPU 와 ReadIOPS 가 튀었다Daangn · 2026
같은 원인 · 공통 데이터베이스
IL-0313 자체 운영 PgBouncer 로 옮기는 운영 카나리에서 일부 요청이 정확히 300초 멈추고 SQLAlchemy 커넥션 풀이 고갈됐다Decagon · 2026
같은 원인 · 공통 데이터베이스
IL-0281 PostHog US 리전 Logs 제품의 ClickHouse 클러스터가 S3 에 둔 로그 데이터를 거의 다 지워 3일보다 오래된 로그가 사라졌다PostHog · 2026
같은 원인 · 공통 데이터베이스
IL-0310 Aurora PostgreSQL 의 수동 장애 조치가 스스로 되돌아가 원래 writer 가 남고 백엔드의 쓰기 쿼리가 실패했다Hightouch · 2025
같은 원인 · 공통 데이터베이스
IL-0150 DynamoDB DNS 자동화의 경쟁 조건이 us-east-1 리전 엔드포인트의 DNS 레코드를 비워 DynamoDB 와 EC2 인스턴스 시작이 실패했고, 그 여파로 EKS, ECS, Fargate 의 컨테이너 시작과 클러스터 스케일링이 14시간 넘게 막혔다Amazon Web Services · 2025
같은 원인 · 공통 데이터베이스
IL-0436 Aurora MySQL 에서 INSERT 가 supremum 락에 막혀 커넥션이 고갈되고 freee 웹 서비스 전체가 다운되었다freee · 2025
같은 원인 · 공통 데이터베이스
IL-0527 OpenStreetMap.org 의 복제 diff 생성이 invalid memory alloc request size 오류로 16시간 멈춤OpenStreetMap Foundation · 2025
같은 원인 · 공통 데이터베이스
IL-0347 FR-PAR-1 가용 영역에서 하이퍼바이저 약 25% 의 VPC 연결이 11분 동안 끊겼다Scaleway · 2024
같은 원인 · 공통 데이터베이스
IL-0373 EU 리전의 Heroku Postgres Essential 등급 데이터베이스가 메모리가 바닥나 두 번에 걸쳐 연결을 받지 못했다Heroku · 2024
같은 원인 · 공통 데이터베이스
IL-0024 무거운 API 요청이 MongoDB 에 과부하를 걸고 취소되지 않은 요청이 쌓여 Hugging Face Hub 가 사흘 동안 세 번 멈췄다Hugging Face · 2024
같은 원인 · 공통 데이터베이스
IL-0217 스키마 캐시가 데워지지 않아 주 MySQL 데이터베이스가 내부 교착에 빠지고 Honeycomb 전체가 68분 동안 멈췄다Honeycomb · 2023
같은 원인 · 공통 데이터베이스
IL-0330 Go database/sql 커넥션 풀을 기다리던 요청이 2주 동안 간헐적으로 타임아웃됐고, 한 요청은 거의 20초를 기다렸다incident.io · 2023
같은 원인 · 공통 데이터베이스
IL-0385 큰 MySQL 테이블의 스키마 마이그레이션 마지막 단계에서 읽기 복제본 다수가 semaphore deadlock 에 걸려 GitHub 핵심 서비스가 2시간 50분 저하됐다GitHub · 2021
같은 원인 · 공통 데이터베이스
IL-0462 GKE 위 MySQL 파드 일부가 시작과 종료에 오래 걸려 KateSQL 인스턴스 교체가 느려졌다Shopify · 2021
같은 원인 · 공통 데이터베이스
IL-0196 Redis Operator 로 레플리카를 늘리면서 메모리 한도를 낮추자 데이터를 가진 유일한 Redis 파드가 재시작됐고, Sentinel 이 빈 레플리카를 마스터로 올려 데이터가 모두 지워졌다.Palark · 2020
같은 원인 · 공통 데이터베이스
IL-0486 Figma의 PostgreSQL 데이터베이스에서 쓰기 IOPS와 락 경합이 치솟아 서비스가 하루 동안 여러 번 내려갔다Figma · 2020
같은 원인 · 공통 데이터베이스
IL-0241 데이터베이스 shard 하나가 primary 를 뽑지 못해 Stripe API 요청 대부분이 두 차례 실패했다Stripe · 2019
같은 원인 · 공통 데이터베이스
IL-0439 블록 디바이스와 파일 시스템을 확장할 때마다 데이터베이스 접근이 한동안 느려졌다Cybozu · 2018
같은 원인 · 공통 데이터베이스
IL-0388 Redis 고가용 클러스터의 primary 노드가 내려간 뒤 Discord API 가 느려지고 길드 일부가 오프라인으로 보이며 접속이 실패했다Discord · 2017
같은 원인 · 공통 데이터베이스
IL-0454 배민 카드사 할인 이벤트가 시작되자 빌링 시스템이 MariaDB 에 새 커넥션을 맺지 못해 결제 요청 일부가 실패했다Woowa Brothers · 2016
같은 원인 · 공통 데이터베이스
IL-0536 US East 의 Amazon SimpleDB 가 두 시간 동안 거의 모든 API 호출에 실패했다Amazon Web Services · 2014
같은 원인 · 공통 데이터베이스
IL-0485 계획된 OS 업그레이드 작업이 운영 중인 데이터베이스 서버를 재설치해 Dropbox 서비스가 멈췄다Dropbox · 2014
같은 원인 · 공통 데이터베이스
IL-0589 Kickstarter 의 모든 MySQL 복제본이 중복 키 오류로 복제를 멈췄다Kickstarter · 2013
같은 원인 · 공통 데이터베이스
IL-0303 GitHub 의 새 3노드 MySQL 클러스터에서 자동 페일오버가 잘못 일어나고 클러스터 상태가 갈라져 GitHub.com 이 두 번 멈췄다GitHub · 2012
같은 원인 · 공통 데이터베이스

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

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

kubegap 열기

AI 도구와 스크립트용

이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0329
가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0329/similar
MCP 서버(Streamable HTTP, 키 없음): https://incidentlib-mcp.benchlet.com/mcp

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