13개 채널에 걸친 복구 작업 중 첫 채널이 완주했다. 끝났다는 것을 무엇으로 확인할지가 다음 문제였다.
Table of contents
Open Table of contents
마커 하나로는 부족한 이유
로그 끝에 완료 문구와 정리 단계 문구가 찍혀 있었다. 마지막 줄만 보면 될 것 같지만 하나가 더 필요했다.
크래시로 죽어도 로그는 어딘가에서 끊기므로 마지막 줄이 완료인지 그냥 거기서 멈춘 것인지를 가려야 한다. 정상 흐름의 끝에서 찍는 마커와 정리 단계에서 찍는 마커 둘을 다 보면 크래시와 구분되는데 크래시면 두 번째가 없다.
프로세스 소멸 확인
로그는 있는데 프로세스가 살아 있으면 다른 일을 하고 있는 것이다. 그래서 해당 패턴의 프로세스가 남아 있는지를 따로 확인했다.
로그 마커와 프로세스 상태는 서로 다른 것을 본다. 로그는 코드가 거기까지 갔다는 것이고 프로세스는 실제로 끝났다는 것이다.
기록 집계의 합
세 번째로 진행 기록을 결정 유형별로 집계했다. 삽입한 것과 이미 정상이던 것의 합이 전체와 맞아떨어졌고 크래시는 0이었다.
셋이 각각 다른 오인을 막는다. 로그 마커 둘은 크래시를 완료로 오인하는 것을 막고 프로세스 소멸은 아직 도는데 끝났다고 오인하는 것을 막으며 기록 집계는 프로세스는 끝났는데 처리가 빠진 것을 잡는다. 하나만 보면 나머지 둘의 오인이 그대로 남는다.
숫자의 정확한 뜻
집계에서 삽입 건수가 2만 7천여 건이었는데 그것을 그만큼 처리했다고 읽으면 안 됐다. 정확한 뜻은 해당 마켓에 재전송될 후보 상품 수다.
이미지 오류 이력이 있는 상품을 재전송 작업으로 넣는 데까지가 이 작업의 몫이고 실제 송신은 워커가 나중에 한다. 처리 완료와 전송 완료가 다르므로 숫자에 어느 쪽 뜻인지를 붙여 적었다.
미루는 것과 안 하는 것
워커가 실제로 보냈는지도 확인해야 하는데 작업 테이블이 2억 행이라 한 채널 확인하자고 조회를 거는 것이 부담이었고 그때 조회 도구도 다운 상태였다.
그래서 전 채널 완료 후 최종 마무리 단계에서 일괄로 하기로 하고 그것을 기록에 적었다. 나중에 확인하겠다는 말은 안 하는 것과 같고 언제 어떻게 할지가 적혀야 미루는 것이 된다.
미뤄도 괜찮다고 본 근거도 있었다. 삽입에서 워커 실행으로 이어지는 경로 자체는 앞선 카나리 채널에서 이미 실증됐으므로 이번에 확인할 것은 이번 건이 그 경로를 탔는지뿐이고 그것은 삽입 건수로 안다. 첫 채널에서 세운 이 3중 검증은 나머지 열두 채널에 그대로 적용하기로 했는데 절차를 매번 새로 만들면 결과를 비교할 수 없기 때문이다.
정리
- 완료 판정은 로그 마커와 프로세스 소멸과 기록 집계 셋으로 한다
- 로그 마커는 둘 이상 봐야 크래시와 구분된다
- 셋이 각각 다른 오인을 막는다
- 집계 숫자의 정확한 뜻을 정한다
- 처리와 전송은 다른 말이다
- 비싼 검증은 언제 할지 정해서 미룬다
- 경로가 이미 실증됐으면 매번 확인하지 않는다
- 첫 대상에서 정한 절차를 나머지에 그대로 쓴다