Azure Cosmos DB .NET SDK 요청 시간 제한 예외 진단 및 문제 해결

  • 아티클

적용 대상: NoSQL

HTTP 408 오류는 SDK가 시간 제한이 발생하기 전에 요청을 완료할 수 없는 경우에 발생합니다.

애플리케이션 디자인이 Azure Cosmos DB SDK를 사용한 복원력 있는 애플리케이션 디자인 가이드를 따라 다양한 네트워크 조건에 올바르게 반응하는지 확인하는 것이 중요합니다. 애플리케이션은 일반적으로 분산 시스템에서 예상되기 때문에 시간 제한 오류에 대해 다시 시도해야 합니다.

시간 제한 오류에 대한 사례를 평가하는 경우:

  • 성공한 작업과 비교하여 영향을 받는 작업의 양으로 측정된 영향은 무엇인가요? 서비스 SLA 내에 있나요?
  • P99 대기 시간/가용성이 영향을 받나요?
  • 오류가 모든 애플리케이션 인스턴스 또는 하위 집합에만 영향을 주나요? 문제가 인스턴스의 하위 집합으로 축소되면 일반적으로 해당 인스턴스와 관련된 문제입니다.

Azure Cosmos DB .NET SDK에서 시간 초과 사용자 지정

SDK에는 각각 다른 범위를 가진 시간 초과를 제어하는 두 가지 고유한 대안이 있습니다.

요청 수준 시간 제한

CosmosClientOptions.RequestTimeout(또는 SDK v2의 경우 ConnectionPolicy.RequestTimeout) 구성을 사용하면 요청이 SDK를 떠난 후 응답이 수신될 때까지 네트워크에 있는 네트워크 요청에 대한 시간 제한을 설정할 수 있습니다.

CosmosClientOptions.OpenTcpConnectionTimeout(또는 SDK v2의 경우 ConnectionPolicy.OpenTcpConnectionTimeout) 구성을 사용하면 초기 연결을 여는 데 소요된 시간에 대한 시간 제한을 설정할 수 있습니다. 연결이 열리면 후속 요청에서 연결을 사용합니다.

사용자가 시작한 작업은 여러 네트워크 요청에 걸쳐 있을 수 있습니다(예: 다시 시도). 이러한 두 구성은 작업에 대한 엔드투엔드가 아닌 요청당 구성입니다.

CancellationToken

SDK의 모든 비동기 작업에는 선택적 CancellationToken 매개 변수가 있습니다. 이 CancellationToken 매개 변수는 모든 네트워크 요청 및 다시 시도에서 전체 작업에 사용됩니다. 네트워크 요청 사이에 취소 토큰을 확인하고 관련 토큰이 만료되면 작업이 취소될 수 있습니다. 취소 토큰을 사용하여 작업 범위에 대한 대략적인 예상 시간 초과를 정의해야 합니다.

참고 항목

CancellationToken 매개 변수는 라이브러리가 잘못된 상태를 발생시키지 않는 경우 취소를 확인하는 메커니즘입니다. 취소에 정의된 시간이 다 되었을 때 작업이 바로 취소되지 않을 수 있습니다. 대신 시간이 지나면 안전할 때 취소됩니다.

문제 해결 단계

다음 목록에는 요청 시간 초과 예외에 대한 알려진 원인과 솔루션이 포함되어 있습니다.

CosmosOperationCanceledException

이 형식의 예외는 애플리케이션이 SDK 작업에 CancellationTokens를 전달할 때 일반적입니다. SDK는 다시 시도 사이에 CancellationToken의 상태를 확인하고 CancellationToken이 취소되면 이 예외와 함께 현재 작업을 중단합니다.

예외의 Message / ToString()은 또한 CancellationToken부터 Cancellation Token has expired: true까지의 상태를 나타내며 여기에는 관련된 요청에 대한 취소 컨텍스트가 포함된 진단도 포함됩니다.

이러한 예외는 다시 시도하기에 안전하며 다시 시도 관점에서 시간 초과로 처리될 수 있습니다.

솔루션

CancellationToken에서 구성된 시간을 확인하고 RequestTimeout 및 CosmosClientOptions.OpenTcpConnectionTimeout보다 큰지 확인합니다(직접 모드를 사용하는 경우). CancellationToken의 사용 가능한 시간이 구성된 제한 시간보다 짧고 SDK에 일시적인 연결 문제가 있는 경우 SDK는 다시 시도할 수 없으며 CosmosOperationCanceledException이 throw됩니다.

높은 CPU 사용률

높은 CPU 사용률은 가장 일반적인 경우입니다. 최적 대기 시간을 위해 CPU 사용량은 약 40%가 되어야 합니다. 최대(평균 아님) CPU 사용률을 모니터링하려면 간격으로 10초를 사용합니다. CPU 급증은 단일 쿼리에 대해 여러 연결을 수행할 수 있는 파티션 간 쿼리에서 더 일반적으로 나타나는 현상입니다.

시간 제한에는 다음이 포함된 진단 포함되어 있습니다.

"systemHistory": [
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
...
]
  • cpu 측정값이 70%를 초과하면 CPU 소모로 인해 시간 초과가 발생할 수 있습니다. 이 경우 해결 방법은 높은 CPU 사용률의 출처를 조사하여 줄이거나 컴퓨터를 더 큰 리소스 크기로 조정하는 것입니다.
  • threadInfo/isThreadStarving 노드에 True 값이 있는 경우 원인은 스레드 부족입니다. 이 경우 해결 방법은 스레드 부족(잠재적으로 잠긴 스레드)의 출처를 조사하거나 컴퓨터를 더 큰 리소스 크기로 조정하는 것입니다.
  • 측정 사이의 dateUtc 시간이 약 10초가 아닌 경우 스레드 풀의 경합을 나타냅니다. CPU는 스레드 풀에서 10초마다 큐에 넣는 독립 작업으로 측정됩니다. 측정 사이의 시간이 길면 비동기 작업을 적시에 처리할 수 없음을 나타냅니다. 가장 일반적인 시나리오는 애플리케이션 코드에서 비동기 코드를 통해 호출을 차단하는 경우 입니다.

