요약

  • 여러 객체를 포함한 RIPE Database 업데이트는 수용된 작업과 거부된 작업을 동시에 담을 수 있습니다. 전체 메시지가 이메일 방식으로 실패 처리되었다고 해서 성공한 변경이 되돌려졌다는 보장은 없습니다.
  • Syncupdates 처리는 HTTP 연결이 닫힌 뒤에도 계속될 수 있습니다. 응답이 오지 않으면 호출자는 확정된 결과를 알 수 없으며, 이는 모든 작업이 실패했거나 성공했다는 뜻이 아닙니다.
  • 객체별 응답 상세, 적절히 범위를 한정한 재조회(readback), 각 알림이 발생한 이유는 서로 다른 증거를 제공합니다. 무엇을 다시 수행할지 결정하기 전에 이 구분을 유지해야 합니다.

네 건의 성공, 세 건의 변경

확인 응답(acknowledgment) 가이드에는 간단한 회계 교훈이 담겨 있습니다. 이 가이드의 예시 요약은 다섯 개 객체를 다룹니다. 네 작업이 성공합니다. 하나는 객체를 생성하고, 둘은 객체를 수정하며, 하나는 변경이 필요 없어 아무 작업도 하지 않습니다. 다섯 번째 작업, 또 하나의 수정은 실패합니다. 네 건의 성공은 네 번이 아니라 세 번의 변경을 만들어냅니다.

같은 가이드의 규칙을 전체 이메일 방식 결과에 적용하면, 오류가 있으면 메시지는 실패로 분류됩니다. 이 레이블은 혼합된 결과 집합 위에 붙을 수 있습니다. 그렇다고 데이터베이스가 요청 이전 상태 그대로였다는 의미는 아닙니다. 이는 가이드의 설명적 예시이며, 이 기사를 위해 수집된 고객 교환 기록이 아닙니다. 별도의 샘플 헤더들을 조합해 실제 응답이라 주장해서는 안 됩니다. 이 구분은 문서화된 규칙 그 자체에 있습니다.확인 응답 가이드

피해야 할 실수는 단순히 단어를 잘못 읽는 것이 아니라 판단에 있습니다. 어떤 애플리케이션은 실패한 메시지를 "아무것도 하지 않은" 작업으로 표시할 수 있고, 다른 애플리케이션은 성공한 HTTP 응답을 "모두 완료된" 작업으로 표시할 수 있습니다. 어느 쪽 지름길이든 의도한 작업을 완성하는 데 필요한 정보를 버릴 수 있습니다. 실패한 작업은 수정이 필요할 수 있고, 성공한 무동작(no-op)은 수정이 필요 없을 수 있으며, 수용된 변경은 조직이 원했던 결과 그 자체일 수 있습니다.

메시지는 커밋 단위가 아닙니다

RIPE의 처리 가이드는 개별 객체 작업을 설명합니다. 한 작업의 실패가 뒤에 오는 객체 평가를 자동으로 막지는 않습니다. 의존성은 여전히 중요합니다. 참조된 객체의 생성이 실패하면 그 객체를 필요로 하는 다른 작업이 자체 무결성 검사에서 실패할 수 있습니다. 일부 자동 생성 식별자도 처리 순서에 영향을 줄 수 있습니다. 이는 엄격한 처음부터 끝까지의 실행 보장도, 모든 의존성을 해결하는 범용 메커니즘도 아닙니다.객체 처리

이러한 독립성에는 합리적인 목적이 있습니다. 형식이 잘못된 연락처 수정이 무관하고 유효한 유지보수 작업을 막을 필요는 없습니다. 각 객체는 여전히 자체 권한 검사와 일관성 검사를 거칩니다. 제출된 모든 객체에 같은 운명을 요구하는 것은 다른 서비스 계약이며, 호출자가 무엇을 함께 묶을 수 있는지에 대한 다른 제약을 갖습니다. 이 증거는 RIPE NCC가 현행 설계를 바꿔야 한다고 주장하지 않습니다.

그럼에도 호출자는 서버가 봉투(envelope)만으로 추론할 수 있는 것보다 더 큰 의도를 갖고 있습니다. 한 팀은 여러 레코드 변경을 하나의 유지보수 작업으로 간주할 수 있지만, 데이터베이스는 이를 여러 개의 유효 또는 무효 작업으로 볼 수 있습니다. 두 완료 정의 사이의 간극을 조율하는 책임은 팀에 있습니다.

