IL-0373 Heroku · 2024-07-27databaseobservability

EU 리전의 Heroku Postgres Essential 등급 데이터베이스가 메모리가 바닥나 두 번에 걸쳐 연결을 받지 못했다

제3자 업체가 배포한 모니터링 변경에 메모리 누수가 있었다. 이 모니터링 에이전트가 쓸 수 있는 자원을 다 써서 Heroku Postgres 데이터베이스 클러스터의 가용 메모리가 계속 줄었다. 2024년 7월 27일 22:31 UTC 부터 EU/Dublin 리전의 클러스터 33개가 요청을 처리하지 못했다. Essential 등급 고객 일부는 데이터베이스에 연결하지 못했다. Heroku Support 가 7월 28일 07:50 UTC 에 고객 지원 티켓을 받고 기술 팀을 호출했고, 기술 팀은 자원을 더 배정하고 클러스터를 재시작해 14:16 UTC 에 문제를 일시적으로 풀었다.

7월 30일 06:04 UTC 에 Heroku Support 의 에스컬레이션으로 둘째 장애가 시작됐다. 16:47 UTC 에 제3자 업체의 지원 엔지니어가 합류해, 두 장애의 근본 원인이 모든 자원을 써 버린 모니터링 에이전트라고 확인했다. 기술 팀은 이 문제가 없는 제3자 서비스의 이전 버전을 프로비저닝하는 우회책을 적용했다. Postgres 데이터베이스 클러스터를 이전 안정 버전으로 바꾸자 메모리가 회수되어 클러스터가 건강한 상태로 돌아왔다. 사후 보고는 17:56 UTC 에 영향이 끝났다고 선언했다고 적었다. 반면 상태 페이지의 해결 공지는 영향 기간을 6:04 AM UTC 부터 4:28 PM UTC 까지로 적었다. 제3자 업체는 영구 수정을 만들고 있고, 그 사이 임시 수정을 제공했다.

심각도: –
영향 범위: 33 Heroku Postgres clusters; some Essential-tier customers could not connect to their databases
영향 사용자: –
지역: EU (Dublin)
감지까지: 9h 19m
복구까지: 15h 45m

증상

EU/Dublin 리전에 있는 Heroku Postgres Essential 등급 고객 일부가 데이터베이스에 연결하지 못했다. 상태 페이지는 영향받은 고객이 데이터베이스에 접근하면 out of memory 오류를 받는다고 알렸다.

2024년 7월 27일 22:31 UTC 부터 Heroku Postgres 클러스터 33개가 요청을 처리하지 못했다. 처음에는 접근할 수 없거나 메모리가 바닥난 데이터베이스가 33개였다. 클러스터의 쓸 수 있는 메모리가 계속 줄다가 결국 접근할 수 없게 됐다.

첫 장애는 고객 지원 티켓으로 드러났고, Heroku Support 가 7월 28일 07:50 UTC 에 기술 팀을 호출했다. 기술 팀은 자원을 더 배정하고 클러스터를 재시작해 14:16 UTC 에 문제를 일시적으로 풀었다.

같은 문제가 7월 30일에 다시 났다. 사후 보고는 06:04 UTC 에 기술 팀이 Heroku Support 의 에스컬레이션을 받으며 둘째 장애가 시작됐다고 적었다. 같은 보고는 16:47 UTC 에 둘째 발생을 알리는 고객 지원 티켓이 들어오기 시작했다고도 적었다. 상태 페이지는 16:59 UTC 에 문제를 알렸다.

증상 메모리 압박 서비스 중단

원인

원인 소프트웨어 결함

구성 요소 데이터베이스 텔레메트리 에이전트

기여 요인 모니터링 사각지대

촉발: 제3자 업체가 메모리 누수가 있는 모니터링 변경을 배포했다.

감지

첫 장애는 고객 지원 티켓으로 알았다. Heroku Support 가 7월 28일 07:50 UTC 에 고객 티켓을 받고 기술 팀을 호출했는데, 장애가 시작되고 9시간 19분 뒤였다. 둘째 장애도 Heroku Support 의 에스컬레이션과 고객 지원 티켓으로 알았다.

