Sessões sticky para seu Application Load Balancer - Elastic Load Balancing

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á.

Sessões sticky para seu Application Load Balancer

Por padrão, um Application Load Balancer roteia cada solicitação de forma independente para um destino registrado com base no algoritmo de balanceamento de carga escolhido. No entanto, você pode usar o recurso sticky session (também conhecida como afinidade de sessão) para permitir que o load balancer vincule a sessão de um usuário a um destino específico. Isso garante que todas as solicitações do usuário durante a sessão sejam enviadas para o mesmo destino. Esse recurso é útil para servidores que mantêm as informações de estado em ordem para fornecer uma experiência contínua aos clientes. Para usar sticky sessions, o cliente deve oferecer suporte a cookies.

Os Application Load Balancers suportam cookies baseados em duração e cookies baseados em aplicativos. As sessões perduráveis são habilitadas no nível do grupo de destino. Você pode usar uma combinação de viscosidade baseada em duração, viscosidade baseada em aplicativos e nenhuma aderência em seus grupos-alvo.

O segredo para o gerenciamento de sticky sessions é determinar por quanto tempo o load balancer deve rotear consistentemente a solicitação do usuário para o mesmo destino. Se sua aplicação tiver seu próprio cookie de sessão, você pode usar a persistência baseada em aplicativos e o cookie de sessão do load balancer acompanhará a duração especificada pelo cookie de sessão do aplicativo. Se sua aplicação não tiver seu próprio cookie de sessão, você pode usar a aderência baseada em duração para gerar um cookie de sessão do load balancer com uma duração especificada.

O conteúdo dos cookies gerados pelo load balancer é criptografado usando uma chave giratória. Não é possível descriptografar nem modificar cookies gerados do load balancer.

Para ambos os tipos de aderência, o Application Load Balancer redefine a expiração dos cookies gerados após cada solicitação. Se um cookie expirar, a sessão não será mais sticky e o cliente deverá remover o cookie do armazenamento de cookies.

Requisitos

  • Um load balancer HTTP/HTTPS.

  • Pelo menos uma instância íntegra em cada Zona de disponibilidade.

Considerações

  • Para cookies baseados em aplicativos, os nomes de cookies precisam ser especificados individualmente para cada grupo-alvo. No entanto, para cookies baseados em duração,AWSALBé o único nome usado em todos os grupos-alvo.

  • Se você estiver usando várias camadas de Application Load Balancers, poderá habilitar sticky sessions em todas as camadas com cookies baseados em aplicativos. No entanto, com cookies baseados em duração, você pode ativar sessões adesivas somente em uma camada, porqueAWSALBé o único nome disponível.

  • A aderência baseada em aplicativos não funciona com grupos-alvo ponderados.

  • Se você tiver umAção para frenteCom vários grupos de destino, e sticky sessions estiverem habilitadas para um ou mais grupos de destino, você deve habilitar a perdurabilidade no nível do grupo de destino.

  • As conexões WebSocket são inerentemente perduráveis. Se o cliente solicitar uma atualização de conexão para WebSockets, o destino que retornará o código de status HTTP 101 para aceitar o upgrade da conexão será o destino usado na conexão do WebSockets. Depois do WebSockets A atualização está completa, a perdurabilidade baseada em cookies não é usada.

  • Application Load Balancers usam aExpiresNo cabeçalho do cookie em vez doMax-AgeAttribute.

  • Os balanceadores de carga do aplicativo não oferecem suporte a valores de cookie codificados por URL.

Persistência baseada na duração

A aderência baseada em duração roteia solicitações para o mesmo destino em um grupo de destino usando um cookie gerado por load balancer (AWSALB). O cookie é usado para mapear a sessão para o destino. Se seu aplicativo não tiver seu próprio cookie de sessão, você pode especificar sua própria duração de persistência e gerenciar por quanto tempo seu load balancer deve rotear consistentemente a solicitação do usuário para o mesmo destino.

