Azure Cosmos DB SQL SDK 연결 모드

  • 아티클

적용 대상: NoSQL

클라이언트가 Azure Cosmos DB에 연결하는 방법은 특히 관찰되는 클라이언트 쪽 대기 시간 측면에서 성능에 중요한 영향을 미칩니다. Azure Cosmos DB는 HTTPS를 통해 게이트웨이 모드라고 하는 단순한 개방형 RESTful 프로그래밍 모델을 제공합니다. 또한 통신 모델에서 REST를 지원하기도 하며 초기 인증 및 암호화 트래픽에 직접 모드라고도 하는 TLS를 사용하는 효율적인 TCP 프로토콜을 제공합니다.

사용 가능한 연결 모드

사용 가능한 두 연결 모드는 다음과 같습니다.

  • 게이트웨이 모드

    게이트웨이 모드는 모든 SDK 플랫폼에서 지원됩니다. 애플리케이션이 엄격한 방화벽으로 제한된 회사 네트워크 내에서 실행되는 경우 표준 HTTPS 포트 및 단일 DNS 엔드포인트를 사용하므로 게이트웨이 모드를 선택하는 것이 가장 좋습니다. 그러나 게이트웨이 모드의 경우 성능 유지를 위해 Azure Cosmos DB에서 데이터를 읽거나 쓸 때마다 네트워크 홉이 추가됩니다. 또한 소켓 연결 수가 제한된 환경에서 애플리케이션을 실행할 때 게이트웨이 연결 모드를 권장합니다.

    특히 소비 플랜에서 Azure Functions SDK를 사용하는 경우 연결에 대한 현재 제한 사항을 알고 있어야 합니다.

  • 직접 모드

    직접 모드는 TCP 프로토콜을 통한 연결을 지원하고, 초기 인증을 위해 TLS를 사용하고, 트래픽을 암호화하며, 네트워크 홉 수가 적기 때문에 더 나은 성능을 제공합니다. 애플리케이션은 백 엔드 복제본에 직접 연결됩니다. 직접 모드는 현재 .NET 및 Java SDK 플랫폼에서만 지원됩니다.

The Azure Cosmos DB connectivity modes

이러한 연결 모드는 기본적으로 데이터 플레인 요청(문서 읽기 및 쓰기)을 클라이언트 머신에서 Azure Cosmos DB 백 엔드의 파티션으로 가져오는 조건을 경로에 지정합니다. 직접 모드는 최상의 성능을 위한 기본 설정 옵션입니다. 즉 이를 통해 클라이언트는 Azure Cosmos DB 백 엔드에서 직접 파티션에 대한 TCP 연결을 열고 중간자 없이 요청을 직접 보낼 수 있습니다. 반대로 게이트웨이 모드에서는 클라이언트의 요청이 Azure Cosmos DB 프런트 엔드의 "게이트웨이" 서버로 라우팅된 다음, Azure Cosmos DB 백 엔드에서 적절한 파티션으로 전달됩니다.

서비스 포트 범위

직접 모드를 사용하는 경우 Azure Cosmos DB는 동적 TCP 포트를 사용하기 때문에 클라이언트가 10000에서 20000 사이의 포트에 액세스할 수 있는지 확인해야 합니다. 게이트웨이 포트에 추가됩니다. 프라이빗 엔드포인트에서 직접 모드를 사용하는 경우 TCP 포트의 전체 범위(0-65535)가 Azure Cosmos DB에서 사용될 수 있습니다. 이러한 포트가 클라이언트에서 열려 있지 않은 상태에서 TCP 프로토콜을 사용하려고 하면 503 서비스를 사용할 수 없음 오류가 발생할 수 있습니다.

다음 표에서는 각 API에 사용되는 다양한 API 및 서비스 포트에 사용할 수 있는 연결 모드를 요약해서 설명합니다.

연결 모드 지원되는 프로토콜 지원되는 SDK API/서비스 포트
게이트웨이 HTTPS 모든 SDK SQL(443), MongoDB(10255), Table(443), Cassandra(10350), Graph(443)
Direct TCP(TLS를 통해 암호화됨) .NET SDK Java SDK 퍼블릭/서비스 엔드포인트를 사용하는 경우: 10000-20000 범위의 포트
프라이빗 엔드포인트를 사용하는 경우: 0-65535 범위의 포트

직접 모드 연결 아키텍처

소개에 자세히 설명된 것처럼 직접 모드 클라이언트는 TCP 프로토콜을 통해 백 엔드 노드에 직접 연결합니다. 각 백 엔드 노드는 물리적 파티션에 속하는 복제본 세트의 복제본을 나타냅니다.

라우팅

