상한치는 수요가 아니다

여러 외부 연동을 순서대로 옮기는 작업에서 어느 것부터 할지를 정해야 했다. 트래픽이 많은 것부터가 합리적으로 보여서 그런 데이터를 찾았다.

Open Table of contents

유일하게 있던 숫자

대상별 속도 제한 설정이 있었고 초당 몇 건까지 보내는지가 적혀 있었다. 값의 차이가 커서 순위를 매기기에 좋아 보였다.

이 축으로 쓸 수 있는 숫자가 그것뿐이었다. 그래서 그대로 쓰려다 그 값이 어떻게 정해졌는지를 먼저 찾아봤다.

문서에는 각 대상의 서버가 견딜 수 있는 최대치를 측정하고 그 일부를 운영 상한으로 잡는다고 적혀 있었다. 우리가 보내는 양이 아니라 상대가 받을 수 있는 양이었다.

상한이 높은 것은 그쪽 서버가 튼튼하다는 뜻이지 우리가 많이 보낸다는 뜻이 아니다. 상한이 큰 대상이 실제로는 거의 안 쓰이고 상한이 작은 대상이 그 한계까지 꽉 차 있을 수 있다.

그러면 실제 호출량은 어디 있는지 찾았는데 집계된 것이 없었다. 로그는 있지만 이 축으로 모니터링 지표가 잡혀 있지 않았다.

즉 어느 것이 트래픽이 많냐는 질문에 답할 데이터 자체가 없다. 없다는 것을 확인한 것도 결과이고 있는 줄 알고 계속 찾는 것이 낭비였다.

여기서 판단이 갈렸는데 완벽하지 않지만 있는 숫자를 쓸 것인지 실제 데이터를 먼저 만들 것인지였다. 이것은 기술 판단이 아니라 우선순위 근거의 신뢰도를 어디까지 요구하느냐의 문제였다.

그래서 이 값이 우리 수요가 아니라 상대의 수용 한계라는 점과 실제 호출량 데이터가 없다는 점을 적고 두 선택지를 나란히 물었다. 내가 고르면 그 선택의 근거가 기록에 안 남고 나중에 순위만 인용된다.

대리 지표로는 못 써도 상한선 정보로는 유효했다. 이 값을 넘는 트래픽은 없다는 것이 확실하므로 용량 산정의 상한으로 쓸 수 있다.

같은 숫자가 어떤 질문에는 답이 되고 어떤 질문에는 안 되며 무엇을 재는 값인지가 그것을 가른다. 우선순위를 정한 뒤에는 그 근거가 실제 사용량 순위와 다를 수 있다는 한계를 함께 적었다.