넉 달 이어진 문제가 근거가 됐다

crontab 에 걸린 정산 배치가 자주 실패했다. 구조를 바꾸자고 몇 번 말했는데 매번 밀렸다.

Open Table of contents

말로는 안 됐다
기록을 남기기 시작했다
결과 — 세어 보니 숫자가 나왔다
무엇을 바꿀지와 승인
검증 — 바꾼 뒤의 숫자
정리

말로는 안 됐다

이거 구조가 안 좋아서 계속 실패한다고 말했다. 그러면 지금 급한 것부터 하고 나중에 보자는 답이 돌아왔다.

맞는 말이었다. 지금 급한 것이 있고 내 말에는 숫자가 없었다. error_log 에 흔적은 남았지만 세어 본 적이 없었고 자주라는 말은 사람마다 다르게 들린다.

다른 일과 견주어 무엇을 먼저 할지 정해야 하는데 비교할 숫자가 없었다. 그러니 우선순위를 정할 때 눈앞에 급한 것이 항상 이겼다.

기록을 남기기 시작했다

실패할 때마다 batch_failure 에 한 행씩 적었다.

날짜        무엇이 실패       원인                   대응            걸린 시간
09-03       정산 배치        메모리 부족            나눠서 재실행    2시간
09-12       정산 배치        타임아웃               재실행           40분
09-21       정산 배치        중간 실패로 중복 데이터  수동 정리       3시간
10-02       정산 배치        메모리 부족            나눠서 재실행    2시간
...

날짜와 원인과 대응과 걸린 시간을 담았다. 매번 적는 것이 일이 될까 걱정했는데 실패를 처리하고 나서 한 줄 적는 데 1분이 안 걸렸다.

오히려 적으면서 정리가 됐다. 같은 원인이 반복되는 것이 적으면서 보였고 세 번째 메모리 부족을 적을 때 이미 패턴을 알아챘다.

결과 — 세어 보니 숫자가 나왔다

넉 달을 적고 GROUP BY 로 묶었다.

기간        2014-09 ~ 2014-12 (4개월)
실패 횟수   17회
대응 시간   합계 31시간
원인 분포   메모리 부족 8, 타임아웃 5, 중복 데이터 4

COUNT(*) 로 세니 한 달에 네 번이고 SUM 으로 합치니 매번 두 시간 가까이 썼다.

구조 변경 예상 기간   5일 (40시간)
4개월간 대응 시간     31시간

이대로 넉 달을 더 가면 31시간을 또 쓰고 여덟 달이면 62시간이다. 말이 아니라 표로 보이니 이야기가 달라졌다.

무엇을 바꿀지와 승인

숫자만으로는 안 됐다. 무엇을 어떻게 바꿀지도 적었다.

지금
  한 번에 전체 기간을 메모리에 올려 계산한다
  중간에 죽으면 어디까지 했는지 모른다

바꾸면
  날짜 단위로 나눠 돌린다
  날짜마다 처리 상태를 기록한다
  실패하면 그 날짜만 다시 돌린다

예상 기간 5일
  1일  상태 테이블 추가, 날짜 단위 분리
  2일  기존 로직 이식
  3일  재실행 처리
  4일  시험 (지난 3개월 데이터로 다시 돌려 값 비교)
  5일  배포와 관찰

4일에 넣은 것이 중요했다. 바꾼 것이 옛것과 같은 값을 내는지 확인하는 방법이었고 한동안 두 방식을 함께 돌려 각각의 출력을 md5sum 으로 대조했다.

표를 보이니 진행하게 됐다. 5일이 아니라 7일이 걸렸다.

계획 5일 → 실제 7일
  이유: 옛 로직에 문서에 없는 예외 처리가 3개 있었다

이것도 적었다. 다음에 기간을 추정할 때 참고가 된다.

검증 — 바꾼 뒤의 숫자

바꾼 뒤에도 batch_failure 에 계속 쌓았다.

2015-01 ~ 2015-04
실패 횟수   2회
대응 시간   합계 40분

17회가 2회가 됐고 두 번 다 재실행으로 끝났다. 바꾸기 전에 센 것이 있어서 비교가 됐고 안 셌으면 좋아진 것 같다로 끝났을 것이다.

그 뒤로 무엇을 바꾸자고 할 때는 먼저 셌다.

- 몇 번 일어나는가
- 한 번에 얼마나 쓰는가
- 바꾸면 얼마나 걸리는가
- 바꾼 뒤에 무엇으로 확인하는가

넷을 적어서 가면 이야기가 짧았다. 기억으로만 두면 요즘 자주 실패하는 것 같다에서 끝나고 자주가 얼마인지 어떤 원인이 많은지가 안 나온다.

넉 달치가 쌓이자 그것이 그대로 근거가 됐다. 처음부터 근거를 만들려고 적은 것이 아니었는데 결과적으로 그렇게 됐다.

정리

구조를 바꾸자는 말에는 숫자가 필요하다
자주라는 말은 사람마다 다르게 들린다
비교할 숫자가 없으면 눈앞의 급한 것이 이긴다
실패할 때마다 batch_failure 에 날짜·원인·대응·걸린 시간을 넣는다
GROUP BY 에 COUNT(*) 를 붙이면 원인이 몇 가지인지 나온다
SUM 으로 합치면 들어간 시간이 숫자가 된다
무엇을 어떻게 바꿀지와 얼마나 걸릴지도 같이 적는다
두 방식을 함께 돌려 출력을 md5sum 으로 대조한다
계획과 실제가 다르면 그것도 적어 다음 추정에 쓴다
바꾸기 전 숫자가 있어야 비교가 된다