Microsoft Fabric 제한을 사용하여 워크로드가 용량 또는 REST API 요청 제한을 초과할 때 서비스 성능 및 안정성을 유지합니다. 이 문서에서는 제한 작동 방식, HTTP 429 응답을 해석하는 방법 및 Fabric API 할당량을 효과적으로 처리하는 애플리케이션을 디자인하는 방법을 설명합니다.
API 할당량 제한
Microsoft Fabric은 자체 REST API에 대해 REST API용 통합 할당량을 도입합니다. 이 모델에서 API 요청은 사용자 또는 서비스 주체별로 적용되는 ID 수준 할당량에 의해 제어됩니다.
목표는 자동화, CI/CD 및 에이전트 기반 시나리오에서 관리되는 API 그룹에 대해 일관되고 예측 가능한 제한 환경 입니다.
이전에는 각 Microsoft Fabric REST API가 자체적으로 독립적인 제한 규칙을 적용하여 엔드포인트 간에 일관되지 않은 동작이 발생하는 경우가 많습니다. 따라서 특히 여러 API와 상호 작용하고 다른 제한이 적용되는 자동화 시나리오의 경우 워크로드가 제한될 수 있는 시기를 예측하기가 어려웠습니다.
API 할당량이 도입되면 Fabric 보다 일관된 ID 기반 접근 방식으로 이동하고 있습니다. 이제 API 사용량은 ID별로 적용되는 통합 할당량에 의해 제어되므로 Fabric API에서 보다 명확하고 예측 가능한 제한 모델을 제공합니다. 그러나 일부 개별 API 관련 제한 제한은 전체 API 할당량 외에도 계속 적용될 수 있습니다.
메모
API 할당량 은 API 요청을 제어하고 제한하기 위해서만 존재합니다. 이는 Fabric의 컴퓨팅, 스토리지 또는 청구 용량을 나타내지 않으며, Fabric 용량 소비나 비용에 아무런 영향도 미치지 않습니다.
API 참조 페이지에서 할당량을 문서화하는 경우 해당 엔드포인트별 제한을 해당 API에 대해 신뢰할 수 있는 것으로 처리합니다. API 참조 페이지에 수치로 명시된 할당량이 없으면 Retry-After을 준수하고, 횟수에 제한을 둔 재시도를 적용하며, 버스트 트래픽을 피함으로써 애플리케이션이 429 응답을 처리할 수 있도록 설계하세요.
할당량 모델의 작동 방식
각 ID(사용자 또는 서비스 주체)에는 다양한 범주의 API 트래픽을 제어하는 여러 독립 할당량 버킷이 할당됩니다. ID가 요청을 보내면 사용 중인 API 범주에 대한 할당량에 대해 요청이 평가됩니다.
세 가지 통합 할당량이 있습니다.
- 플랫폼 API 전용 플랫폼 API에 대한 통합 할당량입니다.
- 작업 스케줄러 API용 통합 할당량 — 작업 스케줄러 API 전용
- Long-Running Operations API용 통합 할당량 — Long-Running Operations API 전용입니다.
| Quota | Limit |
|---|---|
| 플랫폼 API에 대한 통합 할당량 | 200 통화/분 |
| 작업 스케줄러 API에 대한 통합 할당량 | 200 통화/분 |
| 장기 실행 작업 API의 통합 할당량 | 200 통화/분 |
이러한 할당량은 독립적이므로 한 범주의 활동은 다른 범주의 할당량을 사용하지 않습니다. 예를 들어 서비스 주체는 사용 가능한 플랫폼 API에 대한 통합 할당량에 영향을 주지 않고 작업 스케줄러 API에 대한 전체 통합 할당량을 사용할 수 있습니다. 이렇게 분리하면 특수한 API 영역의 대용량 워크로드가 일반 API 작업에 영향을 주지 않으며 다양한 유형의 요청에서 보다 예측 가능한 제한 동작을 사용할 수 있습니다.
API 강제 적용
API 할당량은 ID별로 적용됩니다. 즉, 모든 사용자, 서비스 주체 또는 관리 ID는 자체적으로 독립적인 할당량 할당을 받습니다. 할당량은 ID 간에 공유되지 않으며, 적격 Fabric API는 해당 ID와 연결된 공통 할당량 버킷에서 사용합니다.
따라서 한 ID의 API 사용은 다른 ID에 영향을 주지 않습니다. 예를 들어 많이 사용되는 서비스 주체는 다른 사용자 또는 애플리케이션의 할당량에 영향을 주지 않고 자체 API 할당량을 소진할 수 있습니다.
마찬가지로 ID가 할당량 한도에 도달하고 제한되는 경우 해당 제한은 해당 ID에만 적용되지만 다른 ID는 정상적으로 계속 작동합니다. 이 격리는 워크로드에서 보다 예측 가능하고 관리하기 쉬운 API 사용을 제공합니다.
할당량 적용 계층 구조
모든 API 요청은 ID(사용자 계정 또는 서비스 주체)로 시작합니다. 해당 ID가 Fabric API를 호출하는 경우 요청은 먼저 공유 API 할당량의 용량을 사용합니다. 이 할당량은 API가 아닌 ID별로 적용됩니다. 이 할당량은 단일 ID가 할당된 요청 속도를 초과할 수 없도록 참여하는 모든 API에서 공유되는 중앙 집중식 제한 메커니즘 역할을 합니다.
공유 API 할당량에 대해 요청이 평가되면 API별 제한 제한도 적용됩니다. 이러한 제한은 공유 할당량과 독립적이며 특정 API에 대해서만 존재할 수 있습니다. 따라서 요청이 성공적으로 처리되려면 ID 수준 API 할당량과 적용 가능한 개별 API 제한을 모두 충족해야 합니다.
실질적으로 공유 API 할당량은 API 간에 일관된 제한 환경을 제공하는 반면 개별 API 제한은 추가 보호가 필요한 특정 서비스를 계속 보호합니다. 따라서 ID가 공유 할당량을 소진했거나 특정 API 엔드포인트의 제한에 도달했기 때문에 API 호출을 제한할 수 있습니다.
주요 개념:
- ID 기반 적용: 할당량은 각 사용자 또는 서비스 주체에 대해 별도로 추적됩니다.
- API 간에 공유됨: 다른 API에 대한 요청은 동일한 API 할당량 풀에서 사용합니다.
- 속도 제한만: API 할당량은 요청률을 제어하지만 권한 부여나 권한에는 영향을 미치지 않습니다.
- 이중 적용: 공유 API 할당량 및 API 관련 제한은 모든 요청에 대해 평가됩니다.
- 가장 제한적인 제한이 적용됩니다. 공유 할당량 또는 적용 가능한 API 관련 제한을 초과하면 요청이 제한됩니다.
할당량 사용 방법
모든 API 요청은 호출 ID의 API 할당량 버킷에서 할당량을 사용합니다. 해당 ID에서 수행한 모든 요청은 호출되는 API에 관계없이 동일한 공유 할당량으로 계산됩니다.
할당량 기간 및 갱신
API 할당량은 고정된 60초 창을 사용하여 적용됩니다. 할당량 버킷은 현재 창이 끝나면 한 번에 모두 보충됩니다. 해당 시간 범위 동안 할당량은 점진적으로 복구되지 않습니다.
메모
ID가 창의 시작 부분에서 전체 할당량을 사용하는 경우 다음 60초 창이 시작될 때까지 추가 요청을 수행할 수 없습니다.
타임라인 예제
Second 0 → Quota window begins. Bucket is full (300 requests available).
Second 1 → 300 requests are made. Bucket is exhausted.
Additional requests receive HTTP 429 (Too Many Requests).
Seconds 2-59 → All additional requests continue to receive HTTP 429.
No quota is restored during the window.
Second 60 → New quota window begins.
Bucket is fully replenished (300 requests available).
Requests are accepted again.
실질적인 의미
- 윈도우 시작 시점에 요청을 한꺼번에 몰아 보내는 것은 허용되지만, 그렇게 하면 해당 윈도우의 남은 시간 동안 해당 ID에 스로틀링이 적용될 수 있습니다.
- 60초 동안 요청을 균등하게 분산하면 제한을 방지할 수 있습니다.
- 항상 Retry-After 응답 헤더를 준수하세요. 제한된 요청을 다시 시도하기 전에 대기하는 시간을 나타냅니다.
API별 속도 제한 세부 정보
Microsoft Fabric 통합 제한 범주 및 공유 할당량 개념을 제공하지만 실제 속도 제한은 API에 따라 달라질 수 있습니다. 항상 호출하는 해당 API의 스로틀링 제한 섹션을 확인하세요.
메모
항상 호출하는 해당 API의 스로틀링 제한 섹션을 확인하세요.
제한 메시지
제한이 발생하면 Fabric HTTP 상태 코드 429(요청이 너무 많음)를 반환합니다. Fabric 각각 응답 본문에서 다른 errorCode 것으로 식별되는 두 가지 이유로 429 상태 코드를 반환합니다.
응답의 errorCode 값을 검사하여 발생한 조건과 응답 방법을 확인합니다.
속도 제한을 초과했습니다(RequestBlocked)
사용자가 일정 기간 동안 미리 정해진 한도를 초과하는 많은 요청을 보내면 Fabric 짧은 기간 동안 해당 사용자의 추가 요청을 제한합니다.
이 경우 Fabric 응답에 HTTP 헤더가 Retry-After 있는 HTTP 상태 코드 429(요청이 너무 많음)를 반환하여 호출 애플리케이션이 호출을 다시 시도하기 전에 대기해야 하는 시간(초)을 나타냅니다. 응답 본문은 오류 코드를 사용합니다 RequestBlocked .
{
"errorCode": "RequestBlocked",
"message": "Request is blocked by the upstream service until: 2/18/2026 10:45:04 PM (UTC)"
}
이 오류가 표시되면 요청을 다시 시도하기 전에 헤더에 Retry-After 지정된 기간 동안 기다립니다.
다음 스크린샷은 사용자가 호출을 다시 시도하기 전에 55초 동안 대기하는 것을 제안하는 응답 예제를 보여 줍니다.
용량 제한을 초과했습니다(CapacityLimitExceeded)
또한 Fabric 조직의 Fabric 용량이 제한을 초과하면 HTTP 상태 코드 429(요청이 너무 많음)를 반환합니다. 속도 제한과 달리 이 제한은 특정 호출자가 만드는 API 호출 수로 인해 발생하지 않습니다. 대신, 이는 해당 용량에서 소비되는 컴퓨팅(용량 단위)이 구매한 Fabric SKU의 한도를 초과할 때 발생합니다. 응답 본문은 오류 코드를 사용합니다 CapacityLimitExceeded .
{
"errorCode": "CapacityLimitExceeded",
"message": "Your organization's Fabric compute capacity has exceeded its limits. Try again later."
}
이 오류가 표시되면 나중에 요청을 다시 시도합니다. 이 스로틀링은 개별 요청 속도가 아니라 해당 용량에서 소비되는 전체 컴퓨팅 사용량에 따라 결정되므로, 해당 용량의 컴퓨팅 사용량이 다시 한도 범위 내로 내려갈 때까지는 즉시 재시도해도 성공할 가능성이 낮습니다. 이 오류가 자주 발생하는 경우 Fabric 용량을 확장하거나 스케일 아웃하는 것이 좋습니다. 용량 단위, SKU 및 Fabric 용량을 사용하는 방법에 대한 자세한 내용은 용량 크기 계획을 참조하세요.
고려 사항 및 제한 사항
모든 Fabric 관리자 API 및 핵심 공개 API는 스로틀링될 수 있습니다.
FABRIC REST API를 호출하는 애플리케이션을 디자인할 때 다음 사항을 염두에 두어야 합니다.
- 호출 중인 호출자 ID 및 API에 대한 할당량이 적용됩니다. 별도의 ID가 반드시 동일한 요청 카운터를 공유하지는 않지만 각 호출자는 API에 대해 문서화된 제한을 따라야 합니다.
- 많은 속도 제한은 1분 동안 평가됩니다. 한도를 초과하는 경우 더 많은 요청을 보내기 전에 값을 기다립니다
Retry-After. - 용량 제한은 요청 속도 제한과 다릅니다.
CapacityLimitExceeded는 호출자가 분당 API 할당량을 초과하지 않고 Fabric 용량이 오버로드되었음을 나타냅니다. - 용량 제한 오류를 즉시 다시 시도하는 것은 성공할 가능성이 낮습니다. 제한된 재시도 정책을 사용하고 오류가 지속되는 경우 용량 사용량을 조사합니다.
- 대용량 통합의 경우 사용 가능한 경우 목록, 대량 또는 일괄 처리 작업을 선호하고, 자주 변경되지 않는 메타데이터를 캐시하고, 시간이 지남에 따라 요청을 균등하게 분산하는 것이 좋습니다.
- 페이지 매김을 지원하는 API의 경우 처음부터 반복적인 광범위한 쿼리를 만드는 대신 연속 토큰을 사용합니다.
자주 묻는 질문
API 할당량에 도달했는지 또는 용량 제한에 도달했는지 어떻게 알 수 있나요?
429 응답 본문에서 errorCode를 확인하세요.
RequestBlocked 는 요청 속도가 서비스의 제한 한도를 초과했음을 의미합니다.
CapacityLimitExceeded는 Fabric 용량에서 사용된 컴퓨팅이 구매한 SKU의 제한을 초과했음을 의미합니다.
할당량은 언제 재설정되나요?
대부분의 Fabric REST API 속도 제한은 1분 동안 평가됩니다. 응답에 헤더가 Retry-After 포함된 경우 다시 시도하기 전에 해당 값을 신뢰할 수 있는 대기 시간으로 사용합니다.
요청을 하기 전에 남은 API 할당량을 확인할 수 있나요?
Fabric REST API 응답은 모든 API에 대한 일반 남은 할당량 카운터를 제공하지 않습니다. 클라이언트가 429 응답을 감지하고 Retry-After를 준수하며 스로틀링이 발생하면 요청량을 줄일 수 있도록 구현하세요.
속도 제한될 가능성을 줄이려면 어떻게 해야 하나요?
사용 가능한 경우 대량 및 일괄 처리 작업을 사용하고, 많은 단일 리소스 호출보다 목록 API를 선호하며, 자주 액세스하는 메타데이터를 캐시하고, 갑작스러운 트래픽 버스트를 방지합니다. 영구 용량 제한의 경우 Microsoft Fabric 용량 메트릭 앱을 사용하여 오버로드된 용량 및 워크로드를 식별합니다.
429 응답마다 동일한 방식으로 다시 시도해야 하나요?
No.
RequestBlocked의 경우 Retry-After 헤더를 기다린 후 제한된 재시도 정책으로 다시 시도합니다. 의 경우 CapacityLimitExceeded나중에 지수 백오프를 사용하여 다시 시도하고 문제가 계속되면 용량 사용률을 조사합니다.