Editar atributos do grupo de destino para o Application Load Balancer

Depois de criar um grupo de destino para o Application Load Balancer, você pode editar os atributos do grupo de destino dele.

Atraso do cancelamento do registro

O Elastic Load Balancing interrompe o envio de solicitações aos destinos cujo registro esteja sendo cancelado. Por padrão, o Elastic Load Balancing aguarda 300 segundos antes de concluir o processo de cancelamento do registro, o que pode ajudar na conclusão das solicitações em trânsito para o destino. Para alterar o tempo que o Elastic Load Balancing aguarda, atualize o valor de atraso de cancelamento de registro. .

O estado inicial de um destino que terá o registro cancelado é draining. Depois de decorrido o retardo de cancelamento do registro, processo será concluído e o estado do destino será unused. Se o destino for parte de um grupo do Auto Scaling, ele poderá ser encerrado e substituído.

Se um destino cujo registro esteja sendo cancelado não tiver solicitações em trânsito nem conexões ativas, o Elastic Load Balancing concluirá imediatamente o processo de cancelamento de registro, sem aguardar o término do tempo de espera. No entanto, mesmo que o cancelamento do registro de destino seja concluído, o status do destino será exibido como draining até que o tempo limite de atraso do cancelamento do registro termine. Depois que o tempo limite expirar, o destino passará para um estado unused.

Se cancelar o registro de um destino encerrar a conexão antes de o retardo de cancelamento do registro passar, o cliente receberá uma resposta de erro de nível 500.

Para atualizar o valor de atraso de cancelamento do registro usando a AWS CLI

Use o comando modify-target-group-attributes com o atributo deregistration_delay.timeout_seconds.

Modo de iniciação lenta

Por padrão, um destino começa a receber toda sua parte de solicitações assim que for registrado com um grupo de destino e enviar uma verificação de integridade inicial. Usar o modo de iniciação lenta oferece tempo para que os destinos aqueçam antes que o load balancer envie toda a parte de solicitações.

Com a iniciação lenta habilitada para um grupo de destino, os destinos entrarão no modo de iniciação lenta quando forem considerados íntegros pelo grupo de destino. Um destino sai do modo de iniciação lenta quando a duração da iniciação lenta configurada expira ou o destino se torna não íntegro. O load balancer aumenta linearmente o número de solicitações enviadas a um destino no modo de iniciação lenta. Assim que um destino íntegro deixa o modo de iniciação lenta, o balanceador de carga pode enviar uma parcela total de solicitações para esse destino.

Para atualizar o valor de duração da iniciação lenta usando a AWS CLI

Use o comando modify-target-group-attributes com o atributo slow_start.duration_seconds.

Balanceamento de carga entre zonas para grupos de destino do Application Load Balancer

Os nós do load balancer distribuem solicitações de clientes para destinos registrados. Quando o balanceamento de carga entre zonas estiver ativado, cada nó do balanceador de carga distribuirá o tráfego aos destinos registrados em todas as zonas de disponibilidade registradas. Quando o balanceamento de carga entre zonas estiver desativado, cada nó do balanceador de carga distribuirá o tráfego somente para os destinos registrados na respectiva zona de disponibilidade. Isso poderá ser usado se os domínios de falha de zona tiverem preferência em relação aos regionais, garantindo que uma zona íntegra não seja afetada por uma zona não íntegra ou para melhorias gerais na latência.

Com os Application Load Balancers, o balanceamento de carga entre zonas sempre está ativado por balanceador de carga e não pode ser desativado. Para grupos de destino, o padrão é usar a configuração do balanceador de carga, mas você pode substituir o padrão ativando ou desativando explicitamente o balanceamento de carga entre zonas em nível de grupo de destino.

Desativar o balanceamento de carga entre zonas

Você pode desativar o balanceamento de carga entre zonas para seus grupos de destino do Application Load Balancer a qualquer momento.

Para desativar o balanceamento de carga entre zonas usando a AWS CLI

Use o comando modify-target-group-attributes e defina o atributo load_balancing.cross_zone.enabled como false.

aws elbv2 modify-target-group-attributes --target-group-arn my-targetgroup-arn --attributes Key=load_balancing.cross_zone.enabled,Value=false

Esta é uma resposta de exemplo:

{
    "Attributes": [
        {
            "Key": "load_balancing.cross_zone.enabled",
            "Value": "false"
        },
    ]
}

Ativar o balanceamento de carga entre zonas

Você pode ativar o balanceamento de carga entre zonas para seus grupos de destino do Application Load Balancer a qualquer momento. A configuração de balanceamento de carga entre zonas por grupo de destino substitui a configuração por balanceador de carga.

Para ativar o balanceamento de carga entre zonas usando a AWS CLI

Use o comando modify-target-group-attributes e defina o atributo load_balancing.cross_zone.enabled como true.

aws elbv2 modify-target-group-attributes --target-group-arn my-targetgroup-arn --attributes Key=load_balancing.cross_zone.enabled,Value=true

