한도가 존재하는 이유

공유 시스템에는 모두 한도가 있습니다. 여러분을 귀찮게 하려는 것이 아니라, 폭주하는 스크립트 하나가 모두의 서비스를 멈추지 못하게 하려는 것입니다.

속도 제한: 얼마나 빨리

속도 제한은 시간 창당 요청 수를 제한합니다. 예를 들어 분당 300회. 넘으면 서버는 얼마나 기다릴지 알려주는 Retry-After 헤더와 함께 429 Too Many Requests로 답합니다. 잘 만든 클라이언트는 응답 헤더에서 남은 예산을 읽고 0이 되기 전에 속도를 늦춥니다.

예산은 보통 작업 종류별로 나뉘어, 요청이 잦은 기능이 중요한 기능을 굶기지 못합니다. 읽기는 싸고 재시도해도 안전하지만 쓰기는 그렇지 않아서 종종 더 엄격한 별도 예산을 받습니다.

할당량: 얼마나 많이

할당량은 총량을 제한합니다. 사용한 스토리지, 사용자 수, 월 이메일 수, 예약 작업 수. 할당량은 플랜을 따릅니다. 가까워지면 경고를 받고, 넘으면 자원에 따라 동작이 거부되거나 초과분이 청구됩니다.

무엇을 지키는가

1. 가용성: 한 테넌트의 폭주는 그 테넌트의 문제로 남습니다.
2. 비용: 스토리지와 이메일에는 실제 단가가 있습니다.
3. 보안: 로그인 속도 제한은 백만 번의 비밀번호 추측을 몇백 번으로 줄입니다.

한도 오류 읽기

429는 앱의 버그가 아닙니다. 어느 예산이 떨어졌는지 보고, 안내된 시간만큼 기다리고, 계속 반복되면 요청 빈도를 줄이거나(묶기, 캐시, 폴링 간격 늘리기) 할당량이 더 높은 플랜으로 옮기세요.

DontCode에서는

사용량 페이지는 플랜 한도가 있는 모든 항목(앱 사용자, 팀 좌석, 스토리지, 이메일, 크론 작업과 실행)을 한도와 비교해 보여주고 80%와 95%에서 경고하며, 최근 7일간 제한된 요청도 표시합니다. 공개 API는 모든 응답에 RateLimit 헤더를 싣고, 분당 예산이 소진되면 Retry-After와 함께 429를 돌려줍니다. 두 종류의 한도 모두 플랜별로 정해집니다. 할당량은 플랜에 따라 올라가고 분당 예산도 플랜별로 조정될 수 있으므로, 얼마나 빨리 호출할 수 있는지는 플랜 이름이 아니라 응답의 RateLimit 헤더가 기준입니다.