🥇Kako smo probili Veliki Kineski Vatrozid (č.3)

Pozdrav!
Svaka dobra priča dolazi do kraja. I naša priča o tome kako smo smislili rješenje za brzo prolazak kroz Kineski Vatrozid nije iznimka. Stoga žurim podijeliti s vama posljednji, završni dio o ovoj temi.

U prethodnom dijelu govorili smo o brojnim testnim postavkama koje smo stvorili i kakvi su rezultati proizašli iz njih. I zaustavili smo se na tome da bi bilo dobro dodati CDN! za gustoću u našu shemu.

Reći ću vam kako smo testirali Alibaba Cloud CDN, Tencent Cloud CDN i Akamai, i na kojoj smo se na kraju odlučili. I naravno, napravit ćemo rezime.

Alibaba Cloud CDN

Hostamo se na Alibaba Cloudu, koristimo IPSEC i CEN od njih. Ima smisla prvo isprobati njihova rješenja.

Alibaba Cloud nudi dva proizvoda koja bi nam mogla odgovarati: CDN i DCDN. Prva opcija predstavlja klasični CDN za određenu domenu (poddomen). Druga opcija se dešifrira kao Dynamic Route for CDN (ja ga nazivam dinamički CDN), može se uključiti u režimu Full-site (za wildcard domene), također kešira statiku i ubrzava dinamički sadržaj, što znači da će se i dinamika stranice učitavati putem brzih mreža pružatelja. Ovo je važno za nas jer je naš sajt uglavnom dinamičan, koristi mnogo poddomena i lakše je postaviti CDN jednom za “zvjezdicu” — *.semrushchina.cn.

Već smo vidjeli ovaj proizvod u ranijim fazama našeg kineskog projekta, ali tada nije radio, a developeri su obećali da će proizvod uskoro postati dostupan za sve klijente. I konačno je postao.

U DCDN možete:

konfigurirati SSL terminaciju sa svojim certifikatom,
uključiti ubrzavanje dinamičkog sadržaja,
fleksibilno konfigurirati keširanje statičkih datoteka,
brisati keš,
propuštati web-sokete,
uključiti kompresiju i čak HTML Beautifier.

Ukratko, sve kao kod velikih i ozbiljnih CDN pružatelja.

Nakon što je izvor (mjesto na koje idu CDN edge serveri) označen, sljedeće je stvoriti CNAME za zvjezdicu, koji upućuje na all.semrushchina.cn.w.kunluncan.com (ovaj CNAME je dobiven u konzoli Alibaba Clouda), i CDN će početi raditi.

Prema rezultatima testova, ovaj CDN nam je zaista pomogao. Statistika je navedena u nastavku.

Rešenje
Uptime
Medijan
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 su jako dobri rezultati, posebno ako ih usporedimo s onima na početku. No, znali smo da američka verzija našeg web mjesta www.semrush.com u prosjeku izvršava preglednički test iz SAD-a za 8,3 s (vrlo približna vrijednost). Ima mjesta za poboljšanje. Osim toga, postojali su i CDN pružatelji koje je bilo zanimljivo testirati.

Tako polako prelazimo na još jednog giganta na kineskom tržištu — Tencent.

Tencent Cloud

Tencent tek razvija svoje oblačne usluge — to se može primijetiti po malom broju proizvoda. Tijekom korištenja, željeli smo testirati ne samo njihov CDN, već i općenito mrežnu infrastrukturu:

imaju li nešto slično CEN-u?
kako im radi IPSEC? Je li brzo, koja je dostupnost?
imaju li Anycast?

Ova pitanja ćemo obraditi pojedinačno.

Analog CEN-a

Tencent ima proizvod Cloud Connect Network (CCN), koji omogućuje povezivanje VPC-a iz različitih regija, uključujući regije unutar Kine i izvan nje. Proizvod je trenutno u unutarnjoj beta fazi i potrebno je otvoriti tiket s zahtjevom za pristup. Od podrške smo saznali da globalni računi (ne radi se o građanima Kine i nepravnim osobama) ne mogu sudjelovati u beta testiranju i općenito povezati regiju unutar Kine s regijom izvan nje. 1-0 za Ali Cloud.

IPSEC

Najjužnija regija kod Tencenta — Guanhzhou. Stvorili smo tunel i povezali ga s regijom Hong Kong u GCP (tada je ta regija već bila dostupna). Također smo istovremeno podigli drugi tunel u Ali Cloudu iz Shenzhena u Hong Kong. Ispostavilo se da je latencija putem Tencent mreže do Hong Konga općenito bolja (10ms) nego iz Shenzhena u Hong Kong u Ali (120ms — što?). No to nije ubrzalo rad web mjesta koje je usmjereno na rad preko Tencenta i ovog tunela, što je samo po sebi bio fascinantan podatak i još jednom je dokazalo sljedeće: latencija — za Kinu to nije pokazatelj na koji stvarno treba obratiti pažnju prilikom razvoja rješenja za prolazak kineskog vatrozida.

