캐시된 분류는 조회 한 번을 아끼고 어제의 의견을 오늘의 결정에 얼려 넣는다. 진짜 비교는 캐시 대 캐시 없음이 아니라 관측, 그 신선도, 그리고 사이트가 고른 응답이다. 이 셋 사이의 경계를 잃으면 최적화가 스스로 정책을 만들기 시작한다. 고칠 것은 장부 정리이지 더 나은 피드가 아니다.

서로 다른 시계를 가진 세 개의 기록

관측은 받은 필드, 그것이 온 피드, 그 뒤의 데이터셋 버전이다. 신선도는 캐시 항목의 속성으로, 조회가 언제 실행됐는지, 항목을 언제부터 신뢰하지 않는지, 마지막 새로 고침이 무엇인가를 돌려줬는지다. 응답은 이 요청, 이 계정, 이 행동에 대해 사이트가 그것에 관해 하는 일이다. 이들은 서로 다른 주인이 만들고 서로 다른 속도로 쇠퇴한다. 그래서 blocked라는 한 행으로 합치면 그 구분이 무너진다.

RecordWho owns itHow long it should liveDamage when it is folded into another row
The observationthe feed's operatoruntil a newer dataset version replaces ita stale lookup becomes indistinguishable from a fresh one
Its freshnessthe applicationone request's tolerance for agea failed refresh hides behind a cache hit
The responsewhoever owns the site policyuntil that policy is revieweda feed outage turns into an indefinite block

특히 주의해야 할 시계가 둘이다. 조회가 실행된 순간은 제공자가 데이터셋을 공개한 순간이 아니며, 나중에 행을 읽는 운영자는 각 값이 둘 중 어디에서 왔는지 알아야 한다. 만료와 새로 고침은 피드의 문서화된 갱신 모델과 틀렸을 때의 비용으로 정해야 하며, 다른 사이트에서 빌려온 숫자로 정해서는 안 된다.

판결이 아니라 필드를 남겨라

MaxMind의 익명 IP 문서는 익명 VPN, 호스팅 제공자, 공개 프록시, Tor 출구를 별도 필드로 나누는 피드의 구체적인 예다. 등록되지 않은 VPN 서브넷이 대신 호스팅 표시 아래 나타날 수 있다는 점도 문서화한다. 이것을 하나의 불리언으로 평평하게 만들면 운영자가 나중에 감사할 수 있는 유일한 부분을 버리게 된다.

추론은 어느 방향도 안전하지 않다. 호스팅 라벨은 터널이 쓰였다는 것을 증명하지 않고, VPN 표시의 부재는 클라이언트와 서비스 사이에 아무것도 없었다는 것을 증명하지 않는다. 이는 서로 다른 두 주장이며, 하나의 불리언으로는 어느 것도 표현할 수 없다.

항목을 검증한 주소에 묶어라

역방향 프록시 뒤에서 애플리케이션은 배포가 승인한 클라이언트 주소 처리를 사용해야 한다. 호출자가 제공한 전달 헤더로 다른 사람의 캐시된 평판을 선택할 수 있어서는 안 된다.

그 실패는 정확성 버그이자 보안 버그다. 헤더를 통제하는 공격자는 신뢰된 항목을 물려받거나 피해자를 나쁜 항목에 고정할 수 있기 때문이다. 키는 자체 인프라가 종료한 연결에서 도출하고 어떤 도출을 썼는지 기록하라. 앞에 여러 프록시가 있으면 그럴듯해 보이는 첫 헤더를 믿는 대신 사슬을 문서화하라. 사슬이 모호하면 도출한 키와 거부한 헤더를 기록하라. 사고 검토가 묻는 것은 후자다.

증거가 없음은 깨끗한 결과가 아니다

타임아웃, 잘못된 형식의 응답, 사용할 수 없는 데이터베이스는 각각 아무것도 일치하지 않은 성공적인 조회와 다른 의미를 가진다. 이들을 별개의 결과로 제시하고, 증거가 전혀 없을 때 보호된 행동이 무엇을 하는지 미리 정하라. 읽기 전용 페이지와 로그인된 계정의 행동은 거기서 다른 규칙을 따르는 것이 합당하다.

정상 인증을 유지하거나 지원되는 검증을 요청하는 것이, 장애를 전면 허가나 사이트 전체 금지로 다루는 것보다 대개 나은 답이다. 조회가 얼마나 오래 실행될 수 있는지 제한하고, 통합이 지원하는 방식으로 새로 고침 폭주를 멈춰라. 장애 중 오래된 값을 쓸 때는 결정 지점에서 그것을 오래된 것으로 표시하고, 새로 고침의 마지막 실패를 보이게 하여 오래 지속되는 결함이 건강한 항목으로 통과하지 못하게 하라. 선택이 무엇이든 조회 옆의 주석이 아니라 정책이 시행되는 곳에 적어라.

보존도 같은 결정에 속한다. 이 기능이 필요로 하는 필드와 그 뒤의 검토 흔적만 남기고 더는 남기지 마라. IP 캐시가 탐색 기록이 될 필요는 없다.

수정을 포함한 네 가지 사례를 받아들여라

새 결과, 만료된 결과, 실패한 조회, 나중에 수정된 분류를 시험하라. 각각 다른 분기를 훈련하고, 마지막 것만이 잘못된 제한을 되돌릴 수 있는지 보여준다.

그다음 잘못된 차단 뒤에 일반 사용자가 검토를 요청할 경로가 있는지 확인하라. 피드는 때때로 틀릴 것이고 대기열은 설계의 일부다. 네 사례를 정책 소유자의 이름과 함께 런북에 적어라. 설계는 중복 조회를 없애면서 불확실성을 그대로 두고 결정이 사람의 손에 있음이 보일 때 제자리를 얻는다.

관련 글