Quando um load balancer recebe uma solicitação de um cliente pela primeira vez, ele roteia a solicitação para um destino (com base no algoritmo escolhido) e gera um cookie chamadoAWSALB. Ele codifica informações sobre o destino selecionado, criptografa o cookie e o inclui na resposta para o cliente. O cookie gerado pelo balanceador de carga tem sua própria expiração de 7 dias, o que não é configurável.

Em solicitações subsequentes, o cliente deve incluir oAWSALBCookie. Quando o load balancer receber uma solicitação de um cliente contendo o cookie, ele o detectará e roteará a solicitação para o mesmo destino. Se o cookie estiver presente, mas não puder ser decodificado, ou se ele se referir a um destino que foi cancelado ou não está íntegro, o load balancer selecionará um novo destino e atualizará o cookie com informações sobre o novo destino.

Com solicitações de compartilhamento de recursos de origem cruzada (CORS), alguns navegadores exigemSameSite=None; Securepara permitir a aderência. Nesse caso, o balanceador de carga gera um segundo cookie de aderência,AWSALBCORS, que inclui as mesmas informações que o cookie de perdurabilidade original, além doSameSiteAttribute. Os clientes recebem ambos os cookies.

Para habilitar a perdurabilidade usando o console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, emBalanceamento de carga, escolhaGrupos de destino.

  3. Escolha o nome do grupo de destino para abrir sua página details.

  4. No“Detalhes do grupoguia, na guiaAtributos.seção, selecioneEdite.

  5. Na página Editar atributos, faça o seguinte:

    1. SelectStickiness.

    2. para oTipo de pertensão, selecioneCookie gerado pelo load balancer.

    3. Em Duração da perdurabilidade, especifique um valor entre um segundo e sete dias.

    4. Escolha Save changes (Salvar alterações).

Para habilitar a perdurabilidade usando aAWS CLI

Use o comando modify-target-group-attributes com os atributos stickiness.enabled e stickiness.lb_cookie.duration_seconds.

Use o seguinte comando para habilitar a perdurabilidade.

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.lb_cookie.duration_seconds,Value=time-in-seconds

Sua saída deve ser similar ao seguinte exemplo.

{ "Attributes": [ ... { "Key": "stickiness.enabled", "Value": "true" }, { "Key": "stickiness.lb_cookie.duration_seconds", "Value": "86500" }, ... ] }

Persistência baseada no aplicativo

A aderência baseada em aplicativos oferece a flexibilidade de definir seus próprios critérios para a aderência do alvo do cliente. Quando você habilita a aderência baseada em aplicativos, o balanceador de carga roteia a primeira solicitação para um destino dentro do grupo de destino com base no algoritmo escolhido. Espera-se que o destino defina um cookie de aplicativo personalizado que corresponda ao cookie configurado no balanceador de carga para permitir a aderência. Este cookie personalizado pode incluir qualquer um dos atributos de cookie exigidos pelo aplicativo.

Quando o Application Load Balancer recebe o cookie de aplicativo personalizado do destino, ele gera automaticamente um novo cookie de aplicativo criptografado para capturar informações de aderência. Esse cookie de aplicativo gerado por balanceador de carga captura informações de aderência para cada grupo-alvo que tem a aderência baseada em aplicativos ativada.

O cookie de aplicativo gerado pelo balanceador de carga não copia os atributos do cookie personalizado definido pelo destino. Tem seu próprio vencimento de 7 dias, o que não é configurável. Na resposta ao cliente, o Application Load Balancer valida apenas o nome com o qual o cookie personalizado foi configurado no nível do grupo de destino e não o valor ou o atributo de expiração do cookie personalizado. Contanto que o nome corresponda, o balanceador de carga envia ambos os cookies, o cookie personalizado definido pelo destino e o cookie do aplicativo gerado pelo balanceador de carga, na resposta ao cliente.

Em solicitações subsequentes, os clientes precisam enviar os dois cookies de volta para manter a aderência. O balanceador de carga descriptografa o cookie do aplicativo e verifica se a duração configurada da aderência ainda é válida. Em seguida, ele usa as informações no cookie para enviar a solicitação para o mesmo destino dentro do grupo de destino para manter a perdurabilidade. O balanceador de carga também faz o proxy do cookie de aplicativo personalizado para o destino sem inspecioná-lo ou modificá-lo. Nas respostas subsequentes, a expiração do cookie de aplicativo gerado pelo balanceador de carga e a duração da aderência configurada no balanceador de carga são redefinidas. Para manter a aderência entre o cliente e o alvo, a expiração do cookie e a duração da viscosidade não devem decorrer.