조치

첫 장애 때 자원을 더 배정하고 Heroku Postgres 클러스터를 재시작해 7월 28일 14:16 UTC 에 문제를 일시적으로 풀었다.
둘째 장애 때 문제가 없는 제3자 서비스의 이전 버전을 프로비저닝하는 우회책을 적용했다. Postgres 데이터베이스 클러스터를 이전 안정 버전으로 바꾸자 메모리가 회수되어 클러스터가 건강한 상태로 돌아왔다.
제3자 업체가 임시 완화책을 적용했다.

후속 조치

제3자 모니터링의 지표 수집을 강화했다.
제3자 업체가 메모리 누수를 고친 모니터링 소프트웨어 새 버전을 내면, 기술 팀이 그 버전을 평가하고 괜찮으면 Heroku 고객에게 내보낸다.

교훈

–

출처

https://status.heroku.com/incidents/2678 · 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-0247 쿠버네티스로 옮긴 검색 시스템 Manas 에서 요청 백만 건에 한 건이 평소보다 100배 느려졌다Pinterest · 2025
같은 원인 · 공통 텔레메트리 에이전트
IL-0527 OpenStreetMap.org 의 복제 diff 생성이 invalid memory alloc request size 오류로 16시간 멈춤OpenStreetMap Foundation · 2025
같은 원인 · 공통 데이터베이스
IL-0329 Postgres 17 업그레이드 뒤 다시 켠 PGAudit 가 마이그레이션 중 락을 쥔 채 멈춰, 서비스 전반이 느려지고 데이터베이스가 2분 동안 내려갔다incident.io · 2025
같은 원인 · 공통 데이터베이스
IL-0347 FR-PAR-1 가용 영역에서 하이퍼바이저 약 25% 의 VPC 연결이 11분 동안 끊겼다Scaleway · 2024
같은 원인 · 공통 데이터베이스
IL-0024 무거운 API 요청이 MongoDB 에 과부하를 걸고 취소되지 않은 요청이 쌓여 Hugging Face Hub 가 사흘 동안 세 번 멈췄다Hugging Face · 2024
같은 원인 · 공통 데이터베이스
IL-0217 스키마 캐시가 데워지지 않아 주 MySQL 데이터베이스가 내부 교착에 빠지고 Honeycomb 전체가 68분 동안 멈췄다Honeycomb · 2023
같은 원인 · 공통 데이터베이스
IL-0174 Fluent Bit 2.0 으로 올린 로그 수집 사이드카 가운데 Kafka output 플러그인을 쓰는 컨테이너가 SIGSEGV 로 계속 재시작됐다.Hyperconnect · 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-0041 fluent-bit 이 오류 없이 멈춰 운영 노드 한 대의 애플리케이션 로그가 Elasticsearch 로 전혀 가지 않았다.PrometheusKube · 2020
같은 원인 · 공통 텔레메트리 에이전트
IL-0196 Redis Operator 로 레플리카를 늘리면서 메모리 한도를 낮추자 데이터를 가진 유일한 Redis 파드가 재시작됐고, Sentinel 이 빈 레플리카를 마스터로 올려 데이터가 모두 지워졌다.Palark · 2020
같은 원인 · 공통 데이터베이스
IL-0486 Figma의 PostgreSQL 데이터베이스에서 쓰기 IOPS와 락 경합이 치솟아 서비스가 하루 동안 여러 번 내려갔다Figma · 2020
같은 원인 · 공통 데이터베이스
IL-0241 데이터베이스 shard 하나가 primary 를 뽑지 못해 Stripe API 요청 대부분이 두 차례 실패했다Stripe · 2019
같은 원인 · 공통 데이터베이스
IL-0051 외부 업체의 로그 클라이언트가 새 컨테이너가 뜰 때마다 파일 디스크립터를 다시 열고 이전 것을 닫지 않아 쿠버네티스 노드가 too many open files 로 내려갔다thredUP · 2018
같은 원인 · 공통 텔레메트리 에이전트
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-0373
가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0373/similar
MCP 서버(Streamable HTTP, 키 없음): https://incidentlib-mcp.benchlet.com/mcp

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