인수한 서비스에서 여러 현장의 장비 기록 수집이 동시에 실패했다. 동시에 났으니 공통된 무언가가 문제일 것으로 보고 공통 수집기 RecordCollector 를 의심했다.
Table of contents
Open Table of contents
배경 — 공통 컴포넌트를 의심한 근거
그 수집기의 변경 이력을 보니 최근 배포가 없었다. 그러면 외부가 일제히 바뀐 것인지 따져 봤는데 여러 현장의 장비가 같은 날 펌웨어를 바꿀 이유가 없다.
양쪽 다 성립하지 않으면 전제 쪽을 의심해야 한다. 동시에 실패했다는 사실에서 원인이 하나라는 결론이 자동으로 나오지는 않는다.
해 본 것 — 값의 출처를 역추적했다
실패 지점의 recordedAt 하나를 골라 그 값이 어디서 채워지는지 검색했다. 공통 수집기가 아니라 현장마다 있는 SiteClient 구현에서 채우고 있었다.
현장마다 장비가 주는 필드명이 달라서 매핑도 각자 달랐다. 생산자가 여럿이면 동시 실패의 원인도 여럿일 수 있고 그것은 출처를 따라가야만 드러난다.
원인 — 제각각인 정규화
더 보니 형식 처리도 클라이언트마다 달랐다. 어떤 것은 T 가 든 ISO 형식으로 맞춰 넘기고 어떤 것은 yyyyMMddHHmmss 를 자체 변환했다. 어떤 것은 공백이 든 원본을 거의 그대로 넘겼다.
그 값을 받는 공통 팩토리 RecordFactory 는 LocalDateTime.parse 하나로 받고 있었다. Java 공식 문서대로 이 메서드는 ISO_LOCAL_DATE_TIME 형식만 받으므로 나머지는 전부 DateTimeParseException 이 된다. 각자 다른 편차가 한 지점에서 같은 방식으로 걸린 것이었다.
막힌 지점 — 공통 지점과 공통 원인
정리하면 공통 컴포넌트가 바뀌어서가 아니라 공통 컴포넌트가 여러 편차를 못 견뎌서였다. 동시에 실패한 것은 그 지점이 하나이기 때문이다.
공통 원인이면 그 하나를 고치면 끝난다. 공통 지점이면 그 지점을 관용적으로 바꿔도 각자의 이유는 남는다. 지금은 통과해도 다음 편차가 오면 같은 자리에서 다시 걸린다.
조치 — 볼 필요 없는 곳을 확정하기
팩토리를 관용적으로 바꾸지 않고 각 SiteClient 가 ISO 형식으로 맞춰 넘기게 고치는 쪽을 골랐다. 이유는 편차의 책임을 편차가 생기는 자리에 둬야 다음 현장이 추가될 때 같은 규칙이 적용돼서다. 대신 클라이언트 수만큼 고치는 자리가 늘어나는 것을 감수했다.
이것을 알고 나니 조사 범위가 바뀌어서 볼 곳이 각 클라이언트의 매핑과 팩토리의 파싱으로 좁혀졌다. 레거시 RecordCollector 는 이 경로와 무관하다는 것도 함께 확정됐다. 볼 필요 없는 곳을 확정하는 것도 조사의 결과이고 나중에 그쪽을 손볼 때 이 경로에 영향이 없다는 근거가 된다.
정리
- 동시 실패를 보고 공통 컴포넌트를 의심하는 것은 자연스럽다
- 변경 이력이 없으면 그 전제를 다시 본다
- 값이 어디서 채워지는지 역추적한다
- 생산자가 하나인지 여럿인지가 거기서 갈린다
- 공통 지점을 지나는 것과 공통 원인은 다르다
- 각자 형식이 다른데 공통 처리가 엄격하면 편차가 실패가 된다
- 그 지점만 관용적으로 바꾸면 다음 편차에서 또 걸린다
- 볼 필요 없는 곳을 확정하는 것도 조사의 결과다