Visão geral

Os serviços do AWS Edge são componentes importantes para a criação de aplicações Web com alta disponibilidade. Além de sua alta disponibilidade nativa, graças à sua natureza distribuída, os serviços de borda da AWS atuam como ponto de entrada para aplicações Web e podem rotear solicitações para partições disponíveis em sua infraestrutura de origem (por exemplo, zona de disponibilidade ou região).

Decisões arquitetônicas

Um aplicação Web de alta disponibilidade pode ser arquitetada de várias maneiras, com base em seus requisitos em termos de disponibilidade, SLO, custo e complexidade. No mínimo, você precisa tomar as seguintes decisões técnicas com base nos seus requisitos de negócios:

  • Você tem uma arquitetura ativa/ativa ou ativa/passiva?
  • Você tem origens diferentes? AZs diferentes? Regiões diferentes?
  • Qual é a lógica de roteamento entre as origens para a arquitetura ativa/ativa? Quais são os critérios de failover para a arquitetura ativa/passiva?

Gerenciar erros de origem transitória

O CloudFront pode ajudar você a mitigar o impacto de erros 5xx transitórios que podem ocasionalmente prejudicar um pequeno número de solicitações de usuários. Geralmente, isso se deve a uma origem sobrecarregada por picos repentinos de tráfego ou problemas transitórios de rede. Você pode mitigar erros 5xx transitórios com o CloudFront de diferentes maneiras.

Tentar novamente. O CloudFront pode ser configurado para repetir a conexão TCP até três vezes com um tempo limite de conexão configurável quando uma conexão não pode ser estabelecida com a origem. O CloudFront também repete o GET/HEAD idempotente de acordo com o número configurado de novas tentativas.

Responder com conteúdo obsoleto. Se as novas tentativas falharem com a origem, o CloudFront, por padrão, exibirá uma versão obsoleta do objeto, se disponível no cache, em vez de retornar uma resposta de erro. Esse comportamento pode ser desabilitado usando a diretiva Cache-Control: stale-if-error=0.

Origin Failover para origem secundária. Você pode configurar o CloudFront para falhar em uma origem secundária para a solicitação específica que falhou usando a funcionalidade Origin Failover. O Origin Failover só se aplica a solicitações GET/HEAD idempotentes. Observe que, se você usar o Lambda@Edge em eventos de origem, o CloudFront também executará a função no failover. Nesse cenário, você pode inferir na função Lambda@Edge se a solicitação era de origem primária ou secundária para diferenciar sua lógica. Para fazer isso, configure o mesmo Cabeçalho personalizado de origem nas duas origens, mas com valores diferentes que o Lambda@Edge possa ler.

Failover elegante. Se o Origin Failover para outra origem não for desejável (por exemplo, manter outra infraestrutura de origem), considere fazer o failover para um arquivo estático hospedado em um local diferente (por exemplo, bucket do S3) usando a Página de erro personalizada. Por padrão, a mesma página é usada para todas as solicitações que resultam em erros. No entanto, você cria uma resposta mais dinâmica seguindo o terceiro padrão deste blog.

Failover com reconhecimento de estado durante interrupções de origem

Failover com base na política do Route 53

Você pode usar a política de roteamento de failover do Route 53 com verificações de integridade no nome de domínio de origem que está configurado como a origem no CloudFront. Quando a origem primária deixa de ser íntegra, o Route 53 a detecta e começa a resolver o nome do domínio de origem com o endereço IP da origem secundária. O CloudFront respeita o TTL do DNS de origem, o que significa que o tráfego começará a fluir para a origem secundária dentro do TTL do DNS. A configuração mais ideal (Verificação rápida ativada, um limite de failover de 1 e TTL de DNS de 60 segundos) significa que o failover levará no mínimo 70 segundos para ocorrer. Quando isso acontece, todo o tráfego é transferido à origem secundária, pois é um failover com reconhecimento de estado. Observe que esse design pode ser ampliado ainda mais com o Route 53 Application Recovery Control para um failover de aplicações mais sofisticado em várias regiões da AWS, zonas de disponibilidade e on-premises. Essa abordagem pode ser combinada com a funcionalidade Origin Failover do CloudFront para solicitações GET/HEAD para reduzir erros enquanto o Route 53 faz o failover para a origem secundária. Esse padrão é descrito neste blog.

Quando as diferentes origens não compartilham o mesmo nome de domínio, como nas origens baseadas no S3, o Route 53 não pode ser usado da maneira proposta acima. Nesse cenário, você precisa de uma função do Lambda@Edge configurada no evento em solicitação de origem para consultar a Rota 53 qual origem selecionar e, em seguida, redirecionar a solicitação para a origem selecionada, alterando o nome do domínio de origem e com o cabeçalho Host. Para saber mais sobre essa implementação, leia o seguinte Estudo de caso da Contentful.

Failover com o Global Accelerator

As aplicações que estão usando o Global Accelerator podem se beneficiar de suas funcionalidades nativas de failover. Usando o Global Accelerator, sua aplicação pode ser implantada em uma única região da AWS em várias zonas de disponibilidade ou em várias regiões da AWS. O Global Accelerator monitora a integridade dos endpoints das suas aplicações usando verificações de integridade e direciona o tráfego para longe de endpoints não íntegros em dezenas de segundos.

Arquiteturas ativas/ativas

Roteamento baseado em latência

O CloudFront pode ser usado com a política baseada em latência do Route 53 para rotear solicitações de usuários para a região mais próxima da AWS, na qual você tem origem replicada em uma arquitetura multirregional ativa/ativa. Para fazer isso, configure o nome do domínio de origem no CloudFront com a política baseada em latência no Route 53. Quando o CloudFront resolve o nome de domínio de origem para se conectar e enviar a solicitação à origem, o Route 53 retorna o IP de origem mais próximo com base na latência. Observe que o local de onde o CloudFront resolve o nome de domínio de origem depende da configuração da distribuição e do tipo de tráfego. Em geral, o nome do domínio é resolvido no local da borda para solicitações dinâmicas e em caches de borda regionais para conteúdo armazenável em cache. Este blog orienta você em uma implantação multirregional ativa/ativa do API Gateway.

Quando as diferentes origens não compartilham o mesmo nome de domínio, como nas origens baseadas no S3, o Route 53 não pode ser usado da maneira proposta acima. Nesse cenário, você precisa de um Lambda@Edge configurado no evento em solicitação de origem para rotear até a origem mais próxima. Para saber mais sobre essa implementação, leia os seguintes blogs:

Roteamento avançado

Em certos cenários, o roteamento de solicitações exige lógica em nível de aplicação. Quando a lógica é simples, como rotear para origens diferentes com base no caminho (por exemplo, rotear /api1 para a origem 1 e /api2 para a origem 2), você pode simplesmente usar o recurso Comportamento de cache nativo do CloudFront. Se a lógica for mais sofisticada, o evento em solicitação de origem do Lambda@Edge permitirá rotear o tráfego com base em atributos de nível da aplicação, como URL, cookies, cabeçalhos, país etc. A lógica pode não ter reconhecimento de estado e ser totalmente incorporada ao código da função, ou pode ser armazenada em um local externo, como o S3 ou o DynamoDB, de onde o Lambda@Edge busca a regra de roteamento para executá-la.

Recursos

Esta página foi útil para você?

 Feedback