요약
- 두 시스템이 같은 데이터를 중복 기록 중인지 확인하려고 날짜 프리픽스별 키 교집합을 재면, 두 시스템의 날짜 기준이 달라 교집합이 실제보다 낮게 나온다.
- 교집합 63%를 보고 "트래픽을 절반씩 나눠 쓴다"로 결론 낼 뻔했지만, 한쪽에만 있던 키를 인접일에서 다시 찾으니 30개 중 29개가 있었다. 실제로는 전건 중복 기록이었다.
- 교집합이 100%도 0%도 아닌 어중간한 값이면 결론 전에 경계 효과부터 의심한다.
본문
상황
객체 스토리지 두 곳이 모두 YYYYMMDD/ 프리픽스로 나뉘어 있었다. 같은 작업을 두 번 저장하고 있는지 확인하려고 같은 날짜의 식별자 집합을 비교했다.
A에만: 7,553 교집합: 12,870 B에만: 7,850
교집합 63%. 이 숫자 하나로는 두 해석이 다 가능하다.
- 트래픽을 나눠 처리하는 중이다 (그렇다면 교집합이 0에 가까워야 하는데 63%는 너무 높다)
- 중복 기록인데 경계에서 어긋난다 (그렇다면 교집합이 100%에 가까워야 하는데 63%는 너무 낮다)
둘 다 어긋나서 판단이 안 된다.
왜 어긋나나
두 시스템의 날짜 기준이 달랐다. 한쪽은 작업이 시작된 시각으로, 다른 쪽은 파일이 업로드된 시각으로 폴더를 정한다. 작업이 자정에 걸치거나 업로드가 지연되면 같은 건이 서로 다른 날짜 폴더로 들어간다.
경계 효과를 "자정 몇 분"으로만 생각하면 수 % 수준이라 무시하게 되는데, 업로드 지연이 끼면 수십 %까지 커진다. 처리 파이프라인이 몇 시간씩 밀리는 구조면 하루치의 상당 부분이 다음 날 폴더로 넘어간다.
진단
전체를 다시 나열할 필요가 없다. 이탈 표본만 인접 파티션에서 재조회하면 된다.
- 한쪽에만 있는 키를 30개 뽑는다
- 반대쪽 저장소의 전날·당일·다음날 세 프리픽스에서 그 키를 조회한다
- 양방향 모두 수행한다
결과는 양방향 모두 29/30이 인접일에 존재했다. 분할이 아니라 중복이라는 결론이 나온다. 조회 횟수는 표본 30개 × 프리픽스 3개 × 양방향 = 180번으로 끝난다. 전체 나열(수십만~수백만 객체)과 비교할 수 없이 싸다.
일반화
- 날짜 파티션은 "같은 시각"이 아니라 **"같은 기준의 시각"**일 때만 직접 비교할 수 있다. 비교 전에 양쪽이 무엇을 기준으로 폴더를 나누는지 확인한다
- 교집합 비율이 애매하면 그 자체를 결론의 근거로 쓰지 않는다. 이탈 표본을 인접 파티션에서 재조회해 경계 효과인지 실제 차이인지 가른다
- 표본 재조회는 전수 비교보다 훨씬 싸고, 이 판별에는 충분하다