다음을 통해 공유

속도 및 사용량 제한

  • 아티클

Azure DevOps Services

Azure DevOps Services는 다중 테넌시를 사용하여 비용을 절감하고 성능을 향상시킵니다. 이 디자인은 공유 리소스의 다른 사용자가 사용량이 급증할 때 성능 문제 및 중단에 취약합니다. 따라서 Azure DevOps는 개인이 사용할 수 있는 리소스와 특정 명령에 대해 수행할 수 있는 요청의 양을 제한합니다. 이러한 제한을 초과하면 이후 요청이 지연되거나 차단될 수 있습니다.

자세한 내용은 Git 제한 및 모범 사례를 참조하여속도 제한에 도달하지 않도록 합니다.

전역 사용량 제한

Azure DevOps에는 현재 공유 리소스가 과부하될 위험이 있는 경우 임계값을 초과하여 개별 사용자의 요청을 지연하는 전역 소비 한도가 있습니다. 이 제한은 공유 리소스가 과부하에 가까운 경우 중단을 방지하는 데만 중점을 줍니다. 개별 사용자는 일반적으로 다음 인시던트 중 하나가 발생하는 경우에만 지연된 요청을 받습니다.

  • 공유 리소스 중 하나가 과부하될 위험이 있습니다.
  • 개인 사용량은 (슬라이딩) 5분 기간 내에 일반 사용자의 소비량의 200배를 초과합니다.

지연의 양은 사용자의 지속적인 사용 수준에 따라 달라집니다. 지연 범위는 요청당 몇 밀리초에서 최대 30초까지입니다. 사용량이 0이 되거나 리소스가 더 이상 과부하가 발생하지 않으면 지연이 5분 이내에 중지됩니다. 소비량이 계속 높으면 리소스를 보호하기 위해 지연이 무기한 계속될 수 있습니다.

사용자 요청이 상당한 금액만큼 지연되면 해당 사용자는 웹에서 전자 메일 및 경고 배너를 받습니다. 빌드 서비스 계정 및 전자 메일 주소가 없는 다른 계정의 경우 프로젝트 컬렉션 관리자 그룹의 구성원이 전자 메일을 받습니다. 자세한 내용은 사용량 모니터링을 참조하세요.

개별 사용자의 요청이 차단되면 다음 메시지와 유사한 메시지와 함께 HTTP 코드 429(요청이 너무 많음)가 포함된 응답이 수신됩니다.

TF400733: The request has been canceled: Request was blocked due to exceeding usage of resource <resource name> in namespace <namespace ID>.

Azure DevOps 처리량 단위

Azure DevOps 사용자는 많은 공유 리소스를 사용하며 사용량은 다음 요인에 따라 달라집니다.

  • 많은 수의 파일을 버전 제어에 업로드하면 데이터베이스 및 스토리지 계정에 많은 양의 부하가 발생합니다.
  • 복잡한 작업 항목 추적 쿼리는 검색한 작업 항목 수에 따라 데이터베이스 로드를 만듭니다.
  • 버전 제어에서 파일을 다운로드하고 로그 출력을 생성하여 드라이브 로드를 빌드합니다.
  • 모든 작업은 서비스의 다양한 부분에서 CPU 및 메모리를 사용합니다.

이를 수용하기 위해 Azure DevOps 리소스 사용량은 TTU(Azure DevOps 처리량 단위)라는 추상 단위로 표현됩니다. TSTU는 결국 다음 항목의 혼합을 통합합니다.

  • 데이터베이스 사용량 측정값으로 Azure SQL Database DTU
  • 컴퓨팅 사용량 측정값인 애플리케이션 계층 및 작업 에이전트 CPU, 메모리 및 I/O
  • 스토리지 사용량 측정값인 Azure Storage 대역폭

현재 TSTU는 주로 Azure SQL Database DTU에 초점을 맞추고 있습니다. Azure SQL Database는 과도한 소비로 인해 가장 일반적으로 압도되는 공유 리소스이기 때문에. 단일 TSTU는 Azure DevOps의 일반적인 사용자가 5분당 생성할 것으로 예상하는 평균 부하입니다. 일반적인 사용자도 부하 급증을 생성합니다. 이러한 급증은 일반적으로 5분당 10개 이하의 TSTU입니다. 드물게는 100 TSTU까지 상승하기도 합니다.

전역 소비 한도는 슬라이딩 5분 내에 200TSTU입니다.

Retry-After 헤더에 응답하는 것이 좋습니다. 응답에서 Retry-After 헤더를 검색하는 경우 다른 요청을 보내기 전에 시간이 지나갈 때까지 기다립니다. 이렇게 하면 클라이언트 애플리케이션에서 적용된 지연을 줄일 수 있습니다. 응답은 200이므로 요청에 재시도 논리를 적용할 필요가 없습니다.

