PeeringDB가 복사본에 빠지던 삭제 통지를 고쳤다

요약

PeeringDB는 10월 21일자 2.84.0 릴리스 노트에 지역 인터넷 등록기관 상태를 반영한 삭제가 ?since= 증분 동기화 사용자에게 전달되지 않던 문제의 수정을 기록했다. 원래 결함 보고에는 netixlan 행의 직접 삭제와, 일부 네트워크가 deleted가 되어도 updated 시각이 바뀌지 않은 사례가 있다.
20일 합쳐진 수정은 대량 삭제 단계를 없애고 삭제된 행이 API의 변경 응답에 나타나는지 시험한다. 이전에 벌어진 복사본의 차이는 전체 재동기화로 정리해야 한다는 것이 신고자의 설명이다. 몇 곳이 재동기화를 끝냈는지는 공개되지 않았다.

현재 목록과 지난 목록이 동시에 답할 때

피어링 담당자가 교환 지점에서 어느 네트워크를 만날 수 있는지 알아본다. PeeringDB 사이트에서는 연결 기록을 찾을 수 없다. 조직 내부의 캐시에서는 같은 기록이 여전히 보인다. 디렉터리 항목은 실제 BGP 세션이나 트래픽의 증명서가 아니다. 그러나 연락할 상대와 점검할 위치를 고르는 데 쓰인다. 두 화면이 다른 시기의 목록을 현재형으로 보여주는 순간, 데이터의 오류는 업무의 방향을 바꾸기 시작한다.

PeeringDB API 명세는 ?since=에 Unix 시각을 넣어 그 뒤 바뀐 객체를 가져오는 방법을 설명한다. 양수 since와 status=deleted를 사용하면 삭제된 객체도 조회할 수 있다. 공식 FAQ에 따르면 peeringdb-py는 처음 한 번 전체 데이터를 받고 이후에는 변경분을 가져온다. 원본과 복사본 모두에 부담을 덜 주는 방식이다. 그 대가로 원본은 중요한 변경을 빠짐없이 내보내야 한다. 새 기록은 보내고 삭제는 조용히 끝내면, 복사본은 갱신될수록 오래된 흔적을 더 많이 품는다.

Remco van Mook은 10월 7일 PeeringDB의 공식 저장소에 결함 #2057을 올렸다. ?since=로 동기화한 복사본과 전체 API 목록을 비교한 결과였다. 첫 번째 경로는 RIR의 할당 상태를 점검하는 정기 정리 작업에 있었다. 프로그램은 네트워크를 지우기 전에 그 네트워크와 교환 LAN을 잇는 netixlan 행을 한꺼번에 지웠다. 이 대량 삭제는 행에 deleted를 표시하고 updated를 앞으로 옮기는 객체의 삭제 절차를 통과하지 않았다. 원본에서는 행이 사라졌지만, 다음 변경분에는 삭제 사실이 없었다.

두 번째 경로는 네트워크 행 자체의 시계였다. 일부 행은 상태가 deleted로 바뀐 뒤에도 updated에 옛 시각을 남겼다. 신고자가 공개한 사례에는 2026년에 지워진 네트워크의 갱신 시각이 2022년으로 기록돼 있다. 2026년 이후의 변경을 묻는 복사본은 그 삭제를 받을 수 없다. 요청이 성공했다는 응답과 내용이 맞다는 증명은 전혀 다른 종이다.

신고자가 센 수와 모르는 수

약 여섯 달 동안의 비교에서 신고자는 직접 지워진 netixlan 286개를 찾았다. 이들은 125개 네트워크에 속했다. updated가 움직이지 않은 채 삭제된 네트워크도 46개였다. 이 수치는 그가 조사한 복사본과 원본의 차이를 말한다. 모든 PeeringDB 사용자의 영향 규모나 그 자료로 내린 실제 결정의 수는 발표되지 않았다. 구체적인 ID와 시각이 제시된 덕분에, 어떤 변경이 놓쳤는지는 추적할 수 있다.

10월 9일 댓글에서는 반대 방향의 차이도 드러났다. 원본에는 살아 있는 netixlan 569개가 복사본에는 없었고, 349개 네트워크와 279개 교환 지점에 걸쳐 있었다. 신고자는 긴 트랜잭션이 완료되기 전에 클라이언트의 시간 창이 지나갔거나, 복구된 행이 새 갱신 시각을 얻지 못했을 가능성을 적었다. 어느 쪽인지 확정할 자료는 그 댓글에 없다. 삭제 경로의 수정과 살아 있는 행의 누락은 별개의 확인 항목이다.

PeeringDB는 10월 20일 커밋 81ac767을 합쳤다. 활성 연결을 먼저 대량 삭제하던 호출을 없애고 네트워크의 삭제 절차가 관련 행을 처리하게 했다. 새 시험은 네트워크, 교환 지점, 연결, 기술 담당 연락처를 만든 다음 RIR 상태 정리를 실행한다. 이어 네트워크와 연결이 deleted인지, 시각이 새로워졌는지, GET /api/netixlan?since=...가 삭제된 연결을 반환하는지를 확인한다. 내부 함수가 종료된 사실보다 복사본이 받을 API 응답을 합격 기준으로 삼은 것이다.

PeeringDB 릴리스 노트는 2.84.0의 날짜를 10월 21일로 적고 #2057을 동기화 사용자에게 필요한 삭제 수정으로 설명한다. 같은 문서의 계획표에는 생산 목표일 20일이 적혀 있었다. 20일의 코드 합침과 21일의 공개 버전 날짜는 서로 다른 기록이다. 확인된 수리 범위는 시험한 정리 경로에서 이후의 삭제가 변경분으로 나오는 일이다.

오래된 복사본은 누가 다시 읽나

과거에 통째로 지워진 행은 이제 원본에 없으므로 뒤늦은 삭제 이벤트를 만들 재료가 없다. updated가 2022년인 삭제도 2026년의 증분 커서를 넘지 못한다. 신고자는 기존 차이를 고칠 클라이언트 쪽 방법으로 전체 재동기화를 든다. PeeringDB는 어느 복사본이 그 작업을 마쳤는지 발표하지 않았다. 완료 대상을 집계하면 남아 있는 옛 기록의 규모를 판단할 수 있다.

전체 재동기화는 증분 방식이 아끼려던 다운로드와 처리 비용을 다시 낸다. 원본이 삭제 절차와 API를 운영하고, 각 사용자가 자신의 복사본과 갱신 간격을 운영한다. 잘못된 삭제 통지가 이 둘 사이에 놓이면 원본 화면의 권위는 유지돼도 현장에서 사용하는 자료는 다른 시점에 머문다. 실행 기록의 초록불은 연결 상태를 보여줄 뿐, 데이터 집합의 일치를 보증하지 않는다.

API v3 초안은 증분 자료에 삭제와 공개 철회를 포함하고 매일의 스냅샷을 초기 적재와 복구에 사용하겠다고 쓴다. 초안은 아직 배포된 API가 아니다. 이번 사례는 다음 설계가 통과해야 할 시험을 선명하게 만든다. 어떤 항목이 언제 철회됐는지 복사본이 받을 수 있는가? 자신이 가진 공개 데이터의 버전을 증명할 수 있는가? 서버가 잘 떠 있어도 중요한 한 건을 전달하지 않으면 디렉터리의 현실은 둘로 갈린다.

짧은 대량 삭제 명령 하나가 외부 복사본에 긴 그림자를 남겼다. 2.84.0은 새 그림자를 만드는 길을 막았다. 오래된 그림자는 각각의 복사본을 현재 원본과 견줘야 사라진다.