Modos de conectividade do SDK do SQL do Azure Cosmos DB

  • Artigo

APLICA-SE A: NoSQL

Como um cliente se conecta ao Azure Cosmos DB tem implicações importantes sobre o desempenho, especialmente em termos da latência observada do lado do cliente. O Cosmos DB oferece um modelo de programação RESTful simples e aberto por meio do modo de gateway chamado HTTPS. Além disso, ele oferece um protocolo TCP eficiente, que também é RESTful em seu modelo de comunicação e usa TLS para autenticação inicial e criptografia de tráfego, chamado de modo direto.

Modos de conectividade disponíveis

Os dois modos de conectividade disponíveis são:

  • Modo Gateway

    O modo Gateway é compatível com todas as plataformas SDK. Se seu aplicativo for executado em uma rede corporativa com restrições de firewall rígidas, o modo Gateway será a melhor opção, já que ele usa a porta HTTPS padrão e um único ponto de extremidade DNS. Porém, a compensação do desempenho é que o Modo gateway envolve um salto de rede adicional sempre que os dados são lidos ou gravados no Azure Cosmos DB. Também recomendamos o modo de conexão de gateway quando você executa aplicativos em ambientes que têm um número limitado de conexões de soquete.

    Ao usar o SDK no Azure Functions, especialmente no Plano de consumo, esteja ciente dos atuais limites de conexões.

  • Modo direto

    O modo direto dá suporte à conectividade por meio do protocolo TCP, usando TLS para autenticação inicial e criptografia de tráfego, e oferece melhor desempenho porque há menos saltos de rede. O aplicativo se conecta diretamente às réplicas de back-end. Atualmente, o modo direto só tem suporte em plataformas .NET e SDK Java.

Os modos de conectividade do Azure Cosmos DB

Essencialmente, esses modos de conectividade condicionam a rota que as solicitações de plano de dados – leituras e gravações de documentos – levam da máquina cliente para partições no back-end do Azure Cosmos DB. O modo direto é a opção preferencial para o melhor desempenho: ele permite que o cliente abra conexões TCP diretamente em partições no back-end do Azure Cosmos DB e envie solicitações diretamente sem intermediário. Por outro lado, no modo de gateway, as solicitações feitas pelo cliente são encaminhadas para um servidor chamado de "gateway" no front-end do Azure Cosmos DB, que, por sua vez, encaminha suas solicitações para as partições apropriadas no back-end do Azure Cosmos DB.

Intervalos de portas de origem

Ao usar o modo direto, você precisa garantir que o cliente possa acessar portas que variam entre 10000 e 20000, pois o Azure Cosmos DB usa portas TCP dinâmicas. Isso é adicional às portas do gateway. Ao usar o modo direto em pontos de extremidade privados, o intervalo completo de portas TCP, de 0 a 65535, pode ser usado pelo Azure Cosmos DB. Se essas portas não estiverem abertas no cliente e você tentar usar o protocolo TCP, você poderá receber um erro 503 Serviço indisponível.

A tabela a seguir mostra um resumo dos modos de conectividade disponíveis para várias APIs e as portas de serviço usadas para cada API:

Modo da conexão Protocolo com Suporte SDKs com suporte Porta/serviço de API
Gateway HTTPS Todos os SDKs SQL (443), MongoDB (10255), Table (443), Cassandra (10350), Graph (443)
Direto TCP (criptografado via TLS) SDK Java do SDK .NET Ao usar pontos de extremidade de serviço/público: portas no intervalo de 10000 a 20000
Ao usar pontos de extremidade privados: portas no intervalo de 0 a 65535

Arquitetura de conexão de modo direto

Conforme detalhado na introdução, os clientes do modo Direto se conectarão diretamente aos nós de back-end por meio do protocolo TCP. Cada nó de back-end representa uma réplica em um conjunto de réplicas pertencente a uma partição física.

Roteamento

