재시작해도 안 도는 저쪽 카운터

외부 API에서 한도 초과 응답이 쏟아졌는데 키를 여러 개 두고 돌려 쓰는 구조였다. 우리 쪽 잔여량 표시에는 아직 여유가 남아 있어서 두 가지가 안 맞았다.

Open Table of contents

증상 — 잔여량이 남은 한도 초과

잔여량이 남았는데 저쪽이 초과라고 한다면 둘 중 하나의 숫자가 틀린 것이다. 저쪽 숫자가 틀렸다고 보기는 어려우므로 우리 숫자가 무엇을 세고 있는지를 봐야 했다.

처음에는 나가는 IP 문제인가 싶어서 그쪽을 들여다봤는데 확실한 근거를 못 찾았다. 그래서 추정을 접고 로그를 시각순으로 늘어놓고 보기로 했다.

시각순으로 보니 초과가 시작된 지점 근처에 Docker 컨테이너가 다시 뜬 시각이 있었다. 그 전에는 정상이었고 그 뒤부터 초과가 나오기 시작했다.

우리 쪽 카운터는 프로세스 안에 있어서 다시 뜨면 0에서 시작한다. 저쪽 카운터는 그것과 무관하게 시간 창 기준으로 계속 이어지고 있었다.

그러면 우리 표시는 다시 뜬 뒤로 얼마나 썼는지만 말하고 그 시간 창에서 얼마나 썼는지는 말하지 않는다. 두 숫자가 어긋나는 것이 아니라 애초에 다른 것을 세고 있었다.

그래서 그 표시를 한도에 닿았는지 판단하는 근거로는 쓰지 않기로 했다. 참고로는 보되 실제 판단은 저쪽 API 응답에 맡기는 쪽이 맞았다.

처음에 나가는 IP 문제로 추정했을 때 그대로 조치했으면 아무것도 안 바뀌었을 것이다. 원인이 다른 데 있으니 그 조치는 효과가 없고 시간만 쓰게 된다.

추정을 로그로 확인하고 나서 조치로 넘어가는 순서를 지킨 것이 이 건에서 시간을 줄인 부분이었다. 확인하는 데 든 시간이 잘못 조치하고 되돌리는 시간보다 짧았다.

초과가 나는 동안에도 실제 처리는 전부 성공했는데 폴백이 걸려 있었기 때문이다. 한 곳에서 실패하면 다음으로 넘어가는 단계가 여러 개 있었다.

다만 같은 공급자 안에서만 넘어가는 폴백은 한도 초과 앞에서 무력하다는 것도 함께 확인됐다. 마지막 단은 다른 공급자여야 이런 종류의 실패를 받아 낼 수 있었다.