제한 시간이 초과되기 전에 SDK(소프트웨어 개발 키트)가 요청을 완료할 수 없는 경우 HTTP 408 오류가 발생합니다.
문제 해결 단계
다음 목록에는 요청 시간 초과 예외에 대한 알려진 원인 및 솔루션이 포함되어 있습니다.
종단 간 타임아웃 정책
여기에 제시된 모든 사전 해결책을 적용했음에도 불구하고 408 네트워크 시간 초과 오류가 발생하는 경우가 있습니다. 비상 대기 시간을 줄이고 이러한 시나리오에서 가용성을 개선하기 위한 일반적인 모범 사례는 엔드 투 엔드 시간 제한 정책을 구현하는 것입니다. 꼬리 지연 시간을 줄여 실패율을 낮추고, 시간 초과 후 재시도를 중단하여 요청 단위 및 클라이언트 측 컴퓨팅 비용을 절감합니다. 시간 제한 기간은 CosmosItemRequestOptions에서 설정할 수 있습니다. 그런 다음 NoSQL용 Azure Cosmos DB로 전송된 모든 요청에 옵션을 전달할 수 있습니다.
CosmosEndToEndOperationLatencyPolicyConfig endToEndOperationLatencyPolicyConfig = new CosmosEndToEndOperationLatencyPolicyConfigBuilder(Duration.ofSeconds(1)).build();
CosmosItemRequestOptions options = new CosmosItemRequestOptions();
options.setCosmosEndToEndOperationLatencyPolicyConfig(endToEndOperationLatencyPolicyConfig);
container.readItem("id", new PartitionKey("pk"), options, TestObject.class);
기존 문제
더 긴 기간 동안 요청이 중단되거나 시간이 더 자주 초과되는 경우 Java v4 SDK를 최신 버전으로 업그레이드하세요. 참고: 버전 4.18.0 이상을 사용하는 것이 좋습니다. 자세한 내용은 Java v4 SDK 릴리스 정보를 확인하세요.
높은 CPU 사용률
높은 CPU 사용률은 가장 일반적인 경우입니다. 최적 대기 시간을 위해 CPU 사용량은 약 40%가 되어야 합니다. 시간 간격으로 초를 사용하여 10 최대(평균이 아님) CPU 사용률을 모니터링합니다. CPU 급증은 단일 쿼리에 대해 여러 연결을 수행할 수 있는 파티션 간 쿼리에서 더 일반적으로 나타나는 현상입니다.
해결 방법
SDK를 사용하는 클라이언트 애플리케이션을 스케일 업하거나 스케일 아웃해야 합니다.
연결 제한
호스트 컴퓨터의 연결 제한 또는 Azure SNAT(원본 네트워크 주소 변환) 포트 고갈로 인해 연결 제한이 발생할 수 있습니다.
호스트 컴퓨터의 연결 제한
Red Hat과 같은 일부 Linux 시스템에는 열려 있는 파일의 총 수에 대한 상한이 있습니다. Linux의 소켓은 파일로 구현되므로 이 수는 총 연결 수도 제한합니다. 다음 명령을 실행합니다.
ulimit -a
해결 방법
허용되는 최대 열린 파일 수( nofile10,000개 이상)여야 합니다. 자세한 내용은 NoSQL Java SDK v4용 Azure Cosmos DB 성능 팁을 참조하세요.
소켓 또는 포트 가용성이 낮을 수 있음
솔루션이 Azure에서 실행되면 Java 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 GatewayConnectionConfig에서 구성된 연결 수를 지원할 수 있는지 확인합니다. 그렇지 않으면 연결 문제가 발생할 수 있습니다.
여러 클라이언트 인스턴스 만들기
여러 클라이언트 인스턴스를 만들면 연결 경합 및 시간 초과 문제가 발생할 수 있습니다.
솔루션 1
성능 팁을 따르고 전체 애플리케이션에서 단일 CosmosClient 인스턴스를 사용합니다.
해결 방법 2
애플리케이션에서 Singleton CosmosClient 을 사용할 수 없는 경우 CosmosClient에서 이 API connectionSharingAcrossClientsEnabled(true) 를 통해 NoSQL 클라이언트용 여러 Azure Cosmos DB 간에 연결 공유를 사용하는 것이 좋습니다.
클라이언트의 여러 인스턴스가 여러 계정과 상호 작용하는 경우 이 설정을 사용하도록 설정하면 직접 모드에서 연결을 공유할 수 있습니다. 이 모드는 NoSQL 클라이언트용 Azure Cosmos DB 인스턴스 간에 연결 공유가 가능한 경우에만 사용하도록 설정됩니다. 이 공유 옵션을 설정할 때 첫 번째 인스턴스화된 클라이언트의 연결 구성(예: 소켓 시간 제한 구성, 유휴 시간 제한 구성)이 다른 모든 클라이언트 인스턴스에 사용됩니다.
핫 파티션 키
NoSQL용 Azure Cosmos DB는 전체 프로비전된 처리량을 실제 파티션에 균등하게 분산합니다. 핫 파티션이 있는 경우 물리적 파티션에 있는 하나 이상의 논리적 파티션 키가 모든 물리적 파티션의 초당 요청 단위(RU/s)를 사용하고 있습니다. 동시에 다른 물리 분할의 RU는 사용되지 않습니다. 증상: 사용된 총 RU/s는 데이터베이스나 컨테이너에 프로비저닝된 전체 RU/s보다 적지만, 특정 핫 논리 파티션 키에 대한 요청에 제한(429 오류)이 계속 발생합니다. 정규화된 RU 소비 메트릭을 사용하여 워크로드에 핫 파티션이 발생하는지 확인합니다.
해결 방법
요청 볼륨과 스토리지를 고르게 분배하는 좋은 파티션 키를 선택합니다. 파티션 키 변경 방법에 대해 알아봅니다.
높은 수준의 동시성
애플리케이션이 높은 수준의 동시성을 수행하여 채널에서 경합이 발생할 수 있습니다.
해결 방법
SDK를 사용하는 클라이언트 애플리케이션을 스케일 업하거나 스케일 아웃해야 합니다.
대량 요청 또는 응답
요청이나 응답이 많을 경우, 채널에서의 우선순위 차단이 발생하여 비교적 낮은 동시성 수준에서도 경합이 더 심화될 수 있습니다.
해결 방법
SDK를 사용하는 클라이언트 애플리케이션을 스케일 업하거나 스케일 아웃해야 합니다.
실패율은 Azure Cosmos DB for NoSQL SLA(서비스 수준 계약) 내에 있습니다.
애플리케이션은 일시적인 오류를 처리하고 필요한 경우 다시 시도할 수 있어야 합니다. 408 예외는 만들기 경로에서 서비스가 항목을 만들었는지 여부를 알 수 없기 때문에 다시 시도되지 않습니다. 만들기를 위해 동일한 항목을 다시 보내면 충돌 예외가 발생합니다. 사용자 애플리케이션 비즈니스 논리에는 충돌을 처리하는 사용자 지정 논리가 있을 수 있습니다. 이러한 논리는 기존 항목의 모호성 및 만들기 다시 시도에 따른 충돌을 방지합니다.
실패율이 NoSQL SLA용 Azure Cosmos DB를 위반합니다.
Azure 지원에 문의하세요.