대체 동작이 기본 로그 수준에 안 보였다

배송비를 택배사 Open API로 계산하는 부분이 있었다. Guzzle 호출이 실패하면 기본 요율로 대체하게 돼 있었다.

Open Table of contents

증상 — 문의는 오고 로그는 없다

배송비가 이상하다는 문의가 가끔 들어왔는데, 그 시각 로그를 봐도 오류가 하나도 없었다.

대체 동작은 Monolog debug 수준으로 남고 있었는데, 운영 LOG_LEVEL이 warning이라 아무것도 안 남았다. 실패가 나도 아무 흔적이 없었다.

LOG_LEVEL을 하루만 info로 낮춰 받아 보니 대체로 넘어간 요청이 하루 340건이었다.

전체 요청의 4%였는데, 예상은 0에 가까웠지만 실제로는 매일 수백 건이 기본 요율로 나가고 있었다.

대체 동작 자체가 문제는 아니었고, 문제는 그것이 실패를 성공처럼 보이게 만든다는 데 있었다.

응답은 HTTP 200이고 값도 정상으로 돌아오니 CloudWatch 어느 지표에도 안 잡혔다. 실패율 그래프는 계속 0이었다.

방법이 셋이었다. 대체 동작의 로그 수준을 올리거나, 별도 지표로 세거나, 대체를 아예 없애는 것이다.

Monolog 수준을 올리는 쪽은 간단한 대신 로그 양이 늘고 다른 warning 사이에 묻힌다.

CloudWatch 커스텀 지표로 세는 쪽은 그래프에 그대로 드러나는 대신, 지표를 하나 더 두고 대시보드를 손봐야 한다.

대체를 없애는 쪽은 실패가 실패로 보이는 대신, 외부 API가 잠깐 흔들릴 때마다 주문이 막힌다.

지표로 세는 쪽을 골랐다. 로그는 사람이 봐야 알지만 지표는 임계를 걸어 둘 수 있다.

CloudWatch 알람을 대체 발생률 1%에 걸어 두고 그 아래는 정상 범위로 두었다.

대체 동작을 없애는 것은 하지 않기로 했다. 외부 API가 하루에도 몇 번 흔들리는데 그때마다 주문이 막히면 대체가 있는 편이 낫다. 다만 그것이 몇 번인지는 이제 보인다.

이 일을 계기로 Monolog 수준별 기준을 정했다. error는 지금 봐야 하는 것, warning은 쌓이면 봐야 하는 것, info는 사후 추적용이다.

대체 동작은 warning으로 올렸는데, 한 건은 정상이지만 쌓이면 문제가 되기 때문이다.