Muita tecnologia da Cloudflare está bem documentada. Por exemplo, como lidamos com o tráfego entre os "visitantes" (clientes) e nossos servidores, já foi discutido várias vezes neste blog: "A brief primer on anycast (2011)”, "Load Balancing without Load Balancers (2013)", "Path MTU discovery in practice (2015)", "Cloudflare's edge load balancer (2020)", "How we fixed the BSD socket API (2022)".
No entanto, raramente falamos sobre a segunda parte de nossa configuração de rede, como nossos servidores buscam o conteúdo da internet. Neste blog, vamos cobrir essa lacuna. Discutiremos como gerenciamos os endereços de IP da Cloudflare usados para recuperar os dados da internet, como nosso projeto de rede de saída evoluiu e como o otimizamos para melhor uso do espaço de IP disponível.
Prepare-se. Temos muito para ver.
Primeiro, terminologia.
Cada servidor da Cloudflare lida com muitos tipos de tráfego de rede, mas duas categorias mais próximas se destacam:
Tráfego de origem da internet – Conexões de entrada iniciadas pelo visitante para nossos servidores. No contexto deste post do blog, as chamaremos de "conexões de entrada".
Tráfego originado pela Cloudflare – Conexões de saída iniciadas por nossos servidores para outros hosts na internet. Para abreviar, as chamaremos de "conexões de saída".
A parte de saída, embora raramente discutida neste blog, é essencial para nossa operação. Nossos servidores devem iniciar conexões de saída para realizar seus trabalhos. Como:
Em nosso produto CDN, antes que o conteúdo seja armazenado em cache, ele é obtido dos servidores de origem. Consulte "Pingora, the proxy that connects Cloudflare to the Internet (2022)", Argo e Tiered Cache.
Para o produto Spectrum, cada conexão TCP de entrada resulta em uma conexão de saída.
O Workers geralmente executa várias subsolicitações para construir uma resposta HTTP. Ele pode estar consultando servidores na internet.
Também operamos produtos de proxy direto voltados para o cliente, como o WARP e o Cloudflare Gateway. Esses proxies lidam com conexões de visitantes destinadas à internet. Nossos servidores precisam estabelecer conexões com a internet em nome de nossos usuários.
E assim por diante.
Anycast na entrada, unicast na saída
Nossa arquitetura de rede de entrada é muito diferente da de saída. Na entrada, as conexões provenientes da internet são tratadas exclusivamente por nossas faixas de IP anycast. O anycast é uma tecnologia onde cada um dos nossos data centers "anuncia" e pode lidar com as mesmas faixas de IP. Com muitos destinos possíveis, como a internet sabe para onde rotear os pacotes? Bem, os pacotes dos visitantes são roteados para o data center mais próximo com base nas métricas de BGP da internet, geralmente também é o mais próximo geograficamente. Normalmente, as rotas BGP não mudam muito, e pode-se esperar que cada IP dos visitantes seja roteado para um único data center.
No entanto, embora o anycast funcione bem na direção de entrada, ele não pode operar na saída. Estabelecer uma conexão de saída de um IP anycast não vai funcionar. Considere o pacote de resposta. É provável que seja roteado de volta para um lugar errado, um data center geograficamente mais próximo do remetente, não necessariamente o data center de origem.
Por esta razão, até recentemente, estabelecíamos conexões de saída de forma direta e convencional: cada servidor recebia seu próprio endereço de IP unicast. "IP unicast" significa que há apenas um servidor usando esse endereço no mundo. Os pacotes de retorno vão funcionar bem e vão retornar exatamente ao servidor correto identificado pelo IP unicast.
Segmentação de tráfego com base no IP de saída
No início, as conexões originadas pela Cloudflare eram principalmente buscas de HTTP indo para os servidores de origem na internet. À medida que nossa linha de produtos crescia, também crescia a variedade de tráfego. O exemplo mais notável é nosso aplicativo WARP. No WARP, nossos servidores operam um proxy de encaminhamento e lidam com o tráfego originado por dispositivos de usuários finais. Isto é realizado sem o mesmo grau de intermediação do nosso produto CDN. Isso cria um problema. Servidores de terceiros na internet, como os servidores de origem, devem ser capazes de distinguir entre conexões provenientes de serviços da Cloudflare e nossos usuários de WARP. Essa segmentação de tráfego é tradicionalmente feita usando diferentes intervalos de IP para diferentes tipos de tráfego (embora recentemente tenhamos introduzido técnicas mais robustas como Authenticated Origin Pulls).
Para contornar o problema de diferenciação do pool de tráfego confiável versus não confiável, adicionamos um endereço de IP WARP não confiável a cada um de nossos servidores:
Endereços IP de saída com tags por país
Rapidamente ficou claro que confiável versus não confiável não eram as únicas tags necessárias. Para o serviço WARP, também precisamos de tags por país. Por exemplo, os usuários WARP baseados no Reino Unido esperam que o site bbc.com simplesmente funcione. No entanto, a BBC restringe muitos de seus serviços a pessoas que estejam apenas no Reino Unido.
Ela faz isso por geofencing, usando um banco de dados que mapeia endereços de IP públicos para países e permite apenas os do Reino Unido. O geofencing está difundido na internet atual. Para evitar problemas de geofencing, precisamos escolher endereços de saída específicos marcados com um país apropriado, dependendo da localização do usuário WARP. Como muitas outras partes na internet, marcamos nosso espaço de IP de saída com códigos de país e o publicamos como um geofeed (como este). Observe que o geofeed publicado é apenas dados. O fato de um IP ser marcado como Reino Unido não significa que seja distribuído do Reino Unido, apenas significa que a operadora deseja que ele seja geolocalizado no Reino Unido. Como muitas coisas na internet, é baseado na confiança.
Observe que, neste ponto, temos três tags geográficas independentes:
a tag do país do usuário WARP – o IP de conexão do visitante
a localização do data center ao qual o visitante está conectado
a tag do país do IP de saída
Para um melhor serviço, queremos escolher o IP de saída para que sua tag de país corresponda ao país do IP do visitante. Mas a saída de um IP com tag de um país específico é um desafio: nossos data centers atendem usuários de todo o mundo, possivelmente de muitos países. Lembre-se: devido ao anycast, não controlamos diretamente o roteamento de entrada. A geografia da internet nem sempre corresponde à geografia física. Por exemplo, nosso data center em Londres recebe tráfego não apenas de usuários do Reino Unido, mas também da Irlanda e da Arábia Saudita. Como resultado, nossos servidores em Londres precisam de muitos endereços de saída WARP associados a muitos países:
Você pode ver onde isso vai dar? O tamanho do problema fica enorme. Em vez de ter um ou dois endereços de IP de saída para cada servidor, agora precisamos de dezenas, e os endereços IPv4 não são baratos. Com esse projeto, precisamos de muitos endereços por servidor e operamos milhares de servidores. Essa arquitetura fica muito cara.
O anycast é um problema?
Deixe-me recapitular: com a entrada anycast, não controlamos para qual data center o usuário é roteado. Portanto, cada um de nossos data centers deve ser capaz de sair de um endereço com qualquer tag concebível. Dentro do data center também não controlamos para qual servidor a conexão é roteada. Existem potencialmente muitas tags, muitos data centers e muitos servidores dentro de um data center.
Talvez o problema seja a arquitetura de entrada? Talvez seja melhor usar um design de rede tradicional em que um visitante específico é roteado com DNS para um data center específico ou até mesmo para um servidor?
Essa é uma maneira de pensar, mas decidimos ir contra ela. Gostamos do nosso anycast na entrada. Isso nos traz muitas vantagens:
Desempenho: com o anycast, por definição, o visitante é roteado para o data center mais próximo (por métricas BGP). Geralmente, esse é o data center mais rápido para um determinado usuário.
Failover automático: se um de nossos data centers ficar indisponível, o tráfego será redirecionado instantaneamente e automaticamente para o próximo local melhor.
Resiliência a DDoS: durante um ataque de negação de serviço ou um pico de tráfego, a carga é automaticamente balanceada entre muitos data centers, reduzindo significativamente o impacto.
Software uniforme: a funcionalidade de cada data center e de cada servidor dentro de um data center é idêntica. Usamos a mesma pilha de software em todos os servidores no mundo. Cada máquina pode executar qualquer ação, para qualquer produto. Isso permite fácil depuração e boa escalabilidade.
Por esses motivos, queremos manter o anycast na entrada. Decidimos resolver a questão da cardinalidade do endereço de saída de alguma outra maneira.
Resolver um problema de um milhão de dólares
Dos milhares de servidores que operamos, cada um deve ser capaz de usar um IP de saída com qualquer uma das tags possíveis. É mais fácil explicar nossa solução mostrando primeiro dois designs extremos.
Cada servidor possui todos os IPs necessários: cada servidor possui todos os IPs de saída especializados com as tags necessárias.
Um servidor possui o IP necessário: um IP de saída especializado com uma tag específica reside em um local, outros servidores encaminham o tráfego para ele.
Ambas as opções têm prós e contras:
IP especializado em cada servidor
| Specialized IP on every server | Specialized IP on one server |
|---|---|
| Super expensive $$$, every server needs many IP addresses. | Cheap $, only one specialized IP needed for a tag. |
| Egress always local - fast | Egress almost always forwarded - slow |
| Excellent reliability - every server is independent | Poor reliability - introduced chokepoints |
IP especializado em um servidor
$$$ super caro, todos os servidores precisam de muitos endereços de IP.
$ barato, apenas um IP especializado necessário para uma tag.
Saída sempre local – rápida
| Specialized IP on every server | Specialized IP per data center | Specialized IP on one server |
|---|---|---|
| Super expensive $$$ | Reasonably priced $$ | Cheap $ |
| Egress always local - fast | Egress always local - fast | Egress almost always forwarded - slow |
| Excellent reliability - every server is independent | Excellent reliability - every server is independent | Poor reliability - many choke points |
Saída quase sempre encaminhada – lenta
Excelente confiabilidade – cada servidor é independente
Baixa confiabilidade – introdução de gargalos
Há uma terceira maneira
Temos pensado muito sobre esse problema. Francamente, a primeira opção extrema de ter todos os IPs necessários disponíveis localmente em todos os servidores da Cloudflare não é totalmente impraticável. Isso é, aproximadamente, o que conseguimos fazer para o IPv6. Com o IPv6, o acesso ao grande espaço de IP necessário não é um problema.
No entanto, no IPv4 nenhuma das opções é aceitável. A primeira oferece saída rápida e confiável, mas exige alto custo, os endereços IPv4 necessários são caros. A segunda opção usa o menor espaço de IP possível, por isso é barata, mas compromete o desempenho e a confiabilidade.
A solução que concebemos é uma harmonização entre os extremos. A ideia no geral é mudar a unidade de atribuição. Em vez de atribuir um endereço IPv4 /32 para cada servidor, criamos um método de atribuir um IP /32 por data center e, em seguida, compartilhá-lo entre os servidores físicos.
IP especializado em cada servidor
IP especializado por data center
198.51.100.1 - forward to LHR
198.51.100.2 - forward to CDG
198.51.100.3 - forward to MAN
...IP especializado em um servidor
Super caro $$$
Preço razoável $$
Barato $
Saída sempre local – rápida
Saída sempre local – rápida
Saída quase sempre encaminhada – lenta
Excelente confiabilidade – cada servidor é independente
Excelente confiabilidade – cada servidor é independente
Baixa confiabilidade – muitos gargalos
Compartilhar um IP dentro do data center
A ideia de compartilhar um IP entre servidores não é nova. Tradicionalmente, isso pode ser obtido por Source-NAT em um roteador. Infelizmente, o grande número de IPs de saída de que precisamos e o tamanho de nossa operação nos impede de depender de firewall com estado/NAT no nível do roteador. Também não gostamos de estado compartilhado, então não somos fãs de instalações NAT distribuídas.
Em vez disso, o que escolhemos é dividir um IP de saída entre os servidores por um intervalo de portas. Para um determinado IP de saída, cada servidor possui uma pequena parcela das portas de origem disponíveis, uma parte das portas.
Quando os pacotes de retorno chegam da internet, temos que encaminhá-los de volta para a máquina correta. Para esta tarefa, personalizamos o "Unimog", nosso balanceador de carga baseado em L4 XDP – ("Unimog, Cloudflare's load balancer (2020)") e ele está funcionando perfeitamente.
Com uma parte das portas de, digamos, 2.048 portas, podemos compartilhar um IP entre 31 servidores. No entanto, sempre existe a possibilidade de ficar sem portas. Para resolver isso, trabalhamos muito para poder reutilizar as portas de saída com eficiência. Consulte "How to stop running out of ports (2022)", "How to share IPv4 addresses (2022)" e nosso segmento da Cloudflare TV.
É basicamente isso. Cada servidor está ciente de quais endereços de IP e partes de portas ele possui. Para o roteamento de entrada, o Unimog inspeciona as portas e despacha os pacotes para as máquinas apropriadas.
Compartilhamento de uma sub-rede entre data centers
Porém, este não é o fim da história, não discutimos como podemos rotear um único endereço /32 para um data center. Tradicionalmente, na internet pública, só é possível rotear sub-redes com endereços de IP de granularidade de /24 ou 256. No nosso caso, isso levaria a um grande desperdício de espaço de IP.
Para resolver esse problema e melhorar a utilização do nosso espaço de IP, implantamos nossas faixas de saída como... anycast. Com isso em vigor, personalizamos o Unimog e o ensinamos a encaminhar os pacotes por meio de nossa rede de backbone para o data center correto. O Unimog mantém um banco de dados como este:
Com esse design, não importa para qual data center os pacotes de retorno são distribuídos. O Unimog sempre pode corrigi-los e encaminhar os dados para o lugar certo. Basicamente, enquanto na camada BGP estamos usando anycast, devido ao nosso design, semanticamente um IP identifica um data center e um IP e o intervalo de portas identificam uma máquina específica. Ele se comporta quase como um unicast.
Chamamos essa pilha de tecnologia de "soft-unicast" e ela parece mágica. É como se tivéssemos unicast em software sobre anycast na camada BGP.
O soft-unicast parece magia
Com esta configuração, podemos obter benefícios significativos:
Podemos compartilhar um IP de saída /32 entre muitos servidores.
Podemos espalhar uma única sub-rede por muitos data centers e alterá-la facilmente em tempo real. Isso nos permite usar totalmente nossos intervalos IPv4 de saída.
Podemos agrupar endereços de IP semelhantes. Por exemplo, todos os endereços de IP marcados com a tag "UK" podem formar um único intervalo contínuo. Isso reduz o tamanho do geofeed publicado.
Fica fácil integrar novos intervalos de IP de saída, como IPs de clientes. Isso é útil para alguns de nossos produtos, como o Zero Trust da Cloudflare.
Tudo isso é feito a um custo razoável, sem perda de desempenho e confiabilidade:
Normalmente, o usuário pode sair diretamente do data center mais próximo, proporcionando o melhor desempenho possível.
Dependendo das necessidades reais, podemos alocar ou liberar os endereços de IP. Isso nos dá flexibilidade com o gerenciamento de custos de IP, não precisamos gastar demais antecipadamente.
Como operamos vários endereços de IP de saída em locais diferentes, a confiabilidade não é comprometida.
A verdadeira localização dos nossos endereços de IP é: “a nuvem”
Embora o soft-unicast nos permita obter grande eficiência, encontramos alguns problemas. Às vezes, recebemos a pergunta "Onde esse IP existe fisicamente?" Mas ela não tem resposta. Nossos IPs de saída não existem fisicamente em nenhum lugar. Do ponto de vista de BGP, nossos intervalos de saída são anycast, então eles residem em todos os lugares. Logicamente, cada endereço é usado em um data center por vez, mas podemos movê-lo sob demanda.
As redes de distribuição de conteúdo direcionam os usuários erroneamente
Um outro exemplo de problema. Aqui está um problema que encontramos com CDNs de terceiros. Como mencionamos anteriormente, existem três tags de país em nosso pipeline:
A tag do país de onde o IP do visitante está se conectando.
A localização do nosso data center.
A tag de país dos endereços de IP que escolhemos para as conexões de saída.
O fato de nosso endereço de saída estar marcado como "Reino Unido" nem sempre significa que ele está sendo usado no Reino Unido. Tivemos casos em que um usuário WARP marcado no Reino Unido, devido à manutenção de nosso data center LHR, foi encaminhado para Paris. Uma CDN popular realizou uma pesquisa reversa de nosso IP de saída, encontrou-o marcado como "UK" e direcionou o usuário para um servidor de CDN de Londres. Isso geralmente é bom... mas na verdade tínhamos saído de Paris na época. Esse usuário acabou roteando pacotes de sua casa no Reino Unido para Paris e de volta para o Reino Unido. Isso é ruim para o desempenho.
Resolvemos esse problema realizando solicitações de DNS no data center de saída. Para o DNS, usamos endereços de IP marcados com a localização do data center, não a geolocalização pretendida para o usuário. Isso geralmente corrige o problema, mas, infelizmente, ainda existem algumas exceções.
O futuro é agora
Nossos experimentos de 2021 com o Addressing Agility provaram que temos muitas oportunidades de inovar com o endereçamento de entrada. O soft-unicast nos mostra que podemos alcançar grande flexibilidade e densidade no lado da saída.
A cada novo produto, cresce o número de tags que precisamos na saída, desde a confiabilidade do tráfego, categoria do produto até a geolocalização. À medida que o pool de endereços IPv4 utilizáveis diminui, podemos ter certeza de que haverá mais inovação no espaço. O soft-unicast é a nossa solução, mas com certeza não é o nosso último desenvolvimento.
Por enquanto, porém, parece que estamos nos afastando do unicast tradicional. Nossos IPs de saída realmente não existem mais em um local fixo e alguns de nossos servidores nem mesmo possuem um verdadeiro IP unicast hoje em dia.