Anycast Internet Acceleration

Još jedan proizvod koji omogućuje rad putem anycast IP-a — AIA. No, također nije dostupan globalnim računima, pa o njemu neću govoriti, ali znati da takav proizvod postoji može biti korisno.

Test CDN-a pokazao je prilično zanimljive rezultate. CDN kod Tencenta ne može se uključiti na full-site, samo na određene domene. Registrirali smo domene i usmjerili promet na njih:

Ispostavilo se da ovaj CDN ima takvu funkcionalnost: Optimizacija prekograničnog prometa. Ova funkcija trebala bi smanjiti troškove prilikom prolaska prometa kroz kineski vatrozid. Kao Izvor navedena je IP adresa Googleovog GLB-a (GLB anycast). Tako smo željeli pojednostaviti arhitekturu projekta.

Rezultati su bili jako dobri — na razini Ali Cloud CDN, a katkad čak i bolji. To je iznenađujuće, jer u slučaju uspjeha testova, mogli bismo se odreći značajnog dijela infrastrukture, tunela, CEN, virtualki itd.

Nismo se dugo radovali, jer se pojavila problematika: testovi u Catchpointu su neuspjeli za internet-provajdera China Mobile. Iz bilo koje lokacije smo dobijali timeout putem Tencent CDN-a. Dopisivanje s tehničkom podrškom nije dovelo do rješenja. Oko jednog dana smo pokušavali riješiti ovaj problem, ali ništa nije uspjelo.

U tom trenutku sam bio u Kini, ali nisam mogao pronaći javni Wi-Fi mreže ovog provajdera kako bih se osobno uvjerio u problem. Inače je sve izgledalo brzo i dobro.
Međutim, s obzirom na to da je operater China Mobile jedan od tri najveća operatera, bili smo prisiljeni vratiti promet na Ali CDN.
No, općenito govoreći, to je bila prilično zanimljiva solucija koja zaslužuje duže testiranje i rješavanje problema.

Akamai

Posljednji CDN-provajder kojeg smo testirali je Akamai. To je veliki provajder koji ima svoju mrežu u Kini. Naravno, nismo mogli zaobići njih.

Od samog početka smo se dogovorili s Akamai-om o probnom razdoblju, kako bismo mogli prebaciti domenu i vidjeti kako će raditi na njihovoj mreži. Rezultat svih testova opisat ću u obliku 'Što nam se svidjelo' i 'Što nam se nije svidjelo', a također ću navesti rezultate testova.

Što nam se svidjelo:

Ekipa iz Akamai-a bila je od velike pomoći u svim pitanjima i pratila nas na svim fazama testiranja. Stalno su pokušavali unaprijediti sve s njihova aspekta. Davali su dobre tehničke savjete.
Akamai radi otprilike 10-15% sporije od našeg rješenja putem Ali Cloud CDN-a. Impresivno je što smo u Origin za Akamai naveli IP adresu GLB-a, što znači da promet nije prolazio kroz naše rješenje (potencijalno bismo se mogli odreći dijela infrastrukture). No, rezultati testova pokazali su da je ova opcija rješenja lošija od našeg trenutnog rješenja (usporedni rezultati dolje).
Testirani su i Origin GLB i Origin u Kini. Obje opcije su otprilike jednake.
Postoji Sigurna ruta (automatska optimizacija usmjeravanja). Možete postaviti testni objekt na Origin, a Edge serveri Akamai će pokušati preuzeti (uobičajeni GET). Za te zahtjeve mjeri se brzina i druge metrike, na temelju čega Akamai mreža optimizira rute kako bi promet bio brži za našu stranicu i bilo jasno da uključivanje ove značajke doista značajno utječe na brzinu rada stranice.
Verzioniranje konfiguracije u web sučelju je sjajno. Možete napraviti usporedbu verzija, pogledati diff. Pregledajte prethodne verzije.
Možete implementirati novu verziju najprije samo na Staging mrežu Akamai — to je ista mreža kao i produkcija, ali taj put ne utječe na stvarne korisnike. Za ovu provjeru potrebno je napraviti spoofing DNS zapisa na lokalnom računalu.
Vrlo brza brzina učitavanja putem njihove mreže velike statike, pa i, očito, bilo kojih drugih datoteka. Datoteka iz 'hladnog' predmemoriranja se preuzima višestruko brže nego ista datoteka iz 'hladnog' predmemoriranja Ali CDN-a. Iz 'vrućeg' predmemoriranja brzina je već manje-više ista.

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  Prosječna brzina   Vrijeme    Vrijeme     Vrijeme  Trenutno
                                 Preuzmi  Uploada   Ukupno   Provedeno   Preostalo  Brzina
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 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  Prosječna brzina   Vrijeme    Vrijeme     Vrijeme  Trenutno
                                 Preuzmi  Uploada   Ukupno   Provedeno   Preostalo  Brzina
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