직접 모드에서 Azure Cosmos DB SDK가 작업을 수행하는 경우 연결할 백 엔드 복제본을 확인해야 합니다. 첫 번째 단계는 작업이 이동해야 하는 물리적 파티션을 파악하는 것이며, 이를 위해 SDK는 게이트웨이 노드에서 파티션 키 정의를 포함하는 컨테이너 정보를 가져옵니다. 또한 복제본의 TCP 주소를 포함하는 라우팅 정보도 필요합니다. 라우팅 정보는 게이트웨이 노드에서도 사용할 수 있으며 둘 다 컨트롤 플레인 메타데이터로 간주됩니다. SDK가 라우팅 정보를 가져오면 대상 물리적 파티션에 속한 복제본에 대한 TCP 연결을 열고 작업을 실행할 수 있습니다.

각 복제본 세트에는 주 복제본 1개와 보조 복제본 3개가 포함됩니다. 쓰기 작업은 항상 주 복제본 노드로 라우팅되지만 읽기 작업은 주 노드 또는 보조 노드에서 제공될 수 있습니다.

Diagram that shows how S D Ks in direct mode fetch the container and routing information from Gateway before opening the T C P connections to the backend nodes

컨테이너 및 라우팅 정보는 자주 변경되지 않으므로 후속 작업에서 이 정보를 활용할 수 있도록 SDK에 로컬로 캐시됩니다. 이미 설정된 TCP 연결도 작업 간에 재사용됩니다. SDK 옵션을 통해 달리 구성하지 않는 한 SDK 인스턴스의 수명 동안 연결이 영구적으로 유지됩니다.

분산 아키텍처와 마찬가지로 복제본을 보유하는 머신은 업그레이드 또는 유지 관리를 수행할 수 있습니다. 이 서비스는 복제본 집합이 일관성을 유지하도록 보장하지만 복제본이 이동하면 기존 TCP 주소가 변경됩니다. 이러한 경우 SDK는 라우팅 정보를 새로 고치고 새 게이트웨이 요청을 통해 새 주소에 다시 연결해야 합니다. 이러한 이벤트는 전체 P99 SLA에 영향을 미치지 않아야 합니다.

연결 볼륨

각 물리적 파티션에는 4개의 복제본으로 구성된 복제본 세트가 있으며, 최상의 성능을 제공하기 위해 SDK는 쓰기 및 읽기 작업을 혼합하는 워크로드에 대해 모든 복제본에 대한 연결을 열게 됩니다. 동시 작업은 각 복제본이 제공하는 처리량을 활용하기 위해 기존 연결 간에 부하가 분산됩니다.

SDK가 여는 TCP 연결 수를 결정하는 두 가지 요소가 있습니다.

  • 물리적 파티션 수

    안정적인 상태에서 SDK는 물리적 파티션당 복제본당 하나의 연결을 갖습니다. 컨테이너의 물리적 파티션 수가 많을수록 열린 연결 수가 많아집니다. 작업이 여러 파티션 간에 라우팅되면 요청 시 연결이 설정됩니다. 그러면 평균 연결 수는 물리적 파티션의 4배가 됩니다.

  • 동시 요청 볼륨

    설정된 각 연결은 구성 가능한 수의 동시 작업을 제공할 수 있습니다. 동시 작업의 볼륨이 이 임계값을 초과하면 새 연결이 이를 제공하기 위해 열리고 실제 파티션의 경우 열린 연결 수가 안정적인 상태 수를 초과할 수 있습니다. 이 동작은 운영 볼륨이 급증할 수 있는 워크로드에 대해 예상됩니다. .NET SDK의 경우 이 구성은 CosmosClientOptions.MaxRequestsPerTcpConnection에 의해 설정되고 Java SDK의 경우 DirectConnectionConfig.setMaxRequestsPerConnection을 사용하여 사용자 지정할 수 있습니다.

기본적으로 연결은 향후 작업의 성능에 도움이 되도록 영구적으로 유지 관리됩니다(연결을 열면 계산 오버헤드가 있음). 향후 작업에 약간 영향을 줄 수 있다는 점을 이해하기 위해 한동안 사용되지 않는 연결을 닫을 수 있는 몇 가지 시나리오가 있을 수 있습니다. .NET SDK의 경우 이 구성은 CosmosClientOptions.IdleTcpConnectionTimeout에 의해 설정되고 Java SDK의 경우 DirectConnectionConfig.setIdleConnectionTimeout을 사용하여 사용자 지정할 수 있습니다. 연결이 자주 닫혀 전반적인 성능에 영향을 줄 수 있으므로 이러한 구성을 낮은 값으로 설정하지 않는 것이 좋습니다.

언어별 구현 세부 정보

언어에 대한 자세한 구현 정보는 다음을 참조하세요.

다음 단계

특정 SDK 플랫폼 성능 최적화: