Incident Library

IL-0371 Render · 2023-04-21databasenetworking

PITR 을 켠 Render Postgres 데이터베이스에서 백업이 도는 동안 새 연결의 절반이 실패했다

Render Postgres 데이터베이스에는 dpg-123abc 같은 고정 내부 서비스 이름으로 연결한다. 이 서비스 이름은 클러스터가 관리하고, 데이터베이스의 IP 주소가 바뀌면 라우팅 설정에 반영한다. 2023년 4월 21일 Render 는 Point-in-time Recovery 기능을 조건이 맞는 새 데이터베이스에 내놨다. PITR 은 복원 요청이 오면 정확한 복원 지점을 쓸 수 있도록 매일 데이터베이스를 백업하는데, 이 백업 작업이 데이터베이스와 비슷한 네트워크 레이블로 설정되어 있었다. 라우팅 계층은 이 설정을 보고 백업 작업의 IP 주소를 데이터베이스 서비스 이름의 연결 대상으로 더했다. 백업 작업에서는 데이터베이스가 돌지 않으므로 그 IP 로 간 새 연결은 실패했다. 그래서 백업이 도는 동안 새 연결의 50%가 실패했다.

Render 는 영향받은 데이터베이스의 백업을 트래픽이 적은 시간에 예약할 수 있을 때까지 껐다. 그런데 비동기 작업 스케줄러는 최근 놓친 실행이 있으면 예약 시간대 밖에서도 곧바로 작업을 시작했다. 그래서 백업을 다시 켜고 예약하자 백업이 바로 돌았고, 업무 시간에 장애가 다시 났다. 처음 보는 문제여서 엔지니어들은 메모리 동작의 변화를 쫓다가 원인을 찾는 데 시간이 걸렸다. 백업 작업의 네트워크 레이블 설정을 고쳐 라우팅 계층이 백업 작업을 연결 대상으로 잡지 않게 했고, 4월 27일에 장애를 해결로 표시했다.

심각도
–
영향 범위
New connections to PITR-enabled Render Postgres databases while a PITR backup job was running; existing connections were unaffected
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

특정 시점 복구 기능인 PITR 을 켠 Render Postgres 데이터베이스에 새 연결을 맺으면, PITR 백업 작업이 도는 동안 50% 확률로 실패했다. 커넥션 풀링처럼 이미 맺어 둔 연결은 영향이 없었다.

실패는 백업이 도는 동안에만 났고, 백업은 데이터베이스 크기에 따라 15분에서 45분 걸렸다. 영향받은 데이터베이스의 백업을 트래픽이 적은 시간에 예약하려고 다시 켜자, 놓친 실행이 있다는 이유로 백업 작업이 곧바로 시작돼 업무 시간에 다시 장애가 났다. 초기 공지 일부가 문제가 실제로 끝나기 전에 해결됐다고 알려, 일부 사용자는 문제를 되풀이해 겪었다.

처음 보는 문제여서 근본 원인을 찾는 데 시간이 걸렸다. 엔지니어들은 메모리 동작, 특히 active page cache 의 변화를 보고 그 동작을 재현하려 했다. 그러다 새 연결이 실패한다는 장애의 다른 면을 따져 보지 않았다는 것을 알게 됐다.

증상 간헐적 연결 실패요청 오라우팅

원인

원인 배포 결함

구성 요소 데이터베이스데이터베이스 백업과 스냅숏서비스 디스커버리
기여 요인 –
촉발
Render 는 2023년 4월 21일 Point-in-time Recovery 기능을 조건이 맞는 새 데이터베이스에 내놨다. 이 기능의 백업 작업은 데이터베이스와 비슷한 네트워크 레이블로 설정되어 있었다.

감지

–

조치

후속 조치

교훈

–

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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