Primijetili smo da situacija iz gornjeg primjera ovisi o različitim faktorima. U trenutku pisanja ovog odlomka ponovno sam izvršio test. Rezultati za obje platforme su se pokazali otprilike istima. To nam govori da se internet u Kini čak i za velike operatore i pružatelje oblaka povremeno ponaša različito.

Za prethodnu točku dodajem veliku prednost Akamai-a: ako se kod Ali-a vide ovakvi iznenadni visoki performansi i vrlo niska (to se odnosi i na Ali CDN, i na Ali CEN, i na Ali IPSEC), kod Akamai-a svaki put, bez obzira koliko testiram njihovu mrežu, sve radi stabilno.
Akamai doista ima veliko pokriće u Kini i radi s mnogim provajderima.

Što se nije svidjelo:

Ne sviđa mi se web sučelje i način rada — potpuno su bez veze. No u načelu se navikneš (vjerojatno).
Rezultati testova su lošiji od naše platforme.
Pogrešaka pri testovima je više nego na našoj platformi (uptime je niži).
Nemaju vlastite DNS poslužitelje u Kini. Odavde dolazi mnogo grešaka u testovima zbog DNS resolve timeout.
Ne pružaju svoje IP opsege -> nema mogućnosti ispravno postaviti set_real_ip_from na našim poslužiteljima.

Metrike (~3626 iščitanja; sve metrike, osim Uptime, u ms; statistika za jedan termin):

CDN pružatelj
Medijan
75%
95%
Response
Odgovor web stranice
Uptime
DNS
Povezivanje
Čekanje
Load
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

Distribucija po Percentile (u ms):

Percentil
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

Zaključak je sljedeći: opcija s Akamai-om je održiva, ali ne daje iste pokazatelje stabilnosti i brzine kao naše vlastito rješenje u kombinaciji s Ali CDN-om.

Male napomene

Neki aspekti nisu uključeni u pripovijest, ali želio bih ih također spomenuti.

Peking + Tokio i Hong Kong

Kao što sam već spomenuo, testirali smo IPSEC tunel do Hong Konga (HK). Ali također smo testirali i CEN do HK. Malo je jeftiniji, i bilo je zanimljivo vidjeti kako će raditi između gradova udaljenih ~100km. Zanimljivo je bilo da je latencija između tih gradova 100ms viša nego u našem prvotnom rješenju (do Tajvana). Brzina i stabilnost također su bile bolje za Tajvan. Na kraju, ostavili smo HK kao rezervni IPSEC region.

Osim toga, pokušali smo uspostaviti takvu instalaciju:

terminiranje klijenata u Pekingu,
IPSEC i CEN do Tokija,
u Ali CDN-u je naveden kao origin server u Pekingu.

Ova shema nije bila tako stabilna, iako po brzini u cjelini nije zaostajala za našim rješenjem. Što se tiče tunela, vidio sam povremene padove čak i za CEN koji bi trebao biti stabilan. Stoga smo se vratili na staru shemu i rasklopili ovaj staging.

Ispod je statistika o latenciji između različitih regija kroz različite kanale. Možda će nekome biti zanimljiva.

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

Opće informacije o internetu u Kini

Kao dodatak problemima s internetom, opisanim na početku, u prvom dijelu članka.

Internet u Kini radi prilično brzo unutar zemlje.
- Zaključak je donesen na temelju testiranja javnih Wi-Fi mreža na različitim lokacijama gdje te mreže koriste veliki broj ljudi.
- Brzina preuzimanja i prijenosa na servere unutar Kine bila je oko 20 Mbps odnosno 5-10 Mbps.
- Brzina do servera izvan Kine je jednostavno mizerno mala, ispod 1 Mbps.
Internet u Kini nije vrlo stabilan.
- Ponekad se web stranice mogu otvarati brzo, a ponekad sporo (u isto doba dana različitih dana), pod uvjetom da konfiguracija ostaje nepromijenjena. To smo primijetili na primjeru semrushchina.cn. To se može pripisati Ali CDN-u, koji također radi različito ovisno o doba dana, položaju zvijezda itd.
Mobilni internet je gotovo svugdje 4G ili 4G+. Signal se hvata u metrou, liftovima — jednostavno svugdje.
Mit je da kineski korisnici vjeruju samo domenama u zoni .cn. To smo saznali izravno od korisnika.
- Može se vidjeti kako http://baidu.cn preusmjerava na www.baidu.com (također u mainland Kini).
Mnogi resursi su zaista blokirani. Pritom, jednostavno: google.com, Facebook, Twitter. No, mnogi Googleovi resursi rade (naravno, ne na svim Wi-Fi mrežama i VPN se tada ne koristi (na strani usmjerivača također, to je sigurno).
Mnogi 'tehnički' domene blokiranih korporacija također rade. To znači da nije uvijek potrebno bez razmišljanja uklanjati sve Google-ove i druge resurse koji se čine blokiranim. Treba potražiti neku listu zabranjenih domena.
Imamo tri glavna pružatelja internetskih usluga: China Unicom, China Telecom, China Mobile. Postoji još nekoliko manjih, ali njihov tržišni udio je neznatan.