Azure 기밀 원장 제한

Azure 기밀 원장은 모든 원장의 성능과 가용성을 예측 가능하게 유지하기 위해 구독의 원장 수와 원장이 저장하는 데이터 및 코드를 제한합니다. 이 문서에서는 이러한 제한, 요청이 이를 초과할 때 원장이 응답하는 방법 및 원장에서 기대할 수 있는 성능에 대해 설명합니다.

비고

이 문서의 제한은 기본값입니다. 특정 경우에 개별 원장은 제한이 도입되기 전에 만든 원장과 같은 다른 제한을 가질 수 있습니다. 더 높은 제한을 요청하거나 제한 사항을 논의하려면 Azure 지원 문의하세요.

구독 제한

다음 제한은 각 Azure 구독에 적용됩니다.

Limit	Value
구독당 원장	2

원장 데이터 제한

기본적으로 모든 원장에는 다음 제한이 적용됩니다.

Limit	기본값	오류 코드
원장당 컬렉션	5,000	CollectionCapacityExceeded
컬렉션 ID 길이	256바이트	CollectionIdTooLong
원장 항목의 내용 크기	8KiB(8,192바이트)	EntrySizeCapacityExceeded
원장당 태그(공용 원장만 해당)	1만	TagCapacityExceeded

• 원장당 컬렉션: 기본 컬렉션은 계산되지 않습니다. 원장이 한도에 도달하면 새 컬렉션을 만드는 쓰기가 거부됩니다. 기존 컬렉션에 대한 쓰기는 여전히 성공합니다.
• 컬렉션 ID 길이: 길이는 URL 디코딩 후 UTF-8로 인코딩된 ID의 바이트 단위로 측정됩니다. 이 제한은 쓰기가 새 컬렉션을 만드는 경우에만 적용되므로 이 제한이 도입되기 전에 만든 컬렉션에 계속 쓰고 읽을 수 있습니다.
• 원장 항목의 내용 크기: 크기는 JSON 디코딩 후 UTF-8로 인코딩된 contents 값의 바이트 단위로 측정됩니다. 정확히 8,192바이트의 콘텐츠가 허용됩니다. 이 제한은 새 컬렉션과 기존 컬렉션 모두에 대한 쓰기에 적용됩니다. 요청의 컬렉션 ID, 태그 및 기타 필드는 이 제한에 포함되지 않습니다. 전체 요청은 원장의 최대 요청 본문 크기도 적용됩니다.
• 원장당 태그: 태그는 해당 태그를 사용하는 각 컬렉션에 대해 한 번 계산됩니다. 예를 들어 두 컬렉션에 사용되는 태그 chocolate 는 두 개의 태그로 계산됩니다. 원장이 한도에 도달하면 컬렉션에 새 태그를 추가하는 쓰기가 거부됩니다. 태그가 없거나 컬렉션에서 이미 사용하는 태그를 사용하여 쓰기는 여전히 성공합니다.

제한을 초과하는 쓰기는 HTTP 상태 코드 400(잘못된 요청)으로 거부되고 요청의 아무 것도 원장에 기록되지 않습니다. 응답에는 오류 코드와 원장에 적용되는 제한이 포함된 메시지가 포함됩니다. 다음은 그 예입니다.

{
  "error": {
    "code": "EntrySizeCapacityExceeded",
    "message": "Entry contents of 9000 bytes exceed the limit of 8192 bytes."
  }
}

쓰기당 태그 제한

태그는 공용 원장에서만 지원됩니다. 모든 공용 원장에는 다음 제한이 적용됩니다.

Limit	Value
쓰기당 태그	5
태그 길이	63자

태그는 비워 둘 수 없으며 문자 A(, –Z, a–z9, 0-, , _.및 ~)만 포함할 수 있습니다. 이러한 제한을 초과하거나 잘못된 태그를 포함하는 쓰기는 HTTP 상태 코드 400 및 NotAllowed 오류 코드로 거부됩니다.

사용자 정의 함수 제한

다음 제한은 모든 원장의 UDF(사용자 정의 함수)에 적용됩니다. 이를 초과하는 요청은 HTTP 상태 코드 400으로 거부됩니다.

