Bonjour à tous !
En ligne, Nikita — ingénieur système de l'entreprise SEMrush. Aujourd'hui, je vais vous parler de la manière dont nous avons été confrontés à la tâche d'assurer la stabilité de notre service semrush.com en Chine, et des problèmes que nous avons rencontrés lors de sa réalisation (étant donné l'emplacement de notre centre de données sur la côte est des États-Unis).
Ce sera une longue histoire, divisée en plusieurs articles. Je vais vous raconter comment tout cela s'est passé pour nous : d'un service complètement non fonctionnel en Chine à des performances de service équivalentes à celles de sa version américaine pour les Américains. Je vous promets que cela sera intéressant et utile. Alors, c'est parti.
Les problèmes d'Internet en Chine
Même la personne la plus éloignée des subtilités de l'administration réseau a au moins entendu parler du Grand Firewall de Chine. Ouh, ça sonne bien, n'est-ce pas ? Mais qu'est-ce que c'est, comment cela fonctionne réellement — c'est une question assez complexe. On peut trouver de nombreux articles à ce sujet sur Internet, mais du point de vue technique, le fonctionnement de ce pare-feu n'est décrit nulle part. Ce qui n'est d'ailleurs pas surprenant. Je l'admets, au terme d'une année de travail, je ne pourrai pas dire exactement comment cela fonctionne, mais je pourrai parler de mes observations et conclusions pratiques. Commençons donc par les rumeurs à propos de ce pare-feu.
Il existe de nombreuses rumeurs à propos de ce pare-feu. Regroupons les principales et les plus intéressantes dans une liste :
- Google, Facebook, Twitter et d'autres services similaires sont bloqués et ne fonctionnent pas en Chine.
- Tout le trafic entrant et sortant de la Chine est analysé et restreint grâce à l'apprentissage machine (en cas de trafic suspect), ce qui ralentit considérablement celui passant par la frontière.
- Les services de renseignement chinois piratent tout trafic chiffré passant par leur pare-feu.
- Les tunnels VPN et les tunnels IPSEC sont instables, tombent et sont constamment bloqués.
- Plus le chiffrement est simple, plus la phrase de passe utilisée pour l'authentification/chiffrement du trafic est simple, plus elle passe rapidement le pare-feu chinois.
Voici ce que nous avons pu déterminer sur ces rumeurs :
- Google, Facebook, Twitter et d'autres services similaires sont effectivement bloqués (votre K.O.), mais de nombreux domaines techniques de Google, par exemple, ne sont pas bloqués et fonctionnent (comme gstatic.com). Cela signifie qu'il ne faut pas supprimer sans discernement tous les ressources Google et autres qui semblent bloquées.
- Tout le trafic qui traverse la frontière ajoute en effet un temps de latence considérable. Regardez les deux résultats. Un site, une page, simple GET curl’. La première mesure vient directement de Chine (la magnifique ville de Shenzhen). La deuxième mesure provient de l'extérieur, de Hong Kong (qui a sa souveraineté, et il n'y a pas de pare-feu entre lui et le monde). La distance entre les villes est d'environ 30-40 km.
nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 381k 0 381k 0 0 71824 0 --:--:-- 0:00:05 --:--:-- 82832
time_namelookup: 0.004500
time_connect: 0.169342
time_appconnect: 0.723189
time_pretransfer: 0.723499
time_redirect: 0.000000
time_starttransfer: 1.532912
----------
time_total: 5.443407
----------
size_download: 390968 Bytes
speed_download: 71824.000B/s
nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 319k 0 319k 0 0 2555k 0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup: 0.029366
time_connect: 0.030742
time_appconnect: 0.047310
time_pretransfer: 0.047388
time_redirect: 0.000000
time_starttransfer: 0.120793
----------
time_total: 0.124871
----------
size_download: 326755 Bytes
speed_download: 2616740.000B/sVeuillez noter que time_connect. Et dans l'ensemble, vous voyez le résultat : le pare-feu ajoute 4 secondes supplémentaires, ce qui est incroyablement long.
- Les VPN et les tunnels IPSEC tombent effectivement souvent. J'en parlerai plus en détail tout à l'heure. Les serveurs VPN utilisés par les utilisateurs se font bloquer avec le temps (généralement dans les 24 heures suivant le début de leur utilisation).
- Il y a une opinion formulée par des personnes vivant en Chine, selon laquelle plus le chiffrement du trafic est simple, plus il traverse rapidement la frontière, car il est facile de comprendre qu'il n'y a rien d'illégal. De même, le trafic 'propre' obtient plus de bande passante et de vitesse, tandis que le trafic 'sale', difficile à interpréter, est plutôt ralenti. Par exemple, je vais faire un curl vers ifconfig.co via le protocole HTTPS et HTTP.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13 100 13 0 0 2 0 0:00:06 0:00:05 0:00:01 3
time_namelookup: 0.004305
time_connect: 0.397465
time_appconnect: 5.149305
time_pretransfer: 5.149393
time_redirect: 0.000000
time_starttransfer: 5.568847
----------
time_total: 5.568893
----------
size_download: 13 Bytes
speed_download: 2.000B/s
curl -o /dev/null -w@curl_time "http://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13 100 13 0 0 28 0 --:--:-- --:--:-- --:--:-- 28
time_namelookup: 0.004282
time_connect: 0.212457
time_appconnect: 0.000000
time_pretransfer: 0.212484
time_redirect: 0.000000
time_starttransfer: 0.450565
----------
time_total: 0.450620
----------
size_download: 13 Bytes
speed_download: 28.000B/sUne différence de 5 secondes sur le temps total de téléchargement de 13 octets. En effet, en effectuant ce test plusieurs fois, on peut constater que le GET sur HTTP se termine toujours en un temps relativement constant, tandis que sur HTTPS, le site répond parfois en 3, 5, 10 et même 17 secondes. Parfois, des erreurs SSL se produisent :
Erreur de protocole SSL inconnue lors de la connexion à ifconfig.co:443.
Alors, que pouvons-nous conclure :
- Les problèmes causés par le pare-feu chinois, comme mentionné ci-dessus.
- Les pings vers des ressources externes et au sein des tunnels disparaissent de temps en temps.
- La latence entre deux points change constamment et est souvent imprévisible. En connectant différentes villes/régions, vous vous attendez à ce que la latence soit plus faible en fonction de la disposition géographique des régions, mais vous obtenez exactement le résultat inverse.
- Internet et les canaux de communication fonctionnent parfois rapidement, parfois lentement. Il existe une légère dépendance à l'heure de la journée et au jour de la semaine, mais ce n'est pas systématique.
- Les requêtes DNS vers l'extérieur depuis la Chine dépassent parfois le délai d'attente autorisé.
Le tableau se dessine simplement "excellent".
Le centre de données, comme je l'ai déjà dit, est situé dans l'est des États-Unis, et l'ensemble de SEMrush est composé de dizaines de produits interconnectés, de back-ends, de front-ends, de bases de données, le tout dans le DC et dans le cloud. Notre équipe de systématiciens a reçu pour mission, avec un minimum d'efforts, de commencer rapidement à travailler en Chine.
Nous devions répondre à une question importante : pouvons-nous nous en sortir avec peu d'efforts et résoudre tous les problèmes liés à Internet et au pare-feu chinois au niveau des réseaux/des nuages/des serveurs ?
Nous avons commencé par obtenir .
Licence ICP
Pour pouvoir héberger votre service en Chine continentale et effectuer des tests, vous devez d'abord obtenir une licence ICP pour votre domaine.
Si le trafic utilisateur de votre site est interrompu dans le territoire de la Chine continentale et si votre domaine n'a pas de licence ICP, votre trafic sera bloqué par le fournisseur/ hébergeur. Il est intéressant de noter que la licence ICP est liée à un fournisseur spécifique, qu'il s'agisse de Cloudflare ou d'Alibaba Cloud. Ainsi, si vous avez obtenu une licence ICP pour Cloudflare et hébergé votre site chez eux, il ne sera pas possible de migrer « sans solution » vers Alibaba Cloud par la suite. Il faudra ajouter un autre hébergement à cette licence.
Après avoir obtenu la licence ICP pour le domaine, nous avons pu concevoir et mettre en œuvre des idées et des solutions techniques spécifiques.
Test des solutions
Mais avant de commencer à créer des variantes de staging, à faire des ajustements, à optimiser les performances et la vitesse du site, nous devons choisir un outil pour les tests afin de voir quelles actions améliorent ou, au contraire, détériorent les performances du site.
Notre outil de test devait répondre à deux exigences principales:
- il doit être capable de lancer des tests depuis la Chine,
- il doit avoir des tests basés sur un navigateur.
Ainsi, nous avons trouvé ! Ils ont une excellente couverture des points de test à travers le monde. Avec cet outil, il est également possible de lancer des tests depuis de nombreuses provinces en Chine. Dans chaque province, plusieurs fournisseurs différents + possibilité de faire des tests Backbone (comme une sorte de machine virtuelle dans un centre de données) etdes tests Lastmile (au plus près des conditions utilisateur, c'est-à-dire une station de travail). Ce dernier type de test coûte plus cher. Après avoir signé un contrat d'un an (pas de contrat plus court), nous avons commencé à étudier l'outil. Il faut avouer que nous avons été agréablement surpris par ses fonctionnalités. Il est possible de lancer:des tests DNS,
des tests Web (basés sur un navigateur, simple GET/POST, émulation d'un client mobile, etc.),
- des vérifications transactionnelles (par exemple, la connexion),
- des tests API,
- Ping, traceroute, NTP, etc.
- Il y a beaucoup de tests. Et surtout, chaque test peut être assez bien personnalisé en ajoutant une série d'en-têtes et d'autres paramètres. Le résultat est une énorme quantité d'informations décrivant entièrement votre test. En ce qui concerne ce qui nous intéresse le plus (tests basés sur le navigateur), le résultat comprend:
- Connect, Wait, Load, SSL, Temps DNS,
TTFB, TTLB, Document complet, Temps de rendu, Chargement DOM,
- Réponse (proche du Time To First Byte), Réponse de page Web (proche du Time To Last Byte),
- Tous les percentiles, Temps moyen, Médiane
- Etc.
- Tous les percentiles, Moyenne, Temps médian
- Et cetera.
Ainsi, toutes ces métriques aident parfaitement à voir les changements et à comprendre si c'est mieux. Nous avons principalement examiné Response, Webpage Response, Médiane, 75 et 95 Percentiles.
Une question importante qui a flotté dans l'air depuis le début : Peut-on faire confiance à Catchpoint ?? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
C'est un gros problème, car en étant en Russie, il est pratiquement impossible de savoir avec précision comment un site fonctionne depuis la Chine. En utilisant des socks-proxy via une machine virtuelle, vous obtenez un chargement du site pendant plusieurs minutes, ce qui est inacceptable pour les tests, donc la seule option pour des tests manuels reste curl et de simples GET depuis la console avec mesure du temps. Cela aide car ce test reflète bien la vitesse de la solution réseau, et si des tests de navigateur sont également faits, c'est encore mieux.
Plus tard, nous sommes allés en Chine et nous avons constaté que On peut faire confiance à Catchpoint, car il reflète assez précisément les indicateurs réels de vitesse de fonctionnement.
Cloudflare China Network
Puisque pour le domaine principal semrush.com, nous utilisons avec succès Cloudflare, nous avons décidé d'essayer tout de suite leur fonctionnalité appelée . Cette option n'est activée que pour les sites Enterprise sur demande distincte et moyennant des frais supplémentaires. Elle n'est également disponible que pour les sites ayant la licence ICP correspondante, où Cloudflare est indiqué comme prestataire. Après activation, le site dispose du « CDN chinois » de Cloudflare — le trafic provenant des régions chinoises est dirigé vers le PoP (Points of Presence) CF le plus proche, puis est transmis à l'origine à travers ses réseaux ou ceux des fournisseurs/partenaires.
Le schéma de ce banc d'essai est présenté ci-dessous.
Pour nous, c'est une excellente option. Cela signifie que le second domaine sera également pris en charge par CF, ce qui n'augmente pas le nombre de solutions utilisées dans l'entreprise et n'alourdit pratiquement pas l'infrastructure.
Nous avons lancé des tests de navigateur et voici ce que nous avons obtenu :
Les losanges rouges représentent des échecs de tests. Les échecs en bas sont des erreurs DNS (délai d'expiration de résolution). Les échecs en haut sont des délais d'attente.
Uptime : 86,6
Médiane : 18s
75e percentile : 29,3s
95e percentile : 60s
La médiane, après avoir retiré le chargement reCaptcha (service de Google, bloqué en Chine), est passée de 28 à 18 secondes. Mais cela reste des résultats désastreux si l'on considère qu'un test similaire pour semrush.com (depuis les États-Unis) donnait moins de 10 secondes pour 95 % des utilisateurs (depuis les États-Unis) sur la même page (statique + dynamique).
Vous pouvez entrer dans chaque test et voir Waterfall et d'autres paramètres plus détaillés. Nous avons commencé à examiner les raisons des erreurs, et si pour les délais d'attente tout est plus ou moins clair : Internet en Chine se "connecte et se déconnecte", ce qui rend la vitesse de connexion et le chargement des ressources étrangères instables et inégales, alors les erreurs DNS nous ont beaucoup surpris. Nous avons découvert que PoP de Cloudflare se trouvent effectivement en Chine, l'adresse du site se résout en un IP anycast, mais les serveurs DNS utilisés sont américains, ce qui oblige les requêtes DNS à traverser la frontière, donc parfois elles échouent.
Après avoir éclairci cette question avec CF, il s'est avéré que ils n'ont pas de serveurs DNS en Chine, et quand ils en auront, c'est encore inconnu.
C'est pourquoi nous avons décidé de tester uniquement les DNS de Cloudflare et avons modifié le mécanisme de fonctionnement de Cloudflare pour notre site en mode "DNS seulement". C'est un mode où Cloudflare ne passe pas le trafic par lui-même, ce qui signifie qu'il ne fournit pas de protection DDoS, CDN et autres fonctionnalités, et fonctionne en tant que serveur DNS classique.
Ce stand est schématiquement présenté sur l'image suivante. L'image prend en compte les nouvelles connaissances sur le fait que les serveurs DNS de Cloudflare sont derrière un pare-feu.
Chez Catchpoint, nous avons lancé des tests GET simples (non basés sur un navigateur), qui ont montré beaucoup d'échecs. La cause en était les mêmes erreurs DNS.
Nous avons commencé à déboguer ces erreurs avec dig et avons découvert qu'à la première requête, l'adresse est déterminée correctement, mais à chaque requête répétée, nous recevons toujours SERVFAIL et introuvable. D'où cela vient-il ?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn a l'adresse 220.170.186.192
Hôte semrushchina.cn introuvable : 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn a l'adresse 220.170.186.192
Hôte semrushchina.cn introuvable : 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn a l'adresse 220.170.186.192
Hôte semrushchina.cn introuvable : 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn a l'adresse 220.170.186.192
Hôte semrushchina.cn introuvable : 2(SERVFAIL)Lors de la requête des serveurs NS de Cloudflare directement, il n'y a pas de telles erreurs :
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Utilisation du serveur de domaine :
Nom : ray.ns.cloudflare.com.
Adresse : 173.245.59.138#53
Alias :
semrushchina.cn a l'adresse 220.170.186.192
semrushchina.cn a l'adresse 220.170.186.192
Utilisation du serveur de domaine :
Nom : ray.ns.cloudflare.com.
Adresse : 173.245.59.138#53
Alias :
semrushchina.cn a l'adresse 220.170.186.192
semrushchina.cn a l'adresse 220.170.186.192Donc, le problème vient du "serveur DNS local" ou du serveur du fournisseur.
Une enquête plus approfondie a montré que SERVFAIL nous recevons le résolveur AAAA-enregistrements.
Il s'est avéré qu'à la demande auprès de Cloudflare AAAA-enregistrement, qui n'existe pas dans le domaine, Cloudflare a répondu Un-par un message d'erreur, ce qui constitue une erreur et un non-respect des RFC. Pour cette raison, le résolveur local (x.x.x.x) n'a pas apprécié cela et a répondu SERVFAIL. Dans le journal ci-dessous, ce comportement est clairement visible :
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x
; <> DiG 9.10.3-P4-Ubuntu <> -t AAAA semrushchina.cn @x.x.x.x
;; options globales : +cmd
;; Réponse reçue :
;; ->>HEADER<<- opcode : QUERY, status : SERVFAIL, id : 55467
;; flags : qr rd ra ; QUERY : 1, ANSWER : 0, AUTHORITY : 0, ADDITIONAL : 1
;; OPT PSEUDOSECTION :
; EDNS : version : 0, flags : ; udp : 4096
;; SECTION DE LA QUESTION :
;semrushchina.cn. IN AAAA
;; Temps de requête : 334 msec
;; SERVEUR : x.x.x.x#53(x.x.x.x)
;; QUAND : Mar Aoû 14 23:38:50 CST 2018
;; TAILLE MSG reçue : 44
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
; <> DiG 9.10.3-P4-Ubuntu <> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; options globales : +cmd
;; Réponse reçue :
;; ->>HEADER<<- opcode : QUERY, status : NOERROR, id : 63944
;; flags : qr aa rd ; QUERY : 1, ANSWER : 1, AUTHORITY : 0, ADDITIONAL : 1
;; AVERTISSEMENT : récursion demandée mais non disponible
;; OPT PSEUDOSECTION :
; EDNS : version : 0, flags : ; udp : 512
;; SECTION DE LA QUESTION :
;semrushchina.cn. IN AAAA
;; SECTION DE LA RÉPONSE :
semrushchina.cn. 300 IN A 220.170.186.192
;; Temps de requête : 185 msec
;; SERVEUR : 173.245.58.105#53(173.245.58.105)
;; QUAND : Mar Aoû 14 23:43:03 CST 2018
;; TAILLE MSG reçue : 60
Nous avons envoyé un bug report à Cloudflare, et ils l'ont corrigé après un certain temps. Ce qui s'est avéré intéressant : à l'heure actuelle, il n'y a toujours pas de support IPv6 en Chine, donc Cloudflare ne pouvait pas fournir son adresse IPv6 dans la réponse à la demande AAAA-d'enregistrements. Au final, tout a été résolu de sorte que pour la Chine, Cloudflare a commencé à répondre NODATA à de telles requêtes.
Ainsi, les erreurs DNS dans les tests Catchpoint ont considérablement diminué, mais pas complètement. Les timeouts n'ont également pas disparu :
Et nous avons commencé à chercher une autre solution.
Dans la prochaine partie, je vais raconter comment nous avons testé le cloud chinois Alibaba Cloud, comment avec un peu de « magie » Nginx, nous avons pu rapidement créer des PoC (Proof of Concept) des solutions, comment nous avons créé des solutions Multi-Cloud, dont l'une a finalement beaucoup aidé à accélérer le service depuis la Chine.
Restez à l'écoute !
Les parties suivantes
Source : habr.com