Quando um SDK do Azure Cosmos DB no modo Direto está executando uma operação, ele precisa resolver a réplica de back-end à qual se conectar. A primeira etapa é saber para qual partição física a operação deve ir e, para isso, o SDK obtém as informações de contêiner que incluem a definição de chave de partição de um nó do Gateway. Ele também precisa das informações de roteamento que contêm os endereços TCP das réplicas. As informações de roteamento também estão disponíveis nos nós do Gateway e ambas são consideradas metadados do Painel de Controle. Depois que o SDK obter as informações de roteamento, ele poderá continuar a abrir as conexões TCP para as réplicas que pertencem à partição física de destino e executar as operações.

Cada conjunto de réplicas contém uma réplica primária e três secundárias. As operações de gravação são sempre roteadas para nós de réplica primária, enquanto as operações de leitura podem ser atendidas de nós primários ou secundários.

Diagrama que mostra como os SDKs no modo direto buscam informações de roteamento e contêiner do Gateway antes de abrir as conexões TCP com os nós de back-end

Como as informações de contêiner e roteamento não mudam com frequência, elas são armazenadas em cache localmente nos SDKs para que as operações subsequentes possam se beneficiar dessas informações. As conexões TCP já estabelecidas também são reutilizadas em operações. A menos que sejam configuradas de outra forma por meio das opções de SDKs, as conexões são mantidas permanentemente durante o tempo de vida da instância do SDK.

Assim como acontece com qualquer arquitetura distribuída, os computadores que contêm réplicas podem passar por atualizações ou manutenção. O serviço garantirá que o conjunto de réplicas mantenha a consistência, mas qualquer movimento de réplica fará com que os endereços TCP existentes sejam alterados. Nesses casos, os SDKs precisam atualizar as informações de roteamento e se conectar novamente aos novos endereços por meio de novas solicitações do Gateway. Esses eventos não devem afetar o SLA P99 geral.

Volume de conexões

Cada partição física tem um conjunto de réplicas de quatro réplicas. A fim de fornecer o melhor desempenho possível, os SDKs acabarão abrindo conexões para todas as réplicas para cargas de trabalho que misturam operações de gravação e leitura. As operações simultâneas são balanceadas por carga em conexões existentes para aproveitar a taxa de transferência que cada réplica fornece.

Há dois fatores que determinam o número de conexões TCP que o SDK abrirá:

  • Número de partições físicas

    Em um estado estável, o SDK terá uma conexão por réplica por partição física. Quanto maior o número de partições físicas em um contêiner, maior será o número de conexões abertas. À medida que as operações são roteadas em diferentes partições, as conexões são estabelecidas sob demanda. O número médio de conexões seria então o número de partições físicas vezes quatro.

  • Volume de solicitações simultâneas

    Cada conexão estabelecida pode atender a um número configurável de operações simultâneas. Se o volume de operações simultâneas exceder esse limite, novas conexões serão abertas para atendê-las e é possível que, para uma partição física, o número de conexões abertas exceda o número de estado estável. Esse comportamento é esperado para cargas de trabalho que podem ter picos em seu volume operacional. Para o SDK do .NET, essa configuração é definida por CosmosClientOptions.MaxRequestsPerTcpConnection e, para o SDK do Java, você pode personalizar usando DirectConnectionConfig.setMaxRequestsPerConnection.

Por padrão, as conexões são mantidas permanentemente para beneficiar o desempenho de operações futuras (abrir uma conexão tem sobrecarga computacional). Pode haver alguns cenários em que talvez você queira fechar conexões que não são usadas por algum tempo entendendo que isso pode afetar ligeiramente as operações futuras. Para o SDK do .NET, essa configuração é definida por CosmosClientOptions.IdleTcpConnectionTimeout e, para o SDK do Java, você pode personalizar usando DirectConnectionConfig.setIdleConnectionTimeout. Não é recomendável definir essas configurações como valores baixos, pois isso pode fazer com que as conexões sejam fechadas com frequência e afetem o desempenho geral.

Detalhes de implementação específicos da linguagem

Para obter mais detalhes de implementação sobre uma linguagem, consulte:

Próximas etapas

Para otimizações de desempenho da plataforma SDK específica: