쿼리 하나로 파이프라인 검증하기

복구 작업을 돌리고 나서 그것이 끝까지 갔는지 확인해야 했다. 작업을 넣으면 워커가 가져가고 외부로 전송되는 구조라 어느 단계까지 갔는지를 알아야 했다.

Open Table of contents

두 컬럼이 만드는 상태 표

작업 테이블에 완료 시각과 결과 로그 두 컬럼이 있었고 그 조합으로 상태가 갈렸다. 완료 시각이 비어 있으면 아직 안 가져간 것이고 있으면 처리가 끝난 것이다.

처리가 끝났는데 로그가 비어 있으면 성공이고 값이 있으면 실패였다. 로그가 비어 있는 것이 성공이라는 규약이 처음에는 헷갈렸는데 성공하면 남길 것이 없다는 뜻이었다.

전체와 완료와 성공과 실패를 조건별 합계로 한 번에 뽑게 했다. 대기 중인 것은 전체에서 완료를 빼면 나온다.

한 번의 조회로 파이프라인의 각 단계가 몇 건인지가 전부 보인다. 단계별로 따로 조회하면 조회 사이에 상태가 바뀌어 합이 안 맞을 수도 있다.

처음에는 대기 건이 남아 있는 것이 문제로 보였다. 워커가 삽입 후 일정 시간을 두고 가져가므로 방금 넣은 것이 대기로 남는 것은 정상이었다.

대기와 멈춤은 한 시점의 숫자로는 구분되지 않고 시간을 두고 다시 세어 줄어드는지로만 갈린다. 줄어들면 대기이고 그대로면 멈춤이다.

실패가 0이라는 결과가 단순히 전부 성공했다는 뜻만은 아니었다. 이 파이프라인 앞에는 복구 불가능한 대상을 걸러 내는 게이트가 있다.

게이트가 제대로 걸렀기 때문에 그 대상이 작업으로 안 들어왔고 들어온 것은 외부가 수락했다는 뜻이 된다. 게이트가 안 걸렀거나 외부가 거부했으면 어느 쪽이든 실패로 나타났을 것이므로 한 숫자가 두 단계를 함께 검증했다.

이 집계를 돌리기 전에 실행 계획을 확인해 인덱스를 타는지와 예상 규모가 감당 가능한지를 봤다. 이 테이블은 크고 자주 쓰이므로 조건이 잘못되면 전체를 훑는다.

운영 데이터베이스에서는 조회도 다른 요청에 영향을 준다. 검증을 조회로 하면 반복해서 돌릴 수 있고 결과를 그대로 보고에 붙일 수 있으며 다른 사람이 같은 판정을 재현할 수 있다는 것이 이 방식의 값이었다.