피해 반경은 부분집합이다

8일에 걸쳐 restore:media 를 돌려 수십만 건의 대상을 처리했다. 끝나고 나서 주기적으로 도는 다른 작업이 그것을 되돌리는 것 아니냐는 지적을 받았다.

Table of contents

원인 — 대상 조건의 실제 창

지적받은 작업을 열어 보니 매시간 도는 media:normalize 였다. 내 복구가 이미지를 정사각으로 만드는데 그 작업이 다른 규칙으로 다시 만들고 있었다.

대상 쿼리를 보니 DATE_FORMAT(NOW() - INTERVAL 1 HOUR, '%Y-%m-%d %h') 로 한 시간 전 시각을 구하면서 12시간제 %h 를 쓰고 있었고 날짜는 현재 날짜였다. MySQL 8.0 매뉴얼대로 %h 는 0112 이고 %H 가 0023 이다. 결과적으로 그 기준값의 날짜가 항상 당일이 되므로 매시간 돌아도 실제로 보는 것은 당일 생성분뿐이었다.

좁아진 반경

이것을 알고 나니 반경이 확 줄었다. 복구가 처리한 수십만 건 중 대부분은 오래전에 생성된 미디어라 그 작업의 창에 영구히 안 걸린다.

위험한 것은 복구를 돌린 그날 새로 올라온 것뿐이었다. 셀러가 올린 이미지를 복구가 처리한 뒤 같은 날 보정 작업이 한 번 더 돌아 되돌리는 경우다.

검증 — 모집단의 정의와 실측

계산할 수 있게 모집단을 정의했다. 복구 대상 중 생성일이 복구 실행일인 것의 교집합이다.

restore_log 에서 처리된 전체를 모으고 그중 media_files.created_at 이 복구 기간 안에 있는 것을 골라 수천 건을 얻었다. 처리 건수가 아니라 실제로 겹치는 부분집합을 센 것이고 수십만 중 1퍼센트가 안 됐다.

주의 — 표본과 추정치 표기

두 가지 방법이 있었는데 수천 건의 aspect_ratio 를 전수로 조회하는 것과 60건을 표본으로 뽑는 것이다. 뒤쪽을 골랐다. 이유는 답이 필요한 것은 8일치 전부냐 일부냐의 자릿수라서다. 대신 결과가 추정치에 머무는 것을 감수했다. 몇 건이 되돌아가 있어서 한 자릿수 퍼센트였고 전체로 환산하면 수백 건 정도로 추정됐다.

여기서 조심한 것이 표현이었다. 수백 건이 깨졌다고 쓰지 않고 표본에서 나온 추정치이며 전수 확인 전이라고 적었다. 지적은 8일치가 다 깨졌다는 것이었고 실측 답은 0.1퍼센트 아래 추정이었으므로 전자면 8일을 다시 돌려야 하고 후자면 수백 건만 손보면 된다.

결론 — 한정 클린업과 답하는 방식

원인이 된 보정 작업은 이미 그 모델을 건너뛰도록 수정된 뒤였으므로 다시 덮이지 않는다. 남은 것은 위험 모집단 수천 건에 square:apply 를 멱등으로 다시 적용하는 한정 클린업뿐이었고 이미 정사각인 것은 안 바뀐다.

이 건에서 배운 것은 답하는 방식이다. 전부 깨진 것 아니냐는 지적에 아니라고만 답하면 근거가 없어 받아들여지지 않는다. 모집단을 정의하고 실측해 숫자로 답해야 하고 정의 없이 일부만 영향받는다고 하면 그것도 근거 없는 말이다.

정리

• 주기 작업의 대상 조건을 정확히 읽는다
• 매시간 돌아도 당일 것만 볼 수 있다
• %h 와 %H 처럼 시각 포맷 문자 하나가 창의 크기를 바꾼다
• 피해 반경은 처리 건수가 아니라 겹치는 부분집합이다
• 모집단을 정의하고 실측한다
• 표본에서 나온 값은 추정치라고 밝힌다
• 원인이 고쳐졌으면 한정 클린업으로 닫는다
• 지적에는 모집단 정의와 숫자로 답한다