세 가지 API를 위한 세 가지 Sleep Interval
지난 4월, 세 개의 디렉토리 사이트를 위한 ETL 파이프라인을 구축했습니다. 각 사이트는 Steam, GitHub, HuggingFace라는 서로 다른 API를 사용합니다.
각 API마다 Sleep Interval을 설정해야 했습니다. 수치, 실패 모드, 에러 처리 방식이 모두 다릅니다. 제가 어떤 방식을 사용하는지와 그 이유를 소개합니다.
Steam: 250ms sleep
Steam 문서는 Rate Limit(요청 제한)에 대해 모호하게 설명되어 있습니다. 커뮤니티 데이터에 따르면 IP당 5분마다 약 200번의 요청이 가능하다고 합니다. 즉, 1.5초 간격이면 안전하다는 뜻입니다.
하지만 저는 대신 250ms를 사용합니다. 제 야간 작업은 단 60개의 게임 항목만 처리합니다. 250ms를 적용하면 총 대기 시간은 15초입니다. 1.5초를 적용하면 90초가 됩니다. 여러 사이트를 처리할 때는 시간을 절약하는 것이 중요합니다.
Steam에서 에러가 반환되더라도 작업은 중단되지 않습니다. 에러를 로그에 기록하고 다음 항목으로 넘어갑니다. 데이터는 다음 날 밤에 업데이트됩니다.
GitHub: 100ms sleep
GitHub은 매우 명확합니다. 인증되지 않은 사용자는 시간당 60번의 요청을 받을 수 있고, 토큰을 가진 사용자는 시간당 5,000번의 요청을 받을 수 있습니다.
저는 매너 차원에서 100ms의 sleep을 사용합니다. Rate Limit에 대한 실질적인 역할은 토큰이 수행합니다. 제 파이프라인은 Search API가 아닌 핵심 REST API를 사용하므로 훨씬 더 높은 제한 범위를 가집니다.
HuggingFace: No sleep
몇 주 동안 야간 작업을 실행했지만 Rate Limit에 걸린 적이 없습니다. Registry API는 저와 같은 배치 도구(batch tools)를 위해 설계되었습니다.
한 번에 최대 100개의 모델을 가져옵니다. 인증 토큰을 사용하여 제한을 더욱 높였습니다. 100개의 모델을 처리할 때는 sleep을 두지 않는 것이 가장 간단한 해결책입니다.
요약 표:
• Steam: 250ms sleep. 비치명적 에러. • GitHub: 100ms sleep. 비치명적 에러. • HuggingFace: No sleep. 비치명적 에러.
Sleep Interval은 추측에 기반합니다. 진짜 보호책은 에러를 처리하는 방식에 있습니다. 모든 API 호출에는 try/catch 블록을 사용합니다. 호출이 실패하면 시스템은 충돌(crash)하는 대신 대체 행(fallback row)을 작성합니다.
Sleep Interval은 제한에 얼마나 자주 걸리는지를 제어하고, 에러 처리는 제한에 걸렸을 때 어떤 일이 일어날지를 제어합니다.
선택 사항 학습 커뮤니티: https://t.me/GyaanSetuAi