다음을 통해 공유

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

  • 적용 대상: ✅ NoSQL

제한 시간이 초과되기 전에 SDK(소프트웨어 개발 키트)가 요청을 완료할 수 없는 경우 HTTP 408 오류가 발생합니다.

애플리케이션 디자인이 Azure Cosmos DB for NoSQL SDK를 사용하여 복원력 있는 애플리케이션을 설계하는 가이드 를 따라 다양한 네트워크 조건에 올바르게 반응하도록 하는 것이 중요합니다. 애플리케이션에서는 분산 시스템에서 일반적으로 발생하는 문제인 시간 초과 오류에 대해 재시도 메커니즘을 구현해야 합니다.

시간 초과 오류에 대한 사례를 평가할 때 다음 작업을 고려합니다.

  • 성공한 작업과 비교하여 영향을 받는 작업의 양에 미치는 영향을 측정합니다.
  • 효과가 서비스 수준 계약에 정의된 임계값 내에 있는지 여부를 확인합니다.
  • P99 대기 시간 또는 가용성이 어떻게 영향을 받는지 평가합니다.
  • 오류가 모든 애플리케이션 인스턴스에 영향을 주는지 또는 하위 집합에만 영향을 주는지 여부를 식별합니다.

NoSQL .NET SDK용 Azure Cosmos DB에서 시간 제한 사용자 지정

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

요청 수준 제한 시간

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

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

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

취소 토큰

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

비고

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

문제 해결 단계

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

CosmosOperationCanceledException

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

예외 Message / ToString()는 Cancellation Token has expired: true를 통해 CancellationToken의 상태를 나타내며, 관련 요청에 대한 취소의 컨텍스트가 포함된 Diagnostics도 포함합니다.

이러한 예외는 다시 시도해도 안전하며, 재시도 논리에서 [시간 초과 예외](conceptual-resilient-sdk-applications.md#time outs-and-connectivity-related-failures-http-408503)로 처리할 수 있습니다.

해결 방법

CancellationToken에서 구성된 시간을 확인하십시오. 그런 다음 요청 제한 시간CosmosClientOptions.OpenTcpConnectionTimeout 및 속성보다 큰지 확인합니다( 직접 모드를 사용하는 경우). 사용 가능한 시간이 CancellationToken에서 구성된 시간 제한보다 짧으면, SDK가 [일시적인 연결 문제](conceptual-resilient-sdk-applications.md#time outs-and-connectivity-related-failures-http-408503)에 직면한 경우, SDK는 다시 시도할 수 없고 예외를 CosmosOperationCanceledException 발생시킵니다.

높은 CPU 사용률

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

제한 시간에는 Diagnostics가 포함되어 있으며, 이는 다음을 포함합니다.

"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 값이 있는 경우 원인은 스레드 부족입니다. 이 경우 솔루션은 스레드 부족(잠재적으로 잠긴 스레드)의 원본/s를 조사하거나 머신/s를 더 큰 리소스 크기로 스케일링하는 것입니다.
  • dateUtc 측정 사이의 시간이 약 10 초가 아니면 스레드 풀에서 경합을 나타낼 수도 있습니다. CPU는 스레드 풀에서 몇 초마다 10 큐에 삽입되는 독립적인 작업으로 측정됩니다. 측정 사이의 시간이 길면 비동기 작업을 적시에 처리할 수 없음을 나타냅니다. 이 시나리오는 일반적으로 애플리케이션 코드에서 비동기 코드에 대한 차단 호출 을 수행할 때 발생합니다.

해결 방법

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

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

솔루션이 Azure에서 실행되는 경우 .NET SDK를 사용하는 클라이언트는 Azure SNAT(원본 네트워크 주소 변환) 포트 고갈에 도달할 수 있습니다.

솔루션 1

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

해결 방법 2

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

솔루션 3

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

솔루션 4

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

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

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

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

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

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

해결 방법

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

핫 파티션 키

NoSQL용 Azure Cosmos DB는 전체 프로비전된 처리량을 실제 파티션에 균등하게 분산합니다. 핫 파티션이 있는 경우 물리적 파티션에 있는 하나 이상의 논리적 파티션 키가 모든 물리적 파티션의 초당 요청 단위(RU/s)를 사용하고 있습니다. 동시에 다른 물리 분할의 RU는 사용되지 않습니다. 증상으로, 사용된 RU/s의 총량이 데이터베이스 또는 컨테이너에서 프로비전된 전체 RU/s보다 적음에도 불구하고 핫 논리 파티션 키에 대한 요청에서 속도 제한(429 오류)이 발생합니다. 메트릭을Normalized RU Consumption 사용하여 워크로드에 핫 파티션이 발생하는지 확인합니다.

해결 방법

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

높은 수준의 동시성

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

해결 방법

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

대량 요청 또는 응답

요청이나 응답이 많을 경우, 채널에서의 우선순위 차단이 발생하여 비교적 낮은 동시성 수준에서도 경합이 더 심화될 수 있습니다.

해결 방법

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

실패율은 Azure Cosmos DB for NoSQL SLA(서비스 수준 계약) 내에 있습니다.

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

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

Azure 지원에 문의하세요.

관련 콘텐츠