Incident Library

IL-0527 OpenStreetMap Foundation · 2025-06-25database

OpenStreetMap.org 의 복제 diff 생성이 invalid memory alloc request size 오류로 16시간 멈춤

OpenStreetMap.org 의 복제 diff 는 다른 OpenStreetMap.org 서비스와 제3자 서비스가 지도 편집을 따라가는 데 쓰는 파일이다. 2025년 6월 25일 21:33 UTC 부터 6월 26일 13:22 UTC 까지 약 16시간 동안 diff 생성 시스템이 멈춰 minutely, hourly, daily diff 가 자동으로 만들어지지 않았다. osmdbt-get-log 가 osmdbt-create-diff 에 필요한 로그 데이터를 만들 때 쓰는 SQL 질의가 "ERROR: invalid memory alloc request size 1243650064" 로 계속 실패했다. 원인은 PostgreSQL 복제에 생긴 어떤 상태였고, 그 상태가 무엇인지는 밝혀지지 않았다. 5월 30일에 PostgreSQL 을 15.13-1.pgdg22.04+1 로 올렸고, 15.13 의 최근 변경이 이 오류를 일으켰거나 영향을 주었을 수 있다고 밝혔다.

Alertmanager 가 21:40 UTC 부터 여러 번 알림을 보냈지만 호출기나 SMS 알림은 울리지 않았고, 운영 팀은 6월 26일 이른 아침에 대응을 시작했다. 복제 diff 하나에 담는 변경 묶음 수를 줄여 보았지만 해결되지 않았다. 운영 팀은 IRC 에서 osmdbt 개발자와 원인을 논의했고, osmdbt 의 구성 요소인 fakelog 로 문제 구간을 건너뛰는 우회 방법을 정해 시험 실행을 했다. fakelog 를 손으로 쓰는 동안 편집을 막아야 해서 1시간짜리 읽기 전용 긴급 점검을 잡았고, 주간 PostgreSQL 백업이 이미 끝났음을 확인했다.

12:56 UTC 에 OpenStreetMap.org 가 읽기 전용 점검에 들어갔다. 13:13:47 부터 13:17:04 UTC 까지 fakelog 로 osmdbt 를 손으로 돌려 replication/minute/006/658/640 부터 673 까지 만들었고, 13:21:10 UTC 에 osmdbt 타이머를 다시 켰다. 읽기 전용 점검은 약 25분 만인 13:22 UTC 에 끝났고, 13:41 UTC 에 Alertmanager 알림이 풀렸다. 같은 날 18:00 UTC 운영 팀 정기 통화에 osmdbt 개발자가 함께해 PostgreSQL 쪽 원인, osmdbt 사용성 개선, osmdbt 전용 PostgreSQL 플러그인을 내장 pgout 으로 바꾸는 방안을 논의했다.

심각도
–
영향 범위
No OpenStreetMap.org replication diffs for about 16 hours, so tile.openstreetmap.org, Nominatim, Overpass and third-party services could not stay up to date with map edits; the website and mapping API were read-only for about 25 minutes during the fix
영향 사용자
–
지역
–
감지까지
7m
복구까지
15h 49m

증상

2025년 6월 25일 21:33 UTC 부터 OpenStreetMap.org 의 minutely, hourly, daily 복제 diff 가 새로 만들어지지 않았다. 21:40 UTC 에 Alertmanager 가 운영 팀에 "minutely replication feed delayed - 6m 2s" 라는 첫 알림을 보냈다.

매분 도는 osmdbt 타이머 작업은 21:33:00 부터 "ERROR: invalid memory alloc request size 1243650064" 를 내며 매번 실패했다. PostgreSQL 로그에는 슬롯 "osmdbt" 의 logical decoding 을 시작하고 "SELECT * FROM pg_logical_slot_peek_changes($1, NULL, NULL);" 를 실행한 뒤 21:33:25 GMT 에 같은 오류가 찍혔다.

복제 diff 가 멈추자 tile.openstreetmap.org, Nominatim, Overpass 같은 하류 서비스와 제3자 서비스가 지도 편집을 따라가지 못했다. 6월 26일 00:37 UTC 에 커뮤니티 포럼에 새 데이터가 지도에서 조회되지도 렌더링되지도 않는다는 첫 신고가 올라왔고, 01:13 UTC 에 소셜 미디어에도 첫 신고가 나왔다.

6월 26일 06:08 UTC 에 운영 팀은 osmdbt 타이머를 멈추고 한 번에 처리하는 변경 묶음 수를 줄여 osmdbt 를 손으로 돌렸다. replication/minute/006/658/635.osc.gz 부터 639 까지 다섯 개는 성공했지만 06:27 무렵 다시 같은 메모리 할당 오류가 났다. 운영 팀 엔지니어는 IRC 에서 --max-changes=1 로도 오류가 난다고 알렸고, pg_logical_slot_peek_changes 가 PostgreSQL 내부의 고정 한도에 걸린 것으로 보았다. 운영 팀은 osmdbt 개발자와 함께 1,500만 개가 넘는 노드 변경 같은 큰 편집이 osmdbt 가 쓰는 PostgreSQL 내부 복제 로그를 넘치게 했는지 조사했다.

증상 복제 지연

원인

원인 소프트웨어 결함

구성 요소 데이터베이스 복제데이터베이스
기여 요인 온콜 호출 미전달
촉발
–

감지

Alertmanager 가 이 일과 관련된 알림을 여러 번 보냈고, 첫 알림은 21:40 UTC 의 "minutely replication feed delayed - 6m 2s" 였다. 호출기나 SMS 로 가는 알림은 울리지 않았다.

조치

후속 조치

교훈

osmdbt 개발자와의 소통이 우회 계획을 세우는 데 결정적이었다. 운영 팀은 osmdbt 를 충분히 이해하지 못하고 있었다.

출처

참고 문서

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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