이 버전의 GitHub Enterprise Server는 다음 날짜에 중단됩니다. 2026-04-09. 중요한 보안 문제에 대해서도 패치 릴리스가 이루어지지 않습니다. 더 뛰어난 성능, 향상된 보안, 새로운 기능을 위해 최신 버전의 GitHub Enterprise Server로 업그레이드합니다. 업그레이드에 대한 도움말은 GitHub Enterprise 지원에 문의하세요.

API 속도 제한을 구성하기 위한 모범 사례

데이터 기반의 API 속도 제한 접근 방식은 중요한 통합을 방해하지 않으면서 GitHub Enterprise Server 인스턴스를 과도한 사용으로부터 보호합니다.

누가 이 기능을 사용할 수 있나요?

Site administrators can configure rate limits for a GitHub Enterprise Server instance.

이 기사에서

속도 제한에 대한 데이터 기반 접근 방식 정보

속도 제한이 없으면 시간당 수만 개의 요청을 만드는 단일 CI 통합으로 모든 사용자의 전체 인스턴스 속도가 느려질 수 있습니다. 그러나 제한을 너무 공격적으로 설정하면 팀이 사용하는 통합을 깨뜨릴 수 있습니다. 데이터 기반 접근 방식을 사용하면 적절한 균형을 찾을 수 있습니다. 즉, 실제 사용 패턴을 관찰한 다음 수집한 데이터에 따라 점진적으로 제한을 적용합니다.

이 방법은 다음 단계를 따릅니다.

  1.        **관찰**: 로그 전달을 사용하도록 설정하고 API 트래픽 패턴을 분석합니다.

  2.        **기준:** 초기 값이 높은 속도 제한을 사용하도록 설정하여 속도 제한 데이터 수집을 시작합니다.

  3.        **구체화**: 관찰된 사용량에 따라 제한을 조정하고 영향을 받는 팀과 통신합니다.

  4.        **유지 관리**: 시간에 따른 제한을 지속적으로 모니터링하고 조정합니다.

관리 콘솔를 통해 속도 제한을 사용하도록 설정하는 방법에 대한 자세한 내용은 속도 제한 구성을 참조하세요.

사전 요구 사항

시작하기 전에 다음을 확인합니다.

  • 관리 콘솔에 대한 관리자 액세스
  • 로그 전달 구성에 대한 액세스
  • 중앙 집중식 로그를 분석하는 기능
  • 조직의 API 사용 패턴 및 중요한 통합 이해

1단계: 로그 전달을 활성화

로그 전달을 사용하여 모니터링 및 분석을 위해 API 요청 로그를 중앙 집중화합니다. 자세한 내용은 로그 전달을(를) 참조하세요.

전달된 로그를 분석할 때 다음 주요 필드에 집중합니다.

분야설명
Timestamp요청이 이루어진 시점 추적
user / gh.actor.login사용자 또는 통합 요청 식별
path_info / gh.request.api.route액세스 중인 API 경로
statusHTTP 응답 코드(예: 200 성공 또는 429 속도가 제한된 경우)
user_agent요청을 보내는 클라이언트 또는 통합 식별

속도 제한을 사용하도록 설정하기 전에 전체 사용 추세를 분석하여 기준을 설정합니다.

  •         **상위 소비자를 식별합니다.** 요청 수가 가장 많은 사용자 또는 통합을 찾습니다.

  •         **수요가 많은 엔드포인트를 검토합니다.** 가장 많은 트래픽을 수신하고 최적화를 활용할 수 있는 API 경로(`path_info`)를 강조 표시합니다.

  •         **비효율적인 패턴을 검색합니다.** 캐싱 또는 중복 요청 없이 자주 폴링하는 등 사용량이 많거나 비효율적인 징후를 찾습니다.

이 기준 데이터는 추측이 아닌 실제 사용량에 의해 제공되는 속도 제한을 설정하는 데 도움이 됩니다.

3단계: 초기 값이 높은 속도 제한 사용

속도 제한을 사용하도록 설정할 준비가 되면 높은 임계값으로 시작하여 기존 워크플로를 방해하지 않고 추가 데이터를 수집할 수 있습니다.

  1. 관리 콘솔에서 기본 API 속도 제한을 시간당 25,000개 요청과 같은 높은 값으로 설정합니다. 자세한 내용은 속도 제한 구성을(를) 참조하세요.

  2. 속도 제한을 사용하도록 설정한 후 전달된 로그에 gh.rate_limit 표시되는 필드를 모니터링합니다.

    분야설명
    gh.rate_limit.primary.max허용되는 최대 요청 수
    gh.rate_limit.primary.remaining현재 기간의 나머지 요청
    gh.rate_limit.primary.used해당 기간에 이미 만들어진 요청
    gh.rate_limit.primary.reset요율 제한 기간이 재설정되는 Unix 타임스탬프

4단계: 제한을 구체화하고 사용량이 많은 문제를 해결합니다.

필드의 데이터를 gh.rate_limit 사용하여 정보에 입각한 결정을 내립니다.

  •         **제한에 근접한 사용자를 식별합니다.** 임계값에 자주 접근하거나 초과하는 사용자 또는 통합을 찾습니다.

  •         **적절한 제한을 결정합니다.** 임의의 값이 아닌 관찰된 사용량 추세에 따라 속도 제한을 설정합니다.

  •         **영향을 받는 팀과 통신합니다.** 팀과 협력하여 요청 일괄 처리, 응답 캐싱 및 조건부 요청과 같은 기술을 통해 API 사용량을 최적화합니다.

5단계: 제한 줄이기 및 시간 경과에 따른 유지 관리

API 사용량을 명확하게 파악한 후에는 인스턴스의 용량 및 실제 사용 패턴에 맞게 속도 제한을 점진적으로 줄입니다. 각 조정 후 의도하지 않은 중단을 모니터링합니다.

제한을 구체화할 때 통합에 영향을 받는 팀과 함께 작업합니다. 요청 일괄 처리, 응답 캐싱 및 조건부 요청과 같은 기술은 팀이 API 사용량을 줄이는 데 도움이 될 수 있습니다. 유틸리티 ghe-config를 사용하여 특정 사용자를 속도 제한에서 제외할 수도 있습니다. 자세한 내용은 명령줄 유틸리티을(를) 참조하세요.

새 통합이 추가되고 워크플로가 진화함에 따라 사용 패턴이 변경되므로 주기적으로 속도 제한 데이터를 검토합니다.

추가 고려 사항

  •         **GraphQL API 제한.** GraphQL API에는 예외 목록을 통해 우회할 수 없는 별도의 속도 제한(기본값: 시간당 5,000포인트)이 있습니다. 자세한 내용은 [AUTOTITLE](/graphql/overview/rate-limits-and-node-limits-for-the-graphql-api)을(를) 참조하세요.

  •         **보조 속도 제한입니다.** 보조 속도 제한을 사용하도록 설정하여 전체 서비스 수준을 보호할 수도 있습니다. 자세한 내용은 [AUTOTITLE](/admin/configuring-settings/configuring-user-applications-for-your-enterprise/configuring-rate-limits#enabling-secondary-rate-limits)을(를) 참조하세요.

추가 읽기

  •         [AUTOTITLE](/rest/overview/rate-limits-for-the-rest-api)