Esta é uma resposta de exemplo:

{
    "Attributes": [
        {
            "Key": "load_balancing.cross_zone.enabled",
            "Value": "true"
        },
    ]
}

Ponderações de destinos automáticos (ATW)

As ponderações de destinos automáticos (ATW) monitoram constantemente os destinos que executam suas aplicações, detectando desvios significativos de desempenho, conhecidos como anomalias. As ATW fornecem a capacidade de ajustar dinamicamente a quantidade de tráfego roteado para os destinos, por meio da detecção de anomalias de dados em tempo real.

As ponderações de destinos automáticos (ATW) realizam automaticamente a detecção de anomalias em cada Application Load Balancer da conta. Quando destinos anômalos são identificados, as ATW podem tentar estabilizá-los automaticamente reduzindo a quantidade de tráfego que roteiam, o que é conhecido como mitigação de anomalias. As ATW otimizam continuamente a distribuição de tráfego para maximizar as taxas de êxito por destino e, ao mesmo tempo, minimizar as taxas de falha do grupo de destino.

Detecção de anomalias

As ATW monitoram a detecção de anomalias de qualquer destino que esteja exibindo um desvio significativo no comportamento de outros destinos no grupo de destino. Esses desvios, chamados de anomalias, são determinados comparando os erros percentuais de um destino com os erros percentuais de outros destinos no grupo de destino. Esses erros podem ser tanto erros de conexão quanto códigos de erro HTTP. Destinos que relatam significativamente mais do que seus pares são então considerados anômalos.

A detecção de anomalias requer um mínimo de três destinos íntegros no grupo de destino. Quando um destino é registrado em um grupo de destino, ele precisa primeiro passar pelas verificações de integridade para começar a receber tráfego. Quando o destino está recebendo o destino, as ATW começam a monitorar o destino e publicam continuamente o resultado da anomalia. Em destinos sem anomalias, o resultado da anomalia é normal. Em destinos com anomalias, o resultado da anomalia é anomalous.

A detecção de anomalias das ATW funciona independentemente das verificações de integridade do grupo de destino. Um destino pode passar por todas as verificações de integridade do grupo de destino, mas ainda assim ser marcado como anômalo devido a uma taxa de erro elevada. Destinos que se tornam anômalos não afetam o status da verificação de integridade do grupo de destino.

Status de detecção de anomalia

As ATW publicam continuamente o status das detecções de anomalias que realiza nos destinos. Você pode exibir o status atual a qualquer momento usando o AWS Management Console ou a AWS CLI.

Para exibir os resultados da detecção de anomalias usando a AWS CLI

Use o comando describe-target-health com o valor do atributo Include.member.N definido como AnomalyDetection.

Mitigação de anomalias

A mitigação de anomalias das ATW direciona o tráfego para longe de destinos anômalos automaticamente, dando a eles a oportunidade de se recuperarem.

Ativar a mitigação de anomalias das ATW

É possível ativar a mitigação de anomalias a qualquer momento.

Para ativar a mitigação de anomalias usando a AWS CLI

Use o comando modify-target-group-attributes com o atributo load_balancing.algorithm.anomaly_mitigation.

Status de mitigação de anomalias

Sempre que as ATW estiverem realizando a mitigação em um destino, você pode exibir o status atual a qualquer momento usando o AWS Management Console ou a AWS CLI.

Para exibir o status de mitigação de anomalias usando a AWS CLI

Use o comando describe-target-health com o valor do atributo Include.member.N definido como AnomalyDetection.

Sessões persistentes para seu Application Load Balancer

Por padrão, um Application Load Balancer roteia cada solicitação de modo independente para um destino registrado com base no algoritmo de balanceamento de carga escolhido. No entanto, você pode usar o recurso sessão persistente (também conhecido como afinidade de sessão) para habilitar o balanceador de carga a vincular 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 para fornecer uma experiência contínua aos clientes. Para usar sessões persistentes, o cliente deve ser compatível com cookies.

Os Application Load Balancers são compatíveis a cookies baseados em duração e cookies baseados em aplicação. As sessões persistentes são habilitadas por grupo de destino. Você pode usar uma combinação de persistência baseada em duração, persistência baseada em aplicação e ausência de persistência em seus grupos de destino.

O segredo para o gerenciamento de sessões persistentes é determinar por quanto tempo o balanceador de carga 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ê poderá usar a persistência baseada em aplicação, de forma que o cookie da sessão do balanceador de carga acompanhe a duração especificada pelo cookie de sessão da aplicação. Se sua aplicação não tiver seu próprio cookie de sessão, você poderá usar a persistência baseada na duração para gerar um cookie de sessão do balanceador de carga com uma duração que você especificar.

O conteúdo desses cookies gerados pelo balanceador de carga é criptografado usando uma chave alternante. Você não pode descriptografar nem modificar cookies gerados pelo balanceador de carga.

