Lep pozdrav!
Vseh dobrih zgodb je enkrat konec. In naša zgodba o tem, kako smo prišli do rešitve za hitro prestopanje kitajskega požarnega zidu, ni izjema. Zato z vami hitim deliti zadnjo, zadnji del na to temo.
V prejšnjem delu smo govorili o številnih preskusnih mizah, ki smo jih izdelali, in kakšne rezultate so dali. In dogovorili smo se, kaj bi bilo lepo dodati CDN! za viskoznost v našo shemo.
Povedal vam bom, kako smo preizkusili Alibaba Cloud CDN, Tencent Cloud CDN in Akamai ter kaj smo na koncu dobili. In seveda, povzamemo.
Alibaba Cloud CDN
Gostujemo v oblaku Alibaba in od njih uporabljamo IPSEC in CEN. Logično bi bilo najprej preizkusiti njihove rešitve.
Alibaba Cloud ima dve vrsti izdelkov, ki nam lahko ustrezata: CDN и DCDN. Prva možnost je klasični CDN za določeno domeno (poddomeno). Druga možnost pomeni Dinamična pot za CDN (jaz temu pravim dinamični CDN), omogoči se lahko v načinu Full-site (za domene z nadomestnimi znaki), prav tako predpomni statično vsebino in pospeši dinamično vsebino na sebi, se pravi, da se bo dinamika strani nalagala tudi preko ponudnikovega hitra omrežja. To je za nas pomembno, ker je v bistvu naše spletno mesto dinamično, uporablja veliko poddomen in je bolj priročno enkrat nastaviti CDN za "zvezdico" - *.semrushchina.cn.
Ta izdelek smo že videli v prejšnjih fazah našega kitajskega projekta, vendar takrat še ni deloval in razvijalci so obljubili, da bo izdelek kmalu na voljo vsem strankam. In je.
V DCDN lahko:
- konfigurirajte prekinitev SSL z vašim potrdilom,
- omogočajo pospeševanje dinamičnih vsebin,
- prilagodljivo konfiguriranje predpomnjenja statičnih datotek,
- počisti predpomnilnik,
- posredovanje spletnih vtičnic,
- omogočite stiskanje in celo HTML Beautifier.
Na splošno je vse enako kot pri odraslih in velikih ponudnikih CDN.
Ko je Origin (kraj, kamor bodo šli robni strežniki CDN) določen, je vse, kar ostane, ustvariti CNAME za zvezdico, ki se nanaša na all.semrushchina.cn.w.kunluncan.com (ta CNAME je bil prejet v konzoli Alibaba Cloud) in CDN bo deloval.
Glede na rezultate testiranja nam je ta CDN zelo pomagal. Statistika je prikazana spodaj.
odločitev
Uptime
Mediana
75 percentil
95 percentil
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
To so zelo dobri rezultati, sploh če jih primerjate s številkami, ki so bile na začetku. Vedeli pa smo, da test brskalnika ameriške različice naše spletne strani www.semrush.com teče iz ZDA v povprečju 8.3 s (zelo približna vrednost). Obstaja prostor za izboljšave. Poleg tega so bili tudi CDN ponudniki, ki so bili zanimivi za testiranje.
Tako se gladko premaknemo k drugemu velikanu na kitajskem trgu - Tencent.
Tencentov oblak
Tencent šele razvija svoj oblak – to se vidi iz majhnega števila izdelkov. Med uporabo smo želeli preizkusiti ne le njihov CDN, ampak tudi njihovo omrežno infrastrukturo kot celoto:
- imajo kaj podobnega CEN-u?
- Kako jim deluje IPSEC? Je hiter, kakšen je čas delovanja?
- imajo Anycast?
Oglejmo si ta vprašanja ločeno.
Analogni CEN
Tencent ima izdelek Omrežje Cloud Connect (), kar vam omogoča povezovanje VPC-jev iz različnih regij, vključno z regijami znotraj in zunaj Kitajske. Izdelek je zdaj v interni različici beta in morate ustvariti vstopnico za povezavo z njim. Od podpore smo izvedeli, da globalni računi (ne govorimo o kitajskih državljanih ali pravnih osebah) ne morejo sodelovati v programu testiranja beta in na splošno povezati regijo znotraj Kitajske z regijo zunaj. 1-0 v korist Alija Oblaka
IPSEC
Najjužnejša regija Tencenta je Guangzhou. Sestavili smo tunel in ga povezali z regijo Hong Kong v GCP (takrat je ta regija že postala na voljo). Istočasno je bil dvignjen tudi drugi predor v Ali Cloudu od Shenzhena do Hongkonga. Izkazalo se je, da je prek omrežja Tencent zakasnitev do Hong Konga na splošno boljša (10 ms) kot od Shenzhena do Hong Konga do Alija (120 ms - kaj?). Vendar to nikakor ni pospešilo dela spletnega mesta, namenjenega delovanju prek Tencenta in tega tunela, kar je bilo samo po sebi neverjetno dejstvo in je še enkrat dokazalo naslednje: zakasnitev - za Kitajsko to ni indikator, ki bi bil resnično vreden bodite pozorni pri razvoju rešitve za prehod kitajskega požarnega zidu.
Internetni pospešek Anycast
Drug izdelek, ki vam omogoča delo prek IP-ja anycast, je . Vendar tudi ni na voljo za globalne račune, zato vam o tem ne bom povedal, vendar bi bilo morda koristno vedeti, da tak izdelek obstaja.
Toda test CDN je pokazal nekaj precej zanimivih rezultatov. Tencentovega CDN ni mogoče omogočiti na celotnem spletnem mestu, ampak samo na določenih domenah. Ustvarili smo domene in jim poslali promet:
Izkazalo se je, da ima ta CDN naslednjo funkcijo: Optimizacija čezmejnega prometa. Ta funkcija bi morala zmanjšati stroške, ko promet poteka skozi kitajski požarni zid. Kot izvor Podan je bil naslov IP za Google GLB (GLB anycast). Tako smo želeli poenostaviti arhitekturo projekta.
Rezultati so bili zelo dobri – na ravni Ali Cloud CDN, ponekod celo boljši. To je presenetljivo, kajti če so testi uspešni, lahko opustite pomemben del infrastrukture, tunelov, CEN, virtualnih strojev itd.
Nismo se dolgo veselili, saj se je pokazala težava: pri internetnem ponudniku China Mobile testi v Catchpointu niso uspeli. Od katere koli lokacije smo prejeli časovno omejitev prek Tencentovega CDN. Dopisovanje s tehnično podporo ni privedlo do ničesar. Približno en dan smo poskušali rešiti to težavo, vendar nič ni delovalo.
Takrat sem bil na Kitajskem, vendar v omrežju tega ponudnika nisem našel javnega Wi-Fi-ja, da bi osebno preveril težavo. Sicer je vse izgledalo hitro in dobro.
Ker pa je China Mobile eden izmed treh največjih operaterjev, smo bili prisiljeni vrniti promet na Ali CDN.
Toda na splošno je bila to precej zanimiva rešitev, ki si zasluži daljše testiranje in odpravljanje te težave.
Akamai
Zadnji ponudnik CDN, ki smo ga testirali, je bil Akamai. To je ogromen ponudnik, ki ima svojo mrežo na Kitajskem. Mimo tega seveda nismo mogli.
Že na začetku smo se z Akamai dogovorili za poskusno obdobje, da smo zamenjali domeno in videli, kako bo delovalo v njihovem omrežju. Rezultate vseh testiranj bom opisal v obliki »Kaj mi je bilo všeč« in »Kaj mi ni bilo všeč«, podal pa bom tudi rezultate testiranja.
Kaj mi je bilo všeč:
- Fantje iz Akamai so bili v veliko pomoč pri vseh vprašanjih in nas spremljali na vseh stopnjah testiranja. Nenehno smo poskušali nekaj izboljšati na naši strani. Dali so dobre tehnične nasvete.
- Akamai je približno 10–15 % počasnejši od naše rešitve prek Ali Cloud CDN. Kar je impresivno, je, da smo v Origin for Akamai določili naslov IP GLB-ja, kar pomeni, da promet ni šel skozi našo rešitev (potencialno bi lahko opustili del infrastrukture). Kljub temu so rezultati testa pokazali, da je ta rešitev slabša od naše trenutne različice (primerjalni rezultati spodaj).
- Testiran tako Origin GLB kot Origin na Kitajskem. Obe možnosti sta približno enaki.
- Obstaja Prepričana pot (samodejna optimizacija usmerjanja). Preizkusni objekt lahko gostite na Origin in strežniki Akamai Edge ga bodo poskušali prevzeti (navaden GET). Za te zahteve se merijo hitrost in druge meritve, na podlagi katerih omrežje Akamai optimizira poti, tako da promet za naše spletno mesto poteka hitreje, in jasno je, da je omogočanje te funkcije res močno vplivalo na hitrost spletnega mesta.
- Različico konfiguracije v spletnem vmesniku je kul. Lahko naredite primerjavo za različice, poglejte razl. Oglejte si prejšnje različice.
- Novo različico lahko najprej uvedete samo v omrežju Akamai Staging – istem omrežju kot proizvodnja, le da ta način ne bo vplival na dejanske uporabnike. Za ta preizkus morate ponarediti zapise DNS na vašem lokalnem računalniku.
- Zelo visoka hitrost prenosa prek njihovega omrežja za velike statične datoteke in očitno vse druge datoteke. Datoteka iz "hladnega" predpomnilnika se pridobi večkrat hitreje kot ista datoteka iz "hladnega" predpomnilnika Ali CDN. Iz "vročega" predpomnilnika je hitrost že enaka, plus ali minus.
Ali CDN test:
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/sAkamai test:
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/sOpazili smo, da je stanje v zgornjem primeru odvisno od različnih dejavnikov. V času pisanja te točke sem ponovno izvedel test. Rezultati za obe platformi so bili približno enaki. To nam pove, da se internet na Kitajskem, tudi pri velikih operaterjih in ponudnikih oblakov, občasno obnaša drugače.
K prejšnji točki bom dodal velik plus za Akamai: če Ali pokaže podobne bliskavice visoke in zelo nizke zmogljivosti (to velja za Ali CDN, Ali CEN in Ali IPSEC), potem Akamai vsakič, ne glede kako testiram njihovo omrežje, vse deluje stabilno.
Akamai ima na Kitajskem veliko pokritosti in deluje prek številnih ponudnikov.
Kaj mi ni bilo všeč:
- Ni mi všeč spletni vmesnik in način njegovega delovanja - tako je slab. Ampak v bistvu se navadiš (verjetno).
- Rezultati testa so slabši od našega spletnega mesta.
- Med testi je več napak kot na našem spletnem mestu (spodaj čas delovanja).
- Na Kitajskem nimamo lastnih DNS strežnikov. Zato je v testih veliko napak zaradi časovne omejitve razrešitve DNS.
- Ne zagotavljajo svojih obsegov IP -> pravilnih ni mogoče registrirati set_real_ip_from na naših strežnikih.
Meritve (~3626 izvajanj; vse meritve razen Uptime, v ms; statistika za eno časovno obdobje):
Ponudnik CDN
Mediana
75%
95%
odgovor
Odgovor spletne strani
Uptime
DNS
Connect
Čakaj
Obremenitev
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
Porazdelitev po percentilu (v ms):
Percenttil
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
Zaključek je naslednji: možnost Akamai je izvedljiva, vendar ne zagotavlja enake stabilnosti in hitrosti kot naša lastna rešitev skupaj z Ali CDN.
Majhne opombe
Nekateri trenutki niso bili vključeni v zgodbo, vendar bi rad pisal tudi o njih.
Peking + Tokio in Hong Kong
Kot sem rekel zgoraj, smo testirali predor IPSEC do Hong Konga (HK). Preizkusili pa smo tudi CEN do HK. Stane malo manj in spraševal sem se, kako bo delovalo med mesti z razdaljo ~100 km. Zanimivo se je izkazalo, da je zakasnitev med temi mesti 100 ms višja kot v naši prvotni različici (do Tajvana). Hitrost, stabilnost sta bili tudi boljši za Tajvan. Posledično smo HK pustili kot rezervno regijo IPSEC.
Poleg tega smo poskušali namestiti naslednjo namestitev:
- odpoved strank v Pekingu,
- IPSEC in CEN v Tokio,
- v Ali CDN je bil kot izvor naveden strežnik v Pekingu.
Ta shema ni bila tako stabilna, čeprav glede hitrosti na splošno ni bila slabša od naše rešitve. Glede tunela sem videl občasne padce celo za CEN, ki bi moral biti stabilen. Zato smo se vrnili k stari shemi in to uprizoritev razstavili.
Spodaj so statistični podatki o zakasnitvi med različnimi regijami za različne kanale. Mogoče bo koga zanimalo.
IPsec
Ali cn-peking <—> GCP azija-severovzhod1 — 193 ms
Ali cn-shenzhen <—> GCP asia-east2 — 91ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms
CEN
Ali cn-peking <—> Ali ap-severovzhod-1 — 54ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong — 6ms (!)
Ali cn-shenzhen <—> Ali us-east1 — 216ms
Splošne informacije o internetu na Kitajskem
Kot dodatek k težavam z internetom, opisanim na samem začetku, v prvem delu članka.
- Internet na Kitajskem je znotraj precej hiter.
- Zaključek je bil narejen na podlagi testiranja javnih omrežij Wi-Fi na različnih lokacijah, kjer ta omrežja uporablja veliko število ljudi.
- Hitrosti prenosa in nalaganja na strežnike na Kitajskem so bile približno 20 Mbit/s oziroma 5-10 Mbit/s.
- Hitrost do strežnikov izven Kitajske je preprosto skromna, manj kot 1 Mbit/s.
- Internet na Kitajskem ni zelo stabilen.
- Včasih se lahko spletna mesta odprejo hitro, včasih počasi (ob istem času dneva v različnih dneh), pod pogojem, da se konfiguracija ne spremeni. To smo opazili na primeru semrushchina.cn. To lahko pripišemo Ali CDN, ki tudi deluje tako in tako glede na uro dneva, položaj zvezd ipd.
- Mobilni internet je skoraj povsod 4G ali 4G+. Ujemite ga v metroju, dvigalih – skratka povsod.
- Mit je, da kitajski uporabniki zaupajo le domenam v območju .cn. To smo izvedeli neposredno od uporabnikov.
- Lahko vidite, kako preusmeritev na www.baidu.com (tudi v celinski Kitajski).
- Veliko virov je res blokiranih. Primitivni: google.com, Facebook, Twitter. Toda veliko Googlovih virov deluje (seveda ne na vseh Wi-Fi in VPN se ne uporablja (tudi na strani usmerjevalnika, to je zagotovo).
- Delujejo tudi številne "tehnične" domene blokiranih korporacij. To pomeni, da ne smete vedno nepremišljeno izrezati vseh Googlovih in drugih na videz blokiranih virov. Morate poiskati seznam prepovedanih domen.
- Imajo samo tri glavne internetne operaterje: China Unicom, China Telecom, China Mobile. Obstajajo še manjši, vendar je njihov tržni delež zanemarljiv
Bonus: diagram končne rešitve
Skupaj
Minilo je leto dni od začetka projekta. Začeli smo z dejstvom, da naše spletno mesto na splošno ni hotelo normalno delovati s Kitajske, preprosto GET curl pa je trajalo 5.5 sekunde.
Nato s temi indikatorji v prvi rešitvi (Cloudflare):
odločitev
Uptime
Mediana
75 percentil
95 percentil
Cloudflare
86.6
18s
30s
60s
Na koncu smo dosegli naslednje rezultate (statistika za zadnji mesec):
odločitev
Uptime
Mediana
75 percentil
95 percentil
Ali CDN + CEN/IPsec + GLB
99.86
8.8s
9.5s
13.7s
Kot lahko vidite, nam še ni uspelo doseči 100% uptime, vendar se bomo nekaj domislili, nato pa vam bomo o rezultatih povedali v novem članku :)
Spoštovanje tistim, ki ste prebrali vse tri dele do konca. Upam, da se vam je vse to zdelo tako zanimivo, kot je bilo meni, ko sem to naredil.
PS Prejšnji deli
Vir: www.habr.com