Olá!
Todas as boas histórias chegam ao fim. E nossa história sobre como criamos a solução para contornar o Grande Firewall da China não é diferente. Portanto, estou ansioso para compartilhar com você a última, parte final sobre este tema.
Na parte anterior, falamos sobre muitos bancos de teste que criamos e os resultados que eles trouxeram. E paramos por aí, pensando que seria bom adicionar CDN! para a aderência em nosso esquema.
Vou contar como testamos o Alibaba Cloud CDN, Tencent Cloud CDN e Akamai, e sobre o que decidimos no final. E, claro, faremos um resumo.
Alibaba Cloud CDN
Estamos hospedados no Alibaba Cloud, utilizando IPSEC e CEN da mesma empresa. Faz sentido primeiro testar suas soluções.
O Alibaba Cloud tem dois tipos de produtos que podem nos atender: provedor de CDN). Eles monitoram seu e DCDN. A primeira opção é um CDN clássico para um domínio específico (subdomínio). A segunda opção é conhecida como Dynamic Route for CDN (que eu chamo de CDN dinâmico), ele pode ser ativado em modo Full-site (para domínios wildcard), também cache estáticos e acelera conteúdo dinâmico, ou seja, a dinâmica da página também será carregada através das redes rápidas do provedor. Isso é importante para nós, pois, principalmente, nosso site é dinâmico, utiliza muitos subdomínios, e é mais conveniente configurar o CDN uma vez para “asterisco” — *.semrushchina.cn.
Já vimos esse produto em etapas anteriores do nosso projeto na China, mas na época ele não estava funcionando, e os desenvolvedores prometeram que logo estaria disponível para todos os clientes. E agora está disponível.
No DCDN, é possível:
- configurar a terminação SSL com seu próprio certificado,
- ativar a aceleração de conteúdo dinâmico,
- configurar o cache de arquivos estáticos de forma flexível,
- realizar purge do cache,
- encaminhar web sockets,
- ativar a compressão e até mesmo o HTML Beautifier.
No geral, tudo como nos provedores de CDN grandes e experientes.
Depois de especificar a origem (o local para onde os servidores de borda CDN se conectarão), é necessário criar um CNAME para o asterisco, referenciando all.semrushchina.cn.w.kunluncan.com (este CNAME foi obtido no console do Alibaba Cloud), e o CDN funcionará.
De acordo com os resultados dos testes, este CDN nos ajudou bastante. A estatística está abaixo.
Solução
Uptime
Mediana
Percentil 75
Percentil 95
Cloudflare
86.6
18s
30s
60s
IPsec
99.79
18s
21s
30s
CEN
99.75
16s
21s
27s
CEN/IPsec + GLB
99.79
13s
16s
25s
Ali CDN + CEN/IPsec + GLB
99.75
10s
12.8s
17.3s
Esses são resultados muito bons, especialmente se comparados aos números que tínhamos no início. Mas sabíamos que o teste no navegador da versão americana do nosso site www.semrush.com leva em média 8,3s (um valor muito aproximado). Há espaço para melhorar. Além disso, havia outros provedores de CDN que seria interessante testar.
Assim, passamos para outro gigante do mercado chinês — Tencent.
Tencent Cloud
A Tencent ainda está desenvolvendo sua nuvem — isso é visível pelo pequeno número de produtos. Durante seu uso, queríamos testar não apenas o CDN deles, mas também a infraestrutura de rede em geral:
- eles têm algo semelhante ao CEN?
- como funciona o IPSEC? É rápido? Qual é o uptime?
- eles oferecem Anycast?
Vamos analisar essas questões separadamente.
Análogo ao CEN
A Tencent tem um produto chamado Cloud Connect Network (), permitindo conectar VPCs de diferentes regiões, incluindo regiões dentro e fora da China. O produto está atualmente em beta interna, e é necessário criar um ticket solicitando a conexão. Do suporte, soubemos que contas globais (referindo-se a não cidadãos chineses e não entidades legais) não podem participar do programa de testes beta e, no geral, não é possível conectar uma região dentro da China com uma região fora. 1-0 a favor da Ali Cloud
IPSEC
A região mais ao sul da Tencent é Cantão. Criamos um túnel e o conectamos à região de Hong Kong na GCP (naquela época essa região já estava disponível). Também levantamos simultaneamente um segundo túnel na Ali Cloud de Shenzhen a Hong Kong. Descobrimos que a latência através da rede da Tencent até Hong Kong era, no geral, melhor (10ms), do que de Shenzhen a Hong Kong na Ali (120ms — o quê?). Mas isso não acelerou de forma alguma o funcionamento do site, que estava configurado para operar através da Tencent e desse túnel, o que em si foi um fato surpreendente e mais uma vez comprovou o seguinte: a latência — para a China, não é um indicador que realmente vale a pena prestar atenção ao desenvolver uma solução para passar pelo firewall chinês.
Anycast Internet Acceleration
Outro produto que permite trabalhar através de IP anycast — . Mas ele também não está disponível para contas globais, portanto não posso falar sobre ele, mas saber que existe um produto assim pode ser útil.
O teste do CDN, por sua vez, apresentou resultados bastante interessantes. O CDN da Tencent não pode ser habilitado para um site completo, apenas para domínios específicos. Configuramos os domínios e direcionamos tráfego para eles:
Descobrimos que esse CDN possui a seguinte funcionalidade: Otimização de Tráfego Cross Border. Este recurso deve reduzir os custos ao passar o tráfego através do firewall chinês. Como Origem foi indicado o endereço IP do GLB do Google (GLB anycast). Assim, queríamos simplificar a arquitetura do projeto.
Os resultados foram muito bons — no nível do Ali Cloud CDN, e em algumas ocasiões até melhores. É surpreendente, pois em caso de sucesso dos testes, poderíamos dispensar uma parte significativa da infraestrutura, túneis, CEN, máquinas virtuais etc.
A alegria durou pouco, pois surgiu um problema: os testes no Catchpoint falharam para o provedor de internet China Mobile. De qualquer localização, recebíamos timeout através do CDN da Tencent. A correspondência com o suporte técnico não levou a nada. Tentamos resolver esse problema por cerca de um dia, mas nada funcionou.
Eu estava na China naquele momento, mas não consegui encontrar Wi-Fi público na rede desse provedor para verificar o problema pessoalmente. No restante, tudo parecia rápido e bom.
No entanto, devido ao fato de que a operadora China Mobile está entre os três maiores operadores, fomos forçados a direcionar o tráfego de volta para o Ali CDN.
Mas, de modo geral, foi uma solução bastante interessante que merece testes e troubleshooting mais prolongados.
Akamai
O último provedor de CDN que testamos foi Akamai. Este é um grande provedor que tem sua própria rede na China. É claro que não podíamos ignorá-lo.
Desde o início, fazemos um acordo com a Akamai para um período de teste, para que pudéssemos mudar o domínio e ver como funcionaria na rede deles. Gostaria de descrever o resultado de todos os testes nas seções 'O que gostamos' e 'O que não gostamos', bem como apresentar os resultados dos testes.
O que gostamos:
- A equipe da Akamai foi muito prestativa em todas as questões e nos acompanhou em todas as etapas do teste. Eles sempre tentaram melhorar algo do lado deles. Davam bons conselhos técnicos.
- A Akamai opera aproximadamente 10-15% mais lento que nossa solução através do Ali Cloud CDN. É impressionante que, no origin da Akamai, indicamos o endereço IP do GLB, ou seja, o tráfego não passou pela nossa solução (potencialmente poderíamos dispensar parte da infraestrutura). No entanto, os resultados dos testes mostraram que essa opção foi pior que nossa opção atual (resultados comparativos abaixo).
- Foi testado tanto como Origin GLB quanto como Origin na China. Ambas as opções são aproximadamente iguais.
- Há Sure Route (otimização automática de roteamento). É possível colocar um objeto de teste no Origin, e os servidores Edge da Akamai vão tentar obtê-lo (GET normal). Para essas solicitações, a velocidade e outras métricas são medidas, com base nas quais a rede Akamai otimiza os caminhos, fazendo com que o tráfego flua mais rapidamente para o nosso site e demonstrando que a ativação desse recurso realmente impacta positivamente a velocidade do site.
- O versionamento da configuração na interface web é incrível. É possível fazer uma comparação entre versões, visualizar as diferenças. Conferir versões anteriores.
- É possível lançar uma nova versão apenas na rede de Staging da Akamai — uma rede semelhante à de produção, mas esse caminho não afeta usuários reais. Para esse teste, é necessário fazer o spoofing dos registros DNS na máquina local.
- A velocidade de carregamento pela rede deles para grandes arquivos estáticos, e aparentemente, qualquer outro arquivo, é muito rápida. Um arquivo do cache 'frio' é recuperado várias vezes mais rápido do que o mesmo arquivo do cache 'frio' da Ali CDN. A velocidade do cache 'quente' já é basicamente a mesma.
Teste da Ali CDN:
root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5757k 0 5757k 0 0 513k 0 --:--:-- 0:00:11 --:--:-- 526k
time_namelookup: 0.004286
time_connect: 0.030107
time_appconnect: 0.117525
time_pretransfer: 0.117606
time_redirect: 0.000000
time_starttransfer: 0.840348
----------
time_total: 11.208119
----------
size_download: 5895467 Bytes
speed_download: 525999.000B/sTeste da Akamai:
root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5757k 0 5757k 0 0 1824k 0 --:--:-- 0:00:03 --:--:-- 1825k
time_namelookup: 0.509005
time_connect: 0.528261
time_appconnect: 0.577235
time_pretransfer: 0.577324
time_redirect: 0.000000
time_starttransfer: 1.327013
----------
time_total: 3.154850
----------
size_download: 5895467 Bytes
speed_download: 1868699.000B/sNotamos que a situação do exemplo acima depende de vários fatores. No momento em que escrevi este ponto, fiz o teste novamente. Os resultados para ambas as plataformas foram aproximadamente iguais. Isso indica que a internet na China, mesmo para grandes provedores e provedores de nuvem, se comporta de maneira diferente de tempos em tempos.
Adicionando um grande ponto positivo ao item anterior sobre a Akamai: se na Ali são visíveis esses surtos de alto desempenho e baixa latência (isso se aplica ao Ali CDN, Ali CEN e Ali IPSEC), na Akamai, toda vez que eu testo a rede deles, tudo funciona de forma estável.
Akamai realmente tem uma ampla cobertura na China e trabalha com muitos provedores.
O que não gostei:
- Não gosto da interface web e da estrutura de funcionamento — são bastante limitadas. Mas, em princípio, você acaba se acostumando (provavelmente).
- Os resultados dos testes são piores que os de nossa plataforma.
- Erros nos testes são mais frequentes do que em nossa plataforma (uptime mais baixo).
- Não possuem servidores DNS próprios na China. Daí muitos erros nos testes devido a timeouts de resolução DNS.
- Não fornecem seus ranges de IP — sem possibilidade de configuração correta de set_real_ip_from nos nossos servidores.
Métricas (~3626 execuções; todas as métricas, exceto Uptime, em ms; estatísticas de um único intervalo de tempo):
Fornecedor de CDN
Mediana
75%
95%
Response
Resposta da Página da Web
Uptime
DNS
Conectar
Aguardar
Carga
SSL
Ali CDN
9195
10749
17489
1,715
10,745
99.531
57
17
927
479
200
Akamai
9783
11887
19888
2,352
11,550
98.980
424
91
1408
381
50
Distribuição por Percentis (em ms):
Percentil
Akamai
Ali CDN
10
7,092
6,942
20
7,775
7,583
30
8,446
8,092
40
9,146
8,596
50
9,783
9,195
60
10,497
9,770
70
11,371
10,383
80
12,670
11,255
90
15,882
13,165
100
91,592
91,596
A conclusão é que a opção com a Akamai é viável, mas não oferece os mesmos níveis de estabilidade e velocidade que nossa própria solução combinada com o Ali CDN.
Pequenas observações
Alguns pontos não foram incluídos na narrativa, mas gostaria de mencioná-los também.
Pequim + Tóquio e Hong Kong
Como mencionado anteriormente, testamos o túnel IPSEC até Hong Kong (HK). Mas também testamos o CEN até HK. Ele custa um pouco menos, e era interessante ver como funcionaria entre cidades a cerca de 100 km de distância. O interessante foi que a latência entre essas cidades é 100 ms maior do que em nossa configuração original (para Taiwan). A velocidade e a estabilidade também foram melhores para Taiwan. No entanto, decidimos manter HK como uma região de backup para IPSEC.
Além disso, tentamos implantar a seguinte configuração:
- terminação de clientes em Pequim,
- IPSEC e CEN até Tóquio,
- sendo o Ali CDN indicado como servidor de origem em Pequim.
Esse esquema não foi tão estável, embora em termos de velocidade não fosse inferior à nossa solução. Quanto ao túnel, observei quedas periódicas mesmo para o CEN, que deveria ser estável. Portanto, voltamos ao esquema anterior e desmontamos essa estrutura.
Abaixo está a estatística de latência entre diferentes regiões em diferentes canais. Pode ser que alguém se interesse.
IPsec
Ali cn-beijing GCP asia-northeast1 — 193ms
Ali cn-shenzhen GCP asia-east2 — 91ms
Ali cn-shenzhen GCP us-east4 — 200ms
CEN
Ali cn-beijing Ali ap-northeast-1 — 54ms (!)
Ali cn-shenzhen Ali cn-hongkong — 6ms (!)
Ali cn-shenzhen Ali us-east1 — 216ms
Informações gerais sobre a internet na China
Como complemento aos problemas de internet descritos no início, na primeira parte do artigo.
- A internet na China funciona bastante rapidamente internamente.
- A conclusão foi feita com base na testagem de redes Wi-Fi públicas em várias localidades, onde essas redes são utilizadas por muitas pessoas.
- A velocidade de download e upload para servidores dentro da China foi em torno de 20 Mbps e 5-10 Mbps, respectivamente.
- A velocidade para servidores fora da China é simplesmente miserável, menos de 1 Mbps.
- A internet na China não é muito estável.
- Às vezes, os sites podem abrir rapidamente, às vezes lentamente (na mesma hora do dia em dias diferentes), desde que a configuração não mude. Observamos isso no caso do semrushchina.cn. Isto pode ser atribuído ao Ali CDN, que também funciona de forma intermitente dependendo da hora do dia, da posição das estrelas, etc.
- A internet móvel é praticamente 4G ou 4G+ em toda parte. Funciona no metrô, em elevadores — basicamente, em todo lugar.
- A crença de que os usuários chineses confiam apenas em domínios na zona .cn é um mito. Verificamos isso diretamente com os usuários.
- É possível ver como redireciona para www.baidu.com (também em mainland China).
- Muitos recursos estão realmente bloqueados. De forma primitiva: google.com, Facebook, Twitter. Mas muitos recursos do Google funcionam (claro, nem em todos os Wi-Fi e VPN não é utilizada (também do lado do roteador, isso é certo).
- Muitos domínios 'técnicos' de corporações bloqueadas também funcionam. Isso significa que nem sempre se deve cortar indiscriminadamente todos os recursos do Google e outros que parecem estar bloqueados. É preciso procurar alguma lista de domínios proibidos.
- Eles têm apenas três principais provedores de internet: China Unicom, China Telecom, China Mobile. Existem outros menores, mas sua participação no mercado é insignificante.
Bônus: esquema final de solução
Resultado
Um ano se passou desde o início do projeto. Começamos com nosso site simplesmente se recusando a funcionar adequadamente a partir da China, e uma requisição GET via curl estava levando 5,5 segundos.
Depois, com esses números na primeira solução (Cloudflare):
Solução
Uptime
Mediana
Percentil 75
Percentil 95
Cloudflare
86.6
18s
30s
60s
Finalmente chegamos a esses resultados (estatísticas do último mês):
Solução
Uptime
Mediana
Percentil 75
Percentil 95
Ali CDN + CEN/IPsec + GLB
99.86
8,8s
9,5s
13,7s
Como pode ser visto, não conseguimos alcançar 100% de uptime até agora, mas vamos pensar em alguma solução e depois contaremos a vocês sobre os resultados em um novo artigo :)
Aquele que leu até o final todas as três partes — respeito. Espero que tenha achado tudo isso tão interessante quanto eu quando o fiz.
P.S. Partes anteriores
Fonte: habr.com
