🥇 Si e kaluam Murin e Madh të Kinës (pjesa 3)

🥇Si të arrish në qiell dhe të bëhesh pilot | ProHoster
Çdo histori e mirë ka një përfundim. Dhe historia jonë për mënyrën se si gjetëm një zgjidhje për kalimin e shpejtë të Murit të Kinës nuk është përjashtim. Prandaj, po shpejtoj të ndaj me ju pjesën përfundimtare, pjesa përfundimtare në lidhje me këtë temë.

Në pjesën e mëparshme u tregua për shumë ambiente testi që ne i menduam dhe për rezultatet që ato sollën. Dhe we stopuam te ideja se do ishte mirë të shtonim CDN! për kohezion në skemën tonë.

Do t'ju tregoj si testuam Alibaba Cloud CDN, Tencent Cloud CDN dhe Akamai, dhe mbi çfarë rezultati u ndalëm. Natyrisht, do të bëjmë një përmbledhje.

Alibaba Cloud CDN

Ne jemi hostuar në Alibaba Cloud, përdorim IPSEC dhe CEN nga ata. Ka kuptim që së pari të provojmë zgjidhjet e tyre.

Alibaba Cloud ka dy lloje produktesh që mund të na përshtaten: CDN dhe DCDN. Opsioni i parë është një CDN klasik për një domain të caktuar (në subdomain). Opsioni i dytë shpërndahet si Dynamic Route for CDN (unë e quaj CDN dinamik), mund të aktivizohet në modalitetin Full-site (për domain-e wildcard), gjithashtu ndihmon në ruajtjen e statikës dhe përshpejton ngarkimin e përmbajtjes dinamike, domethënë dinamika e faqes gjithashtu do të ngarkohet përmes rrjeteve të shpejta të ofruesit. Kjo është e rëndësishme për ne, sepse kryesisht kemi një faqe dinamike, me shumë subdomains, dhe më mirë është të konfigurojmë CDN një herë për “yllin” — *.semrushchina.cn.

Ne tashmë e kishim parë këtë produkt në fazat e hershme të projektit tonë në Kinë, por atëherë ai nuk funksiononte ende, dhe zhvilluesit kishin premtuar se shumë shpejt produkti do të bëhet i disponueshëm për të gjithë klientët. Dhe ai u bë.

Në DCDN mund të:

konfigurosh terminimin SSL me certifikatin tënd,
aktivizosh përshpejtimin e përmbajtjes dinamike,
konfigurosh ndjeshëm ruajtjen e skedave statike,
të realizosh purge të caches,
të kalosh web-sockets,
të aktivizosh kompresimin dhe madje edhe HTML Beautifier.

Në përgjithësi, gjithçka është si te ofruesit e mëdhenj dhe të rritur CDN.

Pas caktimit të Origin (vendit ku do të shkojnë serverët edge të CDN), mbetet të krijosh një CNAME për yllin, i cili i referohet all.semrushchina.cn.w.kunluncan.com (ky CNAME u mor në konsolën e Alibaba Cloud), dhe CDN do të fillojë të funksionojë.

Sipas rezultateve të testimeve, ky CDN na ndihmoi shumë. Statistikat e paraqitura më poshtë.

Zgjidhja
Uptime
Median
75 Percentile
95 Percentile

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

Këto janë rezultate shumë të mira, sidomos kur i krahasojmë me numrat që kishim në fillim. Por e dinim që testi i shfletuesit për versionin amerikan të faqes sonë www.semrush.com është realizuar në SHBA mesatarisht për 8.3s (një vlerë shumë e afërt). Ka ende për të arritur. Për më tepër, kishte edhe ofrues CDN që ishin interesante për t'u testuar.

Kështu kalojmë në një gjigand tjetër në tregun kinez — Tencent.

Tencent Cloud

Tencent po e zhvillon ende cloud-in e tij — kjo duket nga numri i vogël i produkteve. Gjatë përdorimit të tij, ne donim të testonim jo vetëm CDN-in e tyre, por edhe në përgjithësi infrastrukturën rrjetësore:

a kanë ndonjë gjë të ngjashme me CEN?
si funksionon IPSEC tek ata? A është i shpejtë, çfarë uptime-i ka?
a kanë Anycast?

Të shqyrtojmë këto çështje një për një.

E ngjashme me CEN

