Partilhar via

Modos de conectividade SQL SDK do Azure Cosmos DB

  • Artigo

APLICA-SE A: NoSQL

A forma como um cliente se conecta ao Azure Cosmos DB tem implicações importantes de desempenho, especialmente para a latência observada do lado do cliente. O Azure Cosmos DB oferece um modelo de programação RESTful simples e aberto sobre HTTPS chamado modo gateway. Além disso, 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 de gateway

    O modo de gateway é suportado em todas as plataformas SDK. Se seu aplicativo é executado em uma rede corporativa com restrições rígidas de firewall, o modo gateway é a melhor escolha, pois usa a porta HTTPS padrão e um único ponto de extremidade DNS. A compensação de desempenho, no entanto, é que o modo de 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, particularmente no plano de Consumo, esteja ciente dos limites atuais de conexões.

  • Modo direto

    O modo direto suporta conectividade através do protocolo TCP, usando TLS para autenticação inicial e criptografando 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ó é suportado nas plataformas .NET e Java SDK.

Os modos de conectividade do Azure Cosmos DB

Esses modos de conectividade essencialmente condicionam a rota que as solicitações do 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 preferida para o melhor desempenho - ele permite que seu cliente abra conexões TCP diretamente para partições no back-end do Azure Cosmos DB e envie solicitações diretamentesem intermediários. Por outro lado, no modo Gateway, as solicitações feitas pelo seu cliente são roteadas para um chamado servidor "Gateway" no front-end do Azure Cosmos DB, que, por sua vez, distribui suas solicitações para a(s) partição(ões) apropriada(s) no back-end do Azure Cosmos DB.

Intervalos de portas de serviço

Ao usar o modo direto, você precisa garantir que seu cliente possa acessar portas que variam entre 10000 e 20000 porque o Azure Cosmos DB usa portas TCP dinâmicas. Isso se soma às portas de gateway. Ao usar o modo direto em pontos de extremidade privados, a gama completa de portas TCP - de 0 a 65535 pode ser usada pelo Azure Cosmos DB. Se estas portas não estiverem abertas no cliente e tentar utilizar o protocolo TCP, 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 de ligação Protocolo suportado SDKs suportados Porta do Serviço/API
Gateway HTTPS Todos os SDKs SQL (443), MongoDB (10255), Tabela (443), Cassandra (10350), Gráfico (443)
Direct TCP (Criptografado via TLS) SDK Java SDK do .NET Quando utilizar pontos finais públicos/de serviço: portas no intervalo 10 000 a 20 000
Quando utilizar pontos finais privados: portas no intervalo 0 a 65 535

Arquitetura de conexão de modo direto

Conforme detalhado na introdução, os clientes de 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.

Encaminhamento

Quando um SDK do Azure Cosmos DB no modo Direto está executando uma operação, ele precisa resolver a qual réplica de back-end 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ó de 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 ambos são considerados metadados do Plano de Controle. Depois que o SDK obtém as informações de roteamento, ele pode continuar a abrir as conexões TCP para as réplicas pertencentes à 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ários, enquanto as operações de leitura podem ser atendidas a partir de nós primários ou secundários.

Diagrama que mostra como S D Ks no modo direto buscar o contêiner e as informações de roteamento do Gateway antes de abrir as conexões T C P para os nós de back-end

Como o contêiner e as informações de 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 todas as operações. A menos que configurado de outra forma através das opções SDKs, as conexões são mantidas permanentemente durante o tempo de vida da instância do SDK.

Como em qualquer arquitetura distribuída, as máquinas 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 faria com que os endereços TCP existentes fossem alterados. Nesses casos, os SDKs precisam atualizar as informações de roteamento e se reconectar aos novos endereços por meio de novas solicitações de Gateway. Esses eventos não devem afetar o SLA P99 global.

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 com 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 de carga entre conexões existentes para aproveitar a taxa de transferência fornecida por cada réplica.

Há dois fatores que ditam 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 servir 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 estacionário. 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 você pode querer 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 para valores baixos, pois isso pode fazer com que as conexões sejam fechadas com frequência e afetar o desempenho geral.

Detalhes da implementação específica do idioma

Para mais detalhes sobre a implementação de uma língua, consulte:

Próximos passos

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