할 일이 없으면 침묵하는 감시

배치가 안 돌면 담당자에게 문자를 보내던 방식을 계측으로 대체하는 작업이었다. 새 계측 코드를 검토하다가 처리 대상 행을 채널별로 묶어 지표를 내보내는 한 줄에서 멈췄다.

Open Table of contents

0건일 때의 무음

배치가 5분에서 10분 주기로 37개 스케줄돼 있는데 대부분의 회차는 처리할 것이 없다. 그러면 그룹이 비고 반복이 0회 돌고 지표가 하나도 나가지 않는다. 결과적으로 대부분의 실행이 아무 신호도 남기지 않는 무음 구조였다.

그러면 지표가 안 보일 때 배치가 아예 안 돈 것인지 돌았는데 처리할 것이 없었던 것인지 구분할 수 없다. 문제는 첫 번째가 바로 대체하려던 문자 알림이 잡던 상황이라는 점이었다. 대체품이 원본이 잡던 것을 못 잡는다.

같은 코드베이스 안에 이 문제를 이미 푼 선례가 하나 있었다. 크롤링 배치는 저장 건수가 0이어도 1건을 내보내고 있었고, 소비하는 쪽에는 감시 대상 키 목록이 상수로 선언돼 있어 여섯 채널 중 하나가 안 오면 안 온 것을 알 수 있었다.

여기서 두 성질이 나온다. 결과가 0이어도 신호를 보내는 무조건성과 무엇이 와야 하는지를 미리 적어 두는 선언성 둘이다. 보낼 것이 없어도 없다는 것을 보내야 하고 와야 할 목록이 없으면 안 온 것을 알 방법이 없다. 침묵하는 계측에는 둘 다 없었다.

문제의 본질은 감시 대상이 될 키 자체를 처리 대상 데이터에서 발견하고 있다는 점이었다.

$rows->groupBy(['channel', 'api_identifier'])->each(fn($g) => emit(...));

데이터가 없으면 키도 없고 키가 없으면 신호도 없는 연쇄가 된다. 그런데 그 키는 이미 다른 곳에 적혀 있었다. 스케줄러가 배치를 부를 때 채널과 식별자를 인자로 명시하고 있었다.

$schedule->command('order:create marketA --identifier=xxx')->everyFiveMinutes();

스케줄 정의에서 가져오면 처리 대상이 0건이어도 어떤 키가 있어야 하는지를 안다. 감시 키는 데이터에서 발견하지 말고 선언된 곳에서 가져와야 한다. 인자든 레지스트리든 상수든 데이터와 무관하게 존재하는 자리여야 한다.

같은 시기에 성격이 정반대인 모양도 하나 봤다. 작업 이력 테이블에서 완료 시각도 찍히고 상태도 성공인데 로그 본문만 비어 있는 건이 하루 17,120건 나왔다.

$this->jobCompleted($result['message'] ?? null);

응답에 해당 키가 없으면 빈 값이 넘어가고 완료 처리 함수는 그것을 로그 컬럼에 그대로 쓰면서 완료 시각과 성공 상태를 같이 찍는다. 성공인데 근거가 비는 상태가 정상 경로로 만들어지고 있었다.

대조군도 있었다. 어떤 채널은 문자열을 명시해서 넘기고 거기에는 이 현상이 없다. 즉 전송 실패가 아니라 관찰성 결함이었고 실패로 단정하고 재전송을 돌렸으면 멀쩡한 17,000건을 다시 밀 뻔했다.

하나 더 나왔다. 새로 넣는 지표의 단계 값이 특정 문자열인데 소비하는 쪽 두 곳을 열어 보니 한쪽은 다른 값만 통과시키는 필터가 있고 다른 쪽은 다른 접두어로 시작하는 키만 읽고 있었다.

결국 아무도 읽지 않는 지표를 넣고 있었던 것이고 이것도 침묵과 같은 종류의 문제다. 계측이 존재한다는 사실이 감시된다는 뜻이 아니다.

그래서 계측을 새로 넣거나 남의 것을 리뷰할 때 세 가지를 본다. 0건일 때 무엇이 나가는지와 와야 할 목록이 어디에 적혀 있는지와 읽는 쪽이 이 값을 실제로 통과시키는지다.

셋 다 데이터가 아니라 코드에서 확인해야 한다. 지표 대시보드에 값이 보이는 것은 지금 데이터가 있다는 뜻일 뿐이고 데이터가 없을 때 어떻게 되는지는 거기서 안 보인다.