Tencent ka një produkt Cloud Connect Network (CCN), i cili lejon lidhjen e VPC-ve nga rajone të ndryshme, përfshirë rajonet brenda dhe jashtë Kinës. Produkti tani është në beta të brendshme, dhe duhet të krijoni një tiket për t'u lidhur me të. Nga mbështetje, mësuam se llogaritë globale (nuk flasim për qytetarët kinezë apo persona juridikë) nuk mund të marrin pjesë në programin e beta testimit dhe në përgjithësi të lidhin një rajon brenda Kinës me një rajon jashtë. 1-0 në favor të Ali Cloud

IPSEC

Rajoni më jugor te Tencent — Guangzhou. Ne ndërtuam një tunel dhe e lidhëm atë me rajonin e Hong Kongut në GCP (atëherë ky rajon ishte tashmë i aksesueshëm). Gjithashtu ngritëm një tunel të dytë në Ali Cloud nga Shenzhen në Hong Kong. Doli se latenca përmes rrjetit Tencent ishte më e mirë për në Hong Kong (10ms), sesa nga Shenzhen në Hong Kong në Ali (120ms — çfarë?). Por kjo nuk e përshpejtonte punën e faqes, e cila ishte orientuar për të punuar përmes Tencent dhe këtij tuneli, që vetë ishte një fakt përcaktues dhe provonte sërish se: latenca — për Kinën nuk është një tregues që vlen të merret parasysh gjatë zhvillimit të zgjidhjeve për kalimin e firewall-it kinez.

Anycast Internet Acceleration

Një produkt tjetër që lejon punën përmes IP-ve anycast — AIA. Por ai gjithashtu nuk është i aksesueshëm për llogaritë globale, prandaj nuk do ta përshkruaj, por të dish se një produkt i tillë ekziston mund të jetë i dobishëm.

Të dhënat nga testi CDN treguan rezultate mjaft interesante. CDN-i te Tencent nuk mund të aktivizohet për faqen e plotë, vetëm për domain specifik. Ne regjistruam domainet dhe lejuam trafikun mbi to:

Doli se ky CDN ka këtë funksion: Optimizimi i Trafikut Ndërkufitar. Ky funksion duhet të ulë kostot kur trafiku kalon përmes firewall-it të Kinës. Si Origjina u caktua adresa IP e GLB të Google (GLB anycast). Kështu ne do të thjeshtojmë arkitekturën e projektit.

Rezultatet ishin shumë të mira — në nivelin e Ali Cloud CDN, dhe ndonjëherë edhe më mirë. Kjo është befasuese, sepse në rastin e suksesit të testeve, mund të heqim dorë nga një pjesë e konsiderueshme e infrastrukturës, tuneleve, CEN, mahnive virtuale etj.

Nuk qëndruam gjatë në gëzim, pasi doli në pah një problem: testet në Catchpoint dështuan për operatorin e Internetit China Mobile. Nga çdo vendndodhje merrnim kohëzgjatje përmes CDN të Tencent-it. Korrespondenca me mbështetje teknike nuk shpuri në asgjë. Rreth një ditë përpiqeshim të zgjidhnim këtë problem, por asgjë nuk arritëm.

Isha në atë moment në Kinë, por nuk arrita të gjeja Wi-Fi publik në rrjetin e këtij operatori, për të verifikuar problemin personalisht. Përndryshe, gjithçka dukej e shpejtë dhe mirë.
Megjithatë, për shkak se operatori China Mobile është një nga tre operatorët më të mëdhenj, u detyruam të rikthejmë trafikun në Ali CDN.
Por në përgjithësi, ishte një zgjidhje mjaft interesante, e cila meriton më shumë testime dhe troubleshooting të këtij problemi.

Akamai

CDN i fundit që testuam ishte Akamai. Ky është një ofrues i madh, i cili ka rrjetin e tij në Kinë. Sigurisht, nuk mundëm të kalojmë përtej tij.

Që nga fillimi, u dakorduam me Akamai për një periudhë testimi, kështu që mund të kalojmë domenin dhe të shikojmë se si do të funksionojë në rrjetin e tyre. Do të përshkruaj rezultatet e gjithë testimeve në formën e “Çfarë na pëlqeu” dhe “Çfarë nuk na pëlqeu”, si dhe do të jap rezultatet e testeve.

Çfarë na pëlqeu:

Djemtë nga Akamai na ndihmuan shumë me të gjitha çështjet dhe na shoqëruan në të gjitha fazat e testimit. Po mundoheshin vazhdimisht të përmirësonin disa gjëra nga ana e tyre. Jepte këshilla të mira teknike.
Akamai punon rreth 10-15% më ngadalë se zgjidhja jonë përmes Ali Cloud CDN. E habitshme është se në Origjinë për Akamai caktuam adresën IP të GLB, që do të thotë trafiku nuk shkonte përmes zgjidhjes sonë (potencialisht mund të heqim dorë nga një pjesë e infrastrukturës). Por megjithatë rezultatet e testeve treguan se kjo zgjidhje ishte më e keqe se opsioni ynë aktual (rezultatet krahasuese më poshtë).
Iu testua si Origjinë GLB, ashtu edhe Origjinë në Kinë. Të dyja opsionet ishin më ose pak të njëjta.
Ka Ruga e Sigurtë (optimizimi automatik i routingut). Mund të vendosni një objekt testues në Origin, dhe serverët Edge të Akamai do të përpiqen ta marrin atë (GET i zakonshëm). Për këto kërkesa matet shpejtësia dhe metrika të tjera, në bazë të të cilave rrjeti Akamai optimizon rrugët, që trafik të kalojë më shpejt për faqen tonë dhe të duket se aktivizimi i kësaj karakteristike vërtet ka ndikuar ndjeshëm në shpejtësinë e punës së faqes.
Versionimi i konfigurimit në ndërfaqen e uebit – është fantastike. Mund të bëni Krahasoni për versionet, të shihni diferencat. Shihni versionet e kaluara.
Mund të shërbehet një version i ri fillimisht vetëm në rrjetin Staging të Akamai – një rrjet të njëjtë si prokurimi, vetëm që kjo rrugë nuk ndikon te përdoruesit e vërtetë. Për këtë test duhet të bëni spufing të regjistrave DNS në makinën lokale.
Shpejtësi shumë e shpejtë ngarkimi përmes rrjetit të tyre të statikës së madhe, dhe, duket, çdo skedari tjetër. Një skedar nga "cache e ftohtë" merret me shumë shpejtësi më shumë se po të ishte po ai skedar nga "cache e ftohtë" i Ali CDN. Nga "cache e ngrohtë", shpejtësia tashmë është më shumë-më pak e njëjtë.

Testi 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/s

Testi 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/s

Kemi vënë re se situata në shembullin e mësipërm varet nga faktorë të ndryshëm. Në momentin kur e shkruaj këtë pikë, kam bërë një test tjetër. Rezultatet për të dy platformat dolën rreth të njëjtave. Kjo na thotë se interneti në Kinë, madje edhe për operatorët e mëdhenj dhe ofruesit e cloud, vepron herë pas here ndryshe.

Përsa i përket pikës paraprake, do të shtoja një avantazh të madh për Akamai: nëse në Ali shihen shpërthime të tilla të performancës së lartë dhe shumë të ulët (kjo vlen si për Ali CDN, ashtu edhe për Ali CEN dhe Ali IPSEC), për Akamai çdo herë, sa herë që testeve rrjetin e tyre, gjithçka funksionon stabilisht.
Akamai në të vërtetë ka një mbulim të madh në Kinë dhe punon përmes shumë ofruesve.

Çfarë nuk më pëlqeu:

Nuk më pëlqen ndërfaqja e internetit dhe skema e punës — janë të tilla të dobëta. Por në parim, e merr me mend (ndoshta).
Rezultatet e testeve janë më të këqija se platforma jonë.
Gabimet gjatë testeve janë më të shumta se në platformën tonë (uptime më i ulët).
Nuk ka serverë DNS të tyre në Kinë. Nga kjo, ka shumë gabime në teste për shkak të DNS resolve timeout.
Nuk ofrojnë gama të tyre të IP-ve -> nuk ka mundësi për të shkruar korrektisht set_real_ip_from në serverët tanë.

Metrikat (~3626 të pastra; të gjitha metrikat, përveç Uptime, në ms; statistika për një interval kohor):

Ofruesi i CDN
Median
75%
95%
Përgjigjja
Përgjigjja e Webfaqes
Uptime
DNS
Lidhja
Pritja
Ngarko
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

Shpërndarja sipas Percentile (në ms):

Percentile
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

Përfundimi është se varianti me Akamai është i aftë për jetesë, por nuk ofron ato të njëjtat tregues të stabilitetit dhe shpejtësisë si zgjidhja jonë vetë së bashku me Ali CDN.

Shënime të vogla

Disa momente nuk u përfshinë në narracion, por do të doja të shkruaja gjithashtu për to.

Pekin + Tokio dhe Hong Kong

