Azure Synapse Analytics의 Apache Spark 풀에 대한 동시성 및 API 속도 제한
다음 섹션에서는 Azure Synapse Analytics에서 작업을 관리하기 위한 Spark 풀 및 API에 대한 다양한 숫자 제한을 나열합니다.
리소스 한계
다음 표에서는 개별 작업 영역 및 Spark 풀에 대한 작업 및 코어의 최대 제한을 보여 줍니다.
중요
Spark 풀에 대해 지정된 제한은 노드 크기, vCore 및 메모리 구성에 관계없이 적용되며, 달리 명시되지 않는 한 사용자에 관계없이 Spark 풀의 생성된 모든 인스턴스에 적용됩니다.
| 리소스 | 메트릭 | 제한 | 범위 | 영역 | 메모 |
|---|---|---|---|---|---|
| 작업 | 동시에 실행 | 50 | Spark 풀 | 모두 | 제한은 Spark 풀 정의의 모든 사용자에 적용됩니다. 예를 들어 두 사용자가 동일한 Spark 풀에 대해 작업을 제출하는 경우 두 사용자에 대해 실행되는 누적 작업 수는 50개를 초과할 수 없습니다. |
| 작업 | Queued | 200 | Spark 풀 | 모두 | 제한은 Spark 풀 정의의 모든 사용자에 적용됩니다. |
| 작업 | 최대 활성 작업 | 250 | Spark 풀 | 모두 | 제한은 Spark 풀 정의의 모든 사용자에 적용됩니다. |
| 작업 | 최대 활성 작업 | 1000 | 작업 영역 | 모두 | |
| 코어 | 사용자당 코어 제한 | 풀 정의 기반 | Spark 풀 | 모두 | 예를 들어 Spark 풀이 50코어 풀로 정의된 경우 각 사용자는 풀의 자체 instance 가져오기 때문에 특정 Spark 풀 내에서 최대 50개의 코어를 사용할 수 있습니다. |
| 코어 | 모든 사용자에 대한 코어 제한 | 작업 영역 정의 기반 | 작업 영역 | 모두 | 예를 들어 작업 영역의 코어 수가 200개인 경우 작업 영역 내의 모든 풀에 있는 모든 사용자는 200개 이상의 코어를 함께 사용할 수 없습니다. |
| Livy | Livy 요청에 대한 최대 페이로드 크기 | 100kBytes | Livy | 모두 |
참고
- 최대 활성 작업은 제출된 총 작업 수이며, 여기에는 및
Jobs Queued가 모두Jobs Running Simultaneously포함됩니다. 즉,Max Active Jobs = Jobs Running Simultaneously + Jobs Queued
API 속도 제한
다음 표에서는 Spark 작업 및 세션 관리 API에 대한 제한 제한을 보여 줍니다.
| 리소스 | 메트릭 | 제한(초당 쿼리 수) | 범위 | 영역 |
|---|---|---|---|---|
| 작업 API | Spark 세션 가져오기 | 200 | Spark 세션 | 모두 |
| 작업 API | Spark 세션 가져오기 | 200 | Spark 풀 | 모두 |
| 작업 API | Spark 문 가져오기 | 200 | Spark 세션 | 모두 |
| 작업 API | 여러 Spark 문 가져오기 | 200 | Spark 세션 | 모두 |
| 작업 API | 세션 만들기 | 2 | 작업 영역 | EastUS, EastUS2, WestUS, WestUS2, CentralUS, EastUS2EUAP, 서유럽 |
| 작업 API | 세션 만들기 | 2 | 작업 영역 | 다른 모든 하위 지역 |
| 작업 API | Batch 작업 만들기 | 2 | 작업 영역 | 모두 |
| 작업 API | Spark Batch 작업 가져오기 | 200 | 작업 영역 | 모두 |
| 작업 API | 여러 Spark Batch 작업 가져오기 | 200 | 작업 영역 | 모두 |
참고
모든 리소스 및 작업에 대한 최대 요청 제한은 모든 지역에 대해 초당 200개의 쿼리입니다.
팁
읽는 오류 메시지 또는 HTTP 429 응답이 표시되는 경우
Your request has hit layered throttling rate-limit of 200 requests per 1 second(s) for requests on resource(s) identified by pattern {subscriptionId}. {workspaceName}. {HTTP-Verb}. {operationName} - You are currently hitting at a rate of 282 requests per 1 second(s). Please retry after 1 second(s)
또는
Your request has hit layered throttling rate-limit of 2 requests per 1 second(s) for requests on resource(s) identified by {subscriptionId}. {workspaceName}. {HTTP-Verb}. {operationName} - You are currently hitting at a rate of 24 requests per 1 second(s). Please retry after 1 second(s)
사용자는 "Retry-After" HTTP 응답 헤더에 제공된 기간 값을 사용하여 재시도를 수행할 때 해당 시간 간격을 기다려야 합니다.트래픽이 많은 시나리오에서 재시도에 임의, 상수 또는 지수 시간 간격을 사용하면 여전히 HTTP 429 오류가 발생하고 재시도 횟수가 높아져 서비스에서 요청을 수락하는 데 걸리는 전체 시간이 증가합니다.
대신 Retry-After 값을 제공하는 서비스를 사용하면 서버에서 클라이언트 요청을 수락하는 데 걸린 재시도 횟수와 시간을 최적화하기 위해 특정 시점 트래픽에 따라 초 단위의 값이 계산되므로 사용자는 작업 제출에서 더 높은 성공률을 경험하게 됩니다.