이를 위해 새로운 범용 보고 형식이 필요한 것은 아닙니다. 현재의 확인 응답은 이미 오류, 성공한 작업, 객체로 인식되지 않은 자료를 구분합니다. 첫 상태 줄만 남기는 클라이언트는 그 구분을 자발적으로 버리는 것입니다. 첫 개선은 작업을 인증하는 새 기관을 요구하는 것이 아니라 반환된 증거를 활용하는 것입니다.

작동하는 연결은 더 작은 질문에 답합니다

인터페이스가 중요합니다. Syncupdates는 하나의 메시지로 여러 객체를 받습니다. 문서는 애플리케이션이 반환된 결과를 처리할 것을 기대하며, 요청 제출을 작업의 끝으로 여기지 말라고 합니다. 확인 응답 가이드는 HTTP 200 응답이 객체 수준 오류와 함께 올 수 있다고 특별히 경고합니다. 요청의 성공적 처리는 그 안의 모든 작업의 성공과 같지 않습니다. 이는 해당 문서화된 인터페이스에 관한 설명이며, 모든 RIPE HTTP 서비스에 적용되는 규칙은 아닙니다.Syncupdates

반대 경우는 더 어렵습니다. 호출자가 확인 응답을 받기 전에 연결이 닫히는 동안 데이터베이스는 업데이트 평가를 계속할 수 있습니다. 따라서 타임아웃은 변경되지 않은 객체에 대한 신뢰할 수 있는 목록을 제공하지 않습니다. 처리가 계속된다고 해서 모든 객체가 통과한다는 뜻도 아닙니다. 단순한 빨간 상태로는 해결할 수 없는 호출자 측 불확실성이 남습니다.

최종 응답을 받지 못한 유지보수 도구를 상상해 보십시오. 운영자는 두 가지 상상된 확신 중 하나를 골라야 할 필요가 없습니다. 요청 전체가 사라졌거나, 모두 적용되었다거나. 정직한 초기 분류는 결과가 아직 확인되지 않았다는 것입니다. 다음 과제는 원래 요청을 반사적으로 반복하는 것이 아니라 운영자의 권한 범위 안에서 관찰과 조율입니다.

이것은 사고 보고서가 아니라 설명적 워크플로입니다. 이 조사를 위해 업데이트를 제출하거나, 연결을 의도적으로 끊거나, 고객 계정을 조사하지 않았습니다. 분석은 이런 클라이언트를 운영하기 전에 공개 문서가 구현자에게 알려줄 수 있는 것에 관한 것입니다.

하나의 알림이 모두의 결과는 아닙니다

이메일은 도움이 되지만 자체 범위가 있습니다. RIPE의 알림 규칙은 수정된 객체와 그 참조에서 수신자를 도출합니다. 따라서 서로 다른 주소가 다중 객체 업데이트의 서로 다른 부분 집합을 받을 수 있습니다. 수신자는 보낸 사람의 전체 작업 기록으로는 불완전하지만 그 수신자에게는 정확한 계정을 볼 수 있습니다.알림 메시지

수정되는 주소 자체도 단순한 완료 증인이 아닙니다. 수정 작업의 경우 이전 객체의notify:값이 해당 속성의 알림을 결정합니다. 다른 참조는 다른 수신자 경로를 제공할 수 있습니다. 요점은 새 연락처가 아무것도 받을 수 없다는 것이 아니라, 제출된 새 주소만으로 전체 알림 지도를 설명할 수 없다는 것입니다.

일반적인 변경 알림과 인증 실패로 촉발된 알림도 서로 다른 의미를 갖습니다. 메일 메시지가 자동으로 승인, 보안 판정, 배치 성공 증명서가 되는 것은 아닙니다. 반대로 한 메일함의 침묵은 그 메일함의 알림 범위 밖 레코드에 대한 약한 증거입니다. 이 기사는 실제 메일 전송에 대해 어떤 주장도 하지 않습니다.