Limit	Value	오류 코드
원장당 UDF	100	UserDefinedFunctionCapacityExceeded
UDF ID 길이	256바이트	InvalidFunctionId
UDF 코드 크기	64KiB(65,536바이트)	InvalidInput
쓰기당 사전 후크	5	InvalidInput
쓰기당 후크 후크	5	InvalidInput

UDF 수 및 ID 길이 제한은 UDF를 만들 때만 적용됩니다. 코드가 64KiB 내에 맞는 경우에도 기존 UDF를 업데이트할 수 있습니다.

UDF를 실행할 때 적용되는 런타임 옵션은 UDF 실행을 참조하세요. 사전 후크 및 후크에 대한 자세한 내용은 트랜잭션 후크를 참조하세요.

사용자 정의 엔드포인트 런타임 옵션

설정된 PATCH /app/userDefinedEndpoints/runtimeOptions 값은 다음 범위 내에 있어야 합니다. 그렇지 않으면 HTTP 상태 코드 400 및 오류 코드로 요청이 InvalidInput 거부됩니다. 요청 값이 변경된 옵션만 확인합니다.

런타임 옵션	허용되는 값
max_heap_bytes	최대 209,715,200개(200MiB)
max_stack_bytes	1 ~10,485,760(10MiB)
max_execution_time_ms	최대 10,000(10초)
max_cached_interpreters	1~20

Performance

원장의 성능은 항목 크기, 동시에 보내는 요청 수, 읽기 및 쓰기 혼합과 같은 워크로드에 따라 달라집니다. 다음 지침은 무엇을 기대해야 하는지에 대한 일반적인 아이디어를 제공합니다. 그것은 보장이 아닙니다.

처리량

• 원장은 초당 수백 개의 쓰기를 유지할 수 있습니다. 항목이 작고 동시 요청이 많을수록 속도가 증가합니다. 사용자 정의 함수를 실행하는 쓰기는 함수의 코드에 따라 더 오래 걸립니다.
• 컬렉션의 최신 항목을 읽으면 쓰기보다 적은 리소스가 사용되므로 원장은 일반적으로 이러한 요청을 더 많이 처리할 수 있습니다. 원장이 먼저 스토리지에서 데이터를 로드하기 때문에 트랜잭션 ID로 항목을 가져오고, 영수증을 받고, 범위 쿼리는 최신 항목을 읽는 것보다 더 많은 리소스를 사용합니다. 이러한 요청의 비율이 높을수록 쓰기에 남아 있는 처리량이 줄어듭니다.
• 다음 요청을 보내기 전에 각 응답을 기다리는 클라이언트는 원장에 대한 왕복 시간으로 제한됩니다. 원장을 최대한 활용하려면 동시에 요청을 보내고 연결을 다시 사용합니다.

워크로드에 높은 처리량이 지속적으로 필요한 경우 프로덕션으로 이동하기 전에 원장에서 테스트합니다. 더 많은 처리량이 필요한 경우 Azure 지원 문의하세요.

Latency

• 기본적으로 쓰기 요청은 원장이 쓰기를 수락하는 즉시 반환되고 원장은 잠시 후에 쓰기를 커밋합니다. 예를 들어 영수증을 받기 위해 쓰기에 의존하기 전에 해당 상태가 Committed있는지 확인합니다. 클라이언트 라이브러리는 커밋을 기다릴 수 있습니다.
• 트랜잭션 ID로 항목 가져오기, 영수증 가져오기 및 범위 쿼리는 원장이 데이터를 로드하는 동안 먼저 반환 Loading 할 수 있습니다. 결과를 반환할 때까지 1분 이내에 요청을 반복합니다.
• 대기 시간은 거리와 부하에 따라 달라집니다. 각 새 연결에는 원장과 TLS 핸드셰이크가 필요하므로 연결을 다시 사용하고 원장의 지역 가까이에서 클라이언트를 실행합니다. 원장의 부하가 유지할 수 있는 값에 가까워지면 대기 시간이 증가할 것으로 예상합니다.

관련 콘텐츠

• 데이터 조직
• 사용자 정의 함수
• 사용자 정의 엔드포인트
• 트랜잭션 영수증 작성