Kaip mes įveikėme Didžiąją Kinijos ugniasienę (3 dalis)

Sveiki!
Visos geros istorijos baigiasi. Ir mūsų pasakojimas apie tai, kaip sugalvojome greitai įveikti Kinijos ugniasienę, nėra išimtis. Todėl skubu pasidalinti su jumis paskutiniu, paskutinė dalis šia tema.

Ankstesnėje dalyje kalbėjome apie daugybę bandymų stendų, kuriuos sugalvojome ir kokius rezultatus jie davė. Ir apsisprendėme, ką būtų malonu pridėti CDN! klampumui įtraukti į mūsų schemą.

Papasakosiu, kaip išbandėme Alibaba Cloud CDN, Tencent Cloud CDN ir Akamai ir kuo baigėsi. Ir, žinoma, apibendrinkime.

Alibaba Cloud CDN

Esame priglobti Alibaba Cloud ir iš jų naudojame IPSEC ir CEN. Būtų logiška pirmiausia išbandyti jų sprendimus.

„Alibaba Cloud“ turi dviejų rūšių produktus, kurie mums gali tikti: CDN и DCDN. Pirmoji parinktis yra klasikinis CDN konkrečiam domenui (subdomenui). Antrasis variantas reiškia Dinaminis CDN maršrutas (Aš tai vadinu dinaminiu CDN), jį galima įjungti visos svetainės režimu (pakaitos simbolių domenams), jis taip pat talpina statinį turinį ir pagreitina dinaminį turinį, tai yra, puslapio dinamika taip pat bus įkeliama per teikėjo greiti tinklai. Tai mums svarbu, nes iš esmės mūsų svetainė yra dinamiška, ji naudoja daug subdomenų, todėl patogiau vieną kartą nustatyti CDN „žvaigždutei“ - *.semrushchina.cn.

Šį produktą jau buvome matę ankstesniuose mūsų Kinijos projekto etapuose, tačiau tada jis dar neveikė, o kūrėjai pažadėjo, kad produktas greitai taps prieinamas visiems klientams. Ir jis padarė.

DCDN galite:

• sukonfigūruokite SSL nutraukimą su savo sertifikatu,
• paspartinti dinaminį turinį,
• lanksčiai konfigūruoti statinių failų talpyklą,
• išvalyti talpyklą,
• persiunčiami interneto lizdai,
• įgalinti glaudinimą ir net HTML gražintuvą.

Apskritai viskas yra taip pat, kaip ir suaugusiems bei dideliems CDN teikėjams.

Nurodius kilmę (vietą, kur bus CDN krašto serveriai), belieka sukurti žvaigždutei CNAME, nurodant all.semrushchina.cn.w.kunluncan.com (šis CNAME buvo gautas „Alibaba Cloud“ konsolėje) ir CDN veiks.

Remiantis bandymų rezultatais, šis CDN mums labai padėjo. Statistika rodoma žemiau.

sprendimas
Pasiekiamumas
Mediana
75 procentilis
95 procentilis

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

Tai labai geri rezultatai, ypač jei lyginate juos su skaičiais, kurie buvo pradžioje. Tačiau žinojome, kad mūsų svetainės www.semrush.com amerikietiškos versijos naršyklės testas iš JAV paleidžiamas vidutiniškai per 8.3 s (labai apytikslė vertė). Yra kur tobulėti. Be to, buvo ir CDN teikėjų, kuriuos buvo įdomu išbandyti.

Taigi sklandžiai pereiname prie kito milžino Kinijos rinkoje - Tencent.

Tencent debesis

Tencent dar tik kuria savo debesį – tai matyti iš nedaugelio produktų. Naudodami jį norėjome išbandyti ne tik jų CDN, bet ir visą tinklo infrastruktūrą:

• ar jie turi kažką panašaus į CEN?
• Kaip jiems veikia IPSEC? Ar tai greita, koks veikimo laikas?
• ar jie turi Anycast?

Pažvelkime į šiuos klausimus atskirai.

Analoginis CEN

Tencent turi produktą „Cloud Connect“ tinklas (CCN), leidžianti prijungti VPC iš skirtingų regionų, įskaitant regionus Kinijoje ir už jos ribų. Produktas dabar yra vidinio beta versijos, todėl turite sukurti bilietą, kuriame prašoma prisijungti prie jo. Iš palaikymo sužinojome, kad pasaulinės paskyros (kalbame ne apie Kinijos piliečius ar juridinius asmenis) negali dalyvauti beta versijos testavimo programoje ir apskritai sujungti regioną Kinijoje su regionu už jos ribų. 1:0 Ali Cloud naudai

