As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Otimize as conexões do driver do cliente para o ambiente sem servidor
Para se comunicar com o Amazon Keyspaces, você pode usar qualquer um dos drivers de cliente Apache Cassandra existentes de sua escolha. Como o Amazon Keyspaces é um serviço de tecnologia sem servidor, recomendamos que você otimize a configuração de conexão do driver de cliente de acordo com as necessidades de throughput do seu aplicativo. Este tópico apresenta as práticas recomendadas, incluindo como calcular quantas conexões seu aplicativo requer, bem como monitoramento e tratamento de erros de conexões.
Tópicos
Como as conexões funcionam no Amazon Keyspaces
Esta seção fornece uma visão geral de como as conexões de driver de clientes funcionam no Amazon Keyspaces. Como a configuração incorreta do driver de cliente Cassandra pode resultar em eventos de PerConnectionRequestExceeded no Amazon Keyspaces, é necessário configurar a quantidade certa de conexões na configuração do driver de cliente para evitar esses e outros erros de conexão semelhantes.
Ao se conectar ao Amazon Keyspaces, o driver precisa de um endpoint inicial para estabelecer uma conexão inicial. O Amazon Keyspaces usa DNS para rotear a conexão inicial para um dos muitos endpoints disponíveis. Os endpoints são conectados a Network Load Balancers que, por sua vez, estabelecem uma conexão com um dos manipuladores de solicitações na frota. Depois que a conexão inicial é estabelecida, o driver de cliente coleta informações sobre todos os endpoints disponíveis na tabela system.peers. Com essas informações, o driver de cliente pode criar conexões adicionais com os endpoints listados. O número de conexões que o driver de cliente pode criar é limitado pelo número de conexões locais especificadas nas configurações do driver de cliente. Por padrão, a maioria dos drivers de clientes estabelece uma conexão por endpoint e estabelece um pool de conexões com o Cassandra e balanceia a carga de consultas sobre esse pool de conexões. Embora várias conexões possam ser estabelecidas no mesmo endpoint, por trás do Network Load Balancer elas podem estar conectadas a vários manipuladores de solicitações diferentes. Ao se conectar por meio do endpoint público, estabelecer uma conexão com cada um dos nove endpoints listados na tabela system.peers resulta em nove conexões com diferentes manipuladores de solicitações.
Como configurar conexões no Amazon Keyspaces
O Amazon Keyspaces suporta até 3.000 CQL consultas por conexão por segundoTCP. Como não há limite no número de conexões que um driver pode estabelecer, recomendamos direcionar apenas 500 CQL solicitações por segundo por conexão para permitir sobrecarga, picos de tráfego e melhor balanceamento de carga. Siga estas etapas para garantir que a conexão do driver esteja configurada corretamente para as necessidades do seu aplicativo.
Aumente o número de conexões por endereço IP que seu driver mantém em seu pool de conexões.
-
A maioria dos drivers do Cassandra estabelece um pool de conexão com o Cassandra e balanceia a carga das consultas sobre esse pool de conexões. O comportamento padrão da maioria dos drivers é estabelecer uma única conexão com cada endpoint. O Amazon Keyspaces expõe nove endereços IP de mesmo nível aos drivers. Portanto, com base no comportamento padrão da maioria dos drivers, isso resulta em 9 conexões. O Amazon Keyspaces suporta até 3.000 CQL consultas por TCP conexão por segundo, portanto, a taxa de transferência máxima de consultas de um driver usando as configurações padrão é de 27.000 CQL consultas por segundo. CQL Se você usar as configurações padrão do driver, uma única conexão pode precisar processar mais do que a taxa de transferência máxima CQL de 3.000 CQL consultas por segundo. Isso pode resultar em eventos
PerConnectionRequestExceeded. Para evitar eventos
PerConnectionRequestExceeded, você deve configurar o driver para criar conexões adicionais por endpoint para distribuir o throughput.Como melhor prática no Amazon Keyspaces, suponha que cada conexão possa suportar 500 CQL consultas por segundo.
Isso significa que, para um aplicativo de produção que precisa suportar cerca de 27.000 CQL consultas por segundo distribuídas pelos nove endpoints disponíveis, você deve configurar seis conexões por endpoint. Isso garante que cada conexão processe no máximo 500 solicitações por segundo.
Calcule o número de conexões por endereço IP que você precisa configurar para seu driver com base nas necessidades do seu aplicativo.
Para saber o número de conexões que você precisa configurar por endpoint para seu aplicativo, considere o exemplo a seguir. Você tem um aplicativo que precisa oferecer suporte a 20.000 CQL consultas por segundo, consistindo em 10.000 INSERTSELECT, 5.000 e 5.000 DELETE operações. O aplicativo Java está sendo executado em três instâncias no Amazon Elastic Container Service (AmazonECS), onde cada instância estabelece uma única sessão no Amazon Keyspaces. O cálculo que você pode usar para estimar quantas conexões você precisa configurar para seu driver usa a seguinte entrada.
O número de solicitações por segundo que seu aplicativo precisa oferecer suporte.
O número de instâncias disponíveis com uma subtraída para contabilizar manutenção ou falha.
O número de endpoints disponíveis. Se você estiver se conectando por meio de endpoints públicos, você tem nove endpoints disponíveis. Se você estiver usando VPC endpoints, terá entre dois e cinco endpoints disponíveis, dependendo da região.
Use 500 CQL consultas por segundo por conexão como uma prática recomendada para o Amazon Keyspaces.
Arredonde o resultado.
Neste exemplo, a fórmula tem a seguinte aparência.
20,000 CQL queries / (3 instances - 1 failure) / 9 public endpoints / 500 CQL queries per second = ROUND(2.22) = 3
Com base nesse cálculo, você precisa especificar três conexões locais por endpoint na configuração do driver. Para conexões remotas, configure somente uma conexão por endpoint.
Como configurar conexões em VPC endpoints no Amazon Keyspaces
Ao se conectar por meio de VPC endpoints privados, você provavelmente tem 3 endpoints disponíveis. O número de VPC endpoints pode ser diferente por região, com base no número de zonas de disponibilidade e no número de sub-redes atribuídas. VPC A região Leste dos EUA (Norte da Virgínia) tem cinco zonas de disponibilidade, e você pode ter até cinco endpoints do Amazon Keyspaces. A região Oeste dos EUA (Norte da Califórnia) tem duas zonas de disponibilidade, e você pode ter até dois endpoints do Amazon Keyspaces. O número de endpoints não afeta a escala, mas aumenta o número de conexões que você precisa estabelecer na configuração do driver. Considere o seguinte exemplo. Seu aplicativo precisa suportar 20.000 CQL consultas e está sendo executado em três instâncias na Amazon, ECS onde cada instância estabelece uma única sessão no Amazon Keyspaces. A única diferença é quantos endpoints estão disponíveis nos diferentes Regiões da AWS.
Conexões necessárias na região Leste dos EUA (Norte da Virgínia):
20,000 CQL queries / (3 instances - 1 failure) / 5 private VPC endpoints / 500 CQL queries per second = 4 local connections
Conexões necessárias na região Oeste dos EUA (Norte da Califórnia):
20,000 CQL queries / (3 instances - 1 failure) / 2 private VPC endpoints / 500 CQL queries per second = 10 local connections
Importante
Ao usar VPC endpoints privados, são necessárias permissões adicionais para que o Amazon Keyspaces descubra dinamicamente os endpoints VPC disponíveis e preencha a tabela. system.peers Para obter mais informações, consulte Como preencher entradas da tabela system.peers com informações do endpoint da VPC de interface.
Ao acessar o Amazon Keyspaces por meio de um VPC endpoint privado usando outro Conta da AWS, é provável que você veja apenas um único endpoint do Amazon Keyspaces. Novamente, isso não afeta a escala da possível throughput para o Amazon Keyspaces, mas pode exigir que você aumente o número de conexões na configuração do driver. Este exemplo mostra o mesmo cálculo para um único endpoint disponível.
20,000 CQL queries / (3 instances - 1 failure) / 1 private VPC endpoints / 500 CQL queries per second = 20 local connections
Para saber mais sobre o acesso entre contas ao Amazon Keyspaces usando um VPC compartilhamento, consulte. Configurar o acesso entre contas usando VPC endpoints em uma VPC compartilhada
Como monitorar conexões no Amazon Keyspaces
Para ajudar a identificar o número de endpoints aos quais seu aplicativo está conectado, você pode registrar o número de pares descobertos na tabela system.peers. O exemplo a seguir é um exemplo de código Java que imprime o número de pares após o estabelecimento da conexão.
ResultSet result = session.execute(new SimpleStatement("SELECT * FROM system.peers")); logger.info("number of Amazon Keyspaces endpoints:" + result.all().stream().count());
nota
O CQL console ou AWS console não são implantados em um VPC e, portanto, usam o endpoint público. Como resultado, executar a system.peers consulta a partir de aplicativos localizados fora do VPCE geralmente resulta em 9 pares. Também pode ser útil imprimir os endereços IP de cada par.
Você também pode observar o número de pares ao usar um VPC endpoint configurando as métricas da VPCE Amazon CloudWatch . Em CloudWatch, você pode ver o número de conexões estabelecidas com o VPC endpoint. Os drivers do Cassandra estabelecem uma conexão para cada endpoint para enviar CQL consultas e uma conexão de controle para coletar informações da tabela do sistema. A imagem abaixo mostra as CloudWatch métricas do VPC endpoint após a conexão com o Amazon Keyspaces com 1 conexão configurada nas configurações do motorista. A métrica mostra seis conexões ativas que consistem em uma conexão de controle e cinco conexões (1 por endpoint nas zonas de disponibilidade).
Para começar a monitorar o número de conexões usando um CloudWatch gráfico, você pode implantar esse AWS CloudFormation modelo disponível GitHub no repositório de modelos do Amazon Keyspaces
Como lidar com erros de conexão no Amazon Keyspaces
Ao exceder a cota de 3.000 solicitações por conexão, o Amazon Keyspaces retorna um evento PerConnectionRequestExceeded e o driver do Cassandra recebe uma exceção WriteTimeout ou ReadTimeout. Você deve repetir essa exceção com um recuo exponencial em sua política de repetição do Cassandra ou em seu aplicativo. Você deve fornecer um recuo exponencial para evitar o envio de solicitações adicionais.
A política de repetição padrão tenta o try next host no plano de consulta. Como o Amazon Keyspaces pode ter de um a três endpoints disponíveis ao se conectar ao VPC endpoint, você também pode ver o acréscimo WriteTimeout e as ReadTimeout exceções NoHostAvailableException nos registros do seu aplicativo. Você pode usar as políticas de repetição fornecidas pelo Amazon Keyspaces, que tentam novamente no mesmo endpoint, mas em conexões diferentes.
Você pode encontrar exemplos de políticas de repetição exponencial para Java GitHub no repositório de exemplos de código Java do Amazon Keyspaces