Se um destino falhar ou ficar não ficar íntegra, o load balancer interromperá as solicitações para esse destino e escolherá um novo destino íntegro com base no algoritmo de balanceamento de carga escolhido. O load balancer trata a sessão agora como sendo “presa” ao novo destino íntegro e continua a rotear solicitações para o novo destino íntegro mesmo que o destino falhado volte.

Com solicitações CORS (cross-origin resource sharing, compartilhamento de recursos de origem cruzada), para habilitar aSameSite=None; Secureatributos ao cookie de aplicativo gerado pelo balanceador de carga somente se a versão user-agent for Chromium80 ou superior.

Como a maioria dos navegadores limita cookies em tamanho 4K, o load balancer fragmenta os cookies do aplicativo maiores do que 4K em vários cookies. Os Application Load Balancers suportam cookies de até 16K de tamanho e, portanto, podem criar até 4 fragmentos enviados para o cliente. O nome do cookie do aplicativo que o cliente vê começa com “AWSALBAPP-” e inclui um número de fragmento. Por exemplo, se o tamanho do cookie for 0-4K, o cliente verá AWSALBAPP-0. Se o tamanho do cookie for 4-8k, o cliente verá AWSALBAPP-0 e AWSALBAPP-1, e assim por diante.

Para habilitar a perdurabilidade baseada na aplicação usando o console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, emBalanceamento de carga, escolhaGrupos de destino.

  3. Escolha o nome do grupo de destino para abrir sua página details.

  4. No“Detalhes do grupoguia, na guiaAtributos.seção, selecioneEdite.

  5. Na página Editar atributos, faça o seguinte:

    1. SelectStickiness.

    2. para oTipo de pertensão, selecioneCookie baseado no aplicativo.

    3. Em Duração da perdurabilidade, especifique um valor entre um segundo e sete dias.

    4. para oNome do cookie do aplicativo, insira um nome para seu cookie baseado na aplicação.

      Não useAWSALB,AWSALBAPP, ouAWSALBTGPara o nome do cookie; eles são reservados para uso pelo load balancer.

    5. Escolha Save changes (Salvar alterações).

Para habilitar a perdurabilidade baseada na aplicação usando aAWS CLI

Usar aModificar atributos do grupo-destinoComando com os seguintes atributos:

  • stickiness.enabled

  • stickiness.type

  • stickiness.app_cookie.cookie_name

  • stickiness.app_cookie.duration_seconds

Use o seguinte comando para habilitar a perdurabilidade baseada em aplicativos.

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.type,Value=app_cookie Key=stickiness.app_cookie.cookie_name,Value=my-cookie-name Key=stickiness.app_cookie.duration_seconds,Value=time-in-seconds

Sua saída deve ser similar ao seguinte exemplo.

{ "Attributes": [ ... { "Key": "stickiness.enabled", "Value": "true" }, { "Key": "stickiness.app_cookie.cookie_name", "Value": "MyCookie" }, { "Key": "stickiness.type", "Value": "app_cookie" }, { "Key": "stickiness.app_cookie.duration_seconds", "Value": "86500" }, ... ] }

Rebalanceamento manual

Ao aumentar a escala, se o número de alvos aumentar consideravelmente, há potencial para distribuição desigual da carga devido à aderência. Nesse cenário, você pode reequilibrar a carga em seus destinos usando as duas opções a seguir:

  • Defina uma expiração no cookie gerado pelo aplicativo que é anterior à data e hora atuais. Isso impedirá que os clientes enviem o cookie para o Application Load Balancer, que reiniciará o processo de estabelecer a aderência.

  • Defina uma duração muito curta na configuração de aderência baseada em aplicativos do balanceador de carga, por exemplo, 1 segundo. Isso força o Application Load Balancer a restabelecer a aderência mesmo que o cookie definido pelo destino não tenha expirado.