알고리즘과 응답까지 정했습니다. 마지막으로 분당 1,000회 이라는 숫자를 어디서 얻는지입니다. 이 부분이 실무와 면접에서 가장 자주 빠집니다.
재기 전에 정하지 않는다
한도를 감으로 정하면 두 가지 중 하나가 됩니다. 너무 높아 아무것도 막지 못하거나, 너무 낮아 정상 사용자를 자릅니다. 그래서 순서가 있습니다.
| 단계 | 하는 일 |
|---|---|
| 1 | 판정 논리를 켜되 자르지 않는다. 넘었을 값만 기록한다 |
| 2 | 키별 사용량 분포를 본다. 상위 1퍼센트가 누구인지 확인한다 |
| 3 | 한도를 정하고, 넘는 키에 먼저 알린 뒤 자르기 시작한다 |
가장 위험한 배포는 한도를 처음 켜는 배포입니다. 그때까지 아무 제약 없이 쓰던 사용자가 갑자기 막히고, 그것이 우리 잘못으로 보이지 않기 때문에 원인 파악도 늦습니다.
한도를 두 겹으로 둔다
키마다의 한도는 공평함을 위한 것입니다. 그런데 키가 아주 많아지면 각자 한도를 지켜도 전체가 넘칠 수 있습니다.
| 겹 | 기준 | 목적 |
|---|---|---|
| 키마다 | API 키 | 한 사용자가 남을 방해하지 않게 |
| 전체 | 서비스 또는 게이트웨이 | 우리 용량을 넘지 않게 |
두 번째 겹이 발동하면 정상 사용자도 거절됩니다. 그래서 이때는 응답을 다르게 줍니다. 사용자 잘못이 아니므로 서버가 버겁다는 쪽으로 알립니다.
한도는 하나의 숫자가 아니다
같은 API 라도 비용이 다릅니다. 목록 조회와 대량 내보내기가 같은 한 번일 수 없습니다.
비싼 호출은 여러 번으로 센다
읽기와 쓰기에 다른 한도를 둔다
등급마다 다른 한도를 둔다
비용이 다른 것을 같게 세면 사용자가 비싼 쪽으로 몰립니다. 한 번의 값이 같으니 당연한 반응입니다.
바꿀 때가 만들 때보다 어렵다
한도를 낮추는 변경은 정상 사용자의 코드를 깨뜨립니다. 그래서 낮출 때는 만들 때와 같은 순서를 다시 밟습니다. 먼저 재고, 넘는 키를 찾아 개별로 알리고, 기간을 준 뒤 적용합니다.
올리는 것은 쉬워 보이지만 되돌리기 어렵습니다. 사용자가 그 여유에 맞춰 코드를 만들면 다시 낮추는 것이 앞의 어려운 변경이 됩니다.
무엇을 보고 한도가 맞는지 판단하나
| 지표 | 의미 |
|---|---|
| 거절 비율 | 갑자기 오르면 한도가 낮거나 남용이 시작됐다 |
| 거절된 키 수 | 소수면 남용, 다수면 한도가 낮다 |
| 한도 근처에서 머무는 키 | 곧 막힐 사용자. 미리 알릴 대상 |
거절 비율만 보면 두 상황을 구분할 수 없습니다. 한 키가 많이 막히는 것과 많은 키가 조금씩 막히는 것은 전혀 다른 문제이고, 대응도 반대입니다.