매핑 누락인가 원시 오수집인가

외부에서 받아 온 상태값 중 매핑이 안 되는 값이 나왔다. 앞선 건에서는 같은 증상에 수십만 건을 다시 받았는데 이번에도 그래야 하는지를 정해야 했다.

Open Table of contents

상황 — 매핑 안 되는 값

재수집을 준비하기 전에 무엇을 다시 받는 것인지부터 봐야 했다.

같은 증상이면 같은 대응을 하면 될 것 같지만 그때와 조건이 같은지는 확인한 적이 없었다. 수십만 건을 curl 로 다시 받는 것은 무른 일이 아니라 시작 전에 근거가 필요했다.

스냅샷 표에 무엇이 들어가는지 봤다.

vendor_status    원시 값

vendor_status 만 저장하고 정규화된 상태는 아예 컬럼이 없었다.

정규화하는 코드를 찾았다.

public function getNormalizedStatus()
{
    return self::STATUS_MAP[$this->vendor_status] ?? null;
}

getNormalizedStatus 가 저장 시점이 아니라 읽을 때 STATUS_MAP 을 탄다.

이 한 가지가 판단을 갈랐다.

원시 값은 정확히 수집됐다
매핑만 없다
    ↓
매핑을 추가하면
    ↓
다음에 읽을 때 자연히 적용된다

이미 저장된 vendor_status 를 그대로 두고 STATUS_MAP 에 줄을 더하면 끝난다.

재수집이 필요 없는 이유가 저장 구조에 있었던 셈이고 정규화 결과를 담는 구조였으면 이미 들어간 값을 전부 다시 계산해야 했다.

그럼 앞선 건은 왜 재수집했는지를 봤다.

잘못된 엔드포인트로 호출
    ↓
전부 같은 값이 수집됨
    ↓
원시 값이 틀림

그때는 vendor_status 자체가 틀려서 STATUS_MAP 을 아무리 더해도 안 맞는다.

재료가 틀렸으니 다시 받는 것 말고 방법이 없었다. 두 상황이 증상만 같았지 원인이 전혀 달랐다.

매핑 누락    →  원시 값은 정확. 매핑만 추가
원시 오수집  →  원시 값이 틀림. 재수집 필요

앞선 대응을 그대로 따라 했으면 필요 없는 작업을 크게 벌일 뻔했다.

실제로 몇 건인지 셌다.

매핑 안 되는 값 A   25건
매핑 안 되는 값 B    0건

값 A 가 25건이고 그중에서도 다수는 매핑을 더해도 결과가 안 바뀐다.

18건은 외부 상태와 우리 상태가 진짜로 다름

그 18건은 매핑을 더해도 여전히 불일치로 잡히는 것이 맞으므로 결국 매핑 추가의 실효는 7건이었다.

앞선 건에는 부수 이득도 있었는데 특정 값을 매핑하면 재조회 대상에서 빠져 큐 부담이 줄었다.

값 A  →  재조회 지속 대상
값 B  →  재조회 지속 대상

이번에는 값 A 와 값 B 둘 다 계속 조회해야 하는 상태라 큐 부담이 안 준다. 같은 종류의 작업이라도 부수 이득은 매번 확인해야 했다.

이득이 작은데 할지 말지도 정해야 했다.

STATUS_MAP 에 없으면 정규화 결과가 null 이라 화면에 알 수 없음으로 나온다. 7건이라도 정확한 쪽이 맞고 STATUS_MAP 에 줄을 더하는 비용이 거의 없으니 하기로 했다.

이 유형의 판별 순서도 적어 뒀다.

1. 스냅샷이 원시 값을 저장하나 정규화 값을 저장하나
2. 원시 값이 정확한가 (샘플 확인)
3. 정확하면 → 매핑만 추가
   틀리면   → 재수집
4. 몇 건에 걸리는지와 부수 이득을 센다
5. 비용 대비 판단

1번이 전제인데 정규화 값을 INSERT 하는 구조면 매핑 추가만으로는 안 되고 재계산이 필요하다.

두 대응의 값이 자릿수만큼 차이 난다. STATUS_MAP 몇 줄과 배포로 끝나는 것과 수십만 건을 다시 받는 것은 상대 쪽 부하와 호출 한도까지 다르다.