Rede
Por dentro da rede de borda da Adios: entrada, computação e failover
Quatorze locais de borda atuais levam requisições à rede Adios. Veja o que acontece ali e o que continua acontecendo em uma região de computação.
Um nó de borda encurta o caminho público até a Adios. Isso não significa que todos os processos de aplicação e bancos de dados executem naquela mesma cidade.
Onde uma requisição entra
A Adios atualmente lista locais de borda em Londres, Paris, Amsterdã, Madri, Frankfurt, Los Angeles, Miami, Nova Jersey, São Paulo, Tóquio, Singapura, Vale do Silício, Mumbai e Chicago. O roteamento Anycast permite que esses locais anunciem os mesmos endereços públicos, para que o roteamento da internet leve uma requisição a um nó de borda.
Nesse ponto, o gateway trata o TLS e consulta a rota do nome de host e caminho solicitados. A rota identifica a aplicação, a versão e a política de tráfego que devem receber a requisição.
Borda e computação resolvem problemas diferentes
Um local de borda é o ponto de entrada. Uma região de computação é onde a réplica da carga de trabalho executa. Separar essas funções permite receber tráfego perto do usuário e ainda selecionar uma réplica saudável conforme a política de localização e failover da aplicação.
Essa distinção importa ao ler o mapa da rede. Um marcador verde de borda significa que a Adios pode receber e rotear tráfego naquele local. Não promete que todos os tipos de carga de trabalho ou serviços gerenciados de dados possam ser instalados naquela região metropolitana.
- —Local de borda: recebe tráfego público, termina a conexão TLS e resolve rotas.
- —Região de computação: executa réplicas da aplicação e aplica os limites de recursos da carga de trabalho.
- —Região de dados: mantém o estado perto da aplicação e pode ter restrições de localização mais rigorosas.
- —Política de rota: determina qual réplica saudável deve receber uma requisição.
Expandir as partes úteis do mapa
Dallas, Oslo, Sydney, Hong Kong, Phoenix, Cidade do México, Tel Aviv, Dubai, Dublin, Honolulu, Auckland, Kathmandu e Istambul estão no planejamento de expansão da borda. Continuam marcados como planejados até realmente receberem tráfego, e seus códigos metropolitanos definitivos serão definidos após a seleção dos locais.
O objetivo não é acumular pontos no mapa. Cada local precisa de roteamento, TLS, verificações de saúde, conectividade privada, observabilidade e um caminho seguro de retirada quando deve parar de atender tráfego. O ciclo automático de retirada BGP baseado em saúde ainda está em homologação; uma sessão BGP configurada, sozinha, não o comprova. Uma rede menor que corresponda à realidade é mais útil do que um mapa maior feito de promessas.
- —Anuncie e retire a rota Anycast sem deixar tráfego encaminhado a destinos obsoletos.
- —Verifique a emissão e a renovação de TLS e o estado compartilhado dos certificados.
- —Medir a acessibilidade a cada região de computação elegível.
- —Confirme que gateways não saudáveis deixam a rotação antes que os usuários vejam falhas repetidas.
O que acontece quando um nó de borda não está saudável
Uma falha de borda deve reduzir a capacidade, não criar uma nova forma de falha da aplicação. O controle previsto interrompe os anúncios quando um gateway não consegue servir as rotas com segurança e deixa o roteamento da internet levar novas conexões a outro nó disponível. A retirada automática baseada em saúde ainda não é um controle beta concluído.
O teste de homologação é de ponta a ponta: retire um nó de borda em staging, confirme a mudança de tráfego, verifique se o nó substituto ainda alcança a carga de trabalho correta e restaure o local sem causar oscilação de rotas. Um processo saudável não basta se o caminho privado ou o estado das rotas estiver obsoleto.