처리율 제한 장치는 요구사항이 짧아 보여서 바로 알고리즘 이야기로 넘어가기 쉽습니다. 그런데 무엇을 기준으로 세는지와 얼마나 정확해야 하는지를 정하지 않으면 어떤 알고리즘도 고를 수 없습니다.
| 항목 | 값 |
|---|---|
| 대상 | 공개 API 게이트웨이 |
| 피크 트래픽 | 초당 5만 요청 |
| 게이트웨이 | 20대 |
| 한도 | API 키마다 분당 1,000회 |
| 판정에 쓸 수 있는 시간 | 1ms 이내 |
| 허용 오차 | 한도의 5퍼센트 까지 |
기능 요구사항과 범위 밖
| 구분 | 내용 |
|---|---|
| 이번에 만든다 | 한도 판정, 초과 응답, 남은 횟수 알려주기, 키마다 다른 한도, 무거운 호출을 더 크게 세기 |
| 범위 밖 | 과금, 봇 탐지, 대규모 공격 방어, 인증 자체 |
범위 밖을 말하는 것이 중요합니다. 대규모 공격 방어를 여기서 하려 하면 판정 하나에 붙는 비용이 커지고, 정작 정상 사용자의 한도 판정이 느려집니다. 공격 방어는 더 앞단에서 값싸게 자르는 별개의 일입니다.
어디서 세고 어디서 자르나
세는 자리가 여러 곳이면 한도가 그만큼 늘어납니다. 서비스 3개가 각자 분당 1,000회 를 센다면 사용자는 실제로 분당 3,000회를 쓸 수 있습니다.
숫자가 정하는 것
| 숫자 | 강제하는 것 |
|---|---|
| 피크 초당 5만 | 판정이 요청마다 일어난다. 중앙 저장소 왕복이 곧 비용이다 |
| 게이트웨이 20대 | 인스턴스별로 세면 실제 한도가 20배가 된다 |
| 한도 분당 1,000회 | 창을 어떻게 자르느냐에 따라 경계에서 두 배가 지나간다 |
| 판정 1ms | 요청마다 기록을 남기는 방식은 예산을 넘긴다 |
| 오차 5퍼센트 | 완벽한 합계를 포기해도 된다 |
무엇을 기준으로 세는가
한도의 기준은 셋 중 하나입니다. 이 선택이 나머지 설계보다 먼저입니다.
| 기준 | 문제 |
|---|---|
| API 키 | 이 요구사항에 맞다. 발급 단위가 곧 책임 단위다 |
| 사용자 | 로그인 전 요청을 셀 수 없다 |
| 접속 주소 | 회사나 통신사 뒤의 수천 명이 한 덩어리로 묶인다 |
접속 주소 기준은 정상 사용자를 무더기로 자릅니다. 다만 키가 없는 요청에는 다른 방법이 없으므로, 인증 전 구간에만 넉넉한 한도로 함께 두는 경우가 많습니다.
정확도를 요구사항으로 적는다
"정확하게" 라고 쓰면 게이트웨이 20대가 매 요청마다 합계를 맞춰야 합니다. 그러면 판정이 저장소 속도에 묶입니다.
오차 5퍼센트 를 허용한다고 적어 두면 근사 계산과 지역 캐시를 쓸 수 있습니다. 분당 1,000회 한도에서 1,050회가 지나가는 것은 아무 문제가 아닙니다. 반대로 2,000회가 지나가는 것은 문제입니다. 허용 오차는 어떤 알고리즘이 탈락하는지를 정하는 기준이 됩니다.