Modos de conectividade do SDK SQL do Azure Cosmos DB

  • Artigo

APLICA-SE A: NoSQL

A forma como um cliente se liga ao Azure Cosmos DB tem implicações de desempenho importantes, especialmente para a latência observada do lado do cliente. O Azure Cosmos DB oferece um modelo de programação RESTful simples e aberto através de HTTPS denominado modo de gateway. Além disso, oferece um protocolo TCP eficiente, que também é RESTful no seu modelo de comunicação e utiliza o TLS para autenticação inicial e encriptação de tráfego, denominado 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 do SDK. Se a sua aplicação for executada numa rede empresarial com restrições estritas de firewall, o modo de gateway é a melhor opção porque utiliza a porta HTTPS padrão e um único ponto final de DNS. O compromisso de desempenho, no entanto, é que o modo de gateway envolve um salto de rede adicional sempre que os dados são lidos ou escritos no Azure Cosmos DB. Também recomendamos o modo de ligação do gateway quando executar aplicações em ambientes com um número limitado de ligações de socket.

    Quando utiliza o SDK no Azure Functions, particularmente no plano Consumo, tenha em atenção os limites atuais das ligações.

  • Modo direto

    O modo direto suporta a conectividade através do protocolo TCP, utilizando o TLS para autenticação inicial e encriptação de tráfego, e oferece um melhor desempenho porque existem menos saltos de rede. A aplicação liga-se diretamente às réplicas de back-end. Atualmente, o modo direto só é suportado em plataformas .NET e Java SDK.

Os modos de conectividade do Azure Cosmos DB

Estes modos de conectividade condicionam essencialmente a rota que os pedidos do plano de dados - leituras e escritas de documentos - levam do computador cliente para as partições no back-end do Azure Cosmos DB. O modo direto é a opção preferencial para o melhor desempenho – permite ao cliente abrir ligações TCP diretamente para partições no back-end do Azure Cosmos DB e enviar pedidos diretamentesem intermediários. Por outro lado, no modo de Gateway, os pedidos feitos pelo cliente são encaminhados para um servidor chamado "Gateway" no front-end do Azure Cosmos DB, o que, por sua vez, elimina os pedidos para as partições adequadas no back-end do Azure Cosmos DB.

Intervalos de portas de serviço

Quando utiliza o modo direto, tem de garantir que o cliente pode aceder a portas entre 10000 e 20000, porque o Azure Cosmos DB utiliza portas TCP dinâmicas. Isto para além das portas do gateway. Ao utilizar o modo direto em pontos finais privados, o intervalo completo de portas TCP – de 0 a 65535 pode ser utilizado 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 seguinte mostra um resumo dos modos de conectividade disponíveis para várias APIs e as portas de serviço utilizadas 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), Grafo (443)
Direct TCP (Encriptado através de TLS) SDK Java do SDK .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 ligação do modo direto

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

Encaminhamento

Quando um SDK do Azure Cosmos DB no modo Direto está a executar uma operação, tem de resolver a réplica de back-end à qual ligar. O primeiro passo é saber para que partição física a operação deve ir e, para isso, o SDK obtém as informações do contentor que incluem a definição da chave de partição a partir de um nó de Gateway. Também precisa das informações de encaminhamento que contêm os endereços TCP das réplicas. As informações de encaminhamento também estão disponíveis nos nós de Gateway e ambas são consideradas metadados do Plano de Controlo. Assim que o SDK obtiver as informações de encaminhamento, pode avançar para abrir as ligações TCP às 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 escrita são sempre encaminhadas para nós de réplica primária, enquanto as operações de leitura podem ser servidas a partir de nós primários ou secundários.

Diagrama que mostra como os S D Ks no modo direto obtêm o contentor e as informações de encaminhamento do Gateway antes de abrir as ligações T C P para os nós de back-end

Uma vez que as informações de contentor e encaminhamento não mudam frequentemente, são colocadas em cache localmente nos SDKs para que as operações subsequentes possam beneficiar destas informações. As ligações TCP já estabelecidas também são reutilizadas em todas as operações. Salvo indicação em contrário, através das opções de SDKs, as ligações são mantidas permanentemente durante a duração da instância do SDK.

Tal como acontece com qualquer arquitetura distribuída, as máquinas que contêm réplicas podem ser submetidas a atualizações ou manutenção. O serviço irá garantir que o conjunto de réplicas mantém a consistência, mas qualquer movimento de réplica faria com que os endereços TCP existentes fossem alterados. Nestes casos, os SDKs têm de atualizar as informações de encaminhamento e voltar a ligar aos novos endereços através de novos pedidos de Gateway. Estes eventos não devem afetar o SLA P99 global.

Volume de ligações

Cada partição física tem um conjunto de réplicas de quatro réplicas, para proporcionar o melhor desempenho possível, os SDKs acabarão por abrir ligações a todas as réplicas para cargas de trabalho que misturam operações de escrita e leitura. As operações simultâneas são balanceadas de carga em todas as ligações existentes para tirar partido do débito fornecido por cada réplica.

Existem dois fatores que ditam o número de ligações TCP que o SDK irá abrir:

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

    Num estado estável, o SDK terá uma ligação por réplica por partição física. Quanto maior for o número de partições físicas num contentor, maior será o número de ligações abertas. À medida que as operações são encaminhadas entre diferentes partições, as ligações são estabelecidas a pedido. Em seguida, o número médio de ligações seria o número de partições físicas vezes quatro.

  • Volume de pedidos simultâneos

    Cada ligação estabelecida pode servir um número configurável de operações simultâneas. Se o volume de operações simultâneas exceder este limiar, serão abertas novas ligações para as servir e é possível que, para uma partição física, o número de ligações abertas exceda o número de estado estável. Este comportamento é esperado para cargas de trabalho que podem ter picos no volume operacional. Para o SDK .NET, esta configuração é definida por CosmosClientOptions.MaxRequestsPerTcpConnection e, para o SDK Java, pode personalizar com DirectConnectionConfig.setMaxRequestsPerConnection.

Por predefinição, as ligações são mantidas permanentemente para beneficiar o desempenho de operações futuras (abrir uma ligação tem sobrecarga computacional). Pode haver alguns cenários em que poderá querer fechar ligações que não são utilizadas durante algum tempo, compreendendo que isso pode afetar ligeiramente as operações futuras. Para o SDK .NET, esta configuração é definida por CosmosClientOptions.IdleTcpConnectionTimeout e, para o SDK Java, pode personalizar com DirectConnectionConfig.setIdleConnectionTimeout. Não é recomendado definir estas configurações para valores baixos, pois pode fazer com que as ligações sejam frequentemente fechadas e afetem o desempenho geral.

Detalhes de implementação específicos do idioma

Para obter mais detalhes de implementação sobre um idioma, veja:

Passos seguintes

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