솔루션

SDK를 사용하는 클라이언트 애플리케이션을 스케일 업하거나 스케일 아웃해야 합니다.

소켓 또는 포트 가용성이 낮을 수 있음

Azure에서 실행할 때 .NET SDK를 사용하는 클라이언트는 Azure SNAT(PAT) 포트 고갈에 다다를 수 있습니다.

솔루션 1

Azure VM에서 실행하는 경우 SNAT 포트 고갈 가이드를 따르세요.

해결 방법 2

Azure App Service에서 실행하는 경우 연결 오류 문제 해결 가이드를 따르고 App Service 진단을 사용합니다.

솔루션 3

Azure Functions에서 실행하는 경우 모든 관련 서비스(Azure Cosmos DB 포함)에 대해 싱글톤 또는 정적 클라이언트를 유지 관리하는 Azure Functions 권장 사항을 준수하는지 확인합니다. 함수 앱 호스팅의 형식 및 크기에 따라 서비스 제한을 확인합니다.

솔루션 4

HTTP 프록시를 사용하는 경우 SDK ConnectionPolicy에서 구성된 연결 수를 지원할 수 있는지 확인합니다. 그렇지 않으면 연결 문제가 발생할 수 있습니다.

여러 클라이언트 인스턴스 만들기

여러 클라이언트 인스턴스를 만들면 연결 경합 및 시간 초과 문제가 발생할 수 있습니다. 진단에는 두 가지 관련 속성이 포함되어 있습니다.

{
    "NumberOfClientsCreated":X,
    "NumberOfActiveClients":Y,
}

NumberOfClientsCreated는 동일한 AppDomain 내에서 CosmosClient가 만들어진 횟수를 추적하고, NumberOfActiveClients는 활성 클라이언트(삭제되지 않음)를 추적합니다. 싱글톤 패턴을 따르는 경우 X는 애플리케이션이 작동하는 계정 수와 일치하고 X는 Y와 동일할 것으로 예상됩니다.

X가 Y보다 큰 경우 이는 애플리케이션이 클라이언트 인스턴스를 만들기 및 삭제하고 있음을 의미합니다. 이로 인해 연결 경합 및/또는 CPU 경합이 발생할 수 있습니다.

솔루션

성능 팁을 따르고 전체 프로세스에서 계정당 단일 CosmosClient 인스턴스를 사용합니다. 클라이언트를 만들고 폐기하지 마세요.

핫 파티션 키

Azure Cosmos DB는 전체 프로비저닝된 처리량을 물리적 파티션에 고르게 분산합니다. 핫 파티션이 있는 경우 물리적 파티션에 있는 하나 이상의 논리적 파티션 키가 모든 물리적 파티션의 초당 요청 단위(RU/s)를 사용하고 있습니다. 동시에 다른 물리 분할의 RU는 사용되지 않습니다. 증상으로, 소비되는 총 RU/s는 데이터베이스 또는 컨테이너에서 프로비저닝된 전체 RU/s보다 적지만 핫 논리적 파티션 키 관련 요청에 대해 제한(429s)이 계속 표시됩니다. 정규화된 RU 소비 메트릭을 사용하여 워크로드에 핫 파티션이 발생하는지 확인합니다.

솔루션

요청 볼륨과 스토리지를 고르게 분배하는 좋은 파티션 키를 선택합니다. 파티션 키 변경 방법에 대해 알아봅니다.

높은 수준의 동시성

애플리케이션이 높은 수준의 동시성을 수행하여 채널에서 경합이 발생할 수 있습니다.

솔루션

SDK를 사용하는 클라이언트 애플리케이션을 스케일 업하거나 스케일 아웃해야 합니다.

대량 요청 또는 응답

요청 또는 응답이 많으면 비교적 낮은 동시성 수준일 때도 채널에 대해 HOL(Head of Line) 차단이 진행되고 경합 상황이 악화될 수 있습니다.

솔루션

SDK를 사용하는 클라이언트 애플리케이션을 스케일 업하거나 스케일 아웃해야 합니다.

실패율이 Azure Cosmos DB SLA을 벗어나지 않습니다.

애플리케이션은 일시적인 오류를 처리하고 필요한 경우 다시 시도할 수 있어야 합니다. 408 예외는 만들기 경로에서 서비스가 항목을 만들었는지 여부를 알 수 없기 때문에 다시 시도되지 않습니다. 만들기에 대해 동일한 항목을 다시 전송하면 충돌 예외가 발생합니다. 사용자 애플리케이션 비즈니스 논리에는 충돌을 처리하는 사용자 지정 논리가 있을 수 있습니다. 이러한 논리는 기존 항목의 모호성 및 만들기 다시 시도에 따른 충돌을 방지합니다.

실패율이 Azure Cosmos DB SLA를 위반합니다.

Azure 지원에 문의하세요.

다음 단계

  • Azure Cosmos DB .NET SDK를 사용하고 있는 경우 문제를 진단 및 해결합니다.
  • .NET v3 및 .NET v2의 성능 지침에 대해 알아봅니다.