Modos de conectividade do SDK do SQL do Azure Cosmos DB

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

  O modo de gateway tem suporte em todas as plataformas do SDK. Se o aplicativo for executado em uma rede corporativa com restrições estritas de firewall, o modo de gateway será a melhor opção porque 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 extra 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, lembre-se dos limites atuais 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. No momento, o modo direto só tem suporte em plataformas SDK .NET e Java.

Esses modos de conectividade condicionam essencialmente a rota que as solicitações do plano de dados (leituras e gravações de documento) levam do computador cliente para partições no back-end do Azure Cosmos DB. O modo direto é a opção preferencial para melhor desempenho; permite que seu cliente abra conexões TCP diretamente para partições no back-end do Azure Cosmos DB e envie solicitações diretassem intermediário. Por outro lado, no modo de gateway, as solicitações feitas pelo 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 as partições apropriadas no back-end do Azure Cosmos DB.

Intervalos de porta de serviço

Ao usar o modo direto, você precisa garantir que seu 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 Azure Cosmos DB pode usar a gama completa de portas TCP de 0 a 65535. Se essas portas não estiverem abertas em seu cliente e você tentar usar 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:

Arquitetura de conexão de modo direto

Conforme detalhado na introdução, os clientes de modo direto se conectam 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 que pertence a uma partição física.

Routing

Quando um SDK do Azure Cosmos DB no modo direto executa 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ó 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 em nós de entrada e são igualmente consideradas 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 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ários. 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.

Como as informações de contêiner e roteamento não são alteradas 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 entre as operações. A menos que 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 garante que o conjunto de réplicas mantenha a consistência, mas qualquer movimentação 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 reconectar-se aos novos endereços por meio de novas solicitações de 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, para fornecer o melhor desempenho possível, os SDKs acabam 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 abre:

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

  Em um estado estável, o SDK tem 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 o número de conexões abertas. À medida que as operações são roteadas entre partições diferentes, 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 estarã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 MaxRequestsPerTcpConnection e, para o SDK do Java, você pode personalizar usando a classe DirectConnectionConfig.

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 IdleTcpConnectionTimeout e, para o SDK do Java, você pode personalizar usando a Classe DirectConnectionConfig. 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 do idioma

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

• Informações de implementação do SDK do .NET
• Informações do modo direto do SDK do Java

Próximas etapas

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

• Dicas de desempenho do SDK do .NET V2
• Dicas de desempenho do SDK do .NET V3
• Dicas de desempenho do SDK do Java V4

Tentando fazer um planejamento de capacidade para uma migração para o Microsoft Azure Cosmos DB? Você pode usar informações sobre o seu cluster de banco de dados existente para planejamento de capacidade.

• Se tudo o que você sabe é o número de vcores e servidores em seu cluster de banco de dados existente, leia sobre como estimar unidades de solicitação usando vCores ou vCPUs.
• Caso saiba as taxas de solicitação típicas da carga de trabalho do banco de dados atual, leia sobre como estimar unidades de solicitação com o planejador de capacidade do Azure Cosmos DB.