Siç kam thënë më lart, ne testuam tunelin IPSEC deri në Hong Kong (HK). Por gjithashtu e testuam edhe CEN deri në HK. Ai kushton pak më lirë, dhe ishte interesante se si do të funksiononte mes qyteteve me një distancë ~100km. E veçanta ishte se latenca mes këtyre qyteteve ishte 100ms më e lartë se në variantin tonë origjinal (deri në Tajvan). Shpejtësia, stabiliteti gjithashtu ishin më të mira për Tajvanin. Si përfundim, ne e lanë HK si një rajon backup IPSEC.

Për më tepër, provuam të ngrinim një instalim të tillë:

terminimi i klientëve në Pekin,
IPSEC dhe CEN deri në Tokio,
në Ali CDN u shënua si server origjinal në Pekin.

Kjo skemë nuk ishte kaq e qëndrueshme, megjithatë, në përgjithësi nuk iu dorëzua zgjidhjes sonë. Sa i përket tunelit, kam parë rënie periodike edhe për CEN-in, i cili duhej të ishte stabil. Prandaj u kthyem në skemën e vjetër dhe e shqyrtuam këtë staging.

Më poshtë është statistika mbi latencën midis rajoneve të ndryshme për kanale të ndryshme. Ndoshta do t'i interesojë dikujt.

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

Informacion e përgjithshme rreth internetit në Kinë

Si një shtesë për problemet me internetin, të përshkruara në fillim, në pjesën e parë të artikullit.

Internet në Kinë funksionon mjaft shpejt brenda vendit.
- Kjo përfundim buron nga testimi i rrjeteve publike Wi-Fi në vende të ndryshme, ku këto rrjete përdoren nga shumë njerëz.
- Shpejtësia e shkarkimit dhe ngarkimit në serverët brenda Kinës ishte rreth 20 mb/s dhe 5-10 mb/s përkatësisht.
- Shpejtësia drejt serverëve jashtë Kinës është thjesht minimale, më pak se 1 mb/s.
Internet në Kinë nuk është shumë stabil.
- Disa herë faqet mund të hapen shpejt, disa herë ngadalë (në të njëjtën periudhë kohore në ditë të ndryshme), për sa kohë që konfigurimi nuk ndryshon. Kjo është vërejtur në shembullin semrushchina.cn. Kjo mund të shkaktohet nga Ali CDN, i cili gjithashtu punon ndonjëherë mirë, ndonjëherë keq, në varësi të orës dhe pozitat e yjeve, etj.
Internet celular është praktikisht 4G ose 4G+ kudo. Kapet në metro, ashensorë — në shkurt, kudo.
Miti është se përdoruesit kinezë besojnë vetëm në domenet në zonën .cn. Ne e verifikuam këtë drejtpërdrejt nga përdoruesit.
- Mund të shihni se http://baidu.cn redirekton në www.baidu.com (edhe në mainland China).
Shumë burime janë vërtet të bllokuara. Në mënyrë primitive: google.com, Facebook, Twitter. Por shumë burime të Google funksionojnë (sigurisht, jo në të gjithë Wi-Fi dhe VPN nuk përdoret (as nga routeri, kjo është e sigurt).
Shumë 'domenet teknike' e kompanive të bllokuara gjithashtu funksionojnë. Kjo do të thotë se nuk duhet të hidhen në mënyrë të paarsyeshme të gjitha burimet e dukshme të bllokuara. Duhet të kërkoni një listë të domainëve të ndaluar.
Ata kanë vetëm tre operatorë të mëdhenj të internetit: China Unicom, China Telecom, China Mobile. Ka disa të vogla, por pjesa e tyre në treg është e papërfillshme.

Bonus: skema përfundimtare e zgjidhjes

Përfundimi

Ka kaluar një vit nga fillimi i projektit. Filluam me faktin se faqja jonë refuzonte të funksiononte normalisht nga Kina, dhe thjesht një GET curl merrte 5.5 sekonda.

Pastaj, nga këto tregues në zgjidhjen e parë (Cloudflare):

Zgjidhja
Uptime
Median
75 Percentile
95 Percentile

Cloudflare
86.6
18s
30s
60s

Më në fund arritëm në këto rezultate (statistika për muajin e fundit):

Zgjidhja
Uptime
Median
75 Percentile
95 Percentile

Ali CDN + CEN/IPsec + GLB
99.86
8.8s
9.5s
13.7s

Siç duket, derisa nuk kemi arritur të arrijmë një kohëzgjatje prej 100%, por ne do të gjejmë ndonjëherë një zgjidhje, dhe më pas do t’ju tregojmë rezultatet në një artikull të ri :)

Atij që e lexoi deri në fund të tre pjesëve — respekt. Shpresoj se gjithçka ishte po aq e interesante për ju sa ishte për mua kur e bëja këtë.