Azure Cosmos DB Java v4 SDK 요청 시간 제한 예외 진단 및 문제 해결
적용 대상: 
NoSQL
HTTP 408 오류는 SDK가 시간 제한이 발생하기 전에 요청을 완료할 수 없는 경우에 발생합니다.
문제 해결 단계
다음 목록에는 요청 시간 초과 예외에 대한 알려진 원인과 솔루션이 포함되어 있습니다.
엔드 투 엔드 시간 제한 정책
아래에 멘션 모든 선점 솔루션이 구현된 경우에도 408 네트워크 시간 제한 오류가 발생하는 시나리오가 있습니다. 이러한 시나리오에서 비상 대기 시간을 줄이고 가용성을 개선하기 위한 일반적인 모범 사례는 종단 간 시간 제한 정책을 구현하는 것입니다. 비상 대기 시간은 더 빠르게 실패하여 감소하며 , 시간 제한 후 재시도를 중지하여 요청 단위 및 클라이언트 쪽 컴퓨팅 비용을 줄입니다. 시간 제한 기간은 에 CosmosItemRequestOptions설정할 수 있습니다. 그런 다음, 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%가 되어야 합니다. 최대(평균 아님) CPU 사용률을 모니터링하려면 간격으로 10초를 사용합니다. CPU 급증은 단일 쿼리에 대해 여러 연결을 수행할 수 있는 파티션 간 쿼리에서 더 일반적으로 나타나는 현상입니다.
해결 방법:
SDK를 사용하는 클라이언트 애플리케이션을 스케일 업하거나 스케일 아웃해야 합니다.
커넥트ion 제한
연결 제한은 호스트 컴퓨터의 연결 제한 또는 Azure SNAT(PAT) 포트 고갈 중 하나로 인해 발생할 수 있습니다.
호스트 머신의 연결 제한
Red Hat과 같은 일부 Linux 시스템에는 열려 있는 파일의 총 수에 대한 상한이 있습니다. Linux의 소켓은 파일로 구현되므로 이 수는 총 연결 수도 제한합니다. 다음 명령을 실행합니다.
ulimit -a
해결 방법:
"nofile"으로 식별되는 허용되는 최대 열린 파일 수는 10,000개 이상이어야 합니다. 자세한 내용은 Azure Cosmos DB Java SDK v4 성능 팁을 참조하세요.
소켓 또는 포트 가용성이 낮을 수 있음
Azure에서 실행할 때 Java SDK를 사용하는 클라이언트는 PAT(Azure SNAT) 포트 고갈에 도달할 수 있습니다.
해결 방법 1:
Azure VM에서 실행하는 경우 SNAT 포트 고갈 가이드를 따르세요.
해결 방법 2:
Azure 앱 Service에서 실행하는 경우 연결 오류 문제 해결 가이드에 따라 App Service 진단 사용합니다.
해결 방법 3:
Azure Functions에서 실행하는 경우 관련된 모든 서비스(Azure Cosmos DB 포함)에 대한 단일 또는 정적 클라이언트를 기본의 Azure Functions 권장 사항을 따르고 있는지 확인합니다. 함수 앱 호스팅의 유형 및 크기에 따라 서비스 제한을 확인합니다.
솔루션 4:
HTTP 프록시를 사용하는 경우 SDK GatewayConnectionConfig에 구성된 연결 수를 지원할 수 있는지 확인합니다. 그렇지 않으면 연결 문제가 발생합니다.
여러 클라이언트 인스턴스 만들기
여러 클라이언트 인스턴스를 만들면 연결 경합 및 시간 제한 문제가 발생할 수 있습니다.
해결 방법 1:
성능 팁을 따르고 전체 애플리케이션에서 단일 CosmosClient 인스턴스를 사용합니다.
해결 방법 2:
싱글톤 CosmosClient를 애플리케이션에 포함할 수 없는 경우 CosmosClient에서 이 API connectionSharingAcrossClientsEnabled(true)를 통해 여러 Azure Cosmos DB 클라이언트 간에 연결 공유를 사용하는 것이 좋습니다.
동일한 JVM에 여러 Azure Cosmos DB 계정과 상호 작용하는 Azure Cosmos DB 클라이언트 인스턴스가 여러 개인 경우 Azure Cosmos DB 클라이언트 인스턴스 간에 직접 모드에서(가능하면) 연결 공유를 사용할 수 있습니다. 이 옵션을 설정할 때 첫 번째 인스턴스화된 클라이언트의 연결 구성(예: 소켓 시간 제한 구성, 유휴 시간 제한 구성)이 다른 모든 클라이언트 인스턴스에 사용됩니다.
핫 파티션 키
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 Cosmos DB Java v4 SDK를 사용하는 경우 문제를 진단하고 해결 합니다.
- Java v4의 성능 지침에 대해 알아봅니다.