한 채널의 작업이 안 빠지는 것을 확인하고 조치했는데 며칠 뒤 다른 채널도 같은 증상으로 보였다. 대기가 늘고 성공이 멈춘 모양이 같았다.
Table of contents
Open Table of contents
상태값이 못 가른 것
먼저 워커 상태를 봤는데 두 채널 다 실행 중으로 나왔다. 앞서 문제였던 채널과 이번 채널이 구분되지 않았다.
실행 중이라는 상태는 프로세스가 살아 있다는 것만 말하고 일을 하고 있는지는 말하지 않는다. 그래서 다른 축이 필요했다.
엉뚱한 곳을 본 조회
큐에 얼마나 쌓였는지를 보면 갈리겠다 싶어 로컬 클라이언트로 큐 길이를 물었는데 키가 없다고 나왔다. 이유를 찾아보니 큐가 중앙 저장소에 있고 각 서버의 로컬 저장소가 아니었다.
각 서버에서 로컬로 물으면 당연히 없다. 조회 결과가 없다는 것이 큐가 비었다는 뜻이 아니라 엉뚱한 곳을 봤다는 뜻이었다.
두 시각의 분포
결국 작업 테이블을 봤다. 워커가 집어서 실행을 시작한 시각과 실행이 끝난 시각 두 컬럼의 분포를 보면 갈린다.
큰 테이블이라 전수로 못 세므로 진행 기록에 있는 식별자로 한정해 집계했다. 한 채널은 전체가 실행 시각이 비어 있고 완료가 0이었으며 다른 채널은 대부분이 실행에 들어갔고 일부가 완료됐으며 1분 전에도 무언가 끝나 있었다.
정체와 느린 드레인
앞쪽은 하나도 안 집혔으므로 발행 자체가 안 됐거나 워커가 그 큐를 안 보고 있는 진짜 정체였다. 뒤쪽은 집어서 처리 중이고 완료가 계속 늘고 있는 느린 드레인이었다.
이 구분이 조치를 갈랐다. 뒤쪽을 정체로 오진해 워커를 재시작했으면 처리 중이던 수천 건이 중단되고 다시 집히면서 외부 호출이 중복될 수 있으며 그러고도 여전히 느리다. 워커가 죽은 것이 아니면 재시작은 해법이 아니고 증상은 그대로인 채 부작용만 생긴다.
순서와 조회 요령
이 판별로 조치 대상이 하나로 좁혀졌다. 두 개인 줄 알았던 문제가 하나였고 문제를 줄이는 것도 조사의 결과다.
그 뒤로 순서를 바꿔 프로세스 상태와 큐를 보기 전에 데이터부터 본다. 프로세스 상태와 큐는 간접 지표이고 정말 알고 싶은 것은 작업이 진행되고 있는지인데 그것은 작업 테이블이 직접 말해 준다. 큰 테이블은 대상 식별자를 이미 알고 있으면 그것으로 한정해 관심 집합만 보면 싸게 볼 수 있다.
정리
- 프로세스가 실행 중이라는 상태는 일을 하는지 말하지 않는다
- 큐를 볼 때 어디에 있는 큐인지 확인한다
- 조회 결과가 없다는 것이 비었다는 뜻이 아니다
- 정체와 적체는 실행 시각과 완료 시각 분포로 갈린다
- 전부 실행 시각이 비면 발행이 안 된 것이다
- 실행됐는데 완료가 늘고 있으면 느린 드레인이다
- 워커가 죽은 것이 아니면 재시작은 해법이 아니다
- 큰 테이블은 관심 식별자로 한정해 조회한다