브랜드를 바꾸면서 외부 연동을 새 도메인과 새 발신 이름으로 하나씩 옮겨야 했다. 어느 것부터 할지를 정해야 했는데 트래픽이 많은 것부터가 합리적으로 보여서 그런 데이터를 찾았다.
Table of contents
Open Table of contents
배경 — 옮길 연동이 여럿이고 순서가 필요했다
외부 시세 조회와 SMS 발송과 지갑 서비스 콜백과 은행 조회가 각각 Camel 라우트 하나로 나가 있다. 라우트 id 는 price-feed 와 sms-send 와 wallet-callback 과 bank-inquiry 다. 상대마다 우리 쪽 도메인이나 발신 정보를 등록해 둬서 옮기는 절차가 다 다르다.
한 번에 다 옮기면 어디서 깨졌는지 못 가른다. 그래서 하나씩 옮기되 영향이 큰 것부터 하려고 했다.
해 본 것 — 라우트의 throttle 값으로 순위 매기기
RouteBuilder 마다 throttle 이 걸려 있고 초당 몇 건까지 보내는지가 적혀 있었다. price-feed 는 큰 값이고 sms-send 는 작은 값이라 차이가 커서 순위를 매기기에 좋아 보였다.
이 축으로 쓸 수 있는 숫자가 그것뿐이었다. 그래서 그대로 쓰려다 그 값이 어떻게 정해졌는지를 먼저 찾아봤다.
막힌 지점 — 그 값은 상대가 받는 양이다
throttle 은 지정한 timePeriodMillis 안에 다음 노드로 넘기는 메시지 수를 제한한다. Camel 공식 문서는 이 패턴의 목적을 특정 엔드포인트가 과부하되지 않게 하거나 외부 서비스와 합의한 SLA 를 넘지 않게 하는 것으로 적는다.
우리 application.yml 의 주석에도 상대가 알려 준 한도의 일부를 잡았다고 돼 있었다. 우리가 보내는 양이 아니라 상대가 받을 수 있는 양이었다.
상한이 높은 것은 그쪽 서버가 튼튼하다는 뜻이지 우리가 많이 보낸다는 뜻이 아니다. 상한이 큰 대상이 실제로는 거의 안 쓰이고 상한이 작은 대상이 그 한계까지 꽉 차 있을 수 있다.
검증 — 실제 호출량 데이터가 없다는 확인
그러면 실제 호출량은 어디 있는지 찾았는데 집계된 것이 없었다. access.log 에 나가는 호출이 남기는 하지만 라우트별 지표로 잡혀 있지는 않았다.
grep -c 와 awk 로 하루치를 세어 볼 수는 있었다. 그런데 하루치 한 번은 표본이지 순위의 근거가 아니다.
즉 어느 것이 트래픽이 많냐는 질문에 답할 데이터 자체가 없다. 없다는 것을 확인한 것도 결과이고 있는 줄 알고 계속 찾는 것이 낭비였다.
조치 — 근거의 신뢰도는 결정권자에게
여기서 판단이 갈렸다. 완벽하지 않지만 있는 숫자를 쓸 것인지 실제 데이터를 먼저 만들 것인지였다. 이것은 기술 판단이 아니라 우선순위 근거의 신뢰도를 어디까지 요구하느냐의 문제였다.
나는 고르지 않고 묻는 쪽을 골랐다. 이유는 내가 고르면 그 선택의 근거가 기록에 안 남고 나중에 순위만 인용돼서다. 대신 결정이 하루 늦어지는 것을 감수했다.
그래서 이 값이 우리 수요가 아니라 상대의 수용 한계라는 점과 실제 호출량 데이터가 없다는 점을 적어 두 길을 나란히 물었다. 답은 있는 숫자로 가되 한계를 적어 두라는 것이었다.
대리 지표로는 못 써도 상한선 정보로는 유효했다. 이 값을 넘는 트래픽은 없다는 것이 확실하므로 옮긴 뒤 새 도메인 쪽 용량 산정의 상한으로는 쓸 수 있다.
같은 숫자가 어떤 질문에는 답이 되고 어떤 질문에는 안 된다. 무엇을 재는 값인지가 그것을 가른다. 순서를 정한 뒤에는 그 근거가 실제 사용량 순위와 다를 수 있다는 한계를 함께 적었다.
정리
- 대리 지표를 쓸 때 그 값이 무엇을 재는지 먼저 확인한다
throttle은 우리 수요가 아니라 상대의 수용 한계다- 상한이 높은 것은 상대가 튼튼하다는 뜻이다
- 정확한 데이터가 없으면 없다는 사실 자체를 확인한다
- 근거의 신뢰도를 어디까지 요구할지는 결정권자에게 묻는다
- 내가 고르면 그 선택의 근거가 기록에 남지 않는다
- 같은 숫자가 어떤 질문에는 답이 되고 어떤 질문에는 안 된다
- 근거를 쓸 때 한계를 함께 적어야 오해가 전파되지 않는다