Bonjour Ă tous!
En contact Nikita est un ingénieur système de SEMrush . Aujourd'hui, je vais vous expliquer comment nous avons fait face à la tâche d'assurer la stabilité de notre service semrush.com en Chine et quels problèmes nous avons rencontrés lors de sa mise en œuvre (compte tenu de l'emplacement de notre centre de données sur la côte est des États-Unis).
Ce sera une grande histoire, divisée en plusieurs articles. Je vais vous raconter comment tout cela s’est passé avec nous: d’un service totalement inutilisé de la Chine à la performance du service au niveau de sa version américaine pour les Américains. Je promets que ce sera intéressant et utile. Alors allons-y.
Problèmes d'Internet chinois
Même la personne la plus éloignée des spécificités de l'administration réseau a au moins une fois entendu parler du grand pare-feu chinois . Euh, ça a l'air cool, hein? Mais ce que c'est, comment cela fonctionne réellement est une question assez compliquée. Sur Internet, vous pouvez trouver de nombreux articles à ce sujet, mais d'un point de vue technique, l'appareil de ce pare-feu n'est décrit nulle part. Ce qui n'est cependant pas surprenant. J'avoue tout de suite que, sur la base des résultats de l'année de travail, je ne peux pas dire exactement comment cela fonctionne, mais je peux parler de mes commentaires et de mes conclusions pratiques. Et nous commencerons par des rumeurs sur ce pare-feu.
Il y a beaucoup de rumeurs sur ce pare-feu. Rassemblons les principaux et les plus intéressants d'entre eux dans une seule liste:
- Google, Facebook, Twitter et d'autres services similaires sont bloqués et ne fonctionnent pas en Chine.
- Tout trafic allant au-delà de la Chine et vers la Chine est analysé et limité par l'apprentissage automatique (en cas de trafic suspect), ce qui le ralentit considérablement (trafic) passant par la frontière.
- Les agences de renseignement chinois piratent tout trafic crypté qui passe par leur pare-feu.
- Les tunnels VPN, les tunnels IPSEC sont instables, tombent et sont constamment bloqués.
- Plus le cryptage est simple, plus la phrase de passe utilisée pour l'authentification / chiffrement du trafic est simple, plus il passe rapidement le pare-feu chinois.
Voici ce que nous avons réussi à découvrir sur ces rumeurs:
- Google, Facebook, Twitter et d'autres services similaires sont vraiment bloqués (votre KO), mais de nombreux domaines techniques de Google, par exemple, ne sont pas interdits et fonctionnent (le même gstatic.com). Cela conduit à la conclusion: ne supprimez pas imprudemment toutes les ressources Google et autres qui semblent être bloquées, apparemment bloquées.
- Tout trafic passant par la frontière ajoute vraiment un sérieux retard à son temps. Regardez les deux résultats. Un site, une page, simple get curl . La première mesure de la Chine elle-même (la belle ville de Shenzhen). Le second s'est figé à l'extérieur de Hong Kong (il a la souveraineté, et il n'y a pas de pare-feu entre lui et le monde). La distance entre les villes en ligne droite est d'environ 30 à 40 km.
nikita@china-shenzhen:~
Faites attention à time_connect . Et en général, vous voyez le résultat: le pare-feu ajoute 4 secondes supplémentaires, ce qui est monstrueusement long.
- Les VPN et les tunnels IPSEC tombent souvent. J'en parlerai un peu plus tard et plus en détail. Les serveurs VPN utilisés par les utilisateurs sont bloqués au fil du temps (généralement dans la journée suivant le début de l'utilisation).
- Des personnes vivant en Chine pensent que plus le cryptage du trafic est facile, plus il passe rapidement à la frontière, car il est facile de comprendre qu'il n'y a rien d'illégal. Et tout comme le trafic «propre» obtient plus de bande passante et de vitesse, et le trafic «sale», qui ne fait rien, obtient un passage plus lent au contraire. Pour un exemple, j'apporterai curl à ifconfig.co en utilisant les protocoles 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/s
La différence est de 5 secondes pour un temps de chargement total de 13 octets. En effectuant ce test plusieurs fois, vous pouvez voir que GET sur HTTP se termine en général en même temps à chaque fois, alors qu'en utilisant HTTPS le site répond parfois en 3, 5, 10 et même 17 secondes. Des erreurs SSL se produisent parfois:
Unknown SSL protocol error in connection to ifconfig.co:443.
Donc ce que nous avons:
- Les problèmes créés par le pare-feu chinois décrit ci-dessus.
- Les pings vers les ressources externes et les tunnels intérieurs disparaissent périodiquement.
- La latence entre deux points est en constante évolution, et souvent elle est tout simplement imprévisible. En connectant différentes villes / régions, vous vous attendez à ce qu'en fonction de la situation géographique des régions, le retard soit moindre et vous obtenez exactement la situation inverse.
- Les canaux Internet et de communication sont rapides ou lents. Il y a une légère dépendance à l'heure et au jour de la semaine, mais pas toujours.
- Les requêtes DNS vers le monde extérieur depuis la Chine dépassent parfois le délai d'attente autorisé.
L'image se profile simplement «excellente».
Le centre de données, comme je l'ai déjà dit, se trouve à l'est des États-Unis, et l'ensemble du SEMrush se compose de dizaines de produits, backends, frontends, bases de données interconnectés, et tout cela dans le centre de données et dans les nuages. En tant qu'équipe d'administrateurs système, nous avons été chargés d'un petit effort pour commencer rapidement à travailler en Chine.
Nous avons dû répondre à une question importante: pouvons-nous nous débrouiller avec un peu de sang et résoudre tous les problèmes liés à Internet chinois et au pare-feu au niveau du réseau / cloud / serveur?
Nous avons commencé par obtenir une licence ICP .
Licence ICP
Afin de pouvoir placer votre service en Chine (Chine continentale) et effectuer des tests, vous devez d'abord obtenir une licence de domaine ICP.
Si le trafic utilisateur de votre site est interrompu en Chine continentale, et si votre domaine n'a pas de licence ICP, votre trafic sera bloqué côté fournisseur / hébergement. Fait intéressant, un fournisseur spécifique s'intègre dans la licence ICP, que ce soit Cloudflare ou Alibaba Cloud. Par conséquent, si vous avez reçu une licence ICP pour Cloudflare et hébergé votre site avec eux, vous ne pourrez pas passer «en toute transparence» à Alibaba Cloud. Il sera nécessaire d'ajouter un hébergement supplémentaire à cette licence.
Ayant reçu une licence de domaine ICP, nous avons pu trouver et mettre en œuvre des idées et des solutions techniques spécifiques.
Solutions de test
Mais avant de créer directement les options de mise en scène, de tourner les boutons, d'optimiser le site et sa vitesse, vous devez choisir un outil pour le tester pour voir ce que nos actions améliorent ou aggravent le travail du site.
Notre outil de test devait répondre à deux exigences principales:
- il devrait pouvoir effectuer des tests en Chine,
- Il doit avoir des tests de navigateur.
Nous avons donc trouvé le point d' arrêt ! Ils ont une excellente couverture avec des points de test dans le monde entier. En Chine, grâce à cet outil, vous pouvez également exécuter des tests dans 100 500 provinces. Dans chacun, plusieurs fournisseurs différents + la possibilité de faire des tests Backbone (quelque chose comme une machine virtuelle dans un centre de données) et des tests Lastmile (aussi près que possible des conditions de l'utilisateur, alias poste de travail). Ce dernier type de test est plus cher.
Après avoir conclu un contrat d'un an (vous ne pouvez pas faire moins), nous avons commencé à étudier l'outil. Franchement, nous avons été agréablement surpris par sa fonctionnalité. Vous pouvez exécuter:
- Tests DNS
- Tests Web (navigateur, simple GET / POST, Ă©mulation d'un client mobile, etc.),
- ContrĂ´les transactionnels (par exemple, connexion),
- Tests API
- Ping, traceroute, NTP, etc.
Vous ne pouvez pas tout répertorier. Et surtout, chaque test peut être assez bien personnalisé en ajoutant un tas d'en-têtes et d'autres paramètres. Le résultat est une énorme quantité d'informations qui décrit pleinement votre test. Si nous parlons des plus intéressants pour nous (tests de navigateur), le résultat comprend:
- Se connecter, attendre, charger, SSL, heure DNS,
- TTFB, TTLB, Document terminé, Temps de rendu, Charge DOM,
- RĂ©ponse (quelque chose proche de Time To First Byte), RĂ©ponse de page Web (quelque chose proche de Time To Last Byte),
- N'importe quel centile, moyenne, temps médian
- Etc.
En conséquence, toutes ces métriques vous aident à voir les changements et à comprendre s'ils se sont améliorés. Nous avons principalement examiné Response, Webpage Response, Median, 75 et 95 Percentiles .
Une question importante qui se pose depuis le tout début: est- il possible de croire Catchpoint ? Cet outil reflète-t-il la vitesse réelle de chargement du site en Chine à partir de différentes villes ou s'agit-il simplement d'une sorte de test dans le vide qui n'a rien à voir avec une véritable expérience utilisateur?
C'est un gros problème, car être en Russie est presque impossible de savoir de manière fiable comment fonctionne le site chinois. En faisant socks-proxy via une machine virtuelle, vous obtenez un chargement de site Web en quelques minutes à la fin, ce qui est tout simplement inacceptable pour les tests, donc les boucles et les GET simples à partir de la console avec mesure du temps restent la seule option pour les tests manuels. Cela aide, car ce test reflète la vitesse de la solution réseau et s'il y a des tests de navigateur, c'est très bien.
Plus tard, nous sommes allés en Chine nous-mêmes et nous sommes assurés que Catchpoint peut être digne de confiance, il reflète assez précisément les vrais indicateurs de vitesse.
RĂ©seau Cloudflare Chine
Comme nous utilisons avec succès Cloudflare pour le domaine principal semrush.com, nous avons décidé d'essayer immédiatement leur fonctionnalité appelée China Network . Cette option est activée uniquement pour les sites Enterprise sur demande et moyennant des frais. Il est également disponible uniquement pour les sites qui ont la licence ICP appropriée, dans laquelle Cloudflare est spécifié comme fournisseur. Après son inclusion, le «CDN chinois» de Cloudflare devient disponible pour le site - le trafic en provenance des régions chinoises arrive dans le prochain PoP (Points of Presence) CF, puis il est livré à l'origine via ses réseaux ou réseaux de fournisseurs / partenaires.
Le schéma de ce banc d'essai est présenté ci-dessous.
C'est une excellente option pour nous. Il s'avère que le deuxième domaine sera également pour CF, ce qui n'ajoute pas le nombre de solutions utilisées dans l'entreprise et ne complique pratiquement pas l'infrastructure.
Nous avons exécuté les tests du navigateur, et c'est ce qui s'est produit:
Les diamants rouges sont des fichiers de test. Les fichiers ci-dessous sont des erreurs DNS (résoudre le délai). Les échecs ci-dessus sont des délais d'attente.
Disponibilité: 86,6
MĂ©diane: 18 s
75 centile: 29,3 s
95 centile: 60s
La médiane, après avoir supprimé le téléchargement de reCaptcha (un service Google bloqué en Chine), est passée de 28 à 18 secondes. Mais quand même, ce sont de terribles indicateurs, étant donné que le même test pour semrush.com (aux USA) a donné moins de 10 secondes pour 95% des utilisateurs (aux USA) à la même page (statique + dynamique).
Dans chaque test, vous pouvez aller voir Waterfall et d'autres paramètres plus détaillés. Nous avons commencé à enquêter sur les causes des erreurs, et si pour les délais d'attente tout est moins ou moins clair: Internet en Chine "se déplace vers le bas, puis s'éloigne", à cause de cela la vitesse de connexion et de chargement des ressources de l'étranger est instable et inégale, alors les erreurs DNS nous ont beaucoup surpris . Nous avons constaté que les PoPs de Cloudflare sont en effet situés en Chine, l'adresse du site se résout en une seule IP anycast, mais les serveurs DNS sont utilisés par les États-Unis, c'est pourquoi les requêtes DNS sont obligées de passer par la frontière, donc parfois elles échouent.
Après avoir clarifié cette question avec CF, il s'est avéré qu'ils n'ont pas leurs propres serveurs DNS en Chine , et on ne sait toujours pas quand ce sera le cas.
Par conséquent, nous avons décidé de tester uniquement DNS Cloudflare et changé le mécanisme Cloudflare pour notre site en mode « DNS uniquement ». C'est un tel mode lorsque Cloudflare ne procède pas à un trafic proxy via lui-même, ce qui signifie qu'il ne fournit pas de protection DDoS, CDN et d'autres fonctionnalités, et fonctionne en mode de serveur DNS normal.
Ce support est représenté schématiquement dans la figure suivante. La figure prend en compte la nouvelle connaissance que le serveur DNS Cloudflare se trouve derrière le pare-feu.
Chez Catchpoint, nous avons exécuté de simples tests GET (sans navigateur) qui ont montré de nombreux échecs. La raison en était toutes les mêmes erreurs DNS.
Nous avons commencé à déboguer ces erreurs à l'aide de dig et avons constaté que l'adresse est déterminée correctement lors de la première demande, et sur demande répétée nous obtenons SERVFAIL et non trouvé à chaque fois. Qu'est-ce que c'est tout d'un coup?
root@iZwz97n2wgbp61qucbfrjsZ:~
Lorsque vous demandez directement des serveurs Cloudflare NS, il n'y a pas de telles erreurs:
root@iZwz97n2wgbp61qucbfrjsZ:~
Cela signifie que le problème est du côté du serveur DNS «local» ou du serveur fournisseur.
Une enquête plus approfondie a montré que nous obtenons SERVFAIL sur la résolution du dossier AAAA .
Il s'est avéré que lorsque Cloudflare a demandé un enregistrement AAAA qui n'était pas dans le domaine, Cloudflare a répondu avec un enregistrement A , qui est une erreur et une incompatibilité RFC. À cause de cela, le résolveur local ( xxxx ) n'aimait pas cela, et il a répondu à SERVFAIL . Dans le journal ci-dessous, ce comportement est clairement visible:
root@iZwz97n2wgbp61qucbfrjsZ:~
Nous avons envoyé un rapport de bogue Cloudflare, et ils l'ont corrigé après un certain temps. Cela s'est avéré intéressant: à l'heure actuelle, il n'y a toujours pas de support IPv6 en Chine, donc Cloudflare n'a pas pu donner son adresse IPv6 en réponse à une demande d'enregistrement AAAA . Au final, tout a été décidé pour que China Cloudflare commence à répondre à NODATA à de telles demandes.
Ainsi, les erreurs DNS dans les tests Catchpoint ont fortement diminué, mais pas jusqu'à la fin. Les délais d'attente n'ont pas non plus disparu:
Et nous avons commencé à chercher une autre solution.
Dans la partie suivante, je dirai comment nous avons testé le cloud chinois d' Alibaba , comment, avec l'aide d'un peu "magique" Nginx, nous avons pu créer rapidement des solutions PoC (Proof of Concept), 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!
Toutes les pièces
2e partie
3e partie