IPSEC

Tencento piečiausias regionas yra Guangdžou. Sumontavome tunelį ir prijungėme jį prie Honkongo regiono GCP (tuomet šis regionas jau buvo prieinamas). Tuo pačiu metu buvo pakeltas ir antrasis tunelis Ali Cloud iš Šendženo į Honkongą. Paaiškėjo, kad per Tencent tinklą vėlavimas į Honkongą paprastai yra geresnis (10 ms) nei nuo Šendženo iki Honkongo iki Ali (120 ms – kas?). Bet tai jokiu būdu nepaspartino svetainės, skirtos dirbti per Tencentą ir šį tunelį, darbo, o tai pats savaime buvo nuostabus faktas ir dar kartą įrodė: delsa – Kinijai tai nėra rodiklis, kurio tikrai verta. atkreipkite dėmesį į tai, kai kuriate sprendimą, kaip perduoti Kinijos užkardą.

„Anycast“ interneto pagreitis

Kitas produktas, leidžiantis dirbti per Anycast IP AIA. Tačiau jis taip pat neprieinamas pasaulinėms paskyroms, todėl apie tai jums nepasakosiu, tačiau gali būti naudinga žinoti, kad toks produktas egzistuoja.

Tačiau CDN testas parodė keletą gana įdomių rezultatų. Tencent CDN negalima įjungti visoje svetainėje, tik tam tikruose domenuose. Sukūrėme domenus ir siuntėme srautą į juos:

Paaiškėjo, kad šis CDN turi šią funkciją: Tarpvalstybinio eismo optimizavimas. Ši funkcija turėtų sumažinti išlaidas, kai srautas praeina per Kinijos užkardą. Kaip Kilmė Buvo nurodytas Google GLB (GLB anycast) IP adresas. Taigi norėjome supaprastinti projekto architektūrą.

Rezultatai buvo labai geri – Ali Cloud CDN lygiu, o kai kur net geresni. Tai stebina, nes jei bandymai bus sėkmingi, galite atsisakyti nemažos dalies infrastruktūros, tunelių, CEN, virtualių mašinų ir kt.

Džiaugėmės neilgai, nes paaiškėjo problema: „Catchpoint“ bandymai nepavyko interneto tiekėjui „China Mobile“. Iš bet kurios vietos gavome skirtąjį laiką per Tencent CDN. Susirašinėjimas su technine pagalba nieko neprivedė. Šią problemą bandėme spręsti apie dieną, bet nieko nepavyko.

Tuo metu buvau Kinijoje, bet negalėjau rasti viešojo „Wi-Fi“ šio teikėjo tinkle, kad galėčiau asmeniškai patikrinti problemą. Kitaip viskas atrodė greitai ir gerai.
Tačiau dėl to, kad „China Mobile“ yra vienas iš trijų didžiausių operatorių, buvome priversti grąžinti srautą į Ali CDN.
Tačiau apskritai tai buvo gana įdomus sprendimas, vertas ilgesnio bandymo ir šios problemos trikčių šalinimo.

Akamai

Paskutinis mūsų išbandytas CDN teikėjas buvo Akamai. Tai didžiulis tiekėjas, turintis savo tinklą Kinijoje. Žinoma, mes negalėjome to apeiti.

Nuo pat pradžių susitarėme su Akamai dėl bandomojo laikotarpio, kad galėtume perjungti domeną ir pažiūrėti, kaip jis veiks jų tinkle. Visų testų rezultatus aprašysiu „Kas man patiko“ ir „Kas nepatiko“, taip pat pateiksiu testo rezultatus.

Kas man patiko:

• Vaikinai iš Akamų labai padėjo visais klausimais ir lydėjo mus visuose testavimo etapuose. Nuolat stengėmės kažką patobulinti iš savo pusės. Jie davė gerų techninių patarimų.
• „Akamai“ yra maždaug 10–15% lėtesnis nei mūsų sprendimas per „Ali Cloud CDN“. Įspūdinga tai, kad „Origin for Akamai“ nurodėme GLB IP adresą, o tai reiškia, kad srautas nevyko per mūsų sprendimą (galbūt galėtume atsisakyti dalies infrastruktūros). Tačiau vis tiek bandymo rezultatai parodė, kad šis sprendimas yra prastesnis nei mūsų dabartinė versija (palyginamieji rezultatai žemiau).
• Išbandyta ir „Origin GLB“, ir „Origin“ Kinijoje. Abi parinktys yra maždaug vienodos.
• Yra Žinomas maršrutas (automatinis maršruto optimizavimas). Galite priglobti bandomąjį objektą „Origin“, o „Akamai Edge“ serveriai bandys jį paimti (įprastas GET). Šioms užklausoms matuojamas greitis ir kiti rodikliai, kuriais remdamasis „Akamai“ tinklas optimizuoja maršrutus, kad mūsų svetainės eismas vyktų greičiau, ir buvo aišku, kad šios funkcijos įjungimas tikrai stipriai paveikė svetainės greitį.
• Konfigūracijos versija žiniatinklio sąsajoje yra puiku. Galite palyginti versijas, žiūrėti skirtumą. Peržiūrėti ankstesnes versijas.
• Pirmiausia galite išleisti naują versiją tik „Akamai Staging“ tinkle – tame pačiame tinkle kaip ir gamyboje, tik tokiu būdu tikriems vartotojams tai nepaveiks. Norėdami atlikti šį testą, turite suklastoti DNS įrašus vietiniame kompiuteryje.
• Labai greitas didelių statinių failų ir, matyt, kitų failų atsisiuntimo greitis per jų tinklą. Failas iš „šaltosios“ talpyklos nuskaitomas daug kartų greičiau nei tas pats failas iš „šaltosios“ Ali CDN talpyklos. Iš „karštos“ talpyklos greitis jau yra toks pat, pliusas ar minusas.

Ali CDN testas:

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

Akamai testas:

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

Pastebėjome, kad situacija aukščiau pateiktame pavyzdyje priklauso nuo įvairių veiksnių. Rašydamas šį punktą, testą atlikau dar kartą. Abiejų platformų rezultatai buvo maždaug vienodi. Tai rodo, kad internetas Kinijoje, net ir didelių operatorių ir debesų paslaugų teikėjų, kartais elgiasi skirtingai.

Prie ankstesnio punkto pridėsiu didelį Akamai pliusą: jei Ali rodo panašius didelio našumo ir labai mažo našumo blyksnius (tai taikoma Ali CDN, Ali CEN ir Ali IPSEC), tada Akamai kiekvieną kartą, nesvarbu. kaip aš testuoju jų tinklą, viskas veikia stabiliai.
„Akamai“ turi daug aprėpties Kinijoje ir dirba per daugelį paslaugų teikėjų.

Kas man nepatiko:

• Man nepatinka žiniatinklio sąsaja ir jos veikimo būdas – ji tokia prasta. Bet iš esmės prie to pripranti (tikriausiai).
• Bandymų rezultatai yra prastesni nei mūsų svetainėje.
• Atliekant bandymus klaidų yra daugiau nei mūsų svetainėje (veikimo laikas žemiau).
• Mes neturime savo DNS serverių Kinijoje. Taigi bandymuose yra daug klaidų dėl DNS sprendimo skirtojo laiko.
• Jie nepateikia savo IP diapazonų -> nėra galimybės užregistruoti teisingų set_real_ip_from mūsų serveriuose.

Metrika (~3626 paleidimai; visa metrika, išskyrus veikimo laiką, ms; vieno laikotarpio statistika):

CDN teikėjas
Mediana
75%
95%
atsakymas
Tinklalapio atsakymas
Pasiekiamumas
DNS
prisijungti
Laukti
Įkelti
SSL

AliCDN
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

Pasiskirstymas pagal procentilį (ms):

Procentilė
Akamai
AliCDN

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

Išvada tokia: Akamai variantas yra perspektyvus, tačiau neužtikrina tokio stabilumo ir greičio, kaip mūsų sprendimas kartu su Ali CDN.

Maži užrašai

Kai kurios akimirkos nebuvo įtrauktos į istoriją, bet apie jas taip pat norėčiau parašyti.

Pekinas + Tokijas ir Honkongas

Kaip sakiau aukščiau, mes išbandėme IPSEC tunelį į Honkongą (HK). Bet mes taip pat išbandėme CEN su HK. Kainuoja šiek tiek pigiau, o man buvo įdomu, kaip tai veiks tarp miestų, kurių atstumas ~100 km. Įdomu tai, kad vėlavimas tarp šių miestų yra 100 ms didesnis nei mūsų pradinėje versijoje (į Taivaną). Greitis, stabilumas taip pat buvo geresnis Taivanui. Dėl to mes palikome HK kaip atsarginį IPSEC regioną.

Be to, bandėme įdiegti šią instaliaciją:

• klientų nutraukimas Pekine,
• IPSEC ir CEN į Tokiją,
• Ali CDN serveris Pekine buvo nurodytas kaip kilmė.

Ši schema nebuvo tokia stabili, nors greičiu apskritai nenusileido mūsų sprendimui. Kalbant apie tunelį, aš mačiau protarpinius kritimus net CEN, kuris turėjo būti stabilus. Todėl grįžome prie senosios schemos ir šią inscenizaciją išmontavome.

Toliau pateikiama skirtingų kanalų delsos tarp skirtingų regionų statistika. Gal kam tai bus įdomu.

IPsec
Ali cn-pekinas <—> GCP asia-northeast1 – 193ms
Ali cn-Shenzhen <—> GCP asia-east2 – 91 ms
Ali cn-shenzhen <—> GCP us-east4 – 200 ms

CEN
Ali cn-peijing <—> Ali ap-northeast-1 – 54ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong – 6 ms (!)
Ali cn-shenzhen <—> Ali us-east1 — 216ms

Bendra informacija apie internetą Kinijoje

Kaip priedas prie interneto problemų, aprašytų pačioje pradžioje, pirmoje straipsnio dalyje.

• Internetas Kinijoje gana greitas viduje.
  • Išvada padaryta išbandžius viešuosius Wi-Fi tinklus įvairiose vietose, kur šiais tinklais naudojasi daug žmonių.
  • Atsisiuntimo ir siuntimo į serverius Kinijoje greitis buvo atitinkamai apie 20 Mbit/s ir 5-10 Mbit/s.
  • Greitis į serverius už Kinijos ribų yra tiesiog menkas, mažesnis nei 1 Mbit/s.
• Internetas Kinijoje nėra labai stabilus.
  • Kartais svetainės gali atsidaryti greitai, kartais lėtai (tuo pačiu paros metu skirtingomis dienomis), jei konfigūracija nesikeičia. Mes tai pastebėjome su semrushchina.cn pavyzdžiu. Tai galima priskirti Ali CDN, kuris taip pat veikia taip ir kitaip, priklausomai nuo paros laiko, žvaigždžių padėties ir pan.
• Mobilusis internetas beveik visur yra 4G arba 4G+. Pagauk jį metro, liftuose – trumpai tariant, visur.
• Tai mitas, kad Kinijos vartotojai pasitiki tik .cn zonoje esančiais domenais. Tai sužinojome tiesiogiai iš vartotojų.
  • Jūs galite pamatyti, kaip http://baidu.cn nukreipti į www.baidu.com (taip pat žemyninėje Kinijoje).
• Daugelis išteklių iš tikrųjų yra užblokuoti. Primityvus: google.com, Facebook, Twitter. Tačiau daugelis „Google“ išteklių veikia (žinoma, ne visuose „Wi-Fi“ tinkluose ir VPN nenaudojamas (ir maršrutizatoriaus pusėje, tai tikrai).
• Taip pat veikia daugelis „techninių“ blokuotų korporacijų domenų. Tai reiškia, kad ne visada neturėtumėte beatodairiškai atsisakyti visų „Google“ ir kitų, atrodo, užblokuotų išteklių. Turite ieškoti draudžiamų domenų sąrašo.
• Jie turi tik tris pagrindinius interneto operatorius: China Unicom, China Telecom, China Mobile. Yra ir mažesnių, tačiau jų užimama rinkos dalis – nežymi

Premija: galutinio sprendimo schema

Visas

Nuo projekto pradžios praėjo metai. Pradėjome nuo to, kad mūsų svetainė paprastai atsisakė normaliai dirbti iš Kinijos, o tiesiog GET curl užtruko 5.5 sekundės.

Tada su šiais rodikliais pirmame sprendime („Cloudflare“):

sprendimas
Pasiekiamumas
Mediana
75 procentilis
95 procentilis

Cloudflare
86.6
18s
30s
60s

Galiausiai pasiekėme šiuos rezultatus (praėjusio mėnesio statistika):

sprendimas
Pasiekiamumas
Mediana
75 procentilis
95 procentilis

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

Kaip matote, mums dar nepavyko pasiekti 100% veikimo laiko, bet ką nors sugalvosime, o tada apie rezultatus papasakosime naujame straipsnyje :)

Pagarba tiems, kurie perskaitė visas tris dalis iki galo. Tikiuosi, kad visa tai jums pasirodė taip pat įdomu, kaip man, kai tai dariau.

PS Ankstesnės dalys

Часть 1
Часть 2

Šaltinis: www.habr.com