가능하면 X-RateLimit-Remaining 및 X-RateLimit-Limit 헤더를 모니터링하는 것이 좋습니다. 이렇게 하면 지연 임계값에 얼마나 빨리 근접하는지 근사화할 수 있습니다. 클라이언트는 시간이 지남에 따라 지능적으로 반응하고 요청을 분산할 수 있습니다.

비고

도구 및 애플리케이션에서 Azure DevOps와 통합하는 데 사용하는 ID는 때때로 허용된 사용량 제한을 초과하는 더 높은 속도 및 사용량 제한이 필요할 수 있습니다. 기본 + 테스트 계획 액세스 수준을 애플리케이션에서 사용하는 원하는 ID에 할당하여 이러한 제한을 늘릴 수 있습니다. 더 높은 속도 제한의 필요성이 충족되면 이전 액세스 수준으로 되돌릴 수 있습니다. id에 할당된 기간 동안에만 기본 + 테스트 계획 액세스 수준에 대한 요금이 청구됩니다.

Visual Studio Enterprise 구독이 이미 할당된 ID는 제거될 때까지 기본 + 테스트 계획 액세스 수준을 할당받을 수 없습니다.

파이프라인

속도 제한은 Azure Pipelines와 유사합니다. 각 파이프라인은 자체 리소스 사용량이 추적된 개별 엔터티로 처리됩니다. 빌드 에이전트가 자체 호스팅되더라도 로그를 복제하고 전송하는 형태로 로드를 생성합니다.

개별 파이프라인에 대해 5분간 슬라이딩 윈도우 방식으로 200 TSTU의 제한을 적용합니다. 이 제한은 사용자의 전체 사용량 제한과 동일합니다. 파이프라인이 속도 제한에 의해 지연되거나 차단되면 연결된 로그에 메시지가 표시됩니다.

API 클라이언트 환경

요청이 지연되거나 차단되면 Azure DevOps는 API 클라이언트가 반응할 수 있도록 응답 헤더를 반환합니다. 완전히 표준화되지는 않았지만 이러한 헤더는 다른 인기 있는 서비스 따라 광범위하게.

다음 표에서는 사용 가능한 헤더와 해당 헤더의 의미를 나열합니다. X-RateLimit-Delay제외하고 요청이 지연되기 전에 이러한 헤더가 모두 전송됩니다. 이 설계를 통해 클라이언트는 요청 속도를 사전에 늦출 수 있습니다.

헤더 이름

설명

Retry-After

RFC 6585에 명시된 헤더는 검출 임계값을 피해 다음 요청을 보내기 전에 얼마나 오래 대기해야 하는지 알려줍니다. 단위: 초.

X-RateLimit-Resource

도달한 임계값의 서비스 및 유형을 나타내는 사용자 지정 헤더입니다. 임계값 유형 및 서비스 이름은 시간에 따라 다르며 경고 없이 달라질 수 있습니다. 이 문자열을 인간에게 표시하는 것이 좋지만 계산에 의존하지 않는 것이 좋습니다.

X-RateLimit-Delay

요청 지연 시간을 측정합니다. 단위: 소수 자릿수가 최대 3개인 초(밀리초)입니다.

X-RateLimit-Limit

지연이 부과되기 전에 허용되는 총 TTU 수입니다.

X-RateLimit-Remaining

지연되기 전 남아 있는 TSTU 수. 요청이 이미 지연되거나 차단된 경우 0입니다.

X-RateLimit-Reset

모든 리소스 사용량이 즉시 중지되면 추적된 사용량이 0TTU로 반환되는 시간입니다. Unix epoch로 시간 표현됩니다.

작업 추적, 프로세스, 프로젝트 제한

Azure DevOps는 조직에서 가질 수 있는 프로젝트 수와 각 프로젝트 내에서 가질 수 있는 팀 수에 제한을 적용합니다. 또한 작업 항목, 쿼리, 백로그, 보드, 대시보드 등에 대한 제한 사항도 알고 있어야 합니다. 자세한 내용은 작업 추적, 프로세스 및 프로젝트 제한을 참조하세요.

위키

일반적인리포지토리 제한 외에도 프로젝트에 대해 정의된 wiki는 단일 파일당 25MB로 제한됩니다.

서비스 연결

서비스 연결을 만드는 데는 프로젝트당 제한이 없습니다. 그러나 Microsoft Entra ID를 통해 적용되는 제한이 있을 수 있습니다. 자세한 내용은 다음 문서를 검토하세요.