작업 이력에 status = 'done'은 정상인데 log가 NULL인 건들이 있었다. 전송이 실패했는데 조용히 넘어간 것으로 보고 마켓 이미지가 깨져 있으리라 판단했다.
Table of contents
Open Table of contents
배경 — 검토하던 대량 재전송
깨진 것을 고치려면 다시 보내야 하는데 대상이 하루치만 수백 건이고 전 기간이면 훨씬 많았다. 실행 전 검토에서 재전송 전에 실제 파손 규모부터 측정하라는 지적을 받았다.
맞는 말이었다. 조용하면 깨진 것이라는 전제를 세워 놓고 그것을 확인하지 않은 상태였다.
문제 — 전수 검증의 비용
먼저 전체를 --dry-run으로 돌려 보니 한 시간 가까이 걸렸고 S3 입출력에 묶여 있었다. 이유를 보니 정상인 1천여 건까지 S3를 전부 GetObject로 조회하고 있었다.
정상인 것을 확인하는 데 대부분의 시간을 쓰는 구조였다. 두 가지 방법이 있었는데 전수를 그대로 돌리는 것과 log IS NULL인 의심 대상만 좁혀서 HeadObject로 존재 여부만 묻는 것이다. 뒤쪽을 골랐다. 이유는 정상인 건을 다시 확인하는 것은 결론에 아무것도 보태지 않아서다. 대신 의심 조건 밖에서 깨진 것은 못 보는 것을 감수했다. 수십 초 만에 끝났고 같은 결론에 도달하는데 백 배 가까이 차이가 났다.
검증 — 1퍼센트에 못 미친 실측
검증 대상 1천여 건 중 실제 파손은 몇 건이었다. 1퍼센트에 한참 못 미쳤고 그 몇 건이 전부 같은 product_id였다.
그 상품을 더 보니 original은 있고 thumb만 없었다. 업로드는 됐고 변환만 실패한 것이므로 전송 실패가 아니라 변환 파이프라인 문제였다.
원인 — 뒤집힌 전제와 붕괴한 규모
조용한 것은 전송 실패가 아니라 로그 기록 누락이었고 이미지는 대부분 멀쩡했다. 브로커가 결과를 log 컬럼에 안 남기는 관찰성 문제였다.
계획이 완전히 달라져서 며칠치 수백 건씩의 대량 재전송이 상품 하나에 대한 소규모 배치가 됐다. 규모가 붕괴하면서 되돌릴 수 없는 외부 재전송과 워커 과부하라는 두 위험도 함께 사라졌다.
결과 — 진짜 산출물과 싼 확인
그러면 이 조사의 산출물이 무엇인가를 다시 정했다. 브로커가 결과를 log에 안 남기는 것을 고치는 일이었고 그러면 앞으로 이런 의심 자체가 안 생긴다.
진짜 문제는 파손이 아니라 안 보이는 것이었다. 규칙으로 둘을 남겼는데 조용한 것을 파손으로 전제하지 않고 재전송 전에 실제 파손 수를 측정하며 전수 시험 실행 대신 의심 모집단만 좁힌다는 것이다. 되돌릴 수 없고 부하가 큰 행동을 할지 정하는 확인이 수십 초였고 비가역 행동 전의 싼 확인은 거의 항상 값어치를 한다.
정리
- 조용하다는 것이 깨졌다는 뜻이 아니고 관찰성 문제일 수 있다
- 비가역 재전송 전에 실제 파손 규모를 잰다
- 전수 시험 실행은 정상인 것을 확인하는 데 시간을 다 쓴다
- 의심 모집단만 좁혀
HeadObject로 존재 여부만 확인한다 - 파손이 한 대상에 몰려 있으면 복구 규모가 붕괴한다
original은 있고thumb만 없으면 전송이 아니라 변환 문제다- 진짜 산출물이 복구가 아니라 로그 수정일 수 있다
- 비가역 행동 전의 싼 확인은 거의 항상 값어치를 한다