Salut
Toute bonne histoire se termine. Et notre histoire sur la façon dont nous avons trouvé une solution au passage rapide du pare-feu chinois ne fait pas exception. Par conséquent, je m'empresse de partager avec vous la dernière et dernière partie sur ce sujet.
Dans la partie précédente, nous avons parlé de nombreux bancs d'essai inventés par nous et des résultats qu'ils ont obtenus. Et nous avons décidé que ce serait bien d'ajouter un CDN! pour la viscosité dans notre circuit.
Je vais vous dire comment nous avons testé Alibaba Cloud CDN, Tencent Cloud CDN et Akamai, et ce que j'ai fini avec. Et bien sûr, pour résumer.
Alibaba Cloud CDN
Nous sommes hébergés sur Alibaba Cloud, nous utilisons IPSEC et CEN d'eux. Il serait logique d'essayer d'abord leurs solutions.
Alibaba Cloud propose deux types de produits qui peuvent nous convenir: CDN et DCDN . La première option est un CDN classique pour un domaine spécifique (sous-domaine). La deuxième option représente Dynamic Route for CDN (je l'appelle Dynamic CDN), elle peut être activée en mode site complet (pour les domaines génériques), elle met également en cache la statique et accélère le contenu dynamique sur elle-même, c'est-à-dire que la dynamique de la page se chargera également rapidement fournisseur de réseau. Ceci est important pour nous, car notre site est essentiellement dynamique, il utilise de nombreux sous-domaines et il est plus pratique de configurer CDN une fois pour le "star" - * .semrushchina.cn.
Nous avons déjà vu ce produit aux premiers stades de notre projet chinois, mais il n'a pas encore fonctionné, et les développeurs ont promis que le produit serait disponible pour tous les clients très bientôt. Et il est devenu.
Dans DCDN, vous pouvez:
- configurer la terminaison SSL avec votre certificat,
- activer l'accélération du contenu dynamique,
- configurer de manière flexible la mise en cache des fichiers statiques,
- faire la purge du cache,
- jeter des sockets web,
- activer la compression et même HTML Beautifier.
En général, tout est comme les adultes et les grands fournisseurs de CDN.
Après que Origin (l'endroit où iront les serveurs de périphérie CDN) soit indiqué, il reste à créer un CNAME pour l'astérisque, en le reliant à all.semrushchina.cn.w.kunluncan.com (ce CNAME a été obtenu dans la console Alibaba Cloud), et CDN fonctionnera.
D'après les résultats des tests, ce CDN nous a beaucoup aidés. Les statistiques sont données ci-dessous.
Ce sont de très bons résultats, surtout si nous les comparons avec les chiffres au début. Mais nous savions que le test du navigateur de la version américaine de notre site www.semrush.com fonctionnait aux États-Unis en moyenne pendant 8,3 secondes (une valeur très approximative). Il y a beaucoup à faire. De plus, certains fournisseurs de CDN étaient intéressés par les tests.
Nous passons donc en douceur à un autre géant sur le marché chinois - Tencent .
Nuage Tencent
Tencent ne fait que développer son cloud - cela est évident dans un petit nombre de produits. Au cours de son utilisation, nous avons voulu tester non seulement leur CDN, mais aussi l'infrastructure réseau dans son ensemble:
- Ont-ils quelque chose de similaire au CEN?
- Comment IPSEC fonctionne-t-il pour eux? Est-ce rapide, qu'est-ce que la disponibilité?
- Ont-ils une diffusion?
Nous analyserons ces questions séparément.
Analog CEN
Tencent dispose d'un produit Cloud Connect Network ( CCN ) qui vous permet d'interconnecter des VPC de différentes régions, y compris des régions en Chine et à l'extérieur. Le produit est maintenant dans la version bêta interne, et vous devez créer un ticket avec une demande pour vous y connecter. Grâce à l'assistance, nous avons appris que les comptes mondiaux (ne concernant pas les citoyens chinois et les entités non juridiques) ne peuvent pas participer au programme de test bêta et connecter généralement la région à l'intérieur de la Chine avec la région à l'extérieur. 1-0 en faveur d'Ali Cloud
IPSEC
La région la plus au sud de Tencent est Guangzhou . Nous avons construit un tunnel et l'avons connecté à la région de Hong Kong dans le GCP (alors cette région était déjà disponible). Ils ont également soulevé le deuxième tunnel vers Ali Cloud de Shenzhen à Hong Kong en même temps. Il s'est avéré qu'à travers le réseau de latence Tencent, Hong Kong est généralement meilleur (10 ms) que de Shenzhen à Hong Kong à Ali (120 ms - quoi?). Mais cela n'a pas accéléré le travail du site, visant à traverser Tencent et ce tunnel, ce qui en soi était un fait étonnant et a une fois de plus prouvé ce qui suit: latence - pour la Chine ce n'est pas un indicateur auquel vous devez vraiment faire attention lors du développement d'une solution pour passer le chinois pare-feu.
Accélération Internet Anycast
Un autre produit qui vous permet de travailler via l'IP anycast est AIA . Mais il est également inaccessible aux comptes mondiaux, donc je n'en parlerai pas, mais savoir qu'un tel produit existe peut être utile.
Mais le test CDN a montré des résultats assez intéressants. Le CDN de Tencent ne peut pas être activé sur un site complet, uniquement sur des domaines spécifiques. Nous avons obtenu des domaines et commencé le trafic sur eux:
Il s'est avéré que ce CDN a la fonction suivante: Optimisation du trafic transfrontalier . Cette fonctionnalité devrait réduire les coûts lorsque le trafic traverse le pare-feu chinois. En tant qu'origine , l'adresse IP de Google GLB (GLB anycast) a été spécifiée. Nous avons donc voulu simplifier l'architecture du projet.
Les résultats étaient très bons - au niveau d'Ali Cloud CDN, et dans certains endroits encore mieux. Cela est surprenant, car si les tests réussissent, vous pouvez abandonner une partie importante de l'infrastructure, des tunnels, du CEN, des machines virtuelles, etc.
Nous ne sommes pas contents depuis longtemps, car le problème a été révélé: les tests de Catchpoint ont truqué pour le fournisseur Internet China Mobile. De n'importe quel endroit, nous avons obtenu un délai d'expiration via le CDN de Tencent. La correspondance avec le support technique n'a abouti à rien. Environ un jour, nous avons essayé de résoudre ce problème, mais rien n'en est sorti.
J'étais en Chine à ce moment-là, mais je n'ai pas pu trouver de Wi-Fi public sur le réseau de ce fournisseur pour vérifier personnellement le problème. Sinon, tout avait l'air rapide et bon.
Cependant, étant donné que China Mobile est l'un des trois plus grands opérateurs, nous avons été contraints de restituer du trafic à Ali CDN.
Mais en général, c'était une solution plutôt intéressante, qui mérite des tests et un dépannage plus longs de ce problème.
Akamai
Le dernier fournisseur CDN que nous avons testé est Akamai . Il s'agit d'un énorme fournisseur qui possède son propre réseau en Chine. Bien sûr, nous ne pouvions pas le dépasser.
Dès le début, nous avons convenu avec Akamai d'une période d'essai afin que nous puissions changer de domaine et voir comment cela fonctionnera sur leur réseau. Je décrirai le résultat de tous les tests sous la forme de «ce que j'ai aimé» et «ce que je n'ai pas aimé», ainsi que les résultats du test.
Qu'avez-vous aimé:
- Les gars d'Akamai ont beaucoup aidé dans tous les domaines et nous ont accompagnés à toutes les étapes des tests. Essayer constamment d'améliorer quelque chose de leur côté. Ils ont donné de bons conseils techniques.
- Akamai fonctionne environ 10 à 15% plus lentement que notre solution via Ali Cloud CDN. Il est impressionnant que dans Origin, nous ayons spécifié l'adresse IP GLB pour Akamai, c'est-à-dire que le trafic ne soit pas passé par notre solution (vous pouvez potentiellement abandonner une partie de l'infrastructure). Mais encore, les résultats des tests ont montré que cette solution est pire que notre version actuelle (résultats comparatifs ci-dessous).
- Testé à la fois Origin GLB et Origin en Chine. Les deux options sont à peu près les mêmes.
- Il existe un Sure Route (optimisation automatique du routage). Vous pouvez héberger l'objet de test sur Origin, et le serveur Akamai Edge essaiera de le récupérer (GET normal). Pour ces demandes, la vitesse et d'autres métriques sont mesurées, sur la base desquelles le réseau Akamai optimise les itinéraires afin que le trafic augmente plus rapidement pour notre site et on peut voir que l'inclusion de cette fonctionnalité a vraiment eu un grand effet sur la vitesse du site.
- La version de la configuration dans l'interface Web est cool. Vous pouvez comparer les versions, voir diff. Afficher les versions précédentes.
- Vous pouvez d'abord déployer la nouvelle version uniquement sur le réseau Akamai Staging - le même réseau que la production, mais de cette façon, cela n'affecte pas les utilisateurs réels. Pour ce test, vous devez usurper des enregistrements DNS sur la machine locale.
- Vitesse de téléchargement très rapide grâce à leur réseau de grandes statiques et, apparemment, de tout autre fichier. Un fichier du cache «froid» est pris plusieurs fois plus vite que le même fichier du cache «froid» Ali CDN. Depuis le cache «chaud», la vitesse est déjà plus ou moins la même.
Test Ali CDN:
root@shenzhen1:~
Test Akamai:
root@shenzhen1:~
Nous avons remarqué que la situation de l'exemple ci-dessus dépend de divers facteurs. Au moment d'écrire ces lignes, j'ai relancé le test. Les résultats pour les deux plates-formes étaient approximativement les mêmes. Cela nous indique que l'Internet en Chine, même pour les grands opérateurs et les fournisseurs de cloud, se comporte de temps en temps différemment.
J'ajouterai un gros plus à Akamai au paragraphe précédent: si Ali montre de tels flashs de haute performance et très bas (cela s'applique à Ali CDN, Ali CEN et Ali IPSEC), puis à Akamai à chaque fois, peu importe comment je teste leur réseau, tous fonctionne de manière stable.
Akamai a vraiment beaucoup de couverture en Chine et travaille avec de nombreux fournisseurs.
Ce qui n'a pas plu:
- Je n'aime pas l'interface Web et le plan de travail - ce sont zéro. Mais au fond, on s'y habitue (probablement).
- Les résultats des tests sont pires que notre site.
- Il y a plus d'erreurs lors des tests que sur notre site (disponibilité ci-dessous).
- Il n'y a pas de serveurs DNS en Chine. À partir de là, il y a beaucoup d'erreurs dans les tests en raison du délai d'expiration de la résolution DNS.
- Ne fournissez pas leurs plages IP -> il n'y a aucun moyen d'enregistrer le set_real_ip_from correct sur nos serveurs.
Métriques (~ 3626 exécutions; toutes les métriques sauf Uptime en ms; statistiques pour une période de temps):
Distribution centile (en ms):
La conclusion est la suivante: l'option avec Akamai est viable, mais ne donne pas les mêmes indicateurs de stabilité et de vitesse que notre propre solution, couplée à Ali CDN.
Petites notes
Certains points n'étaient pas inclus dans l'histoire, mais j'aimerais aussi en parler.
Pékin + Tokyo et Hong Kong
Comme je l'ai dit plus haut, nous avons testé le tunnel IPSEC vers Hong Kong (HK). Mais nous avons également testé CEN avant HK. Cela coûte un peu moins cher, et il était intéressant de voir comment cela fonctionnera entre les villes avec une distance d'environ 100 km. Il s'est avéré intéressant que la latence entre ces villes soit 100 ms plus élevée que dans notre version d'origine (à Taiwan). La vitesse et la stabilité étaient également meilleures pour Taïwan. En conséquence, nous avons quitté HK en tant que région IPSEC de sauvegarde.
De plus, nous avons essayé de monter une telle installation:
- résiliation client à Pékin,
- IPSEC et CEN à Tokyo,
- à Ali, le CDN était répertorié comme serveur d'origine à Pékin.
Ce schéma n'était pas aussi stable, bien qu'en termes de vitesse dans son ensemble il n'était pas inférieur à notre solution. Quant au tunnel, j'ai vu des baisses périodiques même pour le CEN, qui était censé être stable. Par conséquent, nous sommes revenus à l'ancien schéma et avons démantelé cette mise en scène.
Vous trouverez ci-dessous les statistiques sur la latence entre différentes régions sur différents canaux. Peut-être que quelqu'un s'y intéressera.
IPsec
Ali CN-Pékin <--> GCP Asie-Nord-Est1 - 193ms
Ali CN-Shenzhen <--> GCP Asia-East2 - 91ms
Ali cn-shenzhen <--> GCP us-east4 - 200ms
Cen
Ali cn-beijing <---> Ali ap-nord-est-1 - 54ms (!)
Ali cn-shenzhen <---> Ali cn-hongkong - 6ms (!)
Ali CN-Shenzhen <---> Ali US-East1 - 216ms
En complément des problèmes d'Internet, décrits au tout début, dans la première partie de l'article.
- L'Internet en Chine est assez rapide à l'intérieur.
- La conclusion est faite sur la base de tests de réseaux Wi-Fi publics dans divers endroits où ces réseaux sont utilisés par un grand nombre de personnes.
- Les vitesses de téléchargement et de téléchargement vers des serveurs en Chine étaient d'environ 20 Mbps et 5-10 Mbps, respectivement.
- La vitesse vers les serveurs en dehors de la Chine est tout simplement misérable, moins de 1 Mbps.
- Internet en Chine n'est pas très stable.
- Parfois, les sites peuvent s'ouvrir rapidement, parfois lentement (à la même heure de la journée à des jours différents), à condition que la configuration ne change pas. Nous l'avons observé avec l'exemple de semrushchina.cn. Cela peut être attribué à Ali CDN, qui fonctionne également de cette façon et que, selon l'heure de la journée, la position des étoiles, etc.
- L'Internet mobile est presque partout 4G ou 4G +. Captures dans le métro, les ascenseurs - bref, partout.
- Le fait que les utilisateurs chinois ne fassent confiance qu'aux domaines de la zone .cn est un mythe. Nous l'avons appris directement des utilisateurs.
- Vous pouvez voir comment http://baidu.cn redirige vers www.baidu.com (également en Chine continentale).
- De nombreuses ressources sont vraiment bloquées. Primitif: google.com, Facebook, Twitter. Mais de nombreuses ressources Google fonctionnent (bien sûr, tous les Wi-Fi et VPN ne sont pas utilisés en même temps (du côté du routeur, c'est sûr).
- De nombreux domaines «techniques» des sociétés bloquées fonctionnent également. Cela signifie que vous ne devez pas toujours supprimer imprudemment toutes les ressources Google et autres ressources apparemment bloquées. Vous devez rechercher une liste de domaines interdits.
- Ils n'ont que trois principaux fournisseurs d'accès à Internet: China Unicom, China Telecom, China Mobile. Il y en a encore plus petits, mais leur part de marché est insignifiante
Bonus: schéma de décision finale
Résumé
Un an s'est écoulé depuis le début du projet. Nous avons commencé par dire que notre site, en principe, refusait de fonctionner normalement depuis la Chine, mais simplement GET curl a pris 5,5 secondes.
Ensuite, avec de tels indicateurs dans la première décision (Cloudflare):
En conséquence, nous sommes arrivés aux résultats suivants (statistiques du mois dernier):
Comme vous pouvez le voir, le temps de disponibilité à 100% n'a pas encore été atteint, mais nous trouverons quelque chose, puis nous vous informerons des résultats dans un nouvel article :)
À celui qui a lu les trois parties jusqu'au bout - respect. J'espère que vous étiez tous aussi intéressés que moi quand je l'ai fait.
Pièces précédentes PS
Partie 1
2e partie