0은 장애가 아니다

수집 감시 알람을 만들고 있었다. 임계를 이렇게 잡으려 했다.

수집 건수 == 0   →  장애

Open Table of contents

상황 — 임계를 잡기 전

당연해 보였지만 임계를 잡기 전에 먼저 확인할 것이 있었다.

수집 건수 라는 이름만 보면 그 구간에 수집한 전체처럼 읽힌다. 임계를 먼저 잡고 나면 그 뒤에는 값이 왜 그런지를 잘 안 따지게 되고 알람이 울리는 것만 보고 임계를 조정하게 된다.

수집 저장소 계층을 봤다.

foreach ($orders as $order) {
    if (DistributionOrder::where([...])->exists()) {
        continue;   // 이미 있으면 건너뜀
    }
    // 저장
    $count++;
}

exists 면 continue 하므로 이미 저장된 것은 세지 않는다.

[예상]  마켓에서 조회된 전체
[실제]  이번에 새로 저장된 신규분

$count 는 DistributionOrder 에 새로 들어간 것만 세는 값이었다.

한 채널만 그런지 확인했다.

grep -rln "retrieveOrders" app/Models/Repositories/Order/Api/

retrieveOrders 를 가진 저장소가 22개였고 중복 체크가 있는 것이 21개였다.

중복 체크의 구현 방식은 두 갈래였다.

protected function isExists($order) { ... }

if (DistributionOrder::where([...])->exists()) continue;

isExists 헬퍼를 둔 쪽과 인라인으로 검사하는 쪽이 섞여 있었다.

같은 일을 다르게 쓰고 있으니 한 패턴으로 grep 하면 절반쯤만 나온다. 그래서 찾은 자리들이 서로 어떻게 다른지를 보고 다른 형태를 유추해 다시 찾았다.

앞선 대화에서 24개 중 21개로 언급된 것이 있었다.

[언급된 값]  24개
[실제]       22개 (팩토리·인터페이스 제외)

직접 세니 22개라 그 24 라는 분모가 부정확했다.

21/24 와 21/22 는 서로 다른 이야기가 된다. 앞의 것은 셋이 없다는 말이고 뒤의 것은 하나가 없다는 말이라 대화에 나온 수치도 근거로 쓰기 전에 다시 세야 했다.

이제 수집 건수 == 0 임계로 돌아갔다.

건수 = 신규 저장분
    ↓
신규 주문이 없으면 0
    ↓
한산한 새벽·주말에 0이 정상

지난 자료를 전수로 보니 $count 가 0인 구간이 여럿이었고 그때 수집은 정상이었다.

그 값으로 알람을 잡았으면 매일 몇 번씩 잘못 울렸을 것이다. 건수 == 0 을 장애로 잡으면 오탐이 그대로 난다.

성공 판정을 건수 가 아닌 다른 축으로 옮겼다.

[건수]        결과가 얼마인가 — 트래픽에 따라 변함
[성공 이벤트]  호출이 성공했나 — 트래픽과 무관

호출 성공 이벤트가 안 오면 장애이고 성공했는데 건수가 0이면 정상이다.

건수의 뜻이 정해지니 다른 것도 걸렸는데 채널 간 건수 비교와 백테스트가 전부 신규분 기준이었다. A 채널의 주문이 더 많다가 아니라 신규 저장분이 더 많다는 뜻이고 이미 저장된 것이 많은 채널은 신규분이 적게 나온다.

중복 체크가 없는 하나도 기록했다.

Cafe24 저장소만 중복 체크 없음
별도 수집 미들웨어가 존재하나, 부재와의 인과는 미확인

Cafe24 는 미들웨어가 있어서 필요 없다고 쓰지는 않았다.

두 가지 다 사실이지만 그 사이의 인과는 확인하지 않았기 때문이다. 두 사실이 나란히 있다는 것이 하나가 다른 하나의 원인이라는 뜻은 아니다.