API 레이트리밋: 공유 한도·토큰버킷·안전한 재시도 판단

English version

TECH INSIGHT / EXPLAINED

레이트리미터는 언제 요청할지 정하고, 재시도 정책은 같은 작업을 반복해도 안전한지 정합니다. 둘을 섞으면 잠깐의 타임아웃이 중복 주문으로 바뀔 수 있습니다.

세 사람이 토큰버킷·대기 타이머·우선순위 큐로 API 요청을 조절합니다.
AI로 제작한 설명용 일러스트. 세 사람이 토큰버킷·대기 타이머·우선순위 큐로 API 요청을 조절합니다.

서버가 실제로 세는 한도에 맞추기

한도가 IP·계좌·API 키·엔드포인트 그룹·요청 가중치 중 무엇에 묶이는지 확인합니다. 프로세스 내부 버킷만으로는 같은 한도를 공유하는 다른 봇과 조율되지 않습니다. 보고서 조회가 한도를 모두 쓰지 않도록 취소·주문 대조에 사용할 스케줄러 여유를 둡니다.

보충률 r, 용량 B인 토큰버킷은 평균 속도와 순간 몰림을 함께 허용합니다. 모든 1초 구간에서 N회 이하라는 의미는 아닙니다. 서버 규칙에 맞는 모델과 버스트를 골라야 하며 로컬 버킷을 추가해도 서버 한도가 늘지는 않습니다.

Go 구현과 취소 처리

golang.org/x/time/rate에는 Allow·Reserve·Wait가 있고, 설정된 burst 범위 내 가중 요청은 WaitN으로 처리할 수 있습니다. context 마감 시간을 전달하세요. 한도 대기 시간도 요청 전체 예산에 포함하고 재시도에는 중단 가능한 타이머를 사용합니다. 종료 요청 후에도 무조건 sleep하지 않도록 합니다.

안전한 조회 요청은 지터를 포함한 제한된 지수 백오프를 사용할 수 있습니다. 최대 시도와 전체 마감 시간을 정하고, 마지막 실패 뒤에는 더 기다리지 말고 마지막 유의미한 오류를 반환합니다.

Retry-After는 두 형식

HTTP Retry-After는 초 단위 숫자 또는 HTTP 날짜일 수 있습니다. 둘 다 해석해야 합니다. 이는 가장 빨리 재시도할 수 있는 시각으로 취급합니다. 작업 마감보다 길면 보류·실패 결과를 반환하고, 서버 대기를 짧게 잘라 일찍 다시 요청하지 않습니다.

from datetime import datetime, timezone
from email.utils import parsedate_to_datetime
def retry_after_seconds(value, now):
    if not value:
        return None
    value = value.strip()
    if value.isascii() and value.isdigit():
        return float(int(value))
    try:
        target = parsedate_to_datetime(value)
        if target.tzinfo is None:
            return None
        return max(0.0, (target-now).total_seconds())
    except (TypeError, ValueError, OverflowError):
        return None
now = datetime(2026, 9, 29, 0, 0, tzinfo=timezone.utc)
assert retry_after_seconds('5', now) == 5
assert retry_after_seconds('Tue, 29 Sep 2026 00:00:10 GMT', now) == 10

주문 타임아웃은 재주문 지시가 아니다

읽기 타임아웃이나 일부 5xx 응답은 주문 접수 후에도 발생할 수 있습니다. 주문 생성은 거래소가 문서화한 client ID·멱등성 규칙을 확인하고 결과를 대조한 뒤 반복 여부를 결정합니다. 어떤 ID는 조회만 도와주고 멱등성을 보장하지 않습니다. 잘못된 파라미터는 더 시도할 것이 아니라 고쳐야 합니다.

제한에 걸린 횟수, 제공되는 잔여 한도, 큐 대기 시간과 대조 지연을 관찰합니다. 자체 속도 제한은 피할 수 있는 위반을 줄이지만 공유 한도 소진을 완전히 막는다는 보장은 아닙니다.

공식 자료와 함께 읽기

Go rate limiter · HTTP Retry-After · Requests 오류 처리

내용·예제 검토: 2026-09-29

댓글