다음을 통해 공유

속도 및 사용량 제한

  • 아티클

Azure DevOps Services

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

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

전역 사용량 제한

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

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

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

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

개별 사용자의 요청이 차단되면 다음 메시지와 유사한 메시지와 함께 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 TTU(처리량 단위)

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

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

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

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

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

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

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

참고 항목

도구 및 애플리케이션에서 Azure DevOps와 통합하는 데 사용되는 ID는 허용된 사용량 한도를 초과하여 더 높은 속도 및 사용량 한도가 필요할 수 있습니다. 기본 + 테스트 계획 액세스 수준을 애플리케이션에서 사용하는 원하는 ID에 할당하여 추가 속도 및 사용 제한을 얻을 수 있습니다. 더 높은 속도 제한의 필요성이 충족되면 ID가 사용하던 액세스 수준으로 돌아갈 수 있습니다. 기본 + 테스트 계획 액세스 수준의 비용은 ID에 할당된 시간에 대해서만 청구됩니다.

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

Pipelines

속도 제한은 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

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

서비스 연결

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