Para os dois tipos de persistência, o Application Load Balancer redefine a expiração dos cookies que ele gera após cada solicitação. Se um cookie expirar, a sessão não continuará persistente e o cliente deverá remover o cookie de seu repositório de cookies.

Persistência com base em duração

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

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

Nas solicitações subsequentes, o cliente deverá incluir o cookie AWSALB. Quando o balanceador de carga receber uma solicitação de um cliente contendo o cookie, ele a detectará e encaminhará 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.

Para solicitações de compartilhamento de recursos de origem cruzada (CORS), alguns navegadores exigem SameSite=None; Secure para habilitar a persistência. Para oferecer suporte a esses navegadores, o balanceador de carga sempre gera um segundo cookie de persistência, AWSALBCORS, que inclui as mesmas informações do cookie de persistência original, além do atributo SameSite. Os clientes recebem os dois cookies, incluindo solicitações não relacionadas ao CORS.

Para habilitar a persistência com base em duração usando a AWS CLI

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

Use o comando a seguir para habilitar a persistência com base em duração.

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 exemplo a seguir.

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

Persistência com base em aplicação

A persistência baseada em aplicação oferece a flexibilidade de definir seus próprios critérios de persistência entre cliente e destino. Quando você ativa a persistência baseada em aplicação, o balanceador de carga encaminha 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 personalizado de aplicação que corresponda ao cookie configurado no balanceador de carga para viabilizar a persistência. Esse cookie personalizado pode incluir qualquer um dos atributos de cookie exigidos pela aplicação.

Quando o Application Load Balancer receber o cookie personalizado de aplicação do destino, ele gerará automaticamente um novo cookie criptografado de aplicação para capturar informações de persistência. Esse cookie de aplicação gerado pelo balanceador de carga captura informações de persistência para cada grupo de destino que esteja com a persistência baseada em aplicações habilitada.

O cookie de aplicação gerado pelo balanceador de carga não copia os atributos do cookie personalizado definido pelo destino. Ele tem seu próprio prazo de validade de 7 dias, que não é configurável. Na resposta ao cliente, o Application Load Balancer valida somente o nome com o qual o cookie personalizado foi configurado no grupo de destino e não o valor ou o atributo de expiração do cookie personalizado. Desde que o nome corresponda, o balanceador de carga enviará os dois cookies, o cookie personalizado definido pelo destino e o cookie de aplicação gerado pelo balanceador de carga, em resposta ao cliente.

Nas solicitações subsequentes, os clientes precisarão devolver os dois cookies para manter a persistência. O balanceador de carga descriptografa o cookie de aplicação e verifica se a duração configurada da persistência ainda é válida. Em seguida, ele usa as informações do cookie para enviar a solicitação para o mesmo destino dentro do grupo de destino a fim de manter a persistência. O balanceador de carga também transfere o cookie personalizado de aplicação para o destino sem inspecioná-lo ou modificá-lo. Nas respostas subsequentes, a expiração do cookie de aplicação gerado pelo balanceador de carga e a duração da persistência configurada no balanceador de carga serão redefinidas. Para manter a persistência entre o cliente e o destino, a expiração do cookie e a duração da persistência não devem expirar.

Se um destino falhar ou deixar de ser íntegro, o balanceador de carga interromperá as solicitações de roteamento para esse destino e escolherá um novo destino íntegro com base no algoritmo de balanceamento de carga escolhido. O balanceador de carga trata a sessão como “aderida” ao novo destino íntegro e continua a rotear solicitações para o novo destino íntegro, mesmo que o destino com falha retorne.

Com solicitações de compartilhamento de recursos de origem cruzada (CORS), para habilitar a persistência, o balanceador de carga só adiciona os atributos SameSite=None; Secure ao cookie de aplicação gerado pelo balanceador de carga se a versão de agente do usuário for Chromium80 ou superior.

Como a maioria dos navegadores limita os cookies a 4 K, o balanceador de carga fragmenta cookies de aplicação com tamanho superior a 4 K em vários cookies. Os Application Load Balancers são compatíveis com cookies de até 16 K e, portanto, podem criar até 4 fragmentos que enviam ao cliente. O nome do cookie de aplicação que o cliente vê começa com “AWSALBAPP-” e inclui um número de fragmento. Por exemplo, se o tamanho do cookie for de 0 a 4 K, o cliente verá AWSALBAPP-0. Se o tamanho do cookie for de 4 a 8 K, o cliente verá AWSALBAPP-0 e AWSALBAPP-1 e assim por diante.

Para habilitar a persistência baseada em aplicação usando a AWS CLI

Use o comando modify-target-group-attributes com os seguintes atributos:

Use o comando a seguir para habilitar a persistência com base em aplicação.

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 exemplo a seguir.

 
       {
            "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 verticalmente, se o número de destinos aumentar consideravelmente, há potencial para uma distribuição desigual da carga devido à persistência. Nesse cenário, você poderá reequilibrar a carga em seus destinos usando as duas opções a seguir: