restore:channel 을 채널 하나에 돌리기 시작했는데 로그를 보니 이상한 점이 있었다. 복원은 계속 진행되는데 jobs_inserted=0 으로 찍히고 있었다.
Table of contents
Open Table of contents
검증 — 중단 직전의 확인
대상 선별 로직에 버그가 있나 싶어 중단하고 되돌릴까 하다가 왜 0인지부터 확인하기로 했다. 로그에 찍힌 product_id 를 그대로 channel_products 에서 조회하니 연동 행 자체가 존재하지 않았다.
products 를 다시 보니 그 식별자들이 전부 is_master = 1 인 마스터 상품이었다. 로그의 식별자를 직접 조회한 것이 대상의 성격을 바로 알려 준 셈이다.
원인 — 나뉘어 있던 단계
RestoreChannel 을 열어 보니 마스터를 전량 처리한 뒤에 마켓 자식 단계로 넘어가는 구조였다. 마스터는 연동 행이 없는 정본 상품이라 작업을 만들 필요가 없고 그래서 insert_jobs 플래그가 꺼진 채로 돈다.
즉 작업은 자식 단계에 진입해야 비로소 생긴다는 뜻이었다. 로그를 다시 훑으니 MASTER PHASE start total= 줄과 전체 건수가 찍혀 있었고 아직 그 단계의 초반이었다.
판단 기준 — 중단이 만들었을 손해
결국 버그가 아니라 단계가 진행 중이라는 신호였다. 두 가지 방법이 있었는데 이상하니 일단 중단하고 되돌리는 것과 왜 0 인지 확인하고 이어 가는 것이다. 뒤쪽을 골랐다. 이유는 중단 자체가 되돌리기와 재실행 비용을 만들어서다. 대신 확인하는 몇 분 동안 버그였다면 그만큼 더 진행되는 위험을 감수했다. 여기서 중단하고 되돌렸으면 정상 동작을 버그로 판단해 이미 처리한 것을 되돌리고 없는 버그를 찾느라 시간을 쓴 뒤 다시 돌려도 같은 것을 봤을 것이다.
오탐으로 판단해 중단하는 것 자체가 실제 손해이므로 실행 초반의 작업 0건은 마스터 단계가 진행 중이라는 신호이고 중단하지 않는다고 기록에 남겼다.
조치 — 바꾼 진행률 측정
이 일을 겪고 나서 진행률을 보는 방법 자체를 바꿨다. 전에는 grep -c 로 로그에서 특정 문구를 세었는데 문구가 바뀌면 안 잡히고 단계별로 문구가 다르면 헷갈리며 성공과 건너뜀과 오류가 섞여 있으면 못 가른다.
restore_log 를 GROUP BY decision 으로 집계하는 방식으로 바꾸니 필요한 숫자가 한 번에 갈려서 나온다. 로그 문구에 의존하지 않으므로 문구가 바뀌어도 그 집계는 그대로 쓸 수 있다.
원인 미확정과 방법 교체
진행률을 주기적으로 보려고 만든 셸 스크립트가 카운트를 $((a + b)) 로 모으는 자리에서 죽었다. bash 매뉴얼대로 빈 변수는 0 으로 평가되니 빈 값은 아니고 숫자가 아닌 문자열이 들어와 산술이 실패한 것으로 보이지만 원인을 확정하지는 못했다.
더 나은 방법이 이미 있었으므로 그 원인을 파고들 이유가 없었다. 집계 한 줄로 교체하고 원인 미확정을 미확정 그대로 적었다. 셸 산술은 빈 값에 약하므로 집계는 집계할 수 있는 도구에 맡기는 편이 낫다.
정리
- 실행 초반의 0건이 버그가 아니라 단계 신호일 수 있다
- 중단하기 전에 지금 어느 단계인지 본다
- 로그의 식별자를 직접 조회하면 대상의 성격이 나온다
- 오탐으로 판단해 중단하는 것이 실제 손해다
- 진행률은
grep -c보다GROUP BY decision집계가 정확하다 - 집계는 결정 유형별로 갈려서 나온다
- 도구가 죽으면 원인 미확정을 미확정으로 적는다
- 집계는 집계할 수 있는 도구에 맡긴다