적절한 기록은 독자에 따라 다릅니다. 제출자는 제출한 작업의 결과를 필요로 합니다. 유지보수자는 자신이 관리하는 객체와 관련된 정보를 필요로 합니다. 모든 수신자에게 전체 페이로드를 주는 것은 그 설계 문제를 해결하지 못합니다. 오히려 수신자의 책임과 무관한 연락처 정보를 노출할 수 있습니다.

과거를 다시 쓰지 않고 재조회하기

RESTful 인터페이스는 객체 주소 지정 작업과 구조화된 응답을 제공하며, Syncupdates와 다른 의미 체계를 갖습니다. 애플리케이션을 그 인터페이스로 옮기면 개별 결과 처리가 단순해질 수 있습니다. 하지만 일련의 별도 요청이 전부 아니면 전무의 트랜잭션이 되는 것은 아닙니다. 다중 레코드 유지보수 목표에는 여전히 완료의 정의가 필요합니다.RESTful API

재조회에도 주의가 필요합니다. REST 문서는 객체 업데이트와 조회·검색에서의 가시화 사이에 지연이 있다고 설명합니다. 따라서 즉시 표시된 이전 결과만으로는 롤백의 증거가 될 수 없습니다. 운영자는 지원되는 인터페이스의 관찰 규칙을 사용해야 하며, 빠른 반복 조회를 그 이해의 대체물로 삼아서는 안 됩니다. 공개된 시간 지연 설명은 이 조사에서 측정한 것이 아니며, 이 기사가 제공하는 보장도 아닙니다.

사용 가능한 드라이런 기능은 서로 다른 불확실성을 다룹니다. 데이터베이스를 변경하지 않고 구문, 권한, 비즈니스 규칙, 참조에 대해 예정된 작업을 평가할 수 있습니다. 이는 유용한 사전 준비입니다. 하지만 결과를 커밋하지 않고, 일반 변경 알림을 실행하지 않으며, 이후 실제 작업이 실행될 미래 상태를 예약하지도 않습니다.드라이런

응답이 혼합되거나 사라진 후에는, 적용된 변경, 명시적 거부, 변경 없이 성공한 무동작, 미확정 작업을 구분하는 간단한 복구 기록이 유용합니다. 각 항목에 관련 관찰과 다음 결정을 붙이십시오. 원래 응답은 적절한 접근 통제 아래 보관하되, 자격 증명을 운영용 내보내기에 복사하거나 비공개 연락처 페이로드를 게시하지 마십시오.

재시도에 대한 일반적 금지는 없습니다. 권한 있는 작업이 여전히 적절하고 객체가 이미 그 상태와 일치한다면, 다시 아무것도 하지 않는 것이 완전히 만족스러울 수 있습니다. 문제는 무엇이 일어났는지, 같은 의도가 여전히 유효한지 먼저 확인하지 않고 반복하는 것입니다. 이전 작업이 완료된 것처럼 보이기 위해 나중의 합법적 변경을 지우고 싶은 번거로움으로 취급해서는 안 됩니다.

이력 조회는 증거에 기여할 수 있지만, 이력 문서는 개인 이력 데이터를 제외합니다. 공개 조회가 모든 과거 연락처 상태를 재구성한다고 가정할 수 없습니다. 이 제한은 내부 기록의 부재에 대해 아무것도 말하지 않으며, 권한 있는 운영자가 정당하게 받은 증거를 보존해야 하는 이유를 설명합니다.이력 데이터

레지스트리가 조직의 전체 유지보수 계획을 결정할 필요는 없습니다. 자신의 작업에 대한 이해 가능한 계약이 필요하고, 그 문서는 그 계약의 상당 부분을 제공합니다. 조직의 도구는 요청의 레이블과 그 구성 결과 사이의 구분을 유지해야 합니다. 실패는 롤백이 아니어도 유용한 정보가 될 수 있습니다. 성공한 작업은 아무것도 바꾸지 않아도 유용할 수 있습니다. 다음 결정은 어느 것이 일어났는지 아는 데 달려 있습니다.

출처

  1. RIPE NCC: Acknowledgment Message
  2. RIPE NCC: 주체 Processing
  3. RIPE NCC: Syncupdates
  4. RIPE NCC: Notification Messages
  5. RIPE NCC: RIPE Database RESTful API
  6. RIPE NCC: Dry-run
  7. RIPE NCC: Historical Data