크기가 아니라 개수에 비례한 비용

외부 서비스에 내는 요금이 한 달 사이에 여섯 배가 됐는데 자료가 그만큼 늘어난 것은 아니어서 무엇이 요금을 정하는지부터 확인해야 했다.

Table of contents

증상 — 여섯 배가 된 요금

요금은 한 달에 $5 이던 것이 $30 이 돼 있었다. 그 서비스의 집계 화면이 우리 쪽에서는 저장소 미연결로 열리지 않아 사용량을 직접 볼 수 없었고, 대신 우리 쪽 요청 로그에 응답의 사용량 정보가 찍혀 있어서 그것을 grep 하고 wc -l 로 셌다.

하루치를 세어 보니 이렇게 나왔다.

처리한 단위    10개
호출 A         43회
호출 B         13회
호출 C         65회
호출 D        133회
────────────────────
합계          254회

10개를 처리하는 데 254회다. 다만 그것이 요금과 어떻게 이어지는지는 아직 확정되지 않았다.

단위당 고정된 호출 수

처리 하나가 나갈 때 API 호출이 몇 번 일어나는지를 grep 으로 확인했더니 그 수가 고정이었다.

추출 1단계    1~2회
추출 2단계    1~2회
중복 제거 1   다수
중복 제거 2   다수
────────────────────
합계       약 12회

자료가 크든 작든 관계없이 언제나 약 12회가 나가고 있었다.

그러면 비용 공식이 이렇게 선다.

비용 ∝ 단위 수 × 12

크기가 아니라 개수다. 큰 자료 하나와 작은 자료 하나가 같은 비용을 내는 구조였다.

비례 관계를 먼저 확정한다

이 관계를 확정하기 전에는 자료를 작게 만드는 방향으로 조치를 생각하고 있었다. 그런데 개수에 비례하는 것이라면 그 조치로는 아무 효과가 없다.

개수에 비례하므로 여러 건을 묶어서 한 단위로 보내는 것이 해법이 된다. 묶음 크기별로 산출해 보니 이렇게 갈렸다.

1개씩      $30/월
5개 묶음   $1~5/월
10개 묶음  무료 한도 안

비례 관계가 무엇인지에 따라 조치가 정반대로 갈리므로 그것을 먼저 확정해야 했다.

무료 한도와 단위 수

무료 한도가 API 호출 수로 정해져 있어서 그것을 단위당 호출 수로 나눠 봤다.

하루 40회 ÷ 단위당 12회 ≈ 3개

하루 세 단위면 한도가 차고 그 뒤로는 유료로 넘어간다.

요금이 뛴 시점을 보니 저장 단위를 잘게 쪼개도록 고친 시점과 맞았다.

[전]  묶어서 저장 → 단위 수 적음 → 대부분 무료 한도 안
[후]  잘게 저장   → 단위 수 많음 → 대부분 유료

여섯 배가 그것으로 설명됐다.

재시도가 태운 몫

여기에 하나가 더 있었는데 실패한 호출을 다시 보내는 처리가 상한 초과에도 재시도를 하고 있었다. 로그에 실패한 단위 하나가 여섯 번 재시도되고 결국 실패한 기록이 있었고 그 한 건이 하루 한도만큼을 태웠다. 상한을 넘어서 실패한 것은 다시 보내 봐야 같은 응답이 돌아온다.

그러니 그 재시도가 남은 한도를 더 빨리 태우고 있었던 것이다. 재시도 대상인지 아닌지를 API 응답 종류로 갈라야 했고 그 자리를 고치는 것이 묶는 것과 함께 조치가 됐다.

정리

• 처리 단위당 호출 수가 고정이면 비용은 개수에 비례한다
• 집계 화면이 없으면 우리 로그에서 사용량을 뽑는다
• 비례 관계를 먼저 확정한다
• 관계에 따라 조치가 정반대로 갈린다
• 개수에 비례하면 묶어서 단위 수를 줄인다
• 무료 한도를 단위당 호출 수로 나누면 몇 건까지 무료인지 나온다
• 상한 초과는 재시도로 안 풀린다
• 재시도 대상인지